Миграция по Strangler-подходу: запуск модулей и вывод legacy

Зачем вообще уходить с legacy и почему это сложно

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

Полный big bang часто выглядит соблазнительно: выключили старое, включили новое. На практике это ломает процессы, потому что реальная работа всегда шире, чем описано в ТЗ. Не учли один отчет для руководителя или один файл для регулятора, и команда либо откатывается, либо закрывает разрывы вручную.

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

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

Для бизнеса критичны риски простоя процессов, ошибок в расчетах и данных (счета, остатки, договоры, штрафы), проблем с безопасностью и доступами, потери управляемости (цифрам нельзя доверять) и роста затрат на поддержку, когда "временно" становится постоянным.

Поэтому ценят Strangler-подход: он позволяет выводить legacy частями и снижать риск остановки. Но ключевая сложность остается прежней: доказать, что новый модуль делает то же самое, а данные и результаты совпадают с тем, что бизнес считает правильным.

Strangler-подход простыми словами

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

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

Под "модулем" здесь обычно понимают не абстрактный блок в документации, а конкретную бизнес-функцию со своими данными и правилами. Например: прием и обработка заявок, справочники (контрагенты, товары, подразделения), расчет и выставление счетов, отчетность по отдельному процессу.

Успех в Strangler-подходе - не "мы написали новый сервис". Успех - когда пользователи делают задачу в новом контуре, результаты совпадают с ожиданиями, а старый путь можно безопасно отключить. То есть новая функция замещает старую целиком: по логике, данным и операционным показателям (скорость, ошибки, нагрузка на поддержку).

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

Подготовка: границы модулей и список зависимостей

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

Начните с карты функций: какие модули реально существуют сегодня (даже если они так не называются), кто ими пользуется и какая команда поддерживает. Фиксируйте не "как в регламенте", а как люди работают на практике.

Дальше опишите ключевые сквозные потоки, чтобы видеть, где модуль начинается и где заканчивается. Например: "заявка -> согласование -> заказ -> приемка -> счет -> оплата" или "обращение -> диагностика -> ремонт -> закрытие". Такие цепочки сразу показывают места, где новый модуль обязан корректно стыковаться с остальными.

Затем соберите точки интеграции и зависимости, включая неочевидные: внешние системы (ERP/CRM, бухгалтерия, склад, HR), обмены через файлы и выгрузки (Excel, CSV, почта), ручные операции (ввод в две системы, правки "по телефону"), отчеты и витрины данных, которые питаются из legacy, а также роли и права доступа, завязанные на конкретные экраны.

Отдельно определите владельцев данных и тех, кто принимает результат. Для каждого набора данных (клиенты, договоры, номенклатура, платежи) нужен один ответственный за смысл и качество и один ответственный за техническую приемку. Простой тест: если завтра цифры в отчете "поедут", должно быть ясно, кто решает, что считать истиной и где это исправлять.

Как выбрать очередность модулей и критерии успеха

Очередность решает половину рисков. В Strangler-подходе лучше не начинать с самого большого и переплетенного куска, даже если он кажется самым важным. Начните с модуля, где проще отделить границы, быстрее увидеть эффект и научиться работать в параллельном режиме.

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

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

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

Заранее согласуйте длительность параллельного периода и правила поддержки: кто дежурит, как регистрируются расхождения, сколько времени дается на исправление.

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

Архитектура параллельного запуска: маршрутизация и интеграции

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

Единая точка входа и маршрутизация

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

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

Адаптеры к legacy и постепенная замена интеграций

Главная ловушка параллельного запуска - попытка "сразу переписать все интеграции". Практичнее сделать адаптеры к legacy: тонкий слой, который переводит новые форматы данных и вызовы в старые интерфейсы (и обратно). Тогда новый модуль можно подключать к существующим внешним системам постепенно, без массовых переделок.

Например, в интеграции с бухгалтерией новый модуль отправляет единый формат события, а адаптер решает, как корректно вызвать старый обмен или новый.

Для управления доступом и рисками используют фича-флаги: сначала включают новый модуль тестовой группе, затем одному подразделению, потом всем. Это удобно и для отката: выключили флаг, и поток возвращается в legacy без остановки бизнеса.

Наблюдаемость обязательна. Минимальный набор: корреляционный идентификатор операции в обоих контурах, отметка где обработан запрос (legacy или новый модуль), ключевые параметры без персональных данных, результат и код ошибки. Без этого параллельный запуск превращается в гадание, а проблемы в интеграциях находят слишком поздно.

Пошаговый план миграции модулей по Strangler

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

1) Выделите модуль и зафиксируйте контракт

Опишите границу модуля одним предложением: что он делает и где заканчивается ответственность. Затем зафиксируйте контракт: какие данные он получает, что отдает наружу, какие правила и проверки обязательны. Если правила не записать, новый модуль начнет вести себя иначе, и это всплывет уже на пилоте.

2) Поднимите новый модуль рядом и подключите через маршрутизацию

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

3) Включите пилот на узком сегменте

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

4) Расширяйте долю трафика и функциональность

Расширение делайте порциями. Ориентир простой: увеличивайте охват только после стабильной недели (или другого вашего окна) без критичных инцидентов и с понятной картиной расхождений.

5) Зафиксируйте критерии отключения legacy и отключите старую часть

Отключение не должно быть "по ощущению". Обычно достаточно 4-5 критериев: покрыты все нужные операции; нет блокирующих расхождений в данных; выполнены контрольные сверки; поддержка знает типовые инциденты; есть план отката на ограниченное время. После отключения оставьте период наблюдения и только потом убирайте старые интеграции и отчеты.

