Большой релиз «всё и сразу» — это ставка на удачу: либо повезло, либо инцидент на всю аудиторию. Прогрессивная доставка превращает эту ставку в управляемый эксперимент, раскрывая риск постепенно и под наблюдением метрик.
Глава разбирает три механизма безопасной выкатки: blue-green с мгновенным переключением окружений, canary с ростом доли трафика по метрик-гейтам и feature flags, которые отделяют деплой от релиза. Поверх них — автоматический откат, привязанный к SLO и скорости расходования бюджета ошибок.
Соседние главы про SLI/SLO/SLA и дисциплину инцидентов дают сигналы и реакцию на сбой; эта — про то, как до сбоя не доводить, и как реализовать всё это в Kubernetes через Argo Rollouts и Flagger.
Практическая польза главы
Практика проектирования
Переводите знания о Безопасная выкатка изменений: canary, blue-green, feature flags и автооткат по SLO в конкретные эксплуатационные решения: правила оповещений, границы операционных инструкций и стратегии отката.
Качество решений
Оценивайте архитектуру через целевые уровни сервиса, бюджет ошибок, среднее время восстановления и устойчивость критического пути, а не только через функциональную полноту.
Аргументация на интервью
Структурируйте ответ вокруг жизненного цикла надёжности: сигнал деградации, реакция, локализация причины, восстановление и профилактика повторов.
Формулировка компромиссов
Явно фиксируйте компромиссы по Безопасная выкатка изменений: canary, blue-green, feature flags и автооткат по SLO: скорость релизов, уровень автоматизации, стоимость наблюдаемости и операционная сложность.
Источник
Danilo Sato — CanaryRelease (martinfowler.com)
Классическое определение канареечного релиза: новую версию сначала видит небольшая часть пользователей, и только при здоровых сигналах доля растёт.
Прогрессивная доставка — это набор практик безопасной выкатки изменений в продакшен, при которых риск раскрывается не одним рубильником, а постепенно и под наблюдением. В этой главе разберём , , и по . Соседняя глава SLI / SLO / SLA и бюджеты ошибок даёт сигналы и бюджет, на которые опираются критерии остановки, а дисциплина управления инцидентами описывает, что делать, когда выкатка всё же пробила защиту. Эта глава — про то, как до инцидента не доводить.
Зачем: риск релиза и разделение развёртывания (deploy) и релиза (release)
Большой релиз «всё и сразу» — это ставка: либо повезло, либо на всю аудиторию. Прогрессивная доставка превращает ставку в управляемый эксперимент. Первый шаг — разделить два понятия, которые часто путают.
Развёртывание (deploy)
Новый артефакт оказался на серверах и запущен, но это ещё не значит, что им пользуются. Это технический факт: бинарь установлен, процесс жив, прошёл .
Релиз (release)
Изменение стало видимым пользователям и начало обрабатывать их трафик. Именно здесь возникает риск, и именно его мы хотим раскрывать постепенно, а не одним рубильником.
Зачем их разделять
Пока деплой и релиз — один шаг, любой откат означает откат бинаря. Разнесите их, и появляется запас: код уже на проде «погашенным», а включение для аудитории — отдельный управляемый шаг. В этом и есть суть .
Три стратегии раскрытия изменений
Blue-Green
Переключение окружений
Два полных окружения, blue и green. Трафик мгновенно переводится с одного на другое и так же мгновенно откатывается. Цена — дублирование мощностей.
Canary
Процент трафика
Новая версия получает сначала 1-5% трафика, метрики сравниваются с эталонной стабильной версией (baseline), и доля растёт ступенями только при здоровых сигналах. Откат — снижение веса до нуля.
Feature flags
Переключатели в коде
Изменение прячется за и включается без передеплоя — по проценту аудитории, сегменту или мгновенным .
Как раскрывается канареечный запуск (canary): от 5% к 100%
Между ступенями стоит автоматический gate: вес растёт только при здоровых сигналах. Любое отклонение возвращает трафик на стабильную версию. Конкретные числа ступеней — пример, а не норматив.
Blue-green: мгновенное переключение и цена дублирования
держит два полных идентичных окружения. В каждый момент живое одно (скажем, blue), а новый релиз готовится и финально тестируется в зелёном. Когда green готов, маршрутизатор переключает трафик на него; если что-то пошло не так — возвращает на blue. Так достигается с почти мгновенным откатом. Платой становится дублирование мощностей: на время переключения нужно две полные копии. Blue-green отвечает на вопрос «можно ли быстро вернуться», но сам по себе раскрывает изменение скачком — всем сразу, поэтому его часто комбинируют с канареечной фазой.
Канареечный запуск (canary): процент трафика и автоматический анализ
— техника снижения риска: новая версия получает сначала маленькую долю трафика, её поведение наблюдают, и доля растёт постепенно. Имя пришло из шахт, где канарейка служила ранним индикатором опасного газа. Ключевая часть зрелого — автоматический , который сравнивает метрики новой версии с эталоном (baseline) той же конфигурации, а не с историческим средним.
- Задеплоить артефакт и прогнать на инстансах ещё до подачи живого трафика.
- Подать на новую версию небольшой вес трафика (например 5%) через в балансировщике или .
- Сравнить метрики с эталонной версией (baseline): доля ошибок, задержка по перцентилям, насыщение ресурсов — автоматический .
- При здоровых сигналах поднять вес ступенями (5 → 25 → 50 → 100%); при отклонении — вес до нуля.
Feature flags: четыре типа по Ходжсону
В статье на martinfowler.com (автор — Pete Hodgson) делятся на четыре категории по динамике и сроку жизни. Главная их ценность — отделение деплоя от релиза: код можно выкатить заранее, а включать по проценту аудитории или сегменту, и так же мгновенно гасить через .
Release-флаги
Скрывают ещё не готовый код в , чтобы недописанная функция не мешала выпускать остальное. Живут дни-недели и должны удаляться после полного раскрытия.
Ops-флаги
Операционные переключатели: для тяжёлой функции под нагрузкой, деградация неключевого пути. Часть из них живёт долго и управляется дежурными.
Experiment-флаги
Раскладывают пользователей по когортам для . Решение принимается по статистике, а не по факту «работает или нет».
Permission-флаги
Открывают функцию определённым группам: бета-тестерам, внутренним сотрудникам, премиум-тарифу. Часто долгоживущие и завязаны на бизнес-правила.
Долговой риск флагов реален: команды относятся к флагам как к инвентарю со стоимостью владения и стремятся держать его минимальным — задача на удаление в бэклоге, дата истечения, «time bomb» или лимит на число флагов в системе.
Автооткат по целевому уровню сервиса (SLO) и скорости расходования бюджета ошибок (burn rate)
Критерий остановки выкатки — не «кажется, плохо», а измеримый сигнал. Самый надёжный — связать решение со и : если тратит бюджет в разы быстрее допустимого, шаг проваливается, и вес автоматически уходит в ноль.
Привяжите остановку к : её высокое значение (например 14.4x за час) означает немедленный откат, а не «подождём ещё».
Сравнивайте именно с эталонной версией (baseline) той же версии трафика, а не с историческим средним — иначе суточные колебания дадут ложные срабатывания.
Заведите явные : доля 5xx, задержки, рост ретраев. Любая пробивает порог — анализ помечается провалившимся.
Откат должен быть автоматическим и быстрым. Ручное решение «откатывать ли» в три часа ночи — это и есть тот самый риск, который прогрессивная доставка призвана убрать.
Прогрессивная доставка на платформе Kubernetes
В стандартный Deployment умеет только без анализа метрик. Поэтому для прогрессивной доставки используют специализированные контроллеры.
Argo Rollouts
Контроллер заменяет стандартный Deployment ресурсом Rollout со стратегиями и сине-зелёного развёртывания. AnalysisTemplate запускает проверку метрик и автоматически промоутит или откатывает шаг.
Flagger
Оператор поверх и ingress (Istio, Linkerd, NGINX и др.): постепенно сдвигает трафик, гоняет conformance-тесты и принимает решение по метрикам — , сине-зелёное развёртывание, A/B-раскладка.
Метрик-провайдеры
Источником сигналов для анализа служат Prometheus, Datadog, New Relic, Graphite, InfluxDB и другие. На них строятся пороги, по которым шаг считается успешным или провалившимся.
Точное разделение трафика для канареек и blue-green удобно реализовать на уровне : она задаёт веса между версиями и собирает метрики через , что подробно разбирается в соседней главе про service mesh.
A/B-эксперименты против прогрессивной доставки: где граница
Механизм у них общий — управление трафиком и флагами, — но цели разные. Путаница здесь приводит к плохим решениям: эксперимент нельзя обрывать по сторожевой метрике, а нельзя держать неделю ради значимости.
Прогрессивная доставка отвечает на инженерный вопрос «безопасно ли это изменение». A/B-тест отвечает на продуктовый «какой вариант лучше по бизнес-метрике».
Канареечный запуск (canary) живёт минуты-часы и завершается промоутом или откатом. Эксперимент держат дни-недели, пока не набралась статистическая значимость.
смотрит на сторожевые метрики надёжности (ошибки, задержка). Эксперимент смотрит на (конверсия, удержание).
Механизм общий — управление трафиком и флагами, — но цели разные. Один флаг нельзя считать одновременно и аварийным выключателем (kill switch), и экспериментом без путаницы в решениях.
Компромиссы и частые ошибки
Флаги-зомби: release-флаги, которые остались в коде после полного раскрытия. Каждый — это , которое нужно тестировать и держать в голове. Флаги — это инвентарь со стоимостью владения.
Канареечный запуск (canary) без достаточного трафика: на 1% от низконагруженного сервиса метрики статистически шумные, и анализ либо молчит, либо ложно тревожит.
Ручной откат вместо : пока человек разбирается, бюджет ошибок уже потрачен. Откат должен быть дешевле, чем размышление о нём.
Канареечный запуск (canary) без эталонной версии: сравнение новой версии с историей вместо параллельной эталонной версии (baseline) даёт ложные выводы при суточных и недельных колебаниях нагрузки.
Рекомендации
Разделяйте деплой и релиз: выкатывайте код «погашенным» за и включайте отдельным управляемым шагом.
Автоматизируйте : повышение веса должно зависеть от сигналов, а не от того, что инженер «посмотрел и вроде ок».
Свяжите критерии остановки с и , а не с произвольными порогами.
Заводите флаги с датой удаления: задача на удаление в бэклоге, срок истечения или лимит на число флагов в системе. Гигиена флагов — часть Definition of Done.
Источники и материалы
Карта источников: Fowler/Hodgson/Sato держат терминологию feature flags, blue-green и canary release; Argo Rollouts — реализацию progressive delivery в Kubernetes; SRE Book — дисциплину release engineering. Порог остановки канарейки, шаги трафика и набор метрик остаются политикой конкретной системы, а не универсальным рецептом.
Связанные главы
- SLI / SLO / SLA и бюджеты ошибок - Даёт метрики и бюджет ошибок, на которые опираются автоматический анализ канареечного запуска (canary) и критерии остановки выкатки.
- Дисциплина управления инцидентами - Объясняет, что делать, когда выкатка всё же пробила защиту: реагирование, роли и разбор инцидента.
- Observability & Monitoring Design - Покрывает метрики, логи и трассировку — сигналы, без которых анализ канареечного запуска (canary) и метрик-гейты слепы.
- Service Mesh Architecture - Описывает управление трафиком на уровне сети, через которое канарейки и blue-green получают точное разделение трафика.