Disaster Recovery Plan

1) Назначение, область и принципы

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

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

2.1 Уровни критичности

Tier-1 (жизненно важно): платежи/кассауты, core-игры, логин/аутентификация, KYC/санкции.
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. Тогда любой крупный сбой превращается в управляемую процедуру с предсказуемым временем восстановления и нулевыми сюрпризами для регуляторов и игроков.