Операції та Управління → Безперервність бізнес-процесів

Безперервність бізнес-процесів (BCP)

1) Що таке BCP і навіщо він потрібен

BCP (Business Continuity Planning) - це системний підхід до забезпечення стійкості бізнес-процесів при будь-яких збоях: від відмови датацентру до кризи провайдера, витоку даних або раптового зростання навантаження.
У високонавантажених продуктах (iGaming, фінтех, маркетплейси) це не тільки про інфраструктуру - це про збереження довіри, дотримання регуляторних зобов'язань і захист виручки.

• Зберегти доступність критичних сервісів і даних.
• Мінімізувати час відновлення (RTO) і втрати даних (RPO).
• Забезпечити працездатність команд, комунікацій та зовнішніх партнерів у кризі.
• Стандартизувати реакцію і навчання персоналу.

2) Основні компоненти BCP

1. BIA (Business Impact Analysis) - оцінка впливу відмов на процеси і бізнес.
2. Ризики і сценарії - матриця загроз (інфраструктурні, зовнішні, людські).
3. RTO/RPO цілі - цільові значення відновлення і допустимих втрат.
4. План відновлення (DRP) - деталізовані кроки по перезапуску систем і процесів.
5. Комунікації - внутрішні і зовнішні канали, шаблони повідомлень.
6. Тестування та ревізія - регулярні перевірки, навчання, пост-аналіз.
7. Документування і контроль версій - централізований доступ і актуальність.

3) Аналіз впливу (BIA)

BIA визначає, які процеси критичні, і як швидко вони повинні бути відновлені.

1. Перелік усіх бізнес-процесів (Payments, Bets, Games, KYC, Support).

2. Визначення залежностей (сервіси, дані, провайдери, співробітники).

3. Оцінка впливу відмови: фінансове, юридичне, репутаційне, операційне.

4. Встановлення RTO/RPO для кожного процесу.

5. Пріоритизація: «Must Have», «Should Have», «Nice to Have».

4) Матриця ризиків

5) RTO, RPO і рівні критичності

RTO (Recovery Time Objective): скільки часу допустимо до відновлення.
RPO (Recovery Point Objective): який обсяг даних можна втратити.

6) DRP (Disaster Recovery Plan)

Мета: забезпечити швидке і послідовне відновлення систем.

1. Визначити сценарії (катастрофа ЦОДа, збій PSP, компрометація ключів, втрата мережі).

2. Для кожного сценарію - готовий покроковий playbook.

3. Підтримувати DR-інфраструктуру: резервні кластери, БД-репліки, CDN/edge.

4. Регулярно тестувати RTO/RPO і процедури failover.

5. Зберігати всі інструкції в єдиному сховищі з контролем версій.

Scenario: EU region falls
RTO: 30 min    RPO: 5 min
Actions:
1. Activate plan DR # EU
2. Switch DNS → AP Region
3. Verify database consistency (replication lag ≤ 60s)
4. Update Status on StatusPage
5. Perform API benchmarking

7) Організація команд і ролей

BCP-координатор: власник програми, організовує ревізії та тести.
DR lead: відповідає за технічну реалізацію DR-планів.
Domain Owners: забезпечують безперервність своїх процесів (Payments, Games, KYC).
Команда комунікацій: відповідає за внутрішні/зовнішні повідомлення і статус-платформи.
HR/Admin: BCP для персоналу (віддаленка, зв'язки, доступи).
Legal/Compliance: регуляторні повідомлення та юридичні заходи.

8) Комунікації в кризу

• Чіткі канали і резервні контакти.
• Перший апдейт - протягом 15 хвилин після інциденту.
• Єдиний тон комунікацій, факти і ETA.
• Оновлення кожні N хвилин до закриття інциденту.
• Після відновлення - звіт і постмортем.

[HH: MM] PSP-X failed. Impact: Deposits in EU region.
Measures: feilover on PSP-Y. ETA stabilization: 30 min.
The next update is at 15:00.

9) Тестування та навчання

Технічні: failover тести, відновлення БД, симуляції DDoS.
Операційні: handover/рольова зміна команд.
Повні BCP-навчання: сценарій «blackout» або недоступність провайдера.

• DR-тести - щокварталу;
• BCP-повномасштабне навчання - 1-2 рази на рік.
• Документування: результати, відхилення від RTO/RPO, дії по поліпшенню.

10) Метрики та KPI

RTO compliance: % процесів, відновлених ≤ цілі.
RPO compliance: % процесів без втрати даних> цільового.
DR test success rate: успішні перевірки процедур відновлення.
BCP coverage: частка процесів з актуальними планами (> 90%).
Comms SLA: перше зведення ≤ 15 хв, оновлення по ETA.
Postmortem SLA: 100% критичних подій з аналізом ≤ 72 год.

11) Документація та управління знаннями

Єдине BCP-сховище (версії, власники, дати ревізій).
Контроль версій: ревізія не рідше, ніж раз на 6 місяців.
Доступність: офлайн-копії та резервні канали зв'язку (включаючи телеком/месенджери).
Інтеграції: посилання на BCP в SOP, інцидент-процесах і операційних дашбордах.
Синхронізація з Risk Register і Security Policies.

12) 30/60/90 - план впровадження

• Визначити власника BCP і критичні процеси.
• Виконати базовий BIA і класифікацію (RTO/RPO).
• Створити матрицю ризиків і каталог інцидент-сценаріїв.
• Розробити шаблон DRP і першу версію для пріоритетних сервісів.

• Провести пілотне DR-тестування (failover, відновлення БД).
• Підготувати комунікаційні шаблони та рольовий розподіл.
• Створити єдине сховище BCP-документів і SOP-інтеграцію.
• Почати навчання команд і on-call персоналу.

• Провести міжкомандне BCP-навчання.
• Провести аудит відповідності RTO/RPO і метрик KPI.
• Фіналізувати план перегляду та автоматизацію BCP-процесів.
• Включити BCP в квартальні OKR і внутрішні перевірки безпеки.

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

«BCP тільки для галочки»: немає реальних тестів і власників.
Застарілі DR-інструкції, що не співпадають з поточними архітектурами.
Неперевірені канали комунікацій та контакти.
Невраховані залежності (PSP, CDN, KYC-провайдери).
Відсутність постмортемів після збоїв.
Немає офлайн-доступу до BCP при падінні мережі.

14) Приклад структури документа BCP

1. Objectives and Scope
2. Critical Processes (BIA)
3. Risk Matrix
4. Target RTO/RPO
5. DRP (by scenario)
6. Contacts and Roles
7. Communication templates
8. Schedule of tests and exercises
9. Reporting and auditing
10. Version and update history

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

Операційна аналітика: метрики headroom і деградації до інцидентів.
Система повідомлень та алертів: ранні сигнали для запуску BCP-процедур.
Етика управління: прозорі звіти і чесні тести.
AI-помічники: автоматична підготовка BCP-зведень і DR-check-листів.
Культура відповідальності: тренінги, «game days», ретроспективи.

16) FAQ

Q: Чим BCP відрізняється від DRP?
A: BCP - ширше: охоплює людей, процеси, комунікації, партнерів та інфраструктуру. DRP - технічний план відновлення ІТ-систем.

Q: Як часто оновлювати BCP?
A: Після кожної великої зміни архітектури, інциденту або не рідше 1 разу на 6 місяців.

Q: Чи потрібно включати партнерів?
A: Так. PSP, KYC і студії - частина ланцюжка безперервності, повинні мати свої OLA і BCP-угоди.