Введение

T+9M SwiftRide table-top упражнение — Continuity Team симулирует 4h outage SwiftPay. Engineering Lead представляет DRP: «через 47 минут primary Snowflake region promoted; Aurora failed over; data 5min RPO recovered». CFO задаёт вопрос: «А что делает бизнес в 47 минут down? Drivers видят ‘payout pending’ в app? Bank-partner получает push notification? Customer service team имеет script?». Engineering Lead — тишина. Этот gap — BCP, не DRP.

BCP (Business Continuity Plan) шире, чем DRP (Disaster Recovery Plan); DRP ⊆ BCP. DRP — technical layer (восстановление систем, данных, инфраструктуры). BCP — business layer (обходные пути, коммуникация, альтернативные процедуры). Pre-IPO Big 4 ожидает оба артефакта, интегрированных, валидированных через упражнения. Этот урок — про интеграцию BCP: что туда включается, как восстановление данных вписывается, различие BCP vs DRP.

BCP vs DRP — границы

DRP (Disaster Recovery Plan)

Technical subset. Документ:

• Инвентаризация ICT system / data asset + последовательность приоритета восстановления.
• Recovery procedures шаг за шагом — runbooks, scripts, runner playbooks.
• Recovery roles — on-call ротация, цепочки эскалации, decision authority.
• Recovery validation — health checks, smoke tests, проверка целостности данных.
• Failback procedures — когда primary восстановлен, как вернуться.

Аудитория — Engineering / Platform / DBA teams. Drill-tested через DR drills (M6.6). Audit evidence — drill logs + post-mortems.

BCP (Business Continuity Plan)

Более широкий scope включает DRP + business-level continuity. Дополнительно:

• Ручные обходные пути — что делает бизнес, когда автоматизированные системы down. Примеры: SwiftPay paper-process для аварийных payouts; SwiftCapital manual loan approval через email + signed PDF; Customer Service script + цепочка эскалации.
• Alternative sites / locations — физическое нарушение работы офиса (пожар, потоп, региональный power); сотрудники работают из secondary location или удалённо.
• Процедуры коммуникации — внутренние (сотрудники, совет директоров, exec) + внешние (клиенты, регуляторы, media, vendors).
• Decision rights в кризисе — кто может авторизовать аварийные расходы, customer compensation, публичное заявление.
• Эскалация vendor — обработка SLA breach критического vendor.

Аудитория — вся организация. Drill-tested через table-top упражнения (менее частая периодичность, чем DR drills — обычно annual). Audit evidence — exercise reports + минуты + lessons-learned.

Визуализировано:

DORA DORA Art. 11 требует оба — entity должен «adopt а comprehensive business continuity policy… document recovery plans… implement business continuity arrangements addressing… availability, authenticity, integrity, confidentiality of data».

Ручные обходные пути — сценарии недоступности данных

Критический вопрос — что бизнес делает, когда данные недоступны? Несколько паттернов обходных путей.

Pattern 1 — Ручной ввод данных

Если автоматизированный пайплайн down, но ручные системы доступны, сотрудники вводят данные вручную. Пример SwiftRide T+9M: SwiftPay payout flow down → customer service team вручную вводит payout requests в аварийную форму, ставится в очередь на batch processing, когда автоматизированная система восстанавливается.

Ограничения: устойчиво только для low-volume; качество деградирует (опечатки, пропущенные записи); SOX-grade evidence слабый.

Pattern 2 — Кэшированные / staged данные

Если real-time данные недоступны, но недавний кэш существует, бизнес работает на кэше. Пример SwiftRide: trip matching service down → drivers видят cached ride availability heatmap (~30 min stale); матчи деградируют, но сервис продолжает.

Ограничения: окно staleness — данные могут быть неверны; сверка при восстановлении.

Pattern 3 — Альтернативный партнёр / система

Backup vendor или система берёт на себя критический flow. Пример SwiftPay: primary bank partner down → secondary PSP (PayPal commercial agreement) обрабатывает payouts; сверка после восстановления.

Ограничения: обычно требует предварительного commercial agreement; rate-limited; secondary partner может иметь другую data schema.

Pattern 4 — Suspended-with-comms

