Сценарії аварійного відновлення

1) Навіщо потрібен DR і яка мета

Disaster Recovery (DR) - це набір архітектур, процесів і тренувань для відновлення сервісів після катастроф (відмова датацентру/регіону, втрати даних, масових конфігураційних помилок). Мета DR - виконати цільові RTO/RPO при контрольованій вартості і ризику, зберігши довіру клієнтів і відповідність регуляториці.

RTO (Recovery Time Objective): допустимий час простою.
RPO (Recovery Point Objective): допустима втрата даних (час з останньої консистентної точки).
RLO (Recovery Level Objective): рівень функціоналу, який повинен повернутися першим (мінімально життєздатний сервіс).

2) Класифікація систем за критичністю

Tier 0 (життєво важливе): платежі, логін, KYC, ядро транзакцій - RTO ≤ 15 хв, RPO ≤ 1-5 хв.
Tier 1 (висока): операційні панелі, звіти D-1 - RTO ≤ 1 год, RPO ≤ 15-60 хв.
Tier 2 (середня): бек-офіс, аналітика near-real-time - RTO ≤ 4-8 год, RPO ≤ 4-8 год.
Tier 3 (низька): не критичні допоміжні - RTO ≤ 24-72 год, RPO ≤ 24 год.

Кожному сервісу присвоїти Tier + цільові RTO/RPO в каталозі сервісів; рішення і бюджети звіряти саме з ними.

3) Модель загроз і сценарії

Техногенні: відмова AZ/регіону/провайдера, деградація мережі/DNS, збій БД/сховищ, масовий баг релізу.
Людський фактор: помилкові конфіги/IaC, видалення даних, компрометація ключів.
Природні/зовнішні: пожежа/повінь, перебої енергії, правові блокування.
Для кожного - оцінити ймовірність/імпакт, прив'язати до DR-сценарію і плейбуку.

4) Патерни архітектури DR

1. Active-Active (Multi-Region): обидва регіони обслуговують трафік.

Плюси: мінімальні RTO/RPO, висока стійкість.
Мінуси: складність даних/консистентності, висока ціна.
Де: читання-важкі, кешовані навантаження, stateless-сервіси, multi-master DB (суворі правила конфліктів).

2. Active-Passive (Hot Standby): «гарячий» пасив тримає повністю розігріту копію.

RTO: хвилини; RPO: Хвилини. Вимагає автоматизованого failover і реплікації.

3. Warm Standby: частина ресурсів прогріту, масштабування при аварії.

RTO: десятки хвилин; RPO: 15-60 хв. економічніше, але довше.

4. Pilot Light: мінімальна «іскра» (метадані/образи/скрипти) + швидкий розворот.

RTO: годинник; RPO: годинник. Дешево, підходить для Tier 2-3.

5. Backup & Restore: офлайнові бекапи + ручний прогрів.

RTO/RPO: годинник-доба. Тільки для низької критичності та архівів.

5) Дані та узгодженість

• Синхронна - майже нульовий RPO, але ↑latentnost/stoimost.
• Асинхронна - краще продуктивність, RPO> 0 (хвіст журналів).
• Узгодженість: вибирайте модель (strong/eventual/causal). Для платежів - строго, для аналітики - eventual.
• Зрізи (snapshots): регулярно створюйте консистентні точки + зберігайте журнали (WAL/redo).
• Крос-регіонні транзакції: уникайте 2PC; використовуйте ідемпотентні операції, делі-і-повторюй (retry з дедуплікацією), event sourcing.
• Черги/шини: реплікація/дзеркалювання, DLQ, замовлення та ідемпотентність консьюмерів.

6) Мережа, трафік і DNS

GSLB/Anycast/DNS: політики failover/failback, низькі TTL (але не занадто), health-checks з декількох регіонів.
L7-маршрутизація: регіональні карти, фіча-прапори деградації (обмеження функцій).
Private-links/VPN: резервні канали до провайдерів (PSP/KYC/CDN).
Rate limiting: захист від шторму при відновленні.

7) Stateful vs Stateless

Stateless переноситься скриптом/автоскейлом; stateful вимагає узгодженої стратегії даних (реплікація, снапшоти, промоушен репліки, кворум).
Кеш/сесії: зовнішні (Redis/Memcached) з крос-регіонною реплікацією або re-seed по журналах; сесії тримати в токенах (JWT) або загальному сховищі.

8) Тригери та автоматизація DR

SLO-гардрейли і кворум зондів → автоматичний region-failover runbook.
Change freeze при аварії: блокуємо нерелевантні релізи/міграції.
Infrastructure as Code: розгортання стенд-бай по маніфестах, перевірка дрейфу.
Промоушен ролі: автоматичний promote репліки БД + перев'язка writers/секретів.

