Новый отчёт можно считать параллельно с рабочим, сохраняя его результат отдельно. Объясняем, что сравнивать, как разбирать расхождения и почему копирование входных данных само по себе не проверка.
Новый результат пока не должен менять работу
Представим условный расчёт суммы доставок. Команда переделала обработку и хочет проверить её на знакомых рабочих случаях. Пользователи продолжают получать прежний отчёт, а новая версия считает по сопоставимым входным данным и складывает результат отдельно. Так можно изучать различия до решения о замене рабочего результата.
Этот подход часто называют теневым расчётом или теневым тестированием. В инженерном руководстве Microsoft описаны параллельные версии, одинаковый входной поток и сравнение ответов новой версии, которые не возвращают пользователям. Применение этой идеи к отчётам ниже — предлагаемый нами сценарий, а не готовая функция любой системы данных.
Сначала определить, какие результаты сопоставимы
Для условного отчёта предложим зафиксировать период, состав заказов, правила округления и обработку отмен. Если старый вариант получил полный день, а новый — только утро, различие сумм ничего не говорит о правильности изменений. Одинаковое название отчёта ещё не означает одинаковые условия получения результата.
Важно также заранее отметить намеренные изменения. Допустим, команда договорилась учитывать отменённые доставки иначе. Тогда часть расхождений ожидаема, но их всё равно нужно связать с конкретным правилом. Без такого описания любой неудобный результат можно задним числом объявить новой логикой, и проверка потеряет смысл.
Одного общего итога недостаточно
Представим учебный набор из двух пунктов выдачи. В новой версии сумма первого выросла на сто рублей, второго уменьшилась на сто. Общий итог совпал, хотя распределение изменилось. Поэтому для этого сценария предложим сравнивать не только финальную сумму, но и группы, отдельные записи и причины включения или исключения заказа.
Это не призыв проверять каждую строку вручную в любом объёме. Нужно выбрать понятные признаки и заранее подготовленные случаи, а затем объяснять найденные различия. Для нашего учебного отчёта подойдут отмена, позднее изменение и повторная доставка. Набор должен соответствовать реальной задаче; универсального списка случаев для всех расчётов нет.
Копирование запросов ещё не сравнивает ответы
Документация Istio о зеркалировании показывает отправку копии запросов другой версии сервиса, причём её ответы отбрасываются. Это полезное различие: механизм дублирования входа сам по себе не предоставляет содержательный разбор двух итогов. В задаче данных нужно отдельно продумать сбор сопоставимых результатов и объяснение расхождений.
Предлагаем записывать для обнаруженного отличия: какой набор сравнивали, какое правило сработало и считается ли изменение ожидаемым. Затем назначать ответственного за решение. Сообщение «новая версия отработала без ошибки» проверяет завершение процесса, но не доказывает, что она посчитала то же самое или правильно реализовала намеренное изменение.
Изоляция должна быть настоящей
Новая обработка не должна незаметно отправлять рабочие уведомления, повторно оформлять действия или записывать пробные значения в основной отчёт. Для нашего сценария предлагаем отдельное место результата и предварительный разбор всех внешних действий. Само слово «теневой» не гарантирует отсутствия влияния: копирование работы всё равно расходует ресурсы и может обращаться к общим зависимостям.
Доступ к данным также должен соответствовать разрешённой задаче. Для учебного обсуждения достаточно вымышленного набора, а проверку на рабочих сведениях согласовывают отдельно. Полезно заранее определить длительность сравнения и условие завершения, чтобы эксперимент не остался бесконечным вторым процессом без владельца. Решение о переключении принимают по разобранным результатам, а не по одному спокойному запуску.
Как завершить проверку осмысленно
В отличие от ограниченного включения нового поведения потребителям, здесь новая версия пока не заменяет рабочий ответ. План действий при обнаружении проблемы можно связать с инструкцией дежурного, а оценку последствий — с критичностью сбоя данных.
Изучать надёжность процессов можно на курсе DataOPS инженер. Начальный результат разбора — объяснить, какие различия допустимы, какие требуют исправления и почему полученных наблюдений достаточно для следующего решения. Теневой запуск без такого ответа остаётся только дополнительным вычислением.
