Canary deployment: где ломается выкат в прод
Классический выкат в прод отправляет новую версию сразу на весь трафик: поднимаются реплики с новым образом, старые гасятся, балансировщик переключает всех разом. Если в коде ошибка — неверный запрос к схеме данных, утечка соединений, падение на редком сценарии — её одновременно получают все пользователи. Первые обращения в поддержку приходят раньше, чем графики успевают показать рост доли ошибок.
Дальше начинается самое дорогое — откат релиза. Возврат на предыдущий образ сам по себе быстрый, но если вместе с кодом уехала миграция схемы, откат уже неполный: данные записаны в новом формате, часть обработчиков о них не знает. Добавьте сюда прогрев, проверки готовности и повторный выкат — и неудачное обновление растягивается на часы ручных решений.
Ошибка в новом коде редко бывает тотальной. Чаще ломается один сценарий: оплата для части регионов, редкий формат файла на входе, ветка при пустом поле. Разница между «сломалось у всех» и «сломалось у нескольких процентов» — это разница между аварией и незаметной деградацией, о которой узнают из метрик, а не из жалоб.
Разбираем, как это закрывается. Канареечный выкат (canary deployment) на Argo Rollouts переводит на новую версию сначала небольшую долю трафика, сверяет долю ошибок и время ответа с базовой линией и откатывает автоматически — без ожидания дежурного и без пересборки.
Что даёт постепенный выкат на часть трафика
Постепенный выкат — это перенос риска с релиза на малую долю трафика. Новая версия получает вес не целиком: 5%, затем 10, 25, 50 — с паузой на каждом шаге. Пока контроллер Argo Rollouts видит, что метрики канареечного и стабильного окружений сопоставимы, вес растёт; при отклонении трафик возвращается на прежнюю версию.
Проверки шага задаются декларативно: доля ответов с ошибкой, 95-й перцентиль задержки, число перезапусков контейнеров. Пока пороги соблюдены, выкат идёт дальше сам, без ручного подтверждения. Время отката измеряется десятками секунд, потому что откат — это смена веса, а не пересборка и повторное развёртывание.
Главное — устранённый класс отказов. Дефект в коде или в настройках затрагивает малую долю пользователей вместо всех, и разбор остаётся локальным инцидентом, а не общей аварией с простоем. Доля затронутых пользователей становится управляемой величиной: её задают заранее и меняют по ходу выката.
Наблюдаемость релиза растёт вместе с этим: запросы, логи и трассировки помечены версией, поэтому видно, какую часть нагрузки держит канареечное окружение и как она влияет на общую картину. Панель релиза показывает смену веса и сработавшие проверки в одной шкале времени — по ней видно, какой шаг прошёл гладко, а какой вызвал откат.
Отсюда и выбор ширины канала: сначала выпускают на внутренний сегмент или на один регион, затем расширяют до полного веса. Такая схема не заменяет тесты, но снимает главную цену ошибки — массовость.
Canary deployment против сине-зелёного и полного выката
Все три схемы решают одну задачу — довести новую версию до пользователей, но по-разному распоряжаются трафиком и ценой ошибки. Полный выкат меняет все экземпляры сразу: просто и предсказуемо, но регрессия мгновенно уходит на всю аудиторию. Сине-зелёный держит две среды и переводит трафик целиком: откат занимает секунды, зато новая версия сразу получает полную боевую нагрузку.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полный выкат | Внутренние сервисы и редкие релизы, где возврат — повторный выпуск прошлой сборки | Ошибка видна всей аудитории, время между выпуском и возвратом не ограничено |
| Сине-зелёный выкат | Нужен мгновенный откат на прошлую версию и есть запас мощностей | Ресурсы на время выпуска удваиваются, реальный трафик не проверяет версию по частям, миграции схемы требуют совместимости обеих версий |
| Canary с переключением по весам (Argo Rollouts) | Частые релизы, ровный трафик и настроенные метрики ошибок и задержек | Нужна маршрутизация по весам и автоматический разбор показателей, усложняются сессии и кэш |
Постепенный релиз выигрывает там, где есть наблюдаемость: вес растёт от долей процента до сотни, и регрессию отсекают на первых процентах трафика, пока её видят единицы. Если трафик невелик и метрики шумят, малый вес статистики не даёт — тогда честнее сине-зелёный выкат или полный выпуск с быстрым возвратом. Критерий выбора — не мода, а метрики, автоматика отката и совместимость миграций схемы.
Этапы внедрения постепенного выката в релизы
Постепенный выкат не прикручивается поверх конвейера — он опирается на то, как устроены сборка, конфигурация и наблюдаемость. Поэтому этапы внедрения идут от аудита релизного процесса к регламенту, по которому дежурный откатывает версию без автора релиза.
- Аудит релизного процесса. Смотрим, как собираются образы, чем отличаются окружения, есть ли метрики и трассировка по сервису. Без базовой линии по ошибкам и времени ответа канареечный выкат (canary deployment) сравнивать не с чем.
- Подготовка манифестов и разметки. Приложение получает стабильный и канареечный наборы подов, трафик делится по весам через управляемый объект вроде Argo Rollouts, версия видна в метках и логах — иначе инцидент не отличить от прошлого релиза.
- Проверка на предпродуктивной среде. Прогоняем тот же маршрут на копии продакшена: шаги весов, паузы, анализ. Здесь же проверяем откат — он должен возвращать трафик и поды, а не оставлять половинчатое состояние.
- Настройка метрик и порогов. Описываем, что считаем деградацией: доля ответов с ошибкой, задержка на 95-м процентиле, нехватка ресурсов. Пороги выводим из наблюдаемого поведения, иначе автоматический откат срабатывает на шуме.
- Обкатка на реальном релизе. Первый выкат ведём с ручным подтверждением шагов, инженер рядом смотрит метрики. Так видно реальную скорость прогрева и то, какие алерты шумят впустую.
- Передача регламента. Отдаём команде документ: шаги и паузы, условия автоматического отката, действия дежурного, порядок ручного возврата. Канареечный этап становится обязательным пунктом чек-листа релиза.
Конфигурации, схемы трафика и регламенты передачи
Внедрение заканчивается не работающим выкатом, а набором артефактов, по которым ваша команда сама меняет параметры и разбирает сбои. Всё это остаётся в вашем репозитории и кластере: конфигурации под контролем версий, доступы — в вашем контуре, инструкции привязаны к шагам процесса, а не к конкретным людям.
- Конфигурации выката — описание объекта Rollout: доля трафика на канареечной версии, паузы между шагами, условия автоматического продвижения. Правки идут через merge request, а не руками в кластере.
- Схема трафика — как балансировщик и Service делят запросы между стабильной и новой версией, включая удержание сессии и маршрутизацию по заголовку для внутренних проверок. Отдаём диаграммой и рабочими манифестами.
- Политики доступа — роли на продвижение и откат выката, разделение прав между разработкой и эксплуатацией, доступ к дашбордам метрик, запрет ручных изменений в продовом пространстве имён.
- Регламент отката — что считаем деградацией, по каким метрикам, кто принимает решение, какие команды выполняются и в каком порядке. Автоматический возврат по порогу ошибок описан отдельно от ручного.
- Правила анализа метрик — пороги по успешности запросов, задержке и частоте ошибок, время наблюдения на каждом шаге, поведение при нехватке данных от сервиса метрик.
- Документация по инцидентам — шаблон разбора: на каком шаге выката выросли ошибки, какие метрики это показали, что изменили в конфигурации. Накопленные разборы задают следующие настройки шагов.
- Инструкция для дежурного — короткий сценарий: как приостановить выкат, как вернуть предыдущую версию, кого оповещать и с каким интервалом.
Кейс: доля затронутых сбоем пользователей упала в 20 раз
Что было до внедрения
Заказчик выпускал обновления микросервиса целиком: новая версия вставала сразу на все рабочие поды. Любая ошибка в сборке затрагивала 100% активных пользователей, а сигнал приходил извне — от обращений в поддержку, а не из метрик. Откат запускали вручную, на это уходило до 40 минут, и всё это время сбой продолжался.
Что изменили
Мы перевели выкат на постепенный сценарий в Argo Rollouts: новая версия получала сначала 5% трафика, затем 20% и 50%, и только потом 100%. На каждом шаге система сверяла частоту ошибок и задержку ответа с базовой линией и удерживала релиз, если показатель выходил за порог. Шаги, пороги и условия паузы описали в манифесте рядом с сервисом — выкат стал частью репозитория, а не ручной операцией.
Что стало
Доля затронутых сбоем пользователей сократилась в 20 раз: проблемную версию успевало увидеть не больше 5% аудитории. Время восстановления упало с 40 минут до 2–3 — откат срабатывал автоматически по метрике, без участия дежурного инженера. За квартал ни один дефектный выпуск не дошёл до полного трафика, а команда перестала бояться релизов в конце недели.
Что делать, если релизы в кластере уже идут вручную
Переход в уже развёрнутом кластере делают не вместо ручного выката, а рядом с ним: новый контур поднимается параллельно, часть сервисов продолжает выходить по старой схеме, остальные переводят на канареечный выкат (canary deployment) с постепенной долей трафика. Пока новая версия не подтвердит себя на проверках, прежний путь остаётся живым и служит откатом — останавливать релизы не приходится ни на день.
Миграция релизного процесса начинается с инвентаризации: какие сервисы развёрнуты, какие манифесты им соответствуют, кто нажимает кнопку и что проверяется после. Без этой картины пошаговый переход превращается в переписывание кластера целиком — именно тот сценарий, где ломается прод.
Дальше переводят по одному сервису, начиная с наименее критичного. В манифест добавляется объект выката, описывающий шаги и условия продвижения, к нему подключаются проверки готовности и метрики, доля трафика на новую версию растёт небольшими шагами, а каждый шаг подтверждается вручную. Результат виден на той же неделе: версия получает реальную нагрузку, а решение о продвижении остаётся за инженером.
Обратимость здесь важнее скорости. Если метрики просаживаются, трафик возвращается на стабильную версию одной командой — это минуты вместо часов ручной пересборки. Когда несколько релизов подряд проходят без происшествий, ручные подтверждения снимаются точечно, а не все сразу.
Сомнения по метрикам, откату и нагрузке на прод
Пороги отката — не догадки, а параметры, которые мы согласуем до выката. Метрики релиза: доля ошибок новой версии относительно базовой, задержка на 95-м проценте запросов и доля успешных бизнес-операций. Пока канареечная версия держит 5–10% трафика, выход за порог автоматически останавливает выкат и возвращает трафик на стабильную версию.
Ниже — сомнения, которые чаще всего всплывают на согласовании.
Как новая версия влияет на нагрузку на базу данных?
Канареечная доля идёт параллельно со стабильной, поэтому запросы обеих версий живут в одной схеме. Миграции делаем расширяющими: сначала добавляем колонку или индекс, совместимые со старым кодом, затем переключаем приложение и только после вывода прежней версии убираем лишнее. Обратные изменения применяем после полной замены — иначе откат упрётся в несовместимую схему.
Кто принимает решение об остановке выката?
Автоматика по порогам: превышение доли ошибок или задержки возвращает трафик на стабильную версию без участия дежурного. Ручная остановка остаётся — она нужна, когда снаружи видно то, чего нет в метриках, например жалобы на конкретный сценарий.
Какие ограничения у подхода?
Канареечный выкат бесполезен, если трафик слишком мал для статистики, если нет наблюдаемости по нужным метрикам или если релиз меняет формат данных несовместимо. Фоновые задания и очереди делит не балансировщик, а сами обработчики — для них проверку строим отдельно, по доле обрабатываемых задач.
Обсудим задачу: вернёмся с оценкой и планом
Чтобы разговор был предметным, достаточно принести текущее состояние доставки изменений: как релиз попадает в прод сегодня, есть ли отдельный контур для проверок, какие метрики уже собираются с приложения. Часть данных может отсутствовать — требования к инфраструктуре и правила выката сформулируем вместе, опираясь на то, что есть.
В ответ вы получаете рабочую рамку, а не общие соображения: оценку сроков по этапам, план внедрения с точками контроля и схему разделения трафика между версиями. Ниже — что обычно нужно от заказчика и что мы готовим со своей стороны.
- Доступы: чтение кластера, репозитория манифестов и системы сборки образов — этого достаточно, чтобы разобрать текущий процесс, ничего не меняя.
- Текущий способ выката: где именно принимается решение о переходе на новую версию — вручную, скриптом или правилами конвейера.
- Наблюдаемость: какие метрики снимаются, куда пишутся и можно ли сравнить две версии по одинаковым правилам.
- Требования к инфраструктуре: запас ресурсов под две версии одновременно, отдельный контур для проверок, управление трафиком на входе в кластер.
- Правила отката: по какому показателю выкат считается неудачным и сколько времени занимает возврат на предыдущую версию.
- Роли и границы: кто расширяет долю трафика, кто дежурит и как передаётся управление после запуска.
Опишите задачу в свободной форме — вернёмся с оценкой и планом внедрения, где будет виден порядок шагов, состав работ и зоны ответственности.
