Progressive Delivery

«Выкатим сразу всем» — так живут команды без progressive delivery, и я регулярно вижу, чем это заканчивается: инцидент в проде с blast radius во весь трафик. Progressive Delivery — это дисциплина выкатки малыми долями с возможностью посмотреть и откатиться. Код едет через canary с явным гейтом по SLI, feature flag отделяет релиз от деплоя, а откат срабатывает по burn rate, а не по чьей-то команде «жми кнопку». Главная практика внутри L1 Change Management.

Что должен уметь

Главный навык на уровне L5 — сделать автоматический откат по burn rate, а не «решим руками во время инцидента». Я регулярно вижу канарейку без автоотката: инженер смотрит на дашборд и решает в моменте, останавливать или продолжать. Пока он думает, счётчик тикает, и эти минуты доходят до клиента. Порог по burn rate снимает решение с человека, который именно в такой момент соображает хуже всего.

Понимает разницу между rolling update, canary, blue-green и выкаткой через feature flag; различает деплой и релиз.
Запускает деплой по существующему конвейеру команды; знает, как откатиться по документированной процедуре.

Настраивает canary для своего сервиса: доли трафика (5 / 25 / 50 / 100%), гейт по доле ошибок или p99 latency, длительность каждой фазы.
Отделяет релиз от деплоя через feature flag: код уже в проде, а функциональность включается отдельным переключателем — на когорту, на процент трафика, на внутренних пользователей.

Проектирует политику выкатки для сервиса: явные гейты по SLI, временные окна, ограничение blast radius.
Делает автоматический откат по burn rate или по провалу health check; в обычных случаях человек в этой петле не нужен.
Ведёт выкатку изменений, которые не сводятся к правке кода, — миграций схемы БД, смены формата конфигурации: сначала обратно совместимый шаг, потом изменение кода, потом отдельная зачистка старого.

L6+

Внедряет progressive delivery как стандарт для команды или организации: шаблоны конвейеров, обучение, метрики DORA.
Держит баланс скорости и безопасности: где гейт можно ослабить, а где, наоборот, затянуть.

Материалы

Книги

Jez Humble, David Farley — Continuous Delivery (Addison-Wesley, 2010). Фундамент дисциплины частых, безопасных, автоматизированных выкаток.
Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Эмпирическая основа исходной модели DORA; для текущих пяти метрик и failed deployment recovery time нужен актуальный guide DORA.
Gene Kim, Jez Humble, Patrick Debois, John Willis — The DevOps Handbook, 2-е изд. (IT Revolution, 2021). Паттерны выкатки в широком контексте DevOps.

Статьи

Martin Fowler — CanaryRelease. Каноническое определение canary как стратегии выкатки.
Pete Hodgson — Feature Toggles (Feature Flags) (martinfowler.com). Четыре категории флагов (release, experiment, ops, permissioning) и практики управления жизнью флага — от появления до удаления.
Мой разбор — Digital Immune System: инженерия устойчивости как продукт (jtprog.ru, август 2026). Про SLO как гейт в конвейере: выкатка останавливается по сжиганию бюджета ошибок, а не по метрике инфраструктуры, и решение об откате принимает автоматика в заранее оговорённых границах. Полезно, когда Argo Rollouts или Flagger уже стоят, а критерий продвижения всё ещё «посмотрим глазами».

Инструменты

Argo Rollouts — нативный для Kubernetes контроллер под canary / blue-green; интеграция с Prometheus / Datadog для metric-driven promotion и automated rollback.
Flagger — оператор progressive delivery поверх service mesh (Istio, Linkerd), переливающий трафик по метрикам SLI.
Unleash — открытая платформа для feature flag. По моим наблюдениям, её чаще берут там, где всё держат на своих серверах.
LaunchDarkly — коммерческая платформа для feature flag с продвинутым таргетингом и экспериментами. Нужна, когда активных флагов уже десятки и требуется корпоративный SSO с аудитом.
Spinnaker / Argo CD / Flux — оркестрация выкаток; сами по себе progressive delivery они не делают, но дают конвейерную обвязку для Argo Rollouts и Flagger.

