Как перейти на новую систему, не останавливая работу?

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

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

Почему код, преобразованный ИИ, требует иного тестирования

Код, созданный инструментами преобразования, выглядит аккуратно и работает с первого раза, и именно поэтому его ошибки трудно заметить. Ошибка проявляется не в повседневных операциях, а в случае, который бывает раз в месяц или раз в год. Amazon объясняет в своем руководстве по преобразованию мейнфрейм-приложений, что первичное преобразование из COBOL в Java сохраняет прежнее поведение, а затем шаг под названием Reforge с помощью больших языковых моделей перестраивает код в современном стиле Java. COBOL — старый язык программирования, на котором до сих пор работают многие банковские и мейнфрейм-системы; мейнфрейм — это большой центральный сервер, на котором работают ключевые системы крупных организаций.

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

Сравните результаты на одних и тех же реальных операциях

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

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

Некоторые инструменты помогают подготовиться, но не выносят решение. AWS Transform для мейнфреймов, например, составляет план тестирования на основе характеристик кода, сложности заданий и путей планировщика в 3 этапа (настройка, определение охвата и проверка), а затем генерирует скрипты для сбора тестовых данных с мейнфрейма в 4 этапа. Но Amazon предупреждает в том же руководстве, что эти скрипты нужно запускать на вашем собственном мейнфрейме и с правами вашей команды. Инструмент готовит; ваша команда выполняет и решает. Для проверки самих данных Microsoft предлагает сначала сравнить количество строк как быструю проверку, а затем контрольные суммы как более глубокую: контрольная сумма — это число, вычисляемое из данных, которое меняется при изменении хотя бы одного символа.

Редкие случаи: спросите тех, кто их знает

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

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

Утверждение человеком для каждого модуля

Самый наглядный опубликованный пример этого принципа — конвейер миграции банковских систем, который Thought Machine объявила вместе с Amazon 29 сентября 2026 года. Он состоит из 4 этапов: извлечение бизнес-логики из устаревших приложений с помощью AWS Transform, объединение дублирующихся вариантов в единые спецификации, создание новых финансовых продуктов и наборов тестов агентами ИИ и этап проверки, который дает инженерным командам и командам по рискам банка явное право утверждения, прежде чем что-либо будет принято. Даже после утверждения результат попадает в изолированную тестовую среду для дополнительной оценки, а не сразу в промышленную эксплуатацию.

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

Параллельная работа и план отката

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

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

Взгляд Origami

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

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

Упражнение этой недели: лист перехода для каждого модуля

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

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

Что дальше

Остается вопрос, который задает каждый руководитель перед тем, как отправить код и данные в инструмент ИИ: куда уходят мои данные во время модернизации? Часть 7, заключительная, отвечает на него и сводит упражнения всей серии в план на 90 дней.

Источники

• Microsoft: выполнение миграции, Cloud Adoption Framework — встреча по критериям отката, заморозка изменений, проверка данных, 24–48 часов наблюдения и сохранение исходной среды как запасного варианта.
• Amazon: преобразование мейнфрейм-приложений в AWS Transform — планы тестирования, скрипты сбора тестовых данных и шаг Reforge.
• Amazon: объявление Thought Machine и AWS о миграции устаревших банковских систем — четыре этапа и утверждение инженерными командами и командами по рискам.
• AWS Transform: официальная страница.