Неделя 130. Канун большого взрыва: трубы для CRM, первые глаза и мост, который убедил строить свой дом

У читателей этой серии есть преимущество, которого не было у меня: вы уже знаете, что случится дальше. В выпуске о неделе 131 я рассказывал про три ставки, сделанные за семь дней: ИИ-агент в коде, собственная CRM, сайт за выходные. Сегодня отматываю на неделю раньше, на 26 января - 1 февраля 2026 года, и это редкий жанр: неделя накануне решений. Ставки ещё не сделаны. Но если присмотреться к коммитам, видно, как жизнь уже раскладывает карты: каждая история недели 130 закончится развилкой недели 131.

Я Дмитрий Дьяконов, основатель Botseller AI. Это десятый выпуск серии «Ретроспектива», бортжурнал в прошлое: от настоящего к первому коммиту. Неделя 130 была тишайшей неделей той зимы: 38 коммитов против 95 на следующей. По моим тогдашним ощущениям, ничего особенного не происходило: чинили, подключали, прокладывали. А из будущего видно, что именно эта тихая неделя сделала возможным всё громкое потом. Трубы, глаза и мост: разберу все три стройки, и почему каждая была выбором, хотя выбором тогда не выглядела.

Контекст: что было к началу недели

Конец января 2026 года. Продукту полгода, боты отвечают клиентам в мессенджерах, есть личный кабинет и первые платящие клиенты. Новая CRM существует как прототип под одного клиента и живёт отдельно от движка диалогов: два мира, между которыми ходят письма без адресата. На проде мы подслеповаты: логи есть, но искать в них ошибку это археология, а о проблемах чаще сообщают клиенты, чем система. И фоном месяца тянется уборка после одного январского вечера с каскадными удалениями в базе, о котором будет отдельный выпуск: скажу лишь, что с тех пор слово CASCADE в нашем коде читается как ругательство.

Вторник, 06:19: трубы до парадного входа

Самый важный коммит недели случился во вторник в 06:19 утра и назывался буднично: «Полная обвязка ядра и новой CRM». Пять файлов, полторы сотни строк. Если пропустить его в git log, ничего не заметишь. А это, возможно, главные полторы сотни строк той зимы: движок диалогов и новая CRM впервые стали одной системой.

Развилка здесь была архитектурная, и я хочу проговорить её словами, потому что она встречается каждому, кто прикручивает к продукту вторую большую подсистему. Вариант первый: CRM живёт сбоку. Отдельный сервис, общается с ядром по API, как чужой. Так проще начать и так «правильнее» по учебнику. Вариант второй: CRM живёт в сердце. Ядро диалогов знает о ней напрямую: каждый диалог умеет рождать лида, каждый лид знает свой диалог. Так больше связности и страшнее менять, но продукт становится единым организмом, а не федерацией сервисов.

Мы выбрали сердце, и обвязка вторника была этим выбором, просто без торжественных слов. Через день подтянулись эндпоинты создания заказчика, потом создание заказчика в CRM при первой выгрузке воронки: трубы, вентили, стыки. Из будущего виден весь смысл: когда через неделю у платформы появится кнопка «включить CRM», ей будет что включать. Парадный вход, у которого мы потом перерезали ленточку тремя коммитами за пять минут, был бы декорацией без этих утренних труб. Урок, который я отсюда унёс: у каждого «рождения фичи» есть неделя-предшественник, которую никто не празднует. Если её не заложить, праздновать будет нечего.

Вторник и среда, вечерами: у системы появляются глаза

Вторая стройка недели шла по вечерам, после основной работы: во вторник с шести до восьми, в среду до одиннадцатого часа. Тринадцать коммитов и две с лишним тысячи строк в проект, которого раньше толком не было: мониторинг. Метрики всех серверов, дашборды, проверка доступности сервисов снаружи, первый настоящий алерт: «личный кабинет лёг». Утром в среду, до начала рабочего дня, по всем сервисам стандартизировались метки логов: чтобы ошибку можно было найти одним запросом, а не археологией.

Здесь развилка того сорта, где неправильный выбор делается по умолчанию. Мониторинг не продаёт. Клиент не заплатит за дашборд, инвестор не спросит про алерты, в списке хотелок он вечно проигрывает любой фиче. Правильный вопрос, который заставил нас всё-таки потратить эти два вечера, звучал так: сколько стоит час, в течение которого прод лежит, а мы об этом не знаем? После пары эпизодов, когда о проблемах нам сообщали клиенты, ответ стал очевиден.

Той же средой закрылась история про шум: система отчётов об ошибках на фронте генерировала до двадцати исключений в день на ровном месте, в основном от штатных сценариев вроде протухшего токена. Их приглушили до почти нуля. Это менее эффектно, чем новые дашборды, но важнее: сигнализация, которая орёт постоянно, хуже отсутствия сигнализации, потому что учит всех её игнорировать.

