Модернизация легаси-системы: чинить, переписывать или мигрировать

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

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

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

Сколько человек может внести изменение без чужой помощи? Один — критическая зависимость. Двое — риск. От трёх начинается нормальная работа.

Какую долю времени команда тратит на поддержку и разбор инцидентов? До 20% — здоровая система. Половина и больше — команда работает на удержание, и на развитие времени не остаётся.

Как часто вы выпускаете изменения? Ежедневный релиз и релиз раз в квартал — два разных мира. Редкие релизы почти всегда означают, что каждый из них страшный.

Что покрыто тестами? Общий процент покрытия говорит мало. Смотреть надо на расчёты денег — цены, скидки, начисления и налоги. Именно они и мешают трогать код.

Сколько внешних систем обменивается с ней данными? Каждый обмен — отдельная работа при переезде и отдельный риск. Список обменов обычно длиннее, чем помнят.

Что произойдёт при простое в два дня? Ответ переводит разговор из технической плоскости в денежную и обычно решает спор о бюджете.

Бездействие выглядит бесплатным, потому что за него не приходит счёт. Счёт всё равно оплачивается, просто четырьмя строками сразу.

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

Вторая — простои. Каждый час недоступности учётной системы стоит ровно столько, сколько компания зарабатывает за этот час, плюс разбор последствий.

Третья — упущенные возможности. Маркетплейс, новый склад или программа лояльности не запускаются, потому что старая система не отдаёт данные.

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

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

Сценарий повторяется от проекта к проекту. Команда оценивает переписывание в девять месяцев, на десятом месяце новая система умеет половину, а старая продолжает работать и меняться.

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

Вторая — невидимая функциональность. За двенадцать лет в системе накопились обработки, отчёты и исключения, о которых знают только те, кто ими пользуется. В оценку они не попали.

Третья — пауза в развитии. Весь срок переписывания бизнес не получает ничего нового, и на середине пути возникает вопрос, зачем всё это затевали.

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

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

Порядок работы обычно такой:

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

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

Платите за это временем. Какое-то время работают обе системы, и обе нужно поддерживать. Зато бизнес не встаёт ни на один день.

Перед любым переносом нужно восстановить, как система себя ведёт. Документация к этому моменту либо отсутствует, либо описывает версию пятилетней давности.

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

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

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

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

Результат этого этапа — не техническое описание. Это список правил, за которые компания отвечает перед клиентами и контролирующими органами, с пометкой, где каждое из них реализовано.

Главный страх переезда звучит одинаково у всех: новая система посчитает иначе, и это увидят клиенты. Страх обоснованный, и снимается он проверкой на реальных данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По нашим работам ориентиры такие. Аудит кода и архитектуры обходится от 200 до 600 тыс. ₽, заказная система под процесс — от 1,7 млн ₽, бэкенд и веб-часть — от 1 млн ₽, отдельная интеграция — от 150 тыс. до 1,5 млн ₽ в зависимости от системы. Точную цифру считаем по вашему контуру: оценка проекта бесплатная.

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

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

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

Перенос данных ставят в конец плана. Чистка справочников всплывает за две недели до запуска и сдвигает срок на квартал.

Не сверяют расчёты на реальных документах. Расхождение первыми находят клиенты и бухгалтерия.

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

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

Второе — оценить цену бездействия по своим цифрам. Год со старой системой стоит денег, и без этой суммы бюджет модернизации не с чем сравнивать.

Третье — заказать аудит кода и архитектуры. Он даёт карту системы, список рисков и обоснованный выбор пути. Дальше разговор идёт о смете и этапах.