Сервис приостановлен, но клиенты уведомлены ясно. Пример SwiftPay: «Wallet temporarily unavailable; resumes by X UTC; pending payouts processed first».

Лучше всего для коротких outages; не жизнеспособен >4–8h без значительного revenue impact.

Pattern 5 — Деградированный сервис

Сервис работает, но с уменьшенной функциональностью. Пример SwiftRide: ride-hailing продолжается; surge pricing отключён (данные pricing engine недоступны) — flat rate; выручка деградирована, но сервис доступен.

Полезно для сохранения customer engagement; документировать явные ожидания degradation.

Когда что инвоцировать

BCP должен документировать на каждый критический процесс дерево решений:

process: PROC-SWP-001 (driver payout)
workaround_decision_tree:
  - outage_duration: "< 30 min"
    workaround: "Pattern 4 — Suspended with comms; payouts queued"
    invocation_authority: "On-call IC + Customer Success Lead"
  - outage_duration: "30 min - 2h"
    workaround: "Pattern 2 — Cached recent payout data; new payouts queued; communications escalated"
    invocation_authority: "IC + VP Engineering + Head of Customer"
  - outage_duration: "2h - 24h"
    workaround: "Pattern 3 — Failover к secondary PSP (PayPal commercial agreement, pre-staged)"
    invocation_authority: "CTO + CFO sign-off; bank-partner notified"
  - outage_duration: "> 24h (MTPD approaching)"
    workaround: "Pattern 5 — Service degradation; emergency board call; regulator notification"
    invocation_authority: "CEO + Board; General Counsel coordinates external comms"

Alternative sites — hot / warm / cold DR

Терминология DR site — классическая концепция BCM; применима также к data infrastructure.

Hot DR site

Непрерывно синхронизированная replica; takeover ~минуты. Active-active вариант — оба сайта принимают записи; auto-balance.

• Cost — 1.5–2x primary infrastructure.
• RTO — sub-minute (active-active) до ~15 min (active-passive с auto-failover).
• RPO — 0 (sync replication).

Пример data tier: Aurora Global Database в synchronous mode (M6.3); CockroachDB multi-region; Snowflake replication group with failover group.

Когда обязательно: Tier-1 financial flows (SwiftPay payouts подходят), real-time trading, healthcare critical systems.

Warm DR site

Standby с recent data; takeover часы. Replica существует, но не активно обслуживает трафик; нуждается в promotion + warmup.

• Cost — 1.2–1.4x primary.
• RTO — 1–8h (зависит от сложности warmup).
• RPO — 5–60 min (async replica).

Пример data tier: Aurora read replica async; PostgreSQL streaming replication; S3 cross-region replication enabled.

Когда достаточно: Tier-2 regulatory reporting, lending pipelines, non-real-time financial.

Cold DR site

Backup + capability to restore; takeover дни–недели. Бэкапы хранятся offsite; infrastructure manifests готовы, но не работают.

• Cost — <10% primary.
• RTO — дни (provision infrastructure + restore from backup + validate).
• RPO — 24h+ (daily backup cadence).

Пример data tier: S3 + Glacier 7y; AWS Backup vault lock cross-region; daily Snowflake clone к dormant account.

Когда достаточно: Tier-3 internal analytics, reference data, archive.

Multi-region active-active

Специальная архитектура, где несколько регионов обслуживают трафик одновременно. Failure одного региона — трафик переходит к другим без оркестровки.

• Cost — N× primary (N регионов); операционная сложность высока.
• RTO — sub-second (нет failover; load-balancer reroutes).
• RPO — 0 (sync writes ко всем регионам).

Когда обязательно: hyper-critical real-time systems (payment processors, real-time bidding, gaming). SwiftRide не использует active-active в настоящее время — sync hot-standby достаточно для Tier-1; active-active overkill для текущего масштаба.

Communication trees

Кто кого уведомляет при инциденте? BCP включает задокументированные comm trees на сценарий.

Внутренний comm tree

Каждый узел — pre-defined role + named individual + backup individual (если primary недоступен). Методы уведомления явны (телефон предпочтительно для urgent; Slack как secondary).

Внешний comm tree

Тайминг для регуляторов критичен:

