Операции и Управление → Непрерывность бизнес-процессов

Непрерывность бизнес-процессов (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-соглашения.