Новую версию системы назначения выездов включили для небольшой группы. Ошибок нет, среднее время ответа хорошее. Решили продолжать выпуск. Позже обнаружили, что новая логика не учитывает одно ограничение рабочего графика. В первой группе просто не оказалось ни одного сотрудника с таким расписанием.
Canary Deployment даёт возможность оценить изменение на ограниченной части реальной работы до полного выпуска. Но малая аудитория сама по себе ничего не проверяет. Нужно понимать, какую работу новая версия уже выполнила, с чем её сравнили и какое ухудшение команда успеет заметить.
Выберите единицу участия, а не только процент
Долю запросов удобно задать в маршрутизаторе. Для пользователя это может означать, что одна страница работает на новой версии, а следующая — на старой. Если версии по-разному понимают сессию или промежуточное состояние, получится отдельный сценарий, которого не было ни в одной из них по отдельности.
В системе выездов единицей группы может стать филиал или рабочая команда. Тогда связанные изменения расписания проходят согласованно. Но филиал тоже надо выбрать осмысленно: маленькое подразделение без сложных графиков не представляет всю компанию. Начальная группа должна ограничивать риск и содержать нужные для проверки случаи.
Процент экземпляров приложения не равен точному проценту запросов. Долгие соединения, разные клиенты и способ балансировки меняют распределение. Например, Argo Rollouts без отдельного управления трафиком приближает заданную долю через количество экземпляров. Для оценки нужны фактические обращения и операции новой версии.
Сравнивайте работу версий одновременно
Сопоставить утро после выпуска с предыдущей ночью проще, чем организовать контрольную группу. Однако состав заявок и нагрузка могли измениться независимо от кода. При Canary полезнее сравнивать новую и стабильную версии в сопоставимых условиях, сохраняя возможность отдельно видеть каждую.
Общий график продукта способен скрыть плохую небольшую группу. Поэтому ошибки, задержки и результат работы связывают с версией и этапом выпуска. Но и прямое сравнение процентов требует контекста: если новой версии достались самые сложные выезды, различие нельзя автоматически объявить регрессией.
Для диспетчера успешный HTTP-ответ ещё не означает правильное назначение. Нужны проверки доступности исполнителя, отсутствия конфликтов и завершения назначения. Подход к выбору группы и показателей изложен в Google SRE Workbook. Из него не следует универсальный процент, подходящий каждому продукту.
«Не увидели ошибку» и «проверили» — разные результаты
Несколько успешных обращений могут не затронуть изменённую функцию. Фоновой обработчик иногда запускается лишь по расписанию, а неправильное назначение обнаружится после подтверждения исполнителем. Период наблюдения должен охватывать соответствующую работу, а не только время жизни нового процесса.
Условия перехода на следующий этап лучше задать заранее: что должно выполниться, какие сигналы останавливают выпуск и что делать при недостатке данных. Если сбор показателей не работает, отсутствие красного графика не повод автоматически расширять аудиторию. Пауза — нормальный результат, а не сбой самого процесса доставки.
Некоторые инструменты выделяют неопределённый результат отдельно. Например, анализ в Argo Rollouts допускает inconclusive и остановку продвижения для решения человеком. Важно настроить реальное поведение своей проверки: ошибка запроса к метрикам, пустой ответ и хороший результат не должны случайно означать одно и то же.
Длительность не нужно увеличивать бесконечно. Если в выбранной группе нужные случаи слишком редки, лучше изменить способ проверки: подготовить контролируемые сценарии или выбрать другую разрешённую группу. Долгое ожидание неподходящего трафика не делает вывод надёжнее.
Общая база может расширить аварию за пределы группы
Новая версия способна записать статус, который старая не понимает, или занять общий ресурс тяжёлым запросом. Тогда пострадает и контрольная группа. Canary ограничивает направленную работу, но не создаёт автоматически изоляцию данных и мощности.
Перед выпуском проверяют совместимость записей, сообщений и общих настроек. Разрушительная миграция всей базы не становится безопасной от того, что новый интерфейс получили немногие. Для таких изменений требуется отдельная последовательность перехода; аналогичные ограничения разобраны в статье о Blue-Green Deployment.
При остановке новая версия уже могла назначить выезд и отправить уведомление. Возврат маршрута не отменяет эти действия. Нужно определить затронутые операции и способ их исправления. А стабильная версия должна иметь мощность принять возвращаемую нагрузку, включая повторы после неудачных попыток.
Не перепутайте проверку выпуска с выбором лучшего продукта
Canary отвечает прежде всего на вопрос, безопасно ли расширять изменение при выбранных критериях. Эксперимент с новой функцией может решать другую задачу: полезнее ли она пользователю. Для такого вывода нужны подходящие группы и метод оценки; один спокойный этап выпуска его не доказывает.
Функциональный флаг позволяет отдельно включать поведение, но не заменяет проверку самой поставки. Неактивная функция может быть безопасна, пока новая библиотека уже влияет на все запросы. Полезно разделять выпуск кода, включение функции и изменение общих данных, чтобы понимать источник каждого эффекта.
Расширение — новое условие, а не награда за первый этап
На большей аудитории появятся другие данные и нагрузка. Даже удачный малый этап не доказывает, что общий сервис справится с полной частотой обращений. Проверку продолжают при расширении, а не отключают после первого разрешения.
Для конкретного выпуска достаточно короткой записи: версия, фактическая группа, выполненные сценарии, наблюдаемые последствия и решение ответственного. Отдельно отмечают непроверенные случаи. Несколько одновременных изменений могут перемешать сигналы; их надо либо развести, либо явно учитывать при анализе.
В системе назначения выездов решение о полном выпуске стоит принимать после проверки нужных типов расписания и завершённых назначений. Тогда при словах «первая группа прошла» понятно, что именно прошло, а не просто сколько минут никто не позвонил в поддержку.