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

Понедельник: «переход прошёл успешно»

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

В чате поддержки, где нормой было одно-два сообщения за несколько дней, за неделю накопилось больше ста восьмидесяти. К пятнице поток так и не иссяк.

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

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

Кто тушил пожар

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

Контрольный пример

Здесь можно было бы сказать: «ну, миграции — это всегда больно, издержки перехода». И это была бы удобная неправда.

За пару месяцев до этого в той же компании прошли два переноса того же класса — данные за другие периоды, та же система, тот же контур. Делал их другой человек. Инцидентов: ноль. Не «поменьше», а ноль.

Когда одинаковая задача в одних руках проходит бесшумно, а в других превращается в неделю пожара — дело не в задаче.

Первопричина: не техника, а подготовка

Разбор показал, что до старта не существовало ничего из обязательного минимума:

  • Плана отката не было. На прямой вопрос «а как откатываемся, если что-то пойдёт не так?» утром первого дня прозвучало: «пока не вижу причин для отката». Причины появились через час.
  • Пользователей не уведомили. Часть сотрудников продолжала работать в старой базе — неделю жили в двух базах с ручным дублированием документов.
  • Перечень переносимых данных был неполным — это признали сами исполнители к вечеру первого дня.
  • Плана переключения интеграций не существовало. Обмены с внешними сервисами остались активны в обеих базах одновременно — со всеми рисками двойных отправок контрагентам.
  • Критериев приёмки не было вообще. Никто не мог сказать, что значит «перенос успешен», поэтому успех объявили декларативно.

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

«Штатно, ожидаемо и контролируемо»

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

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

Чеклист, который стоит час

Что должно существовать до любой миграции в боевой контур — в письменном виде, а не «в голове»:

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

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

Итог

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

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

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