Zero-Downtime развертывания

(Раздел: Архитектура и Протоколы)

1) Что такое Zero-Downtime и зачем это нужно

• Нулевой простой для клиентов и интеграций.
• Предсказуемые релизы, быстрый откат и управляемый риск.
• Сохранение SLO/SLI (латентность, ошибки, доступность) в границах договоренностей.

Ключ к ZDT — не одна “магическая” техника, а комбинация паттернов доставки, совместимости данных и грамотной маршрутизации трафика.

2) Базовые принципы Zero-Downtime

1. Совместимость версий: новая и старая версии должны одновременно корректно обрабатывать трафик и данные.
2. Идемпотентность операций: повторная обработка не должна ломать состояние.
3. Грациозное завершение (graceful shutdown) и дренаж соединений.
4. Пошаговая проверка здоровья: readiness/liveness пробы, health-эндпойнты.
5. Откат как первый класс гражданин: rollback проще и быстрее, чем hotfix.
6. Наблюдаемость by design: метки релиза, единые дашборды, алерты по SLO.
7. Автоматизация: сценарии релиза и отката — код, а не ручные инструкции.

3) Паттерны доставки без даунтайма

3.1 Rolling Update

Постепенно выводим из-под трафика часть инстансов старой версии, обновляем их на новую и возвращаем в пул.

Плюсы: экономно по инфраструктуре, просто в k8s/ASG.
Минусы: некоторое время кластер работает с двумя версиями одновременно (version skew).

3.2 Blue-Green

Два полных прод-стека: активный (Blue) и кандидат (Green). Переключение трафика — атомарный flip.

Плюсы: мгновенный откат, чистая изоляция.
Минусы: ↑ расходы на инфраструктуру, сложнее со stateful.

3.3 Canary / Прогрессивный rollout

Отдаем малую долю трафика (1–5–10–25–50–100%) новой версии с гейтами по метрикам.

Плюсы: минимальный blast radius, data-driven решения.
Минусы: нужна зрелая наблюдаемость и интеллектуальная маршрутизация.

3.4 Shadow traffic / Dark launch

Зеркалим реальные запросы в новую версию (без ответа пользователю) или запускаем скрыто, чтобы собрать метрики.

Плюсы: раннее выявление проблем.
Минусы: двойная нагрузка на зависимости, нужен контроль побочных эффектов.

4) Управление трафиком и соединениями

4.1 Readiness/Liveness

Liveness говорит оркестратору “перезапусти меня”.
Readiness — “не направляй трафик, я еще не готов”.
Нельзя выпускать без корректной readiness-логики и таймаутов.

4.2 Дренаж соединений (Connection Draining)

• перестаем принимать новые соединения,
• ждем завершения активных,
• прерываем “зависшие” по таймауту.

4.3 Sticky-сессии и маршрутизация уровня L7

Sticky полезен при stateful-сценариях, но усложняет баланс по нагрузке.
L7-правила (по пути, заголовку, куке, версии API) удобны для canary/ring.

4.4 Долгоживущие соединения

WebSocket/gRPC streaming: перед обновлением включайте drain mode + сигнал “GOAWAY”.
Планируйте windows для перевешивания стримов и бэкоф-ретраи клиентов.

5) Совместимость данных и миграции БД

5.1 Expand-Migrate-Contract

1. Expand: добавляем новые столбцы/индексы/таблицы без ломки старой версии.
2. Migrate: переносим данные фоново и идемпотентно (батчи, чекпоинты).
3. Contract: удаляем старое только после стабилизации.

5.2 Практики

Избегайте эксклюзивных DDL-локов в окно релиза.
Версионируйте контракты API/событий (schema registry, CDC).
Для тяжелых миграций — online-инструменты, реплики, поэтапные переключения.
Двухконтурная запись (dual-write) только с дедупликацией и идемпотентными потребителями.
Outbox/Inbox для надежной интеграции через очереди.

6) Кэши, сессии и фоновые задания

Сессии и кэш — внешние (Redis/Memcached), чтобы версии были взаимозаменяемы.
Прогрев кэша/джитов/темп-индексов перед включением в пул.
Разделяйте фоновые очереди по версии или используйте лидерство, чтобы избежать гонок.