А теперь моя любимая часть, ради которой существует ретроспектива. Система, собранная в эти два вечера, через три недели первой увидит шторм на семьдесят тысяч сообщений в очереди и превратит потенциальную катастрофу в разобранный за вечер инцидент. Когда я делал эти коммиты, я не знал, что покупаю. Оказалось: три недели форы.

Четверг и пятница: мост к чужому дому

Третья стройка выглядела самой «продуктовой»: самообслуживание для подключения Битрикс24. Раньше подключение чужой CRM было ручной работой с нашим участием. Теперь: клиент нажимает кнопку, получает ссылку установки, ставит интеграцию в своём Битрикс24, выбирает, куда складывать результат, в лиды или в сделки, а календарная стратегия заполняется сама. Упрощённый визард вместо анкеты. К пятнице мост стоял.

И вот что я понимаю, перечитывая ту неделю: именно на этом мосту созрело решение следующей. Мы честно вложили два дня в дорогу на чужую территорию, и с каждым шагом становилось яснее, как эта территория устроена: чужие правила, чужие лимиты, чужие сущности, под которые надо подстраиваться. Строишь неделю, а владеешь в итоге не ты. Через четыре дня после этого моста, во вторник 131-й недели, я в последний раз обновлю инструкцию по чужой CRM, а в среду мы начнём строить свою. Мост при этом никто не сжёг: он работает до сих пор, по нему мы отлаживали удаление лидов через пару недель, и у нас есть целый гайд по интеграции с Битрикс24. Разница в статусе: мосты нужны, но жить лучше в своём доме.

Четверг, 13:26: первая трещина

Внутри моста нашлась история, которую читатели серии узнают по почерку. В четверг в 13:26 лёг коммит с пометкой SECURITY: эндпоинт списка интеграций Битрикс24 возвращал все интеграции в системе, игнорируя, какому заказчику они принадлежат. Фильтр по клиенту просто не был подключён к запросу. Починили за 24 строки: параметр заказчика теперь обязателен и доходит до самого запроса в базу.

Если вы читали выпуск о неделе 132, у вас сейчас дежавю, и оно оправданно: через две недели похожая логика, только уже в общем слое доступа к данным, чуть не открыла одному пользователю данные всех компаний. Та самая «дверь без замка». Глядя назад, я вижу в четверговом фиксе первую трещину этого рода: изолированный случай, который мы починили точечно и не спросили себя, где ещё живёт этот же паттерн. Спросили бы, возможно, не было бы вторника 132-й. Отсюда правило, которое я теперь применяю к любому багу с пометкой SECURITY: чинишь дыру, ищи её сестёр. Один и тот же дефект почти никогда не живёт в одном месте: его писала одна и та же голова в одном и том же стиле.

Пятница, 15:07: рассылки за двенадцать минут

В пятницу днём, с 15:07 до 15:19, в трёх сервисах синхронно приземлился один и тот же заголовок: «MVP логика для рассылки сообщений через CRM». Движок CRM, канал WhatsApp, ядро. Двенадцать минут, три репозитория, первый работающий прототип массовых рассылок: выбрать клиентов в CRM, отправить сообщение, обновить карточку лида.

Слово MVP здесь стоит воспринимать буквально: минимальный, живой, некрасивый. Читатели серии знают продолжение этой саги лучше меня тогдашнего: через неделю логика переродится в ядре с очередями и периодическими задачами, ещё через неделю появится витрина на выдуманных данных, а через месяц настоящий модуль на восемь тысяч строк. Четыре версии за месяц. Когда я впервые увидел эту цепочку целиком в git log, мне стало смешно: я бы рассказывал эту историю как «мы спланировали эволюцию фичи». Не спланировали. Каждая версия отвечала на вопрос, который задала предыдущая: MVP проверил спрос, ядро выдержало нагрузку, витрина показала сценарий, модуль собрал всё вместе. Планом это стало задним числом, и, честно говоря, все мои лучшие «планы» устроены именно так.

Мелочи с характером

Две маленькие детали той недели я храню как музейные экспонаты. Первая: в перечислении стратегий бота обнаружилось значение «Без дожимов». Не ключ, не подпись для интерфейса, а само значение в коде: русская строка с пробелом в роли системной константы. Работало? Работало. До момента, когда перестало. Заменили на честное no_crm, и с тех пор у меня рефлекс: если строка из интерфейса просочилась в код как константа, где-то рядом прячется баг с её сравнением.

Вторая деталь тише, но с историей: из базы убирались каскадные удаления. Это отголосок того самого январского вечера, когда одна команда удаления утянула за собой связанные таблицы. Подробности прибережём для соответствующего выпуска, но след в неделе 130 показателен: настоящая цена инцидента это не вечер восстановления, а недели зачистки всех мест, где заложена та же мина.

Урок недели: скорость покупается заранее

Неделя 130 научила меня различать два вида работы, которые в моменте ощущаются одинаково, а стоят по-разному.

