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