• DORA Art. 19 — initial notification в течение 4h классификации как major; intermediate report в течение 72h; final 1 месяц.
• NIS2 Art. 23 — early warning 24h; full report 72h; final 1 месяц (для essential entities).
• GDPR Art. 33 — personal-data breach notification 72h.
• Form 8-K — material cybersecurity incident disclosure «without unreasonable delay» (4 рабочих дня после определения materiality, текущая интерпретация SEC).
• PSD2 Art. 96 — major operational/security incidents «without undue delay»; bank-partner обычно файлит.

BCP должен точно указать тайминг по регулятору на сценарий; шаблоны pre-approved General Counsel; auto-trigger workflows.

Crisis vs business-as-usual data production

BCBS 239 Principle 5 явно требует «produce aggregate risk data within timeframes matching risk volatility and reporting needs». Что критично, Principle 5 применяется во время crisis production — не только normal operations.

Normal mode

Стандартные пайплайны работают; daily reporting cadence; reconciliation runs scheduled. Допуски применяются по BIA.

Stress mode

Повышенная волатильность рынка (financial crisis, геополитическое событие); регуляторы могут потребовать intra-day reporting; пайплайны могут нуждаться в ускорении. Допуски временно ужесточаются.

Crisis production mode

Активный инцидент; primary systems compromised или degraded. Данные могут производиться через альтернативные пайплайны — backup compute, ручная агрегация, альтернативные source systems.

SwiftPay (если bank-partner G-SIB-affiliated) subject через contractual flow-down. Планирование crisis production:

• Alternative compute — Snowflake backup account; Spark cluster во вторичном регионе.
• Alternative source — если primary OLTP down, batch reconstruct из event stream (Kafka).
• Ручная агрегация — если и primary, и backup compute down, finance team вручную агрегирует из raw transaction logs.
• Tightened review — выходные данные ревью 2 senior individuals перед публикацией (crisis-mode SoD).

ECB RDARR Guide ожидает «evidence of crisis production capability through testing» — annual stress-mode drill минимум.

SwiftRide BCP-план для сценария 4h outage SwiftPay

Собирая всё вместе:

process: PROC-SWP-001 (Daily driver payout)
scenario: "4h SwiftPay wallet outage — Aurora swiftpay-cluster failed"
plan_components:
  technical_recovery:
    drp_runbook: "DRP-SWP-001 v3.2 (last updated 2026-04-15)"
    target_rto: "1h"
    target_rpo: "5min"
    steps:
      - "T+5min: IC declares incident; PagerDuty Sev-1"
      - "T+15min: Aurora Global Database failover initiated (primary EU-W → replica US-E)"
      - "T+30min: Snowflake account aliasing flip; replication group promoted"
      - "T+45min: Application restart Argo Rollouts blue-green"
      - "T+50min: Health-check + smoke test"
      - "T+55min: Customer comms 'restoring'; first payouts process"
      - "T+60min: Full service restored; communications 'resolved'"

  business_workarounds:
    t_0_to_30min:
      action: "Suspended-with-comms; in-app banner 'temporarily unavailable'; payouts queued"
      authority: "IC + Customer Success Lead"
    t_30min_to_2h:
      action: "Failover к PayPal commercial agreement (pre-staged); rate-limited"
      authority: "CTO + CFO sign-off"
    t_2h_to_4h:
      action: "Customer-service team manually processes top-100 emergency payouts via secured form"
      authority: "VP Customer + Customer Success Lead"

  communications:
    internal:
      - "T+5min: PagerDuty Sev-1 → IC + VP Engineering + Head of Data"
      - "T+15min: Slack #incidents-tier1 → C-suite incident bridge"
      - "T+30min: Email exec + board (template B-1)"
    customer:
      - "T+15min: In-app banner + push notification + status page"
      - "T+30min: Email к active drivers (template C-1)"
      - "T+resolved: All-clear comms"
    regulator:
      - "T+1h: BaFin pre-notification (DORA Art. 19 4h timer running)"
      - "T+4h: BaFin formal initial notification if not resolved"
      - "T+72h: Intermediate report"
      - "T+1mo: Final report"
    bank_partner:
      - "T+30min: Contractual notification via designated channel"

  decision_rights:
    declare_incident: "On-call IC"
    invoke_failover: "VP Engineering"
    invoke_paypal_failover: "CTO + CFO joint"
    invoke_emergency_payouts: "VP Customer + CFO joint"
    public_statement: "General Counsel + CEO joint"
    board_disclosure: "CEO"

  crisis_production_data:
    bcbs_239_p5: "Daily reconciliation continues via batch from Kafka stream backup"
    alternative_compute: "Snowflake account SWR-DR (cold standby; warmup 4h)"
    manual_aggregation: "Finance team script — sum payouts from Kafka topic last 24h"
    review_authority: "Joint Finance Lead + Risk Lead review before publication"

  drill_cadence: "Quarterly table-top + annual full simulation"
  last_drill: "2026-Q1 (47min actual RTO, 0min actual data loss — passed)"
  next_drill: "2026-Q2 (scheduled 2026-06-15)"

