Disaster Recovery Plan

1) Призначення, область і принципи

Мета: забезпечити своєчасне відновлення ІТ-платформи після катастроф (тих, кібер, вендорських, геополітичних) без порушення регуляторних вимог, договорів та очікувань гравців.
Область: продуктивні оточення (ігровий контур, платежі, KYC/AML, антифрод, вітрини DWH/BI), інтеграції (PSP, KYC, CDN, студії/агрегатори), інфраструктура (хмара/K8s, мережі, секрети/ключі), дані (БД, файли, логи).
Принципи: safety-first, мінімізація RTO/RPO, автоматизація і відтворюваність (IaC), «доказовість за замовчуванням», регулярні навчання.

2) Класифікація систем і цілі відновлення

2. 1 Рівні критичності

Tier-1 (життєво важливо): платежі/касаути, core-ігри, логін/автентифікація, КУС/санкції.
Tier-2: аналітика реального часу, маркетинг/CRM, звітність DWH.
Tier-3: внутрішні портали, допоміжні сервіси.

2. 2 Цільові показники

RTO (Recovery Time Objective): час до відновлення сервісу.
RPO (Recovery Point Objective): допустима втрата даних за часом.
RTA (Recovery Time Actual) / RPA (Recovery Point Actual): фактичні значення, що фіксуються у звітах.
MTO/MBCO: максимально переносимий час простою/мінімально прийнятний рівень сервісу (degraded mode).

• Tier-1 - RTO ≤ 30-60 хв, RPO ≤ 15 хв; Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч; Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.

3) Стратегії DR і архітектура

3. 1 Топології

Active-Active (мульти-регіон): мінімальний RTO/RPO, вимагає консистентності і конфлікт-резолву.
Active-Standby (гарячий/теплий/холодний): баланс витрат/швидкості.
Geo-розділення даних і ключів: KMS/HSM per-region, BYOK, незалежні шляхи реплікації.

3. 2 Дані і бекапи

PITR (point-in-time recovery): журнали транзакцій, інтервали архівації ≤ 5-15 хв для Tier-1.
Снепшоти/фул-бекапи: щоденні/годинні, зберігання за схемою 3-2-1 (3 копії, 2 носії, 1 оффлайн/оффсайт).
Іммутабельність: WORM/об'єктні локи, підпис/хеш-ланцюжки артефактів.
Каталог відновлення: інвентар бекапів, цілісність, термін придатності, тестові розшифровки.

3. 3 Додатки та інтеграції

Стейтлес-сервіси: швидке розгортання через IaC/CI.
Стейтфул-компоненти: узгоджені снапшоти, оркестрація послідовності запуску.
Інтеграції (PSP/KYC/агрегатори): подвійні креденшли, fallback-ендпоінти, підписані вебхуки, контроль повторної доставки (ідемпотентність).

4) Порядок відновлення (загальний runbook)

1. Оголошення DR-сценарію → призначення DR Incident Commander (DR-IC), запуск war-room.
2. Оцінка пошкоджень: уражені регіони/підсистеми, актуальні RTA/RPA, рішення про активування фейловера.
3. Ізоляція/контейнмент: блокування вихідних причин (мережеві ACL, секрети, відключення провайдера).

• мережа/секрети/KMS →
• БД/сховища/кеш →
• API/сервіси → фронт/CDN → зовнішні інтеграції.
• 5. Перевірка цілісності: контр. суми, «сухі» запити, health-проби.
• 6. Reconciliation фінансів/ігор: звірки платежів, ставок, балансів, ідемпотентне повторення операцій.
• 7. Комунікації: статус-сторінка, гравці/партнери/регулятори; таймлайн оновлень.
• 8. Спостереження та стабілізація: деактивація деградацій у міру нормалізації.
• 9. Пост-мортем: RCA, CAPA, оновлення DRP.

5) Спеціалізовані runbooks (фрагменти)

5. 1 Втрата основного регіону (Active-Standby → Standby)

yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"

5. 2 Корупція БД/відновлення з PITR

yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]

5. 3 PSP деградація в DR-режимі

yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation

6) Цілісність даних і reconciliation

Фінанси: звірки депозитів/виплат/комісій, повторна відправка повідомлень і вебхуків з дедуплікацією (idempotency-keys).
Ігровий контур: відновлення станів раундів, повтор розрахунків при необхідності, захист від подвійних списань/нарахувань.
Журнали/аудит: зіставлення WORM-логів «до/після», сигнатури/хеші, звіти про несуперечливість.
Звіт DPO/комплаєнсу: у разі впливу на PII - фіксація масштабу, таймлайну і повідомлень.

7) DR для ключових технологій (приклади)