Этапы параллельного запуска: от пилота до масштабирования

Параллельный запуск нужен, чтобы новый модуль начал приносить пользу раньше, чем вы полностью избавитесь от legacy, и при этом не ломал соседние процессы. Обычно движение идет по трем режимам: shadow, затем canary, затем включение по сегментам до 100%.

1) Shadow: новый модуль считает, но не влияет

В режиме shadow вы направляете в новый модуль те же события и запросы, что и в старый, но результат нового модуля не используется в бизнес-процессе. Так удобно проверять логику, производительность и качество данных без риска.

Если без записи не обойтись (например, модуль должен собирать справочники или кэш), фиксируйте изменения в отдельном контуре или помечайте их как тестовые, чтобы не загрязнять боевую базу.

2) Canary: небольшой процент реальных операций

Дальше включайте новый модуль на малую долю трафика (например, 1-5%) или на узкий тип операций. Заранее решите, как выглядит "двойная" работа. На практике чаще встречаются два варианта: двойная запись (обе системы получают изменения, но источник истины на шаге один) или двойная обработка (обе системы считают результат, но в бизнес уходит только один, пока вы сравниваете).

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

3) По сегментам: управляемое расширение охвата

После canary переходите на сегментацию: по филиалам, типам клиентов, продуктовым группам, ролям пользователей. Так проще откатываться и искать причины ошибок. На каждом расширении держите понятный "рубильник" (фича-флаг или маршрут на шлюзе), чтобы быстро вернуть поток в legacy.

Управление релизами, чтобы не ломать соседние модули

Параллельный запуск часто идет рядом с интеграциями, поэтому релизы должны быть предсказуемыми. Работает простое правило: интерфейсы сначала расширяем (добавляем поля или методы), потом начинаем ими пользоваться, и только после стабилизации убираем старое поведение. Так меньше шанс, что новый модуль внезапно уронит зависимые системы.

Контроль качества данных и сверка между контурами

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

Что сверять в первую очередь

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

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

Контрольные итоги лучше фиксировать ежедневно (или по каждой загрузке): количество объектов, сумма по ключевым полям, контрольные балансы. Если в legacy "сходится", то в новом контуре итоги должны совпадать в пределах заранее заданного допуска.

Правила качества и процесс исправления

Заранее договоритесь о правилах: обязательность полей, допустимые диапазоны (например, дата не в будущем), форматы (ИИН/БИН, номера договоров), уникальность ключей. У каждого правила должен быть владелец и понятный приоритет.

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

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

Критерии отключения старого контура для конкретного модуля

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

Минимальный набор критериев

Перед отключением полезно подтвердить пять условий:

• Функциональная готовность. Закрыты ежедневные сценарии, редкие исключения и ручные обходы, которые пользователи реально применяли в legacy.
• Данные. Сверки между контурами дают стабильный результат несколько циклов подряд, расхождения в пределах порога и с понятной причиной.
• Нагрузка. Модуль выдерживает пики (например, закрытие месяца, массовые расчеты, пакетные выгрузки) без деградации времени ответа и без роста ошибок.
• Операции и поддержка. Есть инструкции, метрики, алерты и понятный способ восстановления после сбоя (кто что делает и за какое время).
• Юридические и аудит-требования. Настроены роли и доступы, протоколирование действий, сроки хранения, выгрузки для проверок.

Практичный сигнал, что можно отключать

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

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

Пример сценария: миграция одного бизнес-модуля без остановки работы

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

Сначала команда фиксирует границы: новая система отвечает за создание и согласование заявок, а legacy остается источником истины для оплат и закрывающих документов. Затем запускают пилот, например только для одного подразделения (ИТ-отдел или один филиал). Пользователи создают заявки в новом интерфейсе, но данные все равно попадают в legacy через интеграцию, чтобы бухгалтерия и склад работали как раньше.

Как выглядит параллельная работа на пилоте

На время пилота вводят правило: новый модуль создает заявки, а legacy принимает их как "входящий документ". Каждый день проводят сверку по ключевым полям: статусы (создана, на согласовании, отклонена, утверждена), суммы и валюта, НДС или без НДС, контрагенты и договоры (идентификаторы, ИИН/БИН), сроки поставки и условия (дата, адрес, комментарии), вложения и ссылки на спецификации (если используются).

Если расхождения повторяются, пилот не расширяют. Сначала исправляют маппинг, правила округления и справочники.

Как отключают legacy для этого модуля

Когда пилот стабилен (например, 2-4 недели без критичных расхождений и с нормальным временем обработки), меняют маршрутизацию: все новые заявки идут только в новый модуль. В legacy запрещают создание новых заявок (оставляют просмотр и завершение старых), чтобы не появлялись "двойники".

После переключения важно не расслабляться: 1-2 месяца держат усиленный мониторинг инцидентов, очередь интеграций и отчеты по "хвостам" (незакрытые заявки, зависшие согласования, неверные контрагенты). Только когда хвосты закрыты и метрики стабильны, модуль в legacy можно считать выведенным из эксплуатации.

Частые ошибки и ловушки

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

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

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

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

Короткий чеклист и следующие шаги

Перед тем как двигаться к отключению очередного legacy-модуля, стоит навести порядок в базовых вещах. Иначе параллельная работа быстро превратится в бесконечные созвоны и ручные правки.

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

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

Следующий практичный шаг - оценить инфраструктуру и поддержку для параллельной работы. Нагрузка почти всегда растет из-за двойной записи, фоновых сверок и дополнительных логов. Проверьте, хватает ли мощности для пиков (например, закрытие месяца), и готова ли поддержка работать 24/7 на время критичных переключений.

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