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, тримайте дані ідемпотентними - і релізи перестануть бути подією, перетворюючись в надійний рутинний процес.