Этот план ~3–5 страниц в финальном виде (выше сокращено); reviewed Risk Committee; signed off CFO + CTO + General Counsel + CRO; опубликован в Confluence; on-call team имеет закладку.

Anti-patterns

Только DRP, нет BCP

Паттерн: организация имеет детальный DRP runbook; нет слоя BCP. «Engineering обрабатывает recovery; business разберётся с коммуникациями».

Почему плохо: ISO 22301 + DORA Art. 11 явно требуют оба; pre-IPO Big 4 ожидает интегрированный фреймворк; инцидент раскрывает нескоординированный ответ.

Fix: BCP построен поверх DRP; Continuity Team владеет BCP; CDO Office contributes data extensions.

BCP без drill validation

Паттерн: BCP задокументирован; никогда не drill-tested. Допуски теоретические; decision rights не протестированы.

Почему плохо: реальный инцидент — runbooks имеют ошибки, контакты stale, comms templates имеют опечатки. Первый drill раскрывает всё; делать это под реальным огнём ухудшает всё.

Fix: annual table-top минимум + semi-annual scenario drill для Tier-1. Lessons captured + план обновлён.

Comm tree без time bounds

Паттерн: «notify Customer Success» без «within X minutes».

Почему плохо: неоднозначность → задержка → пропущен regulator deadline → DORA Art. 19 penalty. Эрозия доверия клиента экспоненциально со временем.

Fix: time-bound на каждое уведомление; auto-trigger workflows где возможно (PagerDuty integration; auto-Slack-DM на порогах).

Crisis production не адресован

Паттерн: BCP покрывает business workarounds; data production предполагается «pipeline работает или нет» — бинарно.

Почему плохо: BCBS 239 P5 + ECB RDARR Guide явно требуют capability crisis production. Audit walkthrough: «покажите мне, как SwiftPay payout reconciliation работает, если Snowflake account down». Тишина.

Fix: alternative compute + alternative source pre-staged; процедуры ручной агрегации задокументированы; drill-tested.

Decision rights неоднозначны

Паттерн: «нужен sign-off CFO», но CFO недоступен в 3am. План застревает.

Почему плохо: incident commanders заморожены; задержки накапливаются.

Fix: pre-delegated authority в письменном виде (CFO назначает delegate заранее, signed memo). Backup authority chain на каждую роль.

Резюме

• BCP ⊃ DRP. DRP — technical subset; BCP включает business workarounds, alt sites, comms, decision rights.
• Ручные обходные пути: 5 паттернов (ручной ввод, кэш, альтернативный партнёр, suspended-with-comms, деградированный). Дерево решений на каждую длительность outage.
• DR sites: hot (sync, sub-min, $$$); warm (async, hours, $); cold (backup, days,$); multi-region active-active (sub-second, $$$$). Сопоставить с tier.
• Communication trees: внутренний (каскад IC → leadership → C-suite → board) + внешний (клиенты + регуляторы + партнёры + media). Time-bound на каждый regulator deadline.
• Crisis production (BCBS 239 P5): alternative compute, alternative source, ручная агрегация, tightened SoD review. Drill-tested.
• DORA Arts. 5–16 ICT risk management framework + Art. 11 response and recovery plans — первичные regulatory anchors. ISO 22301 Clause 8.4 strategies + 8.4.3 communications.

В M6.6 раскроем DRP testing — типы (walkthrough, simulation, full restore), периодичность на каждый tier, точки сбора evidence, типичные failure modes.