План безперервності бізнесу

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

Мета: забезпечити продовження критичних сервісів (депозити, ставки/ігри, висновки, KYC/AML, саппорт) при збоях і швидке відновлення без порушення ліцензій і договорів.
Область: онлайн-платформа, платіжний контур, антифрод/КУС, 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 (платформа/платежі/КУС), Tier-2 (ігри/аналітика), Tier-3 (внутрішні).
Порядок підйому: set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Перевірки цілісності: контрольні суми, верифікація журналів/реплікації, звірка транзакцій (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→stsenarii і degradatsii→multi -вендор/мульти-регіон + ясний Incident Command, комунікації та навчання. Підтримуйте документ живим, тестуйте регулярно - і навіть великий збій не зупинить бізнес і не вдарить по ліцензіях.