9) Комунікації та комплаєнс

War-room: IC/TL/Comms/Scribe; інтервали апдейтів по SEV.
Статус-сторінка: географія впливу, ETA, обхідні шляхи.
Регуляторика: терміни повідомлень, безпека даних, незмінне зберігання evidence.
Партнери/провайдери: підтверджені контакти, виділений канал.

10) Тести та навчання DR

Tabletop: обговорюємо сценарій і рішення.
Game Day (стейдж/прод-лайт): імітація відмови AZ/регіонів, відключення провайдера, скидання DNS.
Restore-тести: періодично відновлюємо бекапи в ізоляції і валідуємо цілісність.
Chaos/Failure injection: контрольовані збої мережі/вузлів/залежностей.
KPI навчань: досягнуті RTO/RPO, дефекти плейбуків, CAPA.

11) Фінанси та вибір стратегії (FinOps)

Рахуйте $ за знижений RPO/RTO: чим нижче цілі - тим дорожче канали, ліцензії, резерви.
Гібрид: Tier 0 — active-active/hot; Tier 1 — warm; Tier 2–3 — pilot/backup.
Дані дорогі: використовуйте холодні шари (архів/S3/GLACIER), інкрементальні снапшоти, дедуплікацію.
Періодичний рев'ю витрат і сертифікатів/ліцензій DR-інфри.

12) Метрики зрілості DR

RTO (факт) і RPO (факт) по кожному Tier.
DR Coverage: % сервісів з оформленим сценарієм/плейбуком/тестом.
Backup Success & Restore Success: щоденний успіх бекапів і перевірених відновлень.
Time-to-Declare Disaster: швидкість прийняття рішення про failover.
Failback Time: повернення до нормальної топології.
Defect Rate Навчань: знайдені прогалини/вчення.
Compliance Evidence Completeness: Повнота артефактів.

13) Чек-листи

Перед впровадженням DR

• Сервіс-каталог містить Tier, RTO/RPO, залежності та власників.
• Вибраний патерн (AA/AP/WS/PL/BR) по Tier і бюджету.
• Угоди про консистентність і реплікації задокументовані.
• GSLB/DNS/маршрутизація і health-checks налаштовані і протестовані.
• Бекапи, снапшоти, журнали змін - включені, перевірені на restore.
• Плейбуки DR і контакти провайдерів в актуальному вигляді.

Під час аварії (коротко)

• Оголосити SEV і зібрати war-room; заморозити релізи.
• Перевірити кворум зондів; зафіксувати імпакт/географію.
• Виконати Failover Runbook: трафік, БД-промоушен, черги, кеш.
• Включити degrade-UX/ліміти; публікувати апдейти по SLA.
• Збирати evidence (таймлайн, графіки, логи, команди).

Після аварії

• Спостерігати SLO N інтервалів; виконати failback за планом.
• Провести AAR/RCA; оформити CAPA.
• Оновити плейбуки, каталізатори алертів, тест-кейси DR.
• Відзвітувати перед стейкхолдерами/регуляторами (якщо потрібно).

14) Шаблони

14. 1 Картка DR-сценарію (приклад)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook «Promote репліки БД» (фрагмент)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 План навчань DR (коротко)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) Анти-патерни

«Є бекапи» без регулярних restore-тестів.
Секрети/ендпоінти не перемикаються автоматично.
Відсутність ідемпотентності → дублікати/втрачені транзакції при повторній доставці.
Однакові конфіги для регіонів без фіча-прапорів деградації.
Довгий Time-to-Declare через страх «помилкової тривоги».
Монорегіональні провайдери (PSP/KYC) без альтернативи.
Немає плану failback - живемо в аварійній топології «вічно».

16) Дорожня карта впровадження (6-10 тижнів)

1. Нед. 1–2: класифікація сервісів за Tier, установка цільових RTO/RPO, вибір патернів DR.
2. Нед. 3–4: налаштування реплікацій/бекапів, GSLB/DNS, промоушен-процедур; плейбуки і runbook'і.
3. Нед. 5–6: перші DR-навчання (tabletop→stage), фіксація метрик і CAPA.
4. Нед. 7–8: прод-лайт навчання з обмеженим трафіком; автоматизація failover.
5. Нед. 9–10: оптимізація витрат (FinOps), перенесення Tier 0 в hot/AA, регламент квартальних навчань і звітності.

17) Підсумок

Ефективний DR - це не тільки бекапи. Це узгоджена архітектура, автоматизація failover/failback, дисципліна даних (ідемпотентність/реплікація), тренування та прозорі комунікації. Коли RTO/RPO реальні, плейбуки відпрацьовані, а навчання регулярні, катастрофа перетворюється на керовану подію, після якої сервіси швидко і передбачувано повертаються до норми.