Best practices

Деплой и релиз — разные события, и feature flag их разделяет. Сначала код едет в прод выключенным, и мы убеждаемся, что он там просто лежит и ничего не ломает. Потом функциональность включается — на когорту, на процент трафика, на внутренних пользователей. Если что-то пошло не так, флаг гасится, и откатывать выкатку не нужно вовсе.

Canary без health gate — это не canary, а «пусть постоит часик». Ручное продвижение по таймеру выглядит как осторожность. Проверяет оно ровно ничего. Гейт — это явное условие на SLI, burn rate или error rate: держит пять процентов трафика SLO заданное время — конвейер продвигает сам, не держит — сам же и откатывает.

Откат обязан быть проще, чем накат фикса. «Сейчас докатим быстрее, чем откатим» — фраза, после которой инцидент обычно удлиняется вдвое: под давлением человек пишет код хуже всего, а проверить его негде. Откат — это одна команда или заранее подготовленный revert, проверенный до деплоя, а не придуманный в момент пожара.

Blast radius ограничен на каждом шаге. Особенно дорого «сразу всем» обходится на breaking changes в горячем пути. Канарейка режется по доле трафика (5 / 25 / 50 / 100%), по геозоне (один регион, потом остальные), по когорте (внутренние, бета, все). Цель простая. Пусть баг увидят единицы, а не миллионы. По моим наблюдениям, разница между канарейкой на пяти процентах и выкаткой на весь трафик — это разница между внутренним постмортемом и публичным разбирательством.

Изменения схемы БД и конфигов — отдельный паттерн, а не «ещё один deploy». Миграция схемы и изменение кода в одном деплое означают, что откат сломает данные. Норма — три шага: сначала обратно совместимая схема, где старый и новый код читают оба варианта, затем изменение кода, и только потом, через недели после стабилизации, отдельный деплой с удалением старых колонок и полей. Команды, которые кладут миграцию в один PR с кодом, теряют данные на первом же откате.

Для рискованных изменений — отдельный чеклист перед деплоем. Миграция данных, правки в безопасности и breaking changes, которые видит клиент, не должны идти тем же путём, что опечатка в README. Для них — отдельный предварительный разбор: список рисков, план отката, план коммуникации. Всё остальное едет обычным PR с автодеплоем. Разбор по тяжести изменения экономит время на дешёвом и концентрирует внимание на дорогом.

Связанные листья

Service Ownership — владелец сервиса отвечает за деплой; каталог фиксирует политику выкатки.
Runbooks — процедура отката для каждого сервиса — обязательный runbook; её качество прямо определяет MTTR при сбое деплоя.
Incident Response — откат во время инцидента — стандартный способ погасить.
SLI-based Alerting — burn rate на фазе канарейки и есть тот самый гейт; алертинг — основа автоотката.
SLO Engineering — SLO определяет, насколько безопасна фаза канарейки; без явного SLO гейт настроить не из чего.
GitOps — Argo Rollouts (с ArgoCD) и Flagger (с Flux) — нативные для GitOps инструменты progressive delivery.
Test Strategy — тесты до деплоя и канарейка как проверка в бою дополняют друг друга.
Change Governance — техника выкатки (этот лист) и политика с процессом (соседний) — две половины одной практики. Канарейка без явной классификации изменений — половина дела.
DORA Metrics — эффект progressive delivery проверяется по throughput и instability; для восстановления после неудачного deploy используется failed deployment recovery time, а не общий MTTR инцидентов.

Открытые вопросы

Rollback Discipline (TBD) — учения на откат, автоматическая проверка отката в CI, time-to-rollback как отдельная метрика.
Database Migration Patterns (TBD) — детальная схема: expand-contract, dual-write, backfill, shadow read.

Отдельно висит граница. Всё описанное выше держится на измеримом SLI: canary упирается в health gate, а health gate — в то, что вообще меряется. На сервисах без метрик схема не работает, получается та же выкатка на всех, только в несколько шагов и с ложным чувством безопасности. Хорошего ответа тут у меня нет.