Что ломается в первые месяцы после запуска системы

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

Ниже — что именно ломается, почему это приходит в первые месяцы и что можно подготовить заранее, чтобы этот период стоил дешевле.

Данные: после запуска работа не заканчивается, а меняется

Полезно понимать масштаб заранее, потому что интуиция здесь сильно занижает.

Классическое исследование Lientz и Swanson по 487 организациям показало, из чего реально состоит работа после запуска: исправление ошибок — только 21,7%. Остальное — адаптация к изменениям снаружи (23,6%, из них 17,4% приходится на изменения данных и форматов) и доработки под потребности пользователей (51,3%, из них 41,8% — прямые запросы заказчиков). Сотрудники при этом тратили на сопровождение примерно половину времени.

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

Более поздние работы оценивают долю сопровождения в стоимости жизненного цикла ещё выше — до 90% (Acta Informatica Medica, 2013). Цифры разных исследований расходятся, но направление одинаковое: владение системой стоит дороже её создания.

Три класса поломок первых месяцев

Симптом	Настоящая причина	Что с этим делать
Обмен с внешней системой встал	Чужой релиз, сеть, лимиты на той стороне	Алерт исполнителю, недоставленное доигрывается из очереди
Записи задвоились	Повтор запроса без защиты от дублей	Идемпотентность на приёме, вычистить последствия
«Пришли не те данные»	На той стороне поменяли формат или справочник	Сверить контракт обмена, обновить маппинг
Цифра в отчёте не сходится с учётом	Правило расчёта в системе и в голове бухгалтера разное	Зафиксировать правило письменно, потом править код
Остаток «врёт»	Резервы или фильтр складов считаются иначе, чем ожидали	Сверить формулу свободного остатка с учётом
Пользователи обходят систему	Процесс на бумаге не совпал с процессом в жизни	Менять процесс в системе, а не уговаривать людей

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

Разбор по типам систем — что именно ломается в обменах, в бэк-офисе и в кабинетах — в разделе сопровождения; детальнее про обмены — на странице поддержки интеграций, про учётный контур — в сопровождении ERP-модуля.

Почему это приходит именно сейчас

Три причины, и все три — не про качество разработки.

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

Внешние системы живут своей жизнью. Обновление на стороне 1С, банка или CRM происходит без согласования с тобой. Именно поэтому изменения данных и форматов — та самая адаптивная работа, которая у Lientz и Swanson занимает почти четверть сопровождения.

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

Первая неделя: что смотреть

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

• Сходится ли первый закрытый период — не «работает ли отчёт», а совпадает ли цифра с тем, что независимо посчитали руками. Расхождение проще ловить на одном дне, чем на месяце.
• Прошли ли обмены все до одного. Не «идут ли обмены», а есть ли записи, которые застряли и о которых никто не узнал.
• Кто вошёл и кто не вошёл. Люди, которые не смогли залогиниться, обычно не жалуются — они возвращаются к прежнему способу работы.
• Где начались обходные пути. Excel рядом с новой системой на второй неделе — это не саботаж, а точный указатель на недостающий сценарий.

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

Что нормально, а что нет

Стоит различать. Нормально: правки формулировок и полей, донастройка прав, расхождения в обменах в первые недели, новые отчёты, «а можно ещё вот так». Это адаптация, и её объём — та самая половина работы из исследования.

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

Полезный внешний ориентир: DORA определяет change failure rate как долю развёртываний, приводящих к сбою в проде, который требует исправления. По опубликованным ориентирам у сильных команд это до 15%, у слабых доходит до 46–60%. То есть даже у лучших часть изменений ломает прод — вопрос не в том, случится ли это, а в том, за сколько минут это будет замечено и откачено.

Что входит в поддержку, а что становится задачей

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

Отдельными задачами с ценой, названной до старта, идут: новая интеграция, новый вид документа со своими движениями, изменение правила расчёта (правило сначала фиксируется письменно, потом правится код) и новый модуль — склад, производство, биллинг. Это не жадность, а защита от подмены: «мелкая правка», которая меняет правило учёта, стоит как проект, и лучше это сказать сразу.

Как подготовиться заранее

Пять вещей, которые дешевле сделать до запуска, чем после.

1. Мониторинг и алерты исполнителю, а не клиенту. Об остановке обмена ты должен узнавать от системы.
2. Очередь с повторной попыткой. Внешняя система полежит и встанет; недоставленное должно доиграться само.
3. Журнал действий. Кто что сделал и когда. Без него разбор расхождения превращается в гадание.
4. Сторнирование вместо удаления. Отменённая операция должна оставлять след.
5. Договорённость о правилах. Как считается себестоимость и что происходит с остатком при возврате — письменно, до первой правки.

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

Когда пора не чинить, а менять

Иногда поток обращений — не про поддержку, а про то, что систему пора двигать. Сигналы: каждая правка тянет три соседних (техдолг), одно и то же расхождение возвращается после каждого исправления (модель не сходится с процессом), или пользователи стабильно обходят систему (процесс описан не тот). В этих случаях дешевле точечно переделать участок, чем бесконечно чинить симптомы.

Если система уже запущена и первые месяцы идут тяжело — опиши, что именно повторяется. Скажу, это адаптация, дефект контура или сигнал переделывать. Что я делаю и на каких условиях — услуги.

Источники

Проверено 17.08.2026.

• B. P. Lientz, E. B. Swanson, «Software Maintenance Management» (1980), исследование 487 организаций: исправление ошибок — 21,7% усилий сопровождения (аварийные правки 12,4%, штатная отладка 9,3%); адаптация — 23,6% (изменения данных и форматов 17,4%); доработки — 51,3% (запросы заказчиков 41,8%); сотрудники тратили на сопровождение около половины времени. Цифры приводятся по разбору Jim Bird, 14.04.2011, который отдельно отмечает, что это исследование часто цитируют неточно.
• S. M. H. Dehaghani, N. Hajrahimi, «Which Factors Affect Software Projects Maintenance Cost More?», Acta Informatica Medica, 2013: около 90% стоимости жизненного цикла ПО приходится на фазу сопровождения. pmc.ncbi.nlm.nih.gov
• DORA определяет change failure rate как долю развёртываний, вызывающих сбой в проде (dora.dev); опубликованные ориентиры по кластерам — до 15% у сильных команд и 46–60% у слабых, по сводке DX.
• Классы поломок, их причины и граница между поддержкой и задачей — по моему опыту сопровождения внутренних систем и интеграций.