В продакшене новая версия получает лишь часть трафика, но метрики ухудшаются не сразу. Как механизм canary-релиза помогает остановить неудачное изменение?
Canary-релиз ограничивает долю пользователей, направляемых на новую версию, и сравнивает её показатели с базовой версией. Если заранее заданные метрики качества выходят за допустимые пределы, система прекращает увеличение трафика и возвращает запросы на стабильную версию. Это уменьшает радиус отказа, но не устраняет необходимость в корректных метриках, маршрутизации и совместимых изменениях данных.
Подход появился как ответ на риск крупных развёртываний, когда ошибка новой версии сразу затрагивает всех пользователей. Вместо переключения всей системы за один момент команды стали постепенно увеличивать воздействие изменения и получать обратную связь на ограниченной аудитории.
Canary-релизы особенно полезны в системах с автоматизированными поставками. Они переносят часть проверки из тестовой среды в реальную эксплуатацию, где проявляются особенности нагрузки, данных и взаимодействия с зависимостями.
Новая версия может успешно проходить функциональные тесты, но ошибаться при редких входных данных, реальной нагрузке или взаимодействии с конкретной зависимостью. Если сразу направить на неё весь трафик, локальная ошибка станет массовым инцидентом.
При слишком малой доле трафика проблема может не проявиться, а при слишком позднем обнаружении ущерб уже будет значительным. Дополнительный риск создают неинформативные метрики: средняя задержка может выглядеть нормально, пока растёт доля ошибок для отдельного типа запросов.
Canary-схема содержит стабильную версию и новую версию, между которыми управляемо распределяется трафик. Сначала новой версии назначают небольшую долю запросов, затем при приемлемых результатах постепенно увеличивают её, например по этапам, а не одним переключением.
На каждом этапе сравнивают ошибки, задержку, насыщение ресурсов, бизнес-метрики и состояние зависимостей. Важно сравнивать canary не с историческим средним, а по возможности с одновременно работающей базовой версией: так меньше влияние изменений нагрузки и внешних условий.
Автоматическая проверка может остановить продвижение, если показатель превышает порог или статистически заметно хуже базовой группы. Остановка означает прекращение увеличения доли, а откат обычно выполняется перенаправлением трафика на стабильную версию и последующим разбором новой.
Маршрутизация может выполняться на уровне балансировщика, шлюза, сервисной mesh-системы или другого компонента, способного выбирать версию по доле, пользователю, региону или признаку запроса. Механизм распределения должен сохранять предсказуемость: например, один пользователь может быть закреплён за одной версией, чтобы его сессия не меняла поведение между запросами.
Canary не гарантирует обнаружение всех дефектов. Редкие сценарии, долгие фоновые операции, проблемы восстановления и ошибки миграции данных могут не проявиться на ограниченной выборке.
Откат кода также не всегда откатывает изменения в базе данных. Поэтому изменения схемы обычно проектируют обратно совместимыми: сначала добавляют совместимые структуры, затем переводят чтение и запись, а удаление старых структур выполняют отдельным безопасным этапом.
Команда выпускает новую версию API, в которой изменён алгоритм расчёта стоимости. После направления на неё десяти процентов трафика средняя задержка остаётся нормальной, но для части клиентов растёт доля ответов с ошибкой. Немедленное переключение всех пользователей было бы опасным, потому что ошибка зависит от типа тарифа и не видна на общей средней метрике.
Рассматривались три варианта. Полное переключение было бы простым, но создало бы большой радиус отказа. Ожидание только результатов нагрузочного теста не учитывало бы реальные данные. Ручное наблюдение за несколькими графиками снижало бы автоматизацию и увеличивало время реакции.
Выбрали canary с отдельными метриками по тарифам, автоматическим порогом ошибок и постепенным увеличением доли трафика. Продвижение остановилось на первом этапе, запросы вернули на стабильную версию, а команда обнаружила ошибку в обработке редкого типа тарифа. Пользователей затронуло ограниченное число запросов, а не весь продакшен.
Обычный canary может пропустить такой дефект из-за недостаточной выборки. Для снижения риска используют сегментацию аудитории, репрезентативный набор трафика, увеличенную длительность этапа и отдельные метрики по критичным сценариям.
Полезен и shadow-трафик, при котором копия запросов отправляется новой версии без использования её ответа пользователем. Он позволяет проверить совместимость и нагрузочное поведение, но не выявляет все пользовательские последствия, потому что ответ shadow-версии не участвует в реальном бизнес-процессе.
Нужна одновременно работающая базовая группа, сравнимая по времени, типам запросов и окружению. Анализируют не только абсолютное значение метрики canary, но и разницу между canary и baseline, а также объём выборки и длительность наблюдения.
Если версии размещены в разных зонах или используют разные зависимости, сравнение может быть искажено. Поэтому по возможности выравнивают инфраструктуру, учитывают распределение трафика и не принимают решение по единичному кратковременному всплеску без оценки его значимости.
Потому что новая версия могла изменить данные, отправить внешние события или выполнить необратимую операцию. Возврат маршрутизации к старому коду не отменяет такие побочные эффекты.
Безопасный релиз проектируют с учётом этого ограничения: применяют обратно совместимые изменения схемы, идемпотентные операции, контроль внешних сообщений и отдельные процедуры компенсации. Canary снижает вероятность массового ущерба, но не заменяет проектирование обратимой поставки.