Компания заменяет старую систему расчёта комиссий. Новая реализация проходит все известные тесты. Но в legacy годами появлялись исключения, которые никто полностью не документировал: специальные округления, договорные правила и редкие последовательности операций.
Отдать новой системе всю работу в один день — риск. Parallel Run позволяет временно выполнять сопоставимые расчёты в старой и новой реализации, сравнивать результат и накапливать факты до окончательного переключения.
Параллельный запуск не означает двойное действие
Для чистого расчёта можно передать одинаковые входные данные обеим системам и сравнить результат. Сложнее там, где операция меняет внешний мир: списывает деньги, резервирует товар, отправляет письмо или подтверждает договор.
Такое действие нельзя просто выполнить дважды ради теста. Вторая реализация может работать в теневом режиме: вычислять предполагаемый результат, но не отправлять необратимую команду. Иногда придётся заменить внешние зависимости имитацией или сравнивать данные после завершения реального процесса.
Важно явно отметить, какой путь остаётся авторитетным и кто имеет право записывать окончательный результат. Иначе сравнение превратится в новую проблему целостности данных.
Совпадение результатов не всегда означает правильность
Старый расчёт тоже может содержать ошибку. Если новая система возвращает другую сумму, сначала нужно понять причину. Иногда ошибка в новой реализации. Иногда обнаружилось старое исключение, которое бизнес давно хотел отменить.
Поэтому различия стоит группировать: реальная регрессия, преднамеренное изменение правила, расхождение исходных данных, ошибка сопоставления времени или форматирования. Не каждое несовпадение обязано автоматически блокировать миграцию, но каждое существенное должно быть объяснено.
Какие данные нужны для решения о переключении
Полезнее всего сравнивать результаты по реальным классам операций: обычные заказы, возвраты, частичные оплаты, отмены и редкие исключения. Чистая доля совпадений может скрывать критичную ошибку в одном дорогом сценарии.
Я бы заранее согласовал допустимые различия, продолжительность наблюдения, владельца расследований и критерии выхода. Важный вопрос — что делать, если параллельная проверка обнаружит неверный результат уже после того, как основная система его приняла.
Нужно учитывать и стоимость. Пока идут проверки, две реализации могут потреблять ресурсы, сохранять чувствительные данные и усложнять эксплуатацию. Переход должен иметь точку завершения, а не становиться постоянным способом работы.
Не путайте с двумя активными платформами
Parallel Run в миграции прежде всего проверяет эквивалентность или приемлемость поведения. Blue-Green Deployment решает иную задачу — как переключать трафик между версиями. Оба подхода можно сочетать, но наличие двух работающих сред ещё не означает, что сравнение результатов организовано.
Parallel Run полезен, когда компании недостаточно обещания «новая система должна работать так же». Он покупает доказательства, но только если сравнение не создаёт новые реальные операции.