Оновлення екосистеми без даунтайму

(Розділ: Екосистема та Мережа)

1) Мета та принципи zero-downtime

• Сумісність вперед/назад (backward/forward) на кордонах контрактів.
• Поступовість (progressive delivery) замість «великого перемикання».
• Спостережуваність і оборотність: метрики, трасування, швидкий відкат.
• Ідемпотентність і безпечні ретраї для мережевих і платіжних потоків.
• Ізоляція відмов: cell-архітектура, circuit-breakers, ліміти фан-ауту.

2) Стратегії релізу без даунтайму

Blue-Green - два ідентичних стека (Blue = prod, Green = new). Трафік перемикається атомарно на рівні балансувальника з можливістю миттєвого відкату.
Canary - поетапна частка трафіку (1%→5%→20%→50%→100%) з SLO-гейтами.
Rolling - повузлове оновлення пулу з перевіркою готовності (readiness) і дренажем з'єднань.
Shadow/Traffic Mirroring - дзеркалювання запитів на нову версію без впливу на відповіді.
Feature Flags - бізнес-перемикання фіч поверх незмінного API (gradual rollout).
Dark Launch - включення прихованих гілок логіки для телеметрії та профілювання.

Рекомендація: для критичних сервісів - комбінація canary + rolling + feature flags; для шлюзів і API - blue-green з коротким перемиканням.

3) Контрактна сумісність (API/події/протокол)

API: версіонування за URI/заголовками; додавання полів - допустимо, видалення/перейменування - тільки через «депрекейт-вікно».
Події (event-bus): «тільки додавання» полів; ключі незмінні; нові типи - як нові теми/версії.
Схеми (Avro/JSON-Schema/Protobuf): схема-реєстр, сумісність'BACKWARD'FULL'.
Протокол мережі/Р2Р: version handshake і capability negotiation (вузли оголошують підтримувані версії/фічі).
Gateways: адаптери між vN і vN + 1 (transcoding/field mapping) на період міграції.

Політика депрекейту (приклад): анонс → ≥90 днів попередження → прапорець «deprecated» → видалення поля/ендпоінта.

4) Міграції даних без зупинки (Expand → Migrate → Contract)

1. Expand - додати нові структури/індекси/колонки (nullable/c дефолтом), двозапис (dual-write) в старий і новий формат.
2. Migrate - фонові міграції, backfill, валідатори консистентності; читання через адаптер, що підтримує обидві схеми.
3. Contract - відключити читання/запис в стару схему, видалити технічний борг після завершення «депрекейт-вікна».

sql
-- Expand
ALTER TABLE payouts ADD COLUMN payout_ref TEXT NULL;
CREATE INDEX CONCURRENTLY ix_payouts_ref ON payouts(payout_ref);

-- Migrate (batch + idempotent)
UPDATE payouts SET payout_ref = concat('ref_', id) WHERE payout_ref IS NULL;

-- Contract (after compatibility window)
ALTER TABLE payouts ALTER COLUMN payout_ref SET NOT NULL;

Транзакційність подій: використовуйте Outbox (транзакція із записом події) + CDC для гарантованої доставки.

5) Довгоживучі сполуки і дренаж

Graceful shutdown: SIGTERM → зупинити прийом нових запитів → виставити'readiness = fail'→ дочекатися дренажу WebSocket/HTTP2/QUIC-стрімів → закрити.
Connection draining на балансувальнику: 'deregister _ delay'30-120 с, sticky-сесії - через токени, а не IP.
Back-pressure: обмежити нові апстрими при зростанні p99_latency.

6) Версіонування SDK і клієнтів

SemVer для SDK; LTS-гілка з розширеним вікном підтримки (наприклад, 12 місяців).
Policy: «не менше двох активних мінорних версій»; телеметрія на частку клієнтів за версіями; автоматичні попередження про необхідність апгрейду.
Критичні зміни (security): форсований прапор відключення старих версій через шлюз після дедлайну.

7) Оновлення протоколів і вузлів мережі

Soft-fork: розширення правил без порушення старих вузлів (capabilities).
Hard-fork: заздалегідь оголошене вікно, подвійна валідація, «канарні валідатори», захист від «reorg/rollback» конфліктів, time-lock на активацію.
Крос-ланцюгові апдейти: мости governance передають сигнали активації; у разі розсинхронізації - локальний circuit-breaker.

8) Конфігурації та секрети як дані

Централізований config-service з версіонуванням, цифровими підписами і відкатом.
Secrets rotation без даунтайму: подвійні ключі (old/new), почергове включення; нульові простої для KMS/PKI.
Feature-flags в окремому сторі, аудит включень/відключень.

