← Все материалы

Поддержка после внедрения: что ломается в системе на третий месяц

Поддержка после внедрения — это не строчка в смете «на всякий случай», а признание простого факта: автоматизация живёт внутри чужих систем, которые меняются без предупреждения. Токен истекает, метод API убирают, в CRM добавляют обязательное поле, сайт-источник переверстают — и рабочая система тихо перестаёт работать. Ниже — что именно ломается, почему это не гарантийный случай и сколько стоит держать всё живым.

Что происходит с системой после сдачи

В день сдачи всё честно работает: интеграция гоняет данные, парсер приносит прайсы, отчёт собирается к девяти утра, агент отвечает клиентам. Это состояние стабильно ровно до первого изменения снаружи. И изменения приходят не от вас — их приносят вендор CRM, разработчики сайта-источника, бухгалтер, который обновил 1С, и админ, который отключил учётку уволенного сотрудника.

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

Что ломается чаще всего

Список короткий и повторяется из проекта в проект. Технические причины у всего этого разные, и чинятся они по-разному — от пяти минут до пары дней.

Что ломается	Техническая причина	Как проявляется	Что делать
Авторизация в CRM	истёк refresh-токен: у Битрикс24 access живёт 1 час, refresh — 180 дней; у amoCRM access 3 месяца, refresh — год	все запросы отдают 401, данные не идут ни в одну сторону	автопродление токена по 401 плюс алерт, если refresh мёртв — нужна повторная авторизация человеком
Метод API исчез или изменился	вендор задепрекейтил метод, поменял формат ответа или состав полей в вебхуке	ошибка на одном шаге, остальное работает — заметить труднее всего	проверка ответа по схеме, а не «как получилось», и чтение changelog вендора
Новые поля в CRM	добавили обязательное поле, переименовали воронку, удалили этап — код пишет в id, которого больше нет	сделки не создаются или создаются без части данных	маппинг полей вынести в настройку, а не в код; проверка справочников при запуске
Лимиты и блокировки	у Битрикс24 — 2 запроса в секунду, пакет до 50 команд, суточный лимит по тарифу; вырос поток — упёрлись	часть операций теряется, в логе 503 и отказы	очередь с ретраями и паузами, батчинг, ночная обработка тяжёлого
Съехала вёрстка при парсинге	разработчики источника поменяли шаблон, CSS-селекторы и XPath возвращают пустоту	парсер отработал «успешно» и принёс ноль строк	проверка на подозрительный ноль, эталонные записи, устойчивые селекторы
Обновление 1С	типовую обновили, доработка или внешняя обработка опиралась на изменённый метод	обмен с сайтом или выгрузка останавливаются в тот же день	фиксировать доработки расширением, проверять обмен на копии до обновления
Секреты и доступы	сменили пароль SMTP, отключили учётку уволенного, истёк сертификат или домен	письма не уходят, интеграция «не видит» систему	инвентарь доступов с ответственными, технические учётки вместо личных
Изменилась модель ИИ	провайдер снял версию с поддержки или сменил поведение, промпт перестал давать прежний формат	агент отвечает иначе, разбор перестаёт попадать в поля	фиксировать версию модели, держать набор проверочных примеров
Выросли данные	скрипт, который работал 2 минуты на тестовом объёме, теперь работает 40 и падает по таймауту	задача не доходит до конца, отчёт пустой или обрезанный	постраничная обработка, докачка с места обрыва, вынос в фон

Отдельно про токены, потому что это причина номер один. Схема с автоматическим продлением по ошибке 401 закрывает 90 % случаев, но не все: если интеграция простояла дольше срока жизни refresh-токена — например, систему выключали на переезд — продлевать уже нечего, и требуется живой человек, который заново нажмёт «разрешить» в интерфейсе CRM. Это не баг, это устройство OAuth, и в инструкции по эксплуатации такой пункт должен быть заранее.

Почему это не гарантийный случай

Разговор про поддержку часто начинается с вопроса «а разве это не гарантия?». Граница простая и я её проговариваю до подписания.

• Гарантия — на мой код. Если система делает не то, что согласовано, или падает на данных, которые были при приёмке, это исправляется бесплатно. Обычный срок — 1–3 месяца после сдачи.
• Поддержка — на изменения среды. Вендор убрал метод, источник переверстали, у вас в CRM появилась новая воронка — работоспособность приходится восстанавливать заново. Это новая работа, а не исправление брака.
• Доработки — это доработки. «Добавьте ещё один отчёт и поле» — не поломка, считается отдельно, обычно по часам.
• Изменения на вашей стороне. Сменили тариф CRM, переехали на другую телефонию, обновили 1С — предупреждать лучше до, а не после.

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

Форматы поддержки и цены

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

