План непрерывности бизнеса

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

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

2) BIA — анализ влияния на бизнес

Определите критичные процессы, входы/выходы, зависимости, «ручные» альтернативы и целевые RTO/RPO.

yaml process: payouts owner: head_of_payments criticality: tier1 dependencies: [psp1, psp2, bank_api, kyc_service, ledger_db]
rto: "4h"
rpo: "15m"
manual_workaround: "limited manual VIP payments when the PSP is completely unavailable"
max_tolerable_downtime: "8h"
legal_constraints: ["AML/KYC check before payout," "regulatory notification windows"]

3) Сценарии/угрозы (Risk → Impact → Response)

Тех: падение региона облака, сбой БД, потеря кластера, атаки DDoS, отказ CDN.
Вендоры: PSP/KYC деградация, разрыв с агрегатором игр, недоступность антифрода/санкционного скрининга.
Кибер: компрометация учеток/ключей, ransomware, утечка PII.
Процессы/люди: забастовки/болезни, уход ключевых специалистов, ошибка релиза.
Гео/форс-мажор: отключения связи/энергии, военные/санкционные риски, блокировки доменов/трафика.

Для каждого: триггеры, порог эскалации, контрольные меры, деградация сервиса и шаблоны коммуникаций.

4) Архитектура устойчивости и стратегии

Active-active/active-standby по регионам; infrastructure as code для быстрого подъема.
Деградационные режимы: read-only витрины, отключение не-критичных провайдеров игр, лимиты выплат, «только депозиты» с отложенными кассаутами (если юридически допустимо), понижение частоты аналитики/ETL.
Traffic management: Anycast CDN, гео-балансировка, health-checks, canary-маршрутизация.
Данные: PITR-бэкапы, журналы изменений, репликация межрегиона, криптографическая целостность (хэши/WORM).
Ключи/секреты: независимые KMS per-region, «break-glass» с журналированием.
PSP/KYC multi-homing: автоматический фейловер, маршрутизация по SLA/латентности.

5) Командная структура (Incident Command System)

Incident Commander (IC) — единая точка принятия решений.
Ops Lead (SRE/Platform) — техстабилизация, фейловер, метрики.
Business Continuity Lead — координация процессов/ручных процедур.
Comms Lead — внешние/внутренние уведомления (игроки, партнеры, регуляторы).
Security/DPO — киберинциденты/приватность, регуляторные окна.
Payments/KYC Leads — PSP/KYC сценарии.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

Правило: один IC на инцидент, четкие каналы и логи решений.

6) План коммуникаций

Каналы: war-room (чат/мост), резервные связи (телефон/радио/альт-мессенджер), заранее проверенные контакты PSP/KYC/банков.
Шаблоны внешних сообщений: статус-страница, соцсети, email/push; тон — факты, сроки, следующие шаги.
Регуляторы и партнеры: предустановленные адреса, SLA уведомлений; согласованные формулировки.
Игроки: прозрачные ETA, компенсации/бонусы (если применимо), FAQ на период деградации.

7) Операционные планы (Runbooks)

7.1 Фейловер в другой регион

yaml trigger: "loss of primary availability> = 5m, p95_latency>threshold"
steps:
- IC approves region_failover
- SRE: flip traffic via GSLB to secondary
- Data: verify replication lag < RPO
- Apps: switch env vars/secrets; warm caches
- QA: smoke tests; Business: announce status rollback: "switch-back on 60m stability"

7.2 PSP деградация

yaml trigger: "auth_rate_psp1 < baseline-3σ 15m"
steps:
- Payments: route X%→psp2, include limits
- Comms: banner at the checkout, status page
- Finance: reconciliation plan for T + 0
- Legal: notification log and SLA letter

7.3 KYC провайдер недоступен

yaml trigger: "kyc_sla_breach 30m"
steps:
- Risk: time limits of deposits/rates
- Ops: VIP/High-risk manual check
- Comms: KYC Time Increase Notice
- Vendor: escalation, protection switch

8) Восстановление IT и данных (DR)

Категории систем: Tier-1 (платформа/платежи/KYC), Tier-2 (игры/аналитика), Tier-3 (внутренние).
Порядок подъема: сеть→секреты/KMS→БД→кеш→API→фронт/CDN→интеграции→аналитика.
Проверки целостности: контрольные суммы, верификация журналов/репликации, сверка транзакций (reconciliation).
Тесты DR: ежегодно полный (switch-over), ежеквартально частичный; фиксация фактических RTO/RPO.

9) Люди, офисы и логистика