9) Pipeline релізу і автоматичні «гейти»

Стадії: build → unit → security scan → e2e/stage → shadow → canary → 100%.

• Error-budget burn-rate, p95/p99 latency, error-rate, зниження success-rate подій/платежів, зростання dead-letter черг.
• Авто-відкат при порушенні SLO в будь-якому з етапів.

yaml release:
strategy: canary steps:
- name: shadow traffic_mirror: 5%
gates: [no_data_loss, no_pii_leak]
- name: canary_1 traffic: 1%
gates: [error_rate<0. 2%, p99<400ms]
- name: canary_2 traffic: 10%
gates: [slo_ok_1h, zero_deadletters]
- name: rollout traffic: 100%
gates: [stability_6h]
- name: bake duration: 24h action: finalize_or_rollback

10) Спостережуваність і SLO для релізів

• p95/p99 latency за ендпоінтами; error-rate (5xx + фатальні 4xx); success-rate подій; частка ретраїв; лаг черг; частка «relay» в P2P; частка клієнтів за версіями.

• p99 API ≤ 400 мс; error-rate ≤ 0. 2%; success-rate подій ≥ 99. 5%; лаг черги ≤ 2 с; MTTR відкату ≤ 15 хв.
• Дашборди релізу: порівняння «до/після», канарні графи, карта залежностей (service map), алерти burn-rate 1ч/6ч.

11) Відкати і «kill-switch»

Авто-відкат: зберігайте останні «хороші» артефакти і конфіги; «1-кнопковий» rollback на балансувальнику (Blue←Green).
Partial rollback: фічефлаг вимикає нову логіку при збереженні бінаря.
Data rollback: тільки для «read-paths»; для «write-paths» - захищені міграції (ніколи не видаляйте старі колонки до закінчення вікна).
Kill-switch: централізований прапор для відключення нестабільної підсистеми.

12) Тестування без простою

Контрактні тести прод проти стаба клієнтів (consumer-driven).
Схемні тести з перевіркою сумісності (schema-compat).
Chaos-тести в стейджингу: вихід з ладу% вузлів/регіонів, деградація DHT/TURN/KMS/DNS, «шторм ретраїв».
Навантажувальні/ремаркет тести: канарські регіони і «гарячі» маршрути.

13) Регламенти комунікацій та комплаєнс

Реліз-ноти: що змінюється, вплив, вікна/дедлайни депрекейту, дії для партнерів.
SLA відповідей на інциденти: MTTA ≤ 5 хв, перший апдейт статусу ≤ 15 хв, пост-мортем ≤ 72 год.
Аудит слідів: прив'язка всіх конфіг-змін і релізів до заявок/пропоузалам, підписи артефактів.

14) Спеціальні випадки

Платіжні/фінансові потоки: сувора ідемпотентність, дедуп по idempotency-key, outbox + CDC, «неруйнівні» міграції тільки.
WebSocket/стріми: версія протоколу в handshake, реконнект з резюмуванням (resume tokens).
Кеш/edge: 'stale-while-revalidate', подвійні версії кешу, TTL-гігієна в період релізу.
Мобільні клієнти: поетапний rollout в сторах, примусовий апдейт на security-випусках.

15) Чек-лист zero-downtime

1. Контрактна сумісність і схема-реєстр налаштовані.
2. Expand→Migrate→Contract описаний і автоматизований.
3. Balance/Ingress підтримує blue-green і дренаж з'єднань.
4. Canary-пайплайн з SLO-гейтами і авто-відкатом.
5. Feature-flags і kill-switch доступні 24/7.
6. Outbox + CDC і ідемпотентність включені для всіх write-шляхів.
7. Дашборди «реліз-здоров'я» і алерти burn-rate активні.
8. Комунікації та депрекейт-політика оголошені партнерам заздалегідь.
9. Щотижнева репетиція відкату; щоквартальний chaos-day.

16) Глосарій

Progressive delivery - поетапний випуск фіч з контролем ризиків.
Schema registry - сховище версій схем з політиками сумісності.
Outbox/CDC - шаблон гарантованої публікації подій з транзакцій.
Blue-Green - паралельні стеки з атомарним перемиканням трафіку.
Canary - поступове нарощування частки трафіку на новій версії.
Graceful shutdown/draining - коректне завершення активних з'єднань.

Підсумок: нульовий даунтайм - це не один трюк, а система: контракти, сумісність схем, поетапні стратегії релізу, спостережуваність, безпечні міграції і гарантований відкат. Слідуючи цьому фреймворку, екосистема оновлюється швидко, передбачувано і без болю для користувачів і партнерів.