7) Наблюдаемость и гейты по SLO

Golden signals: латентность p95/p99, error rate, RPS, saturation, лаг очередей.
Бизнес-SLA: авторизации, конверсии, успешные платежи, отказ по шагам воронки.
Гейты: rollout продвигается только если canary ≤ baseline + пороги деградации, а error budget не сгорает.

8) Безопасное завершение и откат

Откат — это тот же пайплайн, только в обратную сторону: фиксированные команды, не “ручной крафт”.
Для blue-green — flip back; для canary — сброс веса до 0% или предыдущего стабильно шага.
Данные: компенсирующие транзакции, повторная обработка, дедупликация событий.

9) Чек-листы Zero-Downtime

Перед релизом

• Собран один подписанный артефакт (immutable), SBOM и проверка зависимостей.
• Readiness/liveness реализованы и протестированы.
• План миграций в режиме expand, обратимость подтверждена.
• Дашборды и алерты для новой версии готовы, метки релиза прокинуты.
• Откат проверен на staging/pre-prod.

Во время релиза

• Дренаж соединений включен, таймауты адекватны.
• Трафик переводится постепенно (canary/ring) или flip (blue-green).
• Метрики сравниваются с baseline, пороги гейтов соблюдаются.

После релиза

• Пост-мониторинг N часов, инциденты отсутствуют.
• Завершены миграции contract, убраны временные флаги/маршруты.
• Ретроспектива, обновление плейбуков.

10) Анти-паттерны

Recreate-деплой без дренажа и readiness ⇒ обрывы запросов.
Неподготовленные DDL ⇒ блокировки и таймауты в прайм-тайм.
Смешение несовместимых схем между версиями сервиса.
Отсутствие идемпотентности в обработчиках и воркерах.
“Выкат по ощущениям” без гейтов и сравнения с baseline.
Длинные DNS-TTL при blue-green, из-за чего flip длится часами.
Локальные сессии/кэш в памяти инстанса при rolling/canary.

11) Сценарии внедрения

11.1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readiness ждет прогрева (инициализация кэша, миграция minor).
Сервис-меш/Ingress с weighted routing (1–5–10–25–50–100%).
Алерты: p95, 5xx, лаг очереди, бизнес-воронка.

11.2 Blue-Green в облаке

Два стека за балансировщиком: `blue.example.com` и `green.example.com`.
Прогрев green, smoke/регресс, затем listener/route swap (или DNS-переключение с низким TTL).
При проблемах — мгновенный flip back.

11.3 Stateful-сервис

Реплики данных + online-миграции; двойное чтение с валидацией.
Фоновые джобы переносятся по “лидерству” версии или разделенным очередям.
Сессии/кэш вне инстанса; sticky включен лишь временно.

12) Фичефлаги и клиентские приложения

Новые фичи активируются флагами (сегменты: сотрудники → бета → все).
Для мобильных/десктоп-клиентов учитывайте границы совместимости протокола и живучесть старых версий (deprecation policy, server-side fallback).

13) Производительность и стоимость

Rolling дешевле, но требует осторожной совместимости.
Blue-Green дороже на время релиза, зато откат мгновенный.
Canary балансирует риски и стоимость, но требует сильной наблюдаемости.
Экономьте через ephemeral-превью и авто-чистку стендов.

14) Минимальный референс-пайплайн ZDT

1. Build: единый артефакт, подпись, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: smoke, нагрузка, миграции в режиме expand, проверка отката.
4. Prod: shadow → canary (гейты) или blue-green flip.
5. Post-deploy: наблюдение, contract-cleanup, ретро.

15) Краткое резюме

Zero-Downtime — это дисциплина: совместимые версии + корректная маршрутизация + управляемые миграции + наблюдаемость и быстрый откат. Выбирайте паттерн под контекст (rolling, blue-green, canary), автоматизируйте гейты по SLO, держите данные идемпотентными — и релизы перестанут быть событием, превращаясь в надежный рутинный процесс.