СУБД (реляційні): синхронна/асинхронна реплікація, слоти WAL, fast-promote, гарячі стендбаї.
NoSQL/кеші: мультикластер, TTL-інвалідація, холодне заповнення, відмова від cross-region write без конфлікт-резолву.
Черги/стріми: дзеркальні топіки/кластери, контроль зміщень, дедуплікація споживачів.
Об'єктне сховище: версіонування, реплікація в «бункер», інвентар об'єктів і політики retention.
CI/CD/артефакти: репліки реєстрів, підпис артефактів, офлайн-копії критичних контейнерів.
Секрети/ключі: KMS per-region, незалежні кореневі ключі, break-glass з журналюванням і TTL.

8) Безпека і приватність в DR

Принцип найменших прав: DR-доступи окремими ролями/профілями (JIT/PAM).
Іммутабельні бекапи: оффлайн/офсайт, тест відновлення і розшифровки.
Регуляторні вікна: фіксація подій і рішення про повідомлення (регулятор/банк/PSP/користувачі) разом з Legal/DPO.
Трасування: повний журнал дій DR-команди, підпис таймлайну.

9) Навчання та види тестів

Walkthrough/Review: перевірка документа/ролей/контактів (щокварталу).
Tabletop: прогін сценаріїв на «суху» з вирішенням конфліктів.
Technical partial: відновлення окремого сервісу/БД.
Full failover / switch-over: перенесення трафіку і даних в резервний регіон.
Chaos-дні (контрольовано): ін'єкції відмов/збоїв для перевірки автоматик.

Кожен тест → звіт з RTA/RPA, списком відхилень, CAPA і оновленням DRP.

10) Метрики (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1): ≥ 95% відповідностей.
DR Test Coverage: ≥ 2 повних DR-тесту/рік + регулярні часткові.
Time-to-First-Status: ≤ 15 хв після оголошення DR.
Reconciliation Zero-Diff: всі грошові та ігрові звірки без розбіжностей.
Backup Integrity: 100% вибіркових відновлень успішні за квартал.
Config Drift: 0 дрейфу між primary/secondary (IaC-порівняння).
Security in DR: 100% DR-дій з журналом і підтвердженням.

11) RACI (укрупнено)

12) Чек-листи

12. 1 Готовність до DR

• Оновлені контакти DR-команди/вендорів/регуляторів
• Реплікація зелена, PITR включений, тестова розшифровка бекапів
• Доступи JIT/PAM, «break-glass» перевірено
• Фейловер-плейбуки і змінні оточення валідни
• Подвійні креденшли/вебхуки PSP/KYC, альтернативні маршрути
• Статус-сторінка/шаблони повідомлень готові

12. 2 Під час DR

• Призначений DR-IC, відкритий war-room, таймлайн подій
• Ізоляція причини, вибір сценарію, запуск runbooks
• Перевірки цілісності, health-проби, smoke-тести
• Перший публічний апдейт ≤ 15 хв; повідомлення партнерам/регуляторам по SLA
• Захоплення артефактів для розслідування

12. 3 Після DR

• Повна звірка грошей/ігор і журналів
• Пост-мортем, RCA, CAPA з датами і власниками
• Оновлення DRP/BIA/контактів/IaC
• План повторного тесту фіксів

13) Шаблони (фрагменти)

13. 1 Картка сервісу (DR-паспорт)

yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]

13. 2 Звіт DR-тесту (витримка)

yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"

13. 3 Шаблон статус-повідомлення

[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.

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

Тижні 1-2: інвентаризація сервісів і залежностей, класифікація Tier, цілі RTO/RPO, вибір топологій, DR-паспорти.
Тижні 3-4: реалізація бекапів/PITR/іммутабельності, реплікації секретів/KMS, підготовка runbooks і статусу.
Тижні 5-6: часткові тех-тести (БД/кеш/черги), tabletop за сценаріями PSP/KYC/регіон.
Тижні 7-8: full switch-over (по можливості), звіт з RTA/RPA, CAPA, оновлення DRP і план регулярних тестів.

15) Інтеграція з іншими розділами wiki

Зв'язати з: BCP, Реєстр ризиків, Інцидент-менеджмент, Політика логів (WORM), TPRM і SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilege, Парольна політика і MFA, Управління змінами/релізами.

TL; DR

Робочий DRP = ясні RTO/RPO по Tier → архітектура Active-Active/Standby + іммутабельні бекапи/PITR → відтворювані runbooks і фейловер → reconciliation грошей/ігор → регулярні навчання і CAPA. Тоді будь-який великий збій перетворюється на керовану процедуру з передбачуваним часом відновлення і нульовими сюрпризами для регуляторів і гравців.