Есть работа-расход: закрыл задачу, получил результат, потратил день. И есть работа-покупка: потратил тот же день, а купил скорость будущих недель. Обвязка ядра и CRM была покупкой: без неё «рождение платформы» на 131-й осталось бы красивым коммитом без содержания. Два вечера мониторинга были покупкой: они превратили будущий шторм из катастрофы в инцидент. Даже мост к Битрикс24 был покупкой, хотя купил неожиданное: ясность, что свой дом нужен.

Практический вывод для тех, кто ведёт свой продукт: тихие недели не случаются сами, их надо разрешать себе. Мой критерий с тех пор простой: раз в несколько недель я спрашиваю, что сломается первым, если завтра темп вырастет вдвое. И чиню это до того, как темп вырос. На неделе 130 ответами были «связка ядра с CRM», «слепота на проде» и «ручное подключение интеграций». Через семь дней темп действительно вырос вдвое: 95 коммитов, три ставки, большой взрыв. Выдержали, потому что трубы уже лежали.

Цифры недели

• 38 коммитов в восьми проектах: самая тихая неделя зимы
• Около 4900 добавленных строк, из них 2358: мониторинг за два вечера
• 06:19: время самого важного коммита недели, обвязка ядра и CRM
• 24 строки: фикс SECURITY, первая трещина изоляции данных
• С 20 до почти нуля: шумовые исключения фронта в день после чистки
• 12 минут и 3 сервиса: MVP рассылок в пятницу
• 1 алерт, который окупится через три недели: «личный кабинет лёг»
• 0 коммитов в сайт: его ещё не существует, он родится в следующую пятницу

Что было дальше

Дальше была неделя 131: три ставки за семь дней, ИИ-агент в коде, рождение BotsellerCRM тремя коммитами за пять минут и сайт за выходные. Трубы недели 130 получили свою кнопку, мост к чужой CRM подтолкнул к строительству собственной, а глаза, вставленные за два вечера, через три недели первыми увидят шторм. Тихая неделя оказалась фундаментом громких.

Все выпуски серии собраны в категории ретроспектива, а текущая хроника разработки продолжается в бортовом журнале.

FAQ

Что такое ретроспектива Botseller?

Серия «Ретроспектива», бортжурнал в прошлое: от настоящего к первому коммиту. Каждый выпуск разбирает одну неделю разработки платформы по реальным git-логам, с фокусом на развилки: почему выбрали именно эту задачу, какие были альтернативы и как решение развернулось спустя месяцы. Все выпуски собраны в категории ретроспектива.

Зачем маленькой команде мониторинг и с чего начать?

Затем, что без него о падениях сообщают клиенты, и каждый такой эпизод стоит дороже, чем весь мониторинг. Разумный минимум для старта: метрики серверов, проверка доступности ключевых сервисов снаружи и один-два алерта на действительно критичные события вроде «личный кабинет недоступен». Важно сразу бороться с шумом: сигнализация, которая срабатывает по десять раз в день на штатные события, приучает себя игнорировать.

Как ИИ-бот подключается к Битрикс24?

В режиме самообслуживания: клиент получает ссылку установки, ставит интеграцию в своём портале Битрикс24 и выбирает, куда бот складывает результат работы, в лиды или в сделки. Дальше бот ведёт переписку и синхронизирует данные автоматически. Подробный разбор со скриншотами есть в гайде по интеграции с Битрикс24.

Что значит «обвязка» и зачем соединять бота и CRM на уровне ядра?

Обвязка это код, который соединяет две подсистемы в одну: движок диалогов начинает знать о CRM, а CRM о диалогах. Альтернатива, держать CRM отдельным сервисом за API, проще на старте, но тогда каждый сценарий «диалог рождает лида» требует лишних вызовов и синхронизации. Связка на уровне ядра позволяет боту создавать лида прямо из переписки и держать историю общения в карточке без двойного ввода, как в нашей простой CRM для малого бизнеса.

Как быстро проверить спрос на фичу, не строя её целиком?

Сделать минимальную живую версию на реальных данных и дать её реальным клиентам. Наши массовые рассылки прошли четыре версии за месяц: MVP за день, движок с очередями, интерфейс на выдуманных данных, полноценный модуль. Каждая версия отвечала на один вопрос: есть ли спрос, держит ли нагрузку, удобен ли сценарий. Это дешевле, чем строить сразу идеальное и месяц спустя узнать, что сценарий не тот.

Почему баги изоляции данных стоит искать пачкой, а не чинить по одному?

Потому что один и тот же дефект редко живёт в одном месте: его писала одна голова в одном стиле. Если эндпоинт забыл фильтр по клиенту, с высокой вероятностью есть соседние эндпоинты с тем же пропуском. Починив точечно, вы закрываете симптом; поиск «сестёр» бага по всей базе кода закрывает класс проблемы. Мы усвоили это на собственном опыте: точечный фикс на неделе 130 не уберёг от большой дыры той же природы двумя неделями позже.