Формат	Что входит	Реакция	Цена
Разовые правки по факту	починка, когда сломалось; мелкие доработки по запросу; ничего не мониторится	по договорённости, обычно 1–3 рабочих дня — я могу быть занят другим проектом	от 2 500 ₽/час, типовая поломка — 1–4 часа
Абонентское сопровождение	мониторинг и алерты, продление токенов и сертификатов, починка сбоев, обновление под изменения API и вёрстки, 4–10 часов правок в месяц, ежемесячный отчёт	критичное — в течение рабочего дня, остальное — до 2–3 дней	от 15 000 ₽/мес; сложная связка нескольких систем — 30–60 тыс. ₽/мес
Передача в штат	документация, схема связей, инвентарь доступов, разбор кода с вашим разработчиком, 2–4 недели консультаций на подхвате	дальше вы сами, я — вторая линия по запросу	работа по часам от 2 500 ₽; типовая передача 30–80 тыс. ₽ разово

Разовые правки честно подходят большему числу проектов, чем принято говорить. Если парсер собирает цены конкурентов раз в неделю и день без данных ничего не решает — платить абонплату незачем, дешевле починить по факту. Абонент нужен там, где простой виден клиентам или останавливает деньги: заявки с сайта в CRM, выгрузка заказов, бот, который принимает записи, обмен с 1С в конце месяца.

Передача в штат — нормальный и правильный финал для компании, у которой появился свой разработчик. Тут важно, чтобы передавать было что: не архив со скриптами, а репозиторий, конфиг с секретами вне кода, README с описанием запуска и списком внешних зависимостей. Если этого нет, передача превращается в реверс-инжиниринг за ваши деньги.

Когда сопровождение можно не брать

Скажу прямо: часть проектов на абонплате не нуждается, и предлагать её всем — способ продать воздух. Отказаться от постоянного сопровождения нормально, если совпадают три условия.

• День простоя ничего не стоит. Парсер цен конкурентов раз в неделю, отчёт для себя, разовая выгрузка — почините через два дня и ничего не потеряете.
• Внешних зависимостей мало. Скрипт на Python, который читает Excel и складывает результат в другой Excel, ломаться просто нечему: там нет ни токенов, ни чужой вёрстки, ни лимитов API.
• Есть свой человек. Системный администратор или разработчик, который может перезапустить задачу, посмотреть лог и обновить авторизацию по инструкции.

Но даже в этом случае стоит один раз поставить наблюдение и алерт. Мониторинг — это разовая работа, а не абонплата, и он отделяет «сломалось на день» от «сломалось в мае, заметили в июле».

Мониторинг: как узнавать о поломке не от клиента

Разница между «сломалось на пять минут» и «сломалось на неделю» — это не квалификация исполнителя, а наличие наблюдения. Схема простая и стоит один-два дня работы при внедрении.

• Сигнал жизни. Каждая регулярная задача отмечается после успешного завершения. Молчание дольше нормы — уже повод для алерта, даже если ошибки не было.
• Проверка смысла, а не кода возврата. «Ответ 200 и ноль строк» — это поломка. Ноль заявок в понедельник у компании, где их всегда 30, тоже.
• Контрольный прогон. Раз в сутки система прогоняет одну заведомо известную запись через всю цепочку и сверяет результат. Ловит именно тихие поломки — съехавшие селекторы, изменившийся формат ответа.
• Алерт человеку, а не в лог. Сообщение в Telegram с текстом «что сломалось и что теперь не работает». Ответственный на вашей стороне должен видеть его тоже, а не только я.
• Журнал инцидентов. Одна строка на случай: дата, причина, что сделали. Через полгода из этого видно, что чинить в корне, а что было единичным.

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

Что должно быть передано, чтобы систему вообще можно было поддерживать

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

1. Репозиторий с историей. Не архив, а git, куда есть доступ у вас. Иначе через год никто не отличит рабочую версию от черновика.
2. Секреты вне кода. Ключи, пароли, токены — в переменных окружения или отдельном файле конфигурации, который не лежит в репозитории. Плюс список: что где хранится и кто может обновить.
3. Инвентарь доступов. Какие учётки, в каких системах, на кого зарегистрированы, когда истекают. Технические учётки, а не личные — уволенный сотрудник не должен уносить с собой интеграцию.
4. Инструкция по эксплуатации на одну страницу. Как запустить руками, как понять, что работает, что делать при типовой ошибке, к кому идти. Пишется для того, кто увидит систему впервые.
5. Схема связей. Какая система с какой обменивается, в какую сторону, с какой периодичностью. Одна картинка экономит часы разбирательств.
6. Порядок отката. Как вернуться к предыдущей версии и откуда взять резервную копию данных. Проверить это надо один раз при сдаче, а не в момент, когда уже нужно.

Всё перечисленное — не бюрократия, а разница между сопровождением за 15 000 ₽ и сопровождением за 60 000 ₽ при одинаковой функциональности. Чем понятнее система, тем дешевле её держать живой, и это единственный способ повлиять на стоимость поддержки заранее.

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

Частые вопросы

Читайте дальше