← назад к разделу

Образ собран и проверен — остался последний и самый рискованный шаг: встреча нового кода с реальным трафиком. Стратегии релиза отличаются одним параметром — сколько пользователей встретят проблему и как быстро вы вернётесь назад. Плюс ортогональный всем стратегиям инструмент — feature flags.

Rolling update: дефолт

Реплики заменяются порциями; ёмкость не проседает; кривая версия с честной readiness не получает трафик. Механика разобрана в k8s-серии — здесь её место в ряду: это дефолт по соотношению цены и защиты. Чего rolling не даёт: мгновенного отката (откат — это ещё один rolling), защиты от ошибок, которые проявляются под полным трафиком, и контроля «кто именно увидит новое».

Обязательное условие любой постепенной стратегии (rolling, canary): две версии работают одновременно — значит, N−1 совместимость схемы БД и контрактов событий не опция, а входной билет.

Blue-green: мгновенный переключатель

Два полных окружения: green несёт трафик, в blue деплоится новая версия, прогревается и проверяется — затем трафик переключается целиком (балансировщиком/Service-ом). Откат — переключение обратно, секунды.

Покупает: мгновенный откат и проверку новой версии в проде до трафика. Платится: двойная ёмкость на время выкатки и честный ответ на вопрос про состояние — БД-то одна: миграции должны быть совместимы с обеими версиями (тот же expand-contract), а фоновые обработчики (полеры, консьюмеры) не должны работать в две версии одновременно — их переключают, а не дублируют. Ниша: релизы с высокой ценой ошибки и редкой частотой; системы, где секунды отката важнее стоимости второго окружения.

Canary: процент и метрики

Новая версия получает малую долю трафика (1% → 5% → 25% → 100%), и продвижение по ступеням происходит по метрикам: ошибки, латентность p99, бизнес-показатели канарейки против основной группы. Деградация — автоматический откат, который заметила сотая часть пользователей.

Цена — самая высокая из всех: маршрутизация с весами (mesh или Gateway, Argo Rollouts/Flagger как автоматика), метрики, которым можно верить (canary без надёжной телеметрии — это rolling с лишними шагами), и время — выкатка размазывается на часы. Canary оправдан при большом трафике (на 100 RPS канарейка в 1% статистически слепа) и зрелой наблюдаемости.

Feature flags: деплой ≠ релиз

Флаги работают поверх любой стратегии и решают другую задачу: код едет в прод выключенным, включается без деплоя — на всех, на процент, на сегмент:

if (featureFlags.isEnabled("new-pricing", customerId)) {
    return newPricingPolicy.calculate(order);
}
return currentPricingPolicy.calculate(order);

Что это даёт конвейеру: деплой становится частым и скучным (выключенный код не риск), включение — обратимым за секунды без отката, расскатка — постепенной по пользователям (продуктовая canary без инфраструктуры весов). Что требует: дисциплины жизненного цикла — флаг с датой и владельцем, удаление после полной раскатки; кодовая база, где сотня вечных флагов переплетена условиями, хуже любого монолита. И тестовый вопрос: критические комбинации флагов должны быть покрыты — комбинаторику не победить, но главные пути «вкл» и «выкл» — обязаны быть зелёными.

Инструменты — от таблицы в PG с кешем до Unleash/самописного сервиса; для старта таблицы достаточно (Оккам).

Выбор стратегии

RollingBlue-greenCanary+ Feature flags
Радиус ошибкиВсе, постепенноВсе, мгновенноПроцентУправляемый сегмент
Скорость откатаМинуты (обратный rolling)СекундыАвтоматика по метрикамСекунды (выключить)
ЦенаНоль сверх k8sДвойная ёмкостьМаршрутизация + телеметрияДисциплина флагов
ТребуетЧестную readiness, N−1Совместимые миграции, одна БДТрафик + метрикиЖизненный цикл флагов
КогдаДефолтДорогая ошибка, мгновенный откатБольшой трафик, зрелая observabilityВсегда полезны

Практичная связка для большинства команд: rolling + feature flags, canary — когда трафик и телеметрия дозрели, blue-green — точечно для самых рискованных систем.

Антипаттерны

  • Canary без метрик-критериев. «Посмотрим глазами в Grafana» — это не canary, это надежда. Продвижение по ступеням — только по формальным критериям.
  • Blue-green с несовместимой миграцией. Переключили на blue, мигрировали схему — green умер; откат-«за секунды» превратился в восстановление из бэкапа.
  • Вечные флаги. Флаг без даты удаления через год становится частью архитектуры, которую никто не понимает.
  • Релизные окна по пятницам в полночь. Симптом, что деплой страшен; лечение — не запрет деплоев, а флаги, стратегии и скучный конвейер.
  • Фоновые воркеры под canary. Консьюмер двух версий, по-разному обрабатывающий одну очередь, — рассинхрон данных; для воркеров — Recreate или переключение, не проценты.

Что почитать дальше

  • Деплой в Kubernetes — механика rolling и N−1 миграций.
  • Принципы конвейера — деплой ≠ релиз как принцип.
  • Observability Style Guide — метрики, без которых canary слеп.
  • Ветки и релизный цикл — как код доезжает до этих стратегий.