Canary deployment: как выпускать изменения на части трафика
Новая версия сайта может пройти тесты и всё же ошибиться на реальных заказах, непривычных данных или определённом устройстве. Canary deployment позволяет сначала направить на неё ограниченную часть рабочего трафика, сравнить результат с действующей версией и только затем расширять выпуск. Польза появляется, когда команда управляет составом группы и заранее понимает, по каким данным продолжать или останавливать релиз.
Канареечный релиз не превращает реальные операции в безопасную имитацию. Новая версия может изменить общую базу, перегрузить зависимость или отправить задачу, которая выполнится позднее. Поэтому постепенный rollout сайта требует согласованной маршрутизации, метрик по версиям и подготовленного возврата. Разберём процедуру на практических примерах без универсальных процентов и обещаний нулевого риска.
Что проверяет canary deployment
Google SRE описывает canary как ограниченное по охвату и времени развёртывание изменения с оценкой, позволяющей решить, продолжать ли выпуск. Новая версия обслуживает выделенную часть запросов или пользователей, а контрольная остаётся действующей точкой сравнения. Смысл процедуры — получить наблюдения до распространения изменения на всю аудиторию.
Для владельца сайта это означает управляемое решение: релиз расширяют после проверки, оставляют на текущем этапе при недостатке данных или прекращают при неприемлемом результате. Просто запустить второй экземпляр приложения недостаточно. Нужно знать, кто фактически получил новую версию, какие операции выполнил и что произошло после их завершения.
Перед началом сформулируйте проверяемое изменение. Например, новый расчёт доставки должен сохранять корректные суммы и укладываться в согласованное время ответа. Если в выпуск одновременно включены новый расчёт, смена базы и переработка авторизации, обнаруженное ухудшение сложнее связать с причиной. Объём релиза должен позволять команде понять результат сравнения.
Выберите устойчивую группу пользователей или операций
Сначала определите единицу распределения: отдельный запрос, сессию, учётную запись или организацию клиента. Для независимого чтения страницы допустимо распределять запросы. Для многошагового оформления заказа полезнее сохранить согласованный маршрут всей операции: случайное переключение версии между корзиной и подтверждением способно создать сочетание, которое отдельно не проверяли.
Устойчивая группа означает, что правило назначения не меняется произвольно при каждом запросе. Проект может использовать закрепление сессии или стабильное распределение разрешённых идентификаторов по группам. При расширении аудитории сохраняют понятное поведение уже включённых пользователей. Правило, срок его действия и условия выхода из группы записывают в карточке релиза.
В официальном примере Istio показана маршрутизация к версии сервиса по пользовательскому признаку в заголовке. В своём проекте такой признак назначают и проверяют на доверенной границе. Маршрутизация не должна давать дополнительные права: доступ к данным и действиям продолжает проверяться обычным механизмом авторизации.
Долю аудитории и долю запросов фиксируют отдельно. В учебном наборе 50 учётных записей из 1000 составляют 5% аккаунтов. Если эти пользователи активнее остальных, они создадут больше 5% запросов. Поэтому число участников, фактическую нагрузку и число завершённых бизнес-операций измеряют, а не выводят друг из друга автоматически.
Управляйте трафиком отдельно от количества экземпляров
Один новый экземпляр среди десяти не обещает ровно десятую часть HTTP-запросов. Распределение зависит от балансировщика, соединений, закрепления сессий и других настроек. Даже заданный вес маршрута оценивают по наблюдениям за выбранный интервал: короткая выборка может заметно отличаться от ожидаемой пропорции.
Argo Rollouts различает способы управления трафиком, включая веса и маршруты по заголовкам, и использует интеграции с соответствующими маршрутизаторами. Для конкретной платформы подрядчик должен показать, какой механизм управляет распределением и как подтверждается фактический результат. Число pod и процент запросов нельзя считать одной настройкой.
Ресурсы новой версии подбирают под направляемую нагрузку, а контрольная должна сохранять возможность принять трафик при возврате. Проверьте это до начала выпуска. Иначе небольшая canary-группа получит перегруженное приложение, либо остановка эксперимента отправит все запросы на уже уменьшенную и недостаточно мощную контрольную сторону.
Сделайте контрольную версию сопоставимой
Сравнивайте версии в один период и на похожих операциях. Вчерашний вечер и сегодняшнее утро могут различаться составом посетителей и нагрузкой независимо от релиза. Одновременная контрольная группа помогает увидеть такие изменения, но не устраняет все различия автоматически: новая версия может получать только мобильных пользователей или только один регион.
Для проверки составьте короткий профиль групп: устройства, источники обращений, маршруты, типы аккаунтов и сложность операций. Если canary обслуживает большие корзины, а контроль — преимущественно чтение каталога, сравнение средней задержки всего сайта мало что говорит о качестве изменения. Нужны сопоставимые срезы, в которых одинаково определены успешный результат и ошибка.
Внутренняя группа сотрудников удобна для первоначального допуска, но обычно отличается от покупателей знаниями, правами и поведением. Её успех разрешает следующий согласованный этап, а не доказывает пригодность выпуска для всей аудитории. Ограничение представительности следует сохранить в отчёте, особенно если редкие устройства и сценарии ещё не встречались.
Кроме относительного сравнения задайте абсолютные требования к результату. Если обе версии одинаково часто теряют заявки, отсутствие разницы между ними не делает выпуск приемлемым. Контроль показывает фон текущего периода, но не заменяет обязательные условия работы сайта. Поэтому в решении учитываются и различия групп, и нарушение важных правил самой услуги.
Какие показатели собирать по каждой версии
До подачи трафика убедитесь, что наблюдения можно связать с фактически обслужившей версией. В семантических соглашениях OpenTelemetry для версии компонента предусмотрен атрибут service.version. Название конкретного поля в вашей системе может отличаться; важно последовательно связывать выпуск, конфигурацию и полученные результаты.
| Показатель | Что сравнивать | Что способно исказить вывод |
|---|---|---|
| Технические ошибки | Ошибки относительно числа подходящих запросов по каждой версии | Разные маршруты или неодинаковое правило учёта |
| Задержка | Распределение времени выполнения сопоставимой операции | Смешение быстрых чтений и тяжёлых расчётов |
| Бизнес-результат | Доля операций, дошедших до согласованного конечного состояния | Повторы, незавершённые операции и разный срок ожидания |
| Фоновая обработка | Время завершения и ошибки задач, связанных с выпуском | Оценка только ответа веб-приложения |
| Общие зависимости | Изменение доступности, загрузки и ожидания общей инфраструктуры | Предположение, что контроль полностью изолирован |
Согласуйте знаменатель каждого процента. Для отправки формы это могут быть допустимые попытки отправки, а не все просмотры сайта. Для завершения заказа считайте уникальные операции по выбранному правилу, иначе повторные запросы одного клиента изменят результат. Ожидаемые ошибки проверки введённых данных отделяйте от технических сбоев, сохраняя возможность заметить поломку самой проверки.
Идентификаторы пользователей и заказов полезны для расследования конкретных случаев, но их не следует автоматически превращать в метки каждой агрегированной метрики. Для сравнения выпуска обычно достаточно версии, группы и ограниченного набора маршрутов. Детали операции сохраняют в разрешённых журналах без секретов и лишних персональных данных.
Проверьте влияние кеша на фактически показанную версию. Маршрутизатор может назначить пользователя в canary, но общий кеш вернёт ранее сохранённую страницу. Тогда метка назначения и реально выполненный код расходятся. В проекте нужен проверенный способ разделять необходимые ответы или учитывать их происхождение, сохраняя работоспособность кеширования. Контрольный запрос должен подтверждать всю цепочку выдачи, а не только намерение правила распределения.
Учебный пример: общий график скрывает проблему canary
Предположим, за один интервал получены 20 000 сопоставимых запросов к одному маршруту. В этом примере ошибка определяется одинаково для обеих версий; данные полные, а наблюдаемая доля canary равна 5% запросов. Это самостоятельный учебный срез, а не статистика реального сайта.
| Версия | Запросы | Ошибки | Доля ошибок |
|---|---|---|---|
| Контрольная | 19 000 | 38 | 38 / 19 000 = 0,2% |
| Canary | 1000 | 20 | 20 / 1000 = 2% |
| Обе версии вместе | 20 000 | 58 | 58 / 20 000 = 0,29% |
У новой версии доля ошибок в десять раз выше контрольной, а абсолютная разница равна 1,8 процентного пункта. Общий показатель 0,29% сильно сглаживает проблему небольшой группы. Поэтому решение о расширении нельзя принимать только по объединённому графику доступности или ошибок.
Допустим, условная политика команды запрещает расширение, если canary превышает 1% технических ошибок после 500 подходящих запросов. В приведённом срезе правило требует остановки: 1000 запросов и 2% ошибок. Порог выбран исключительно для примера; он не является универсальным стандартом, а 500 запросов не дают гарантии выявления редких дефектов.
Эти числа достаточны для выполнения заданного операционного правила, но сами по себе не доказывают причинность. Команда проверяет состав запросов, полноту наблюдений и окружение. Остановить расширение при подозрении можно раньше, чем окончательно установить причину: продолжать воздействие на клиентов ради красивой статистики не требуется.
Сколько трафика и времени нужно для решения
Универсального ответа «пять минут на пяти процентах» нет. За это время сайт может получить тысячи однотипных чтений и ни одного завершённого заказа. Тогда проверена лишь часть поведения. Перед релизом перечислите операции, которые должны встретиться, требуемое время ожидания результата и условия, при которых данных будет недостаточно.
Ноль ошибок на десяти запросах означает только отсутствие наблюдённых ошибок в этих десяти запросах. Это не доказательство безопасности всей версии. Для редких маршрутов можно увеличить период наблюдения, использовать контролируемую группу с нужным сценарием или дополнить проверку безопасным тестом. Увеличивать долю реальных клиентов только ради быстрого накопления числа следует лишь в пределах согласованного риска.
Бизнес-результаты часто запаздывают. Заказ, начатый в конце окна, ещё не обязан завершиться в этом же окне. Заранее задайте правило зрелости наблюдения: сколько времени ждут и как учитывают незавершённые операции. Сравнение разных по длительности ожидания групп создаёт ложное впечатление ухудшения новой версии.
Отсутствие телеметрии — отдельное состояние. Пустой ответ системы метрик, пропавшая метка версии или переставший обновляться график не равны нулю ошибок. При таком состоянии автоматическое расширение блокируют до восстановления доказательств, даже если общая главная страница продолжает открываться.
На сайте с небольшим потоком заранее предусмотрите предельную длительность этапа и решение при недостатке наблюдений. Можно завершить выпуск без расширения и подготовить другую проверку конкретного риска. Бессрочно оставленная экспериментальная группа усложняет поддержку, а принудительный переход по истечении срока скрывает отсутствие доказательств. В отчёте честно указывают, какие операции встретились, какие не встретились и почему решение осталось неопределённым.
Почему контроль тоже может ухудшиться из-за новой версии
Canary и контроль часто используют одну базу, очередь или внешний API. Новая версия может выполнять более тяжёлый запрос и занять общий ресурс. Тогда задержки вырастут у обеих групп, а небольшая разница между ними создаст впечатление, что выпуск ни при чём. Ограниченный процент входящего трафика не ограничивает автоматически весь ущерб.
Для выбранного изменения определите вероятные общие ограничения. Например, после изменения поиска наблюдают не только время ответа двух версий, но и ожидание общей базы. После переработки отправки заявок проверяют поток задач и результат обработки. Это авторская схема проверки риска: набор наблюдений выбирается по тому, что меняет конкретный релиз.
Одинаковое ухудшение обеих версий может быть вызвано и независимой аварией поставщика. Поэтому сохраняйте отметки выпуска, изменения нагрузки и состояние зависимостей. Решение об остановке расширения допускает неопределённость; утверждение о причине требует дополнительных данных. Одновременные изменения в этой же цепочке усложняют такое разбирательство.
Подготовьте данные, сессии и фоновые обработчики
AWS Builders’ Library о безопасном возврате рассматривает совместимость версий, которые взаимодействуют через данные и протоколы. Для canary это непосредственное условие: контрольная версия должна корректно работать с тем состоянием, которое новая версия уже успела создать. Обратная маршрутизация не отменяет изменения в хранилище.
Проверьте формат сессии, API и записей, которые читают обе версии. Если canary создаёт новый статус заказа, старый обработчик не должен принимать его за ошибку или незаметно переписывать. Изменения, которые удаляют необходимые прежней версии данные, требуют отдельной подготовки совместимости до запуска такого сравнения.
Веб-маршрутизация не определяет автоматически, какой воркер возьмёт задачу. Укажите допустимые версии производителей и потребителей сообщений, правила назначения и способ связать конечный результат с исходной группой. Возвращая трафик на контроль, учитывайте уже выполняющиеся задания и действия, отправленные во внешние системы.
Новая версия способна отправить письмо, создать документ или инициировать платёж. Такие действия не исчезают при остановке canary. Повторы должны следовать предусмотренным правилам проекта, а неопределённые результаты требуют сверки. Если обратимость изменения не доказана, небольшой охват не заменяет её: сначала ограничивают риск самого действия.
Расширение, пауза, остановка и возврат
Каждый этап должен завершаться явным решением. Допустимы три основных результата: критерии выполнены, критерии нарушены или данных недостаточно. В Argo Rollouts предусмотрен результат Inconclusive, при котором процесс приостанавливается и требует решения. Конкретные условия такого результата настраивают; его нельзя считать синонимом успешного анализа.
| Наблюдение | Решение команды |
|---|---|
| Достаточные наблюдения, критерии выполнены, зависимости стабильны | Перейти к следующему согласованному охвату |
| Нет данных по важному маршруту или результат ещё не наступил | Сохранить текущий этап и определить способ получения наблюдений |
| Подтверждено нарушение стоп-критерия | Прекратить расширение и выполнить подготовленное действие ограничения воздействия |
| Нарушена совместимость данных | Не выполнять слепой возврат; применить заранее предусмотренную процедуру |
Лестница охвата, например 5%, 20%, 50% и полный выпуск, может быть удобной учебной схемой, но не обязательным рецептом. Для каждого шага проверяют фактическое распределение, достаточность ресурсов и результаты. Следующий процент не должен включаться лишь потому, что истёк таймер.
После решения о возврате подтвердите, что новые запросы действительно направляются на контроль, а остающиеся сессии и задачи обработаны по плану. Сохраните версии, границы интервала и затронутые идентификаторы для сверки. Отметка «вес canary равен нулю» не доказывает отсутствие отложенных последствий.
Карточка канареечного релиза для владельца и подрядчика
До выпуска заполните одну карточку, которая связывает технические настройки с решением бизнеса. Она нужна и небольшой команде: без неё пауза часто превращается в спор о том, достаточно ли зелёных графиков для продолжения.
- Изменение: конкретная функция, версии кода и конфигурации, ожидаемый результат.
- Группа: единица назначения, правило устойчивого распределения и исключённые сценарии.
- Контроль: действующая версия, сравниваемые маршруты и существенные различия групп.
- Наблюдения: ошибки, задержки, бизнес-результат и состояние общих зависимостей.
- Достаточность: минимальные наблюдения по нужным операциям и ожидание отложенных результатов.
- Этапы: охват, условия перехода, предел воздействия и ответственный за решение.
- Стоп: немедленные запреты, правила паузы при потере данных и проверенный возврат.
- Совместимость: данные, сессии, сообщения, воркеры и внешние действия.
- Завершение: проверка полного выпуска, оставшихся задач и сохранение отчёта.
Перед первым применением проверьте управление маршрутом и реакцию на учебный сигнал в безопасной среде. Исполнитель должен уметь отличить остановку расширения от возврата трафика и увидеть результат каждого действия. Эти операции нельзя впервые осваивать на клиентах во время неудачного выпуска.
Продолжайте наблюдение после полного выпуска
Когда новая версия получила весь согласованный трафик, короткий эксперимент закончен, но отложенные последствия ещё возможны. Убедитесь, что завершаются фоновые операции, ресурсы выдерживают нагрузку, а старые сессии не сталкиваются с несовместимостью. Срок дополнительного наблюдения выбирают по длительности реальных процессов сайта.
Сохраните итоговую карточку с фактическим охватом, интервалами сравнения и решениями по каждому этапу. Она помогает объяснить, почему выпуск разрешили, и улучшить следующую процедуру. Если проблема всё же обнаружилась позднее, эти сведения покажут, не встречался ли нужный сценарий вообще или существующий показатель оказался недостаточно чувствительным к его отказу.
Во время выпуска контролируйте внешнюю HTTP-доступность сайта с помощью SiteGuard. Для решения о расширении canary используйте собственные метрики по версиям и результатам операций.