Прогрессивная доставка: канарейка, blue-green и флаги

Деплой — это не релиз

Вот рамка, на которой держится весь урок. Деплой — это размещение нового кода на серверах: бинарь работает, контейнер поднят. Релиз — это направление пользовательского трафика к этому коду: решение, кто на самом деле на него попадёт. Прошлые уроки довели тебя до опубликованного артефакта; они не сказали, что хоть один пользователь уже должен его увидеть. Сеньорский ход — считать это двумя отдельными переключателями. Выкатывай код тёмным — задеплоенным, но без трафика — и затем крути ручку трафика вверх постепенно, следя за сигналами, готовый повернуть её обратно в тот момент, когда они деградируют. Всё ниже — это разные механизмы одной идеи: отдели «код здесь» от «пользователи на нём» и навесь ограничитель радиуса поражения на второй переключатель.

Четыре стратегии выката

# big-bang (recreate): останови всё, запусти новую версию — простой + 100% радиуса поражения
strategy:
  type: Recreate          # старые поды умирают, новые стартуют: зазор, где никто не обслуживает

# rolling: заменяй инстансы партиями — без простоя, но две версии работают одновременно
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 0      # почти дефолт k8s: инкрементально, но БЕЗ явного гейта трафика

• Big-bang (recreate / всё-сразу): останови старую версию, запусти новую. Есть зазор простоя, и в момент, когда она поднялась, радиус поражения — 100%: все пользователи разом на коде, непроверенном в проде. Это провал из Hook. Приемлемо только для крошечных или внутренних приложений, где сбой не страшен.
• Rolling: заменяй инстансы партия за партией (дефолт Kubernetes). Без простоя — поэтому кажется безопасным — но две версии работают одновременно, так что они обязаны быть обратно/прямо совместимы, а плохая версия всё равно доходит до пользователей инкрементально без явного гейта, следящего, здорова ли она. Rolling управляет доступностью, а не риском.
• Blue-green: подними два полных окружения. Задеплой в GREEN (простаивающее), прогони smoke-тест в изоляции, затем атомарно переключи балансировщик / роутер с BLUE на GREEN. Переключение мгновенно, и откат тоже мгновенный — переключи роутер обратно на BLUE. Цена — примерно 2x инфраструктуры на время переключения, и трудная часть — общее состояние: обе версии обычно ходят в одну базу, так что изменение схемы должно быть совместимо и с BLUE, и с GREEN через весь флип.
• Canary (канарейка): направь маленький процент реального трафика (1-5%) на новую версию, следи за её error rate, латентностью и бизнес-метриками против старой, затем поднимай 5 → 25 → 50 → 100%, если остаётся здоровой, или прерывай, если нет. Канарейка ловит проблемы на реальном продовом трафике при крошечном радиусе поражения — ровно тот класс багов, что staging пропустил.

Фича-флаги: переключатель релиза, которому не нужен редеплой

Канарейка двигает трафик на уровне инфраструктуры. Фича-флаг переносит решение о релизе на уровень приложения: оберни новое поведение в условие, задеплой с флагом OFF, и код едет тёмным, пока пользователи продолжают получать старый путь. Затем ты переключаешь флаг — для 1% пользователей, потом 10%, потом всех — независимо от любого деплоя. Новый код уже был на каждом сервере; ты просто меняешь значение конфига.

// новый код задеплоен везде, но тёмный, пока флаг его не откроет
if (flags.isEnabled("new-checkout-pipeline", { userId })) {
  return runNewCheckout(order);   // открыт на 1% -> 10% -> 100% через конфиг, без редеплоя
}
return runLegacyCheckout(order);  // все остальные, без изменений

Два свойства делают это любимым инструментом сеньора. Первое — это мгновенный kill switch: если new-checkout-pipeline ведёт себя плохо, ты переключаешь флаг обратно в OFF, и каждый пользователь на старом пути за секунды — без прогона пайплайна, без пересборки образа, без редеплоя. Второе — таргетинг по пользователю / проценту, что и питает A/B-тесты и dark launch (гоняй новый путь, отбрасывай его результат, просто измеряй его нагрузку). Если у тебя есть флаг, который «временно включили» полгода назад — ты уже в колонке затрат. Цена реальна: долг флагов. Каждый флаг — это ветка в коде и строка в конфиге; устаревшие флаги, которые так и не убрали, превращаются в комбинаторный бардак, который никто не смеет удалить. Флаги — это рычаг релиза, а не постоянный дом: открой их, узнай что нужно, потом удали.

Автоматический откат: решает гейт, а не человек

Всё выше просто безопаснее, если человек смотрит. Сеньорская версия — автоматическая. Контроллер прогрессивной доставки — Argo Rollouts, Flagger или логика в твоём деплой-пайплайне — поднимает канарейку по расписанию и на каждом шаге прогоняет аналитический запрос к твоим метрикам: error rate, p99 латентность, скорость прожига SLO. Если запрос пробивает порог, контроллер авто-прерывает и откатывает — сдвигает трафик обратно на стабильную версию — без человека в петле. Вот ключевое число, которое надо усвоить: решение об откате завязано на метрики, а не на ощущения и не на то, что кто-то случайно пялится в дашборд в 16:00.

# Канарейка Argo Rollouts с шагом анализа по метрике (набросок)
strategy:
  canary:
    steps:
      - setWeight: 5            # 5% трафика на новую версию
      - analysis:               # запрос к Prometheus; авто-прерывание при провале
          templates: [{ templateName: error-rate }]
      - setWeight: 25
      - analysis: { templates: [{ templateName: error-rate }] }
      - setWeight: 50
      - setWeight: 100          # полное продвижение только если каждый гейт прошёл

Прогони инцидент из Hook через это. Плохая версия едет на 5% трафика. Баг сериализации срабатывает под реальной конкуренцией, и аналитический запрос видит, как error rate на канарейке скачет за порог за секунды. Контроллер прерывает на 5% и сдвигает трафик обратно на стабильную — автоматически. Радиус поражения: 5% пользователей на несколько секунд вместо 100% пользователей на минуты. Баг всё равно случился; прогрессивная доставка просто сделала его не-событием.