Заказчик хочет уйти с устаревшей АБС, биллинга или самописной ERP – но переписать всё за один релиз нельзя. Система работает в проде, на ней висят интеграции с десятком смежных контуров, а в госсекторе ещё и значимый объект КИИ, который нельзя останавливать. Большой взрыв («переключаем всё в выходные») в таких условиях – почти гарантированный откат и срыв сроков. Рабочая альтернатива – паттерн «душитель» (Strangler Fig): новая система постепенно перехватывает функции старой, пока та не отомрёт полностью.
Как работает «душитель»
Перед legacy-системой ставится фасад – слой маршрутизации (API-gateway, ESB или обратный прокси), через который идёт весь трафик. Снаружи потребители видят прежние контракты, внутри фасад решает, куда направить вызов: в старый монолит или в новый сервис.
Дальше функции выносятся по одной. Выбираете срез – например, расчёт пеней или выгрузку отчётности, – реализуете его в новом стеке, переключаете маршрут на фасаде и наблюдаете. Если что-то идёт не так, откат – это смена правила маршрутизации, а не ночной rollback всей платформы. Так старый код «удушается» постепенно: с каждым релизом legacy теряет очередной кусок ответственности, пока от него не остаётся пустая оболочка, которую можно выключить.
Ключевое условие – измеримость каждого шага. Перед переключением среза прогоняйте параллельный режим (shadow mode): новый сервис получает копию реального трафика, а его ответы сверяются со старыми без влияния на пользователя. Расхождения ловятся до боевого переключения, а не в инциденте.
Где паттерн ломается
Главная ловушка – общая база данных. Если новый сервис и legacy пишут в одни и те же таблицы, вы не разнесли системы, а добавили ещё одного клиента к старой схеме. «Душитель» требует развязки по данным: либо новый сервис владеет своим хранилищем и синхронизируется через события, либо доступ к данным идёт строго через API старой системы. Двусторонняя репликация на уровне БД почти всегда превращается в источник трудноуловимых конфликтов.
Вторая проблема – недооценка фактической логики legacy. В старых системах годами копились недокументированные правила, обработка краевых случаев и «исторические» костыли, на которые молча опираются смежники. Прежде чем переносить срез, его поведение нужно зафиксировать: контрактные тесты, логи реальных вызовов, разбор обращений к данным. Здесь помогает связка инструментов – от агентного разбора документации и кода до аналитики на исторических данных эксплуатации, о которой мы писали в материале про BI и большие данные.
Регуляторный контур
Если в периметре есть значимые объекты КИИ, фасад и новые сервисы попадают под те же требования, что и заменяемая система: категорирование, средства защиты, контроль изменений. Менять архитектуру в обход модели угроз нельзя – каждый вынесенный срез нужно сопровождать обновлением документации и проверкой по требованиям ФСТЭК. Мы разбирали эту дисциплину в статье про финальный аудит КИИ: миграция по «душителю» как раз удобна тем, что изменения дробятся и каждое проходит контроль отдельно, без замораживания всего объекта.
Вывод
«Душитель» – не способ избежать сложной работы, а способ разбить её на проверяемые шаги с дешёвым откатом. Он окупается там, где простой недопустим, а цена ошибки высока: финансовый софт, госуслуги, объекты КИИ. Если перед вами стоит замена legacy-системы без остановки бизнеса, всё начинается с проектирования фасада, развязки данных и порядка поэтапной интеграции систем.
