Стратегии деплоя: rolling, blue-green, canary, feature flags, откат

↑ Этап 3 · CI-CD

Обязательно~5 мин чтенияУровень: middle

Зачем это на собесе

Ключевой вопрос про релизы без простоя и откат: нужно сравнить стратегии и назвать компромиссы.

Сравнение

Стратегия	Суть	Простой	Откат	Ресурсы	Риск
Recreate	остановить старую → запустить новую	есть	передеплой	1×	высокий
Rolling update	постепенная замена экземпляров	нет	откат rolling (минуты)	~1× + surge	средний (две версии одновременно)
Blue-Green	две полные среды; переключение трафика	нет	мгновенный (переключить обратно)	2×	низкий
Canary	небольшая доля трафика на новую версию, затем расширение	нет	быстрый (убрать canary)	1× + canary	очень низкий (ограниченный охват)
A/B testing	разные версии для сегментов пользователей ради метрик	нет			бизнес-эксперимент
Shadow (mirroring)	копия трафика на новую версию без влияния на ответы	нет		2×	проверка без риска
Feature flags	код выкачен, фича выключена; включение отдельно	нет	выключить флаг	1×	минимальный

Rolling update (Kubernetes)

strategy:
  type: RollingUpdate
  rollingUpdate: { maxSurge: 25%, maxUnavailable: 0 }       # не терять ёмкость

Поды заменяются порциями; трафик идёт только на Ready поды (readiness probe). Требования: обратная совместимость версий (две версии работают вместе), корректный graceful shutdown, minReadySeconds, PodDisruptionBudget. Откат: kubectl rollout undo deployment/api, helm rollback.

Blue-Green

Blue (v1, активна)  ◀── трафик ── LB/Ingress/Service
Green (v2, новая)       проверяем smoke-тестами, прогреваем
        → переключение селектора Service / weight в Ingress / DNS
Откат: переключить обратно на Blue (пока не удалена)

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

Canary

Постепенно: 1% → 5% → 25% → 50% → 100% с анализом метрик на каждом шаге (ошибки, латентность, бизнес-метрики). Автоматизация: Argo Rollouts, Flagger (Istio/Linkerd/NGINX/Traefik), метрики из Prometheus; автооткат при нарушении SLO.

# Argo Rollouts
strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - analysis: { templates: [{ templateName: success-rate }] }
      - setWeight: 50
      - pause: { duration: 10m }

Маршрутизация по весу, заголовку (X-Canary: true), cookie, пользователям (внутренние сначала). Nginx Ingress: nginx.ingress.kubernetes.io/canary: "true", canary-weight.

Feature flags

Разделение деплоя (код в проде) и релиза (включение функциональности):

• включение по пользователям, процентам, окружениям, регионам; kill switch (мгновенное отключение);
• инструменты: LaunchDarkly, Unleash, Flagsmith, GrowthBook, OpenFeature (стандарт SDK), собственные;
• trunk-based development с незавершённым кодом за флагом;
• риски: «мёртвые флаги» (чистить), комбинаторика состояний, тестирование обеих веток, безопасность (флаги на клиенте публичны), производительность вычисления.

Откат

Должен быть быстрым, автоматическим, проверенным.

• откат артефакта: предыдущий неизменяемый тег образа/версия чарта (helm rollback api 12);
• откат конфигурации/флага: мгновенно;
• БД: совместимые миграции позволяют откатить только код; деструктивные изменения откладываются (contract позже);
• критерии автоотката: рост 5xx, латентность, провал readiness/smoke, падение бизнес-метрик; helm upgrade --atomic --timeout 5m;
• tag/версия предыдущего релиза известны и доступны (реестр не очищен);
• учения по откату, runbook.

Проверки после деплоя

• readiness/liveness и smoke-тесты (ключевые эндпоинты, логин, критичный сценарий);
• мониторинг золотых сигналов: ошибки, задержки, трафик, насыщение; сравнение с базовой линией;
• аннотации релиза на дашбордах Grafana, трассы по версии (service.version OTel);
• синтетический мониторинг; алерты на всплески после релиза.

Особые случаи

• stateful-сервисы и миграции схем: expand/contract, dual-write, бэкфилл;
• фронтенд SPA: хэшированные файлы, index.html без кэша, хранить предыдущие ассеты (старые вкладки), CDN invalidation;
• API-контракты: версионирование, обратная совместимость, депрекейшн;
• очереди/воркеры: совместимость форматов сообщений, постепенный вывод старых консьюмеров;
• долгоживущие соединения (WebSocket, gRPC streaming): плавный drain.

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

Ситуация	Выбор
простой сервис, допустим простой	recreate
stateless API, Kubernetes	rolling update + readiness + PDB
критичные релизы, быстрый откат	blue-green
риск высок, большой трафик	canary + автоанализ
эксперименты и постепенное включение	feature flags
нельзя тестировать на проде	shadow-трафик + staging

Вопросы с ответами

Чем blue-green отличается от canary?

Blue-green переключает весь трафик между двумя полными средами (быстрый откат, двойные ресурсы). Canary постепенно направляет долю трафика на новую версию с анализом метрик (ограниченный охват проблем).

Что нужно учитывать при rolling update?

Две версии работают одновременно: обратная совместимость API и БД, readiness probe, graceful shutdown, maxUnavailable/maxSurge, PDB.

Как сделать откат безопасным при миграциях БД?

Применять обратно совместимые миграции (expand), откладывать удаление старых структур (contract) на следующий релиз; тогда достаточно откатить код.