Remote-ready: резервные ноутбуки/модемы, доступ через SSO/MFA, «красный» доступ для IC.
Альтернативные локации: запасные офисы/коворкинги, списки пропусков, план на случай эвакуации.
Ротация смен: матрица компетенций, дублирование ключевых ролей, план замещения.
Критичные провайдеры связи/энергии: контакты, SLA, генераторы/UPS (если релевантно).

10) Вендоры и цепочка поставок

BCP/DR-требования в договорах: RTO/RPO, обязательные тесты, право аудита и совместные учения.
Реестр субпроцессоров: контакты, планы на outage, подтверждения удаления/экспорта данных при offboarding.
Ежеквартальные ревью Tier-1: инциденты, DR-протоколы, статус сертификатов, SLA.

11) Обучение, учения и тестирование

Tabletop раз в квартал: PSP/KYC/облако/кибер-сценарии.
Тех-учения: DR частичные/полные; DDoS/переключение CDN; «kill-switch» SDK провайдеров.
Коммуникационные учения: пресс-релиз/статус-обновления/регуляторные письма.
Ретроспективы: таймлайн, RCA, CAPA, обновление runbooks и BIA.

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

RTO/RPO факт (по Tier-1): соответствуют целям ≥ 95%.
MTTD/MTTR: тренд на снижение; MTTR критичных инцидентов ≤ целевого.
Успешность фейловера: без потери данных/заказов/ставок, ≤ X мин деградации.
Coverage учениями: ≥ 2 полных DR-теста/год + 4 tabletop.
Коммуникации: время до первого апдейта ≤ 15 мин, частота обновлений согласно политики.
Vendor resilience: доля Tier-1 с подтвержденными DR-тестами за 12 мес — 100%.

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

14) Чек-листы

14.1 Ready-to-Failover

• Актуальные контакты IC/вендоров/регуляторов
• Здоровье репликации, регулярный PITR-бэкап
• Проверены «kill-switch» для SDK/вебхуков
• Трафик-менеджер (GSLB/CDN) с проверенными health-checks
• Шаблоны статуса/писем и права публикации
• Runbooks и доступы (SSO/MFA) проверены ежемесячно

14.2 Во время инцидента

• Назначен IC, открыт war-room, старт логов решений
• Классификация (P1/P2), выбор сценария и деградации
• Техдействия (фейловер/лимиты/отключения)
• Первый публичный апдейт ≤ 15 минут
• Регуляторные/партнерские уведомления по SLA
• Захват артефактов для пост-мортема

14.3 После инцидента

• Пост-мортем с RCA и CAPA
• Обновлены BIA/пороги/рутинные процедуры
• Тренировка/ретест фиксов, отчет борду
• Финансовая/данная сверка (reconciliation)

15) Шаблоны (фрагменты)

15.1 Карточка сценария

yaml scenario: "Region outage: cloud-eu1"
triggers: ["error_rate>5%", "loss of quorum", "cdn health fail"]
degradation: ["disable live-casino", "payments=psp2 only", "payouts=VIP manual"]
rto_target: "30m"
rpo_target: "15m"
contacts: {cloud: "...", isp: "...", regulator: "..."}
comms_templates: ["status_page_v1", "partner_notice_v2"]

15.2 Сообщение на статус-страницу

[UTC + 02] We are seeing the degradation of payments through PSP # 1. Transactions are automatically routed through an alternative provider. Player funds are safe. The next update is in 15 minutes.

16) Управление документами и версиями

Версионирование BCP/Runbooks в репозитории, change-log, владелец документа.
Сроки пересмотра (ежеквартально для Tier-1), контроль доступности офлайн-копий.
Хранение артефактов учений/инцидентов и метрик эффективности.

17) Дорожная карта внедрения (6–8 недель)

Недели 1–2: BIA и критичные процессы, цели RTO/RPO, список сценариев и владельцев.
Недели 3–4: архитектура устойчивости и деградационных режимов, runbooks, коммуникационные шаблоны, контакты.
Недели 5–6: интеграция с вендорами (PSP/KYC/облако), пилотные учения (tabletop + частичный DR), корректировки.
Недели 7–8: полный DR-тест (по возможности), запуск квартального цикла учений, отчет борду и регуляторный пакет (если требуется).

18) Связанные разделы wiki

Реестр рисков, Инциденты и утечки, DR/BCP тесты, TPRM и SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privilege, Политика логов/WORM — для единого контура устойчивости и доказуемости.

TL;DR

Эффективный BCP = BIA→RTO/RPO→сценарии и деградации→мульти-вендор/мульти-регион + ясный Incident Command, коммуникации и учения. Поддерживайте документ живым, тестируйте регулярно — и даже большой сбой не остановит бизнес и не ударит по лицензиям.