Введение

SwiftRide T+8M. CDO Office имеет BIA entries (M6.1) и 4-уровневое mapping (M6.2). Continuity Lead: «Процесс Tier-1, RTO 1h, RPO 5 min». Engineering Lead: «Я могу дать RTO 1h и RPO 5 min для Aurora cluster — sync multi-region replication. Стоит около $1.8M в год incremental». CFO: «А если RPO 60 минут?». Engineering Lead: «$600K — async replica». CFO: «А RPO 24h?». Engineering Lead: «$50K — daily backup S3».

Decision matrix имеет реальные материальные последствия. Этот урок — про derivation: как методично перевести tier classification в конкретные data RTO/RPO targets, как обосновать cost tradeoffs перед business owner и аудитом, и как выровнять data tolerances с process tolerances, избегая gaps.

Tier-based: process tier → наследование CDE

Базовый принцип — data tier наследует process tier (worst-case среди потребляющих процессов, M6.2). Из tier следуют дефолтные RTO/RPO targets. SwiftRide T+9M tier matrix:

Несколько критических заметок:

1. Data tier RTO обычно более свободный, чем process tier RTO (буфер). Восстановление процесса требует и application, и data восстановления; если data tier RTO равен process RTO, у application — ноль времени. Best practice — data tier RTO = process RTO × 1.5–2; оставшийся бюджет — application startup, валидация, ramp-up.
2. Data tier RPO равен process RPO (без буфера). RPO измеряет потерю данных; нет смысла в «application RPO» отдельно — stateless application layer полагается на данные. Data RPO = process RPO напрямую.
3. Дефолты — стартовая точка, не обязаловка. Конкретный CDE может оправдать tighter (например, commission_pct никогда не восстанавливаем — RPO=0 обязателен) или looser. Документируй отклонения явно.

Cost-impact tradeoff matrix

Выбор recovery pattern — компромисс между infrastructure cost и достижимым RTO/RPO. Категории:

Sync replication — RPO=0 (или sub-second), RTO 1–2h

Архитектуры:

• Aurora Global Database в synchronous mode — single-region primary + cross-region replica синхронно обновляются. Никакая запись не подтверждается, пока обе регионы не закоммитили. RPO sub-second. Cost — 2x primary cost + cross-region network. Годовая оценка SwiftRide ~$1.8M для Aurora swiftpay-cluster sync replication EU + US.
• CockroachDB multi-region serializable — distributed transactions с synchronous quorum write. RPO 0. Cost — 3x single-region (3 региона для quorum). SwiftRide использует для критических метаданных SwiftPay.
• Snowflake account с replication + failover — Snowflake replication group + failover group; near-zero RPO для replicated objects; RTO измеряется в минутах promote+DNS-switch. Cost — ~1.5x primary account.

Sync replication — оправдана только для Tier-1 CDE, где RPO 0 обязателен. Underpayments драйверов при потере данных = запросы labor regulator + restatement; RPO 0 — бизнес-требование, не предпочтение инженерии.

Async replication — RPO 5–60 min, RTO 4–8h

Архитектуры:

• Aurora read replica async — replica lag типично 100ms–5s при нормальной нагрузке; под стрессом может растягиваться до минут. RPO 5–15 min комфортно. Cost — 1.2x primary (replica compute + storage).
• PostgreSQL streaming replication async — WAL streamed; похожий профиль.
• S3 cross-region replication (CRR) — async; replication lag минуты–часы для крупных объектов. RPO 15–60 min реалистично.
• Kafka MirrorMaker / Confluent Replicator — топики реплицируются async; RPO 1–15 min.

Async — рабочая лошадка для Tier-2. Cost-effective; восстановление чистое; SLA достижим. ECL pipeline SwiftCapital (RPO 60min target) — async replication достаточно.

Daily backup + cross-region — RPO 24h, RTO 8–48h

Архитектуры:

• AWS Backup vault lock + cross-region — daily snapshots автоматизированы; vault lock предотвращает tampering 7y; cross-region copies S3.
• Snowflake daily full clone в alt account — дорого, если большие данные; обычно предпочтительнее включить Time Travel + replication group.
• S3 + Glacier Vault Lock — архивы для long-term retention; SOX 7y immutability.

Daily backup — дефолт для Tier-3. Дёшево; restore измеряется часами–сутками; daily granularity (терять до 24h записей приемлемо). CDE Marketplace analytics — daily backup подходит.

Интерактивный калькулятор

Калькулятор демонстрирует нелинейную cost-кривую. Движение от RPO 24h к RPO 60 min — скромный прыжок (~3x cost). От RPO 60min к RPO 5min — значительный прыжок (~2x). От RPO 5min к RPO 0 — мажорный прыжок (~2x). Total cost от самого дешёвого к самому дорогому ~10x. Обосновать инвестицию через impact-curve из BIA: импакт на час-X $Y; разница cost sync vs async$D в год; если ожидаемая вероятность инцидента × loss > D/год → инвестируй sync.

Sync vs async vs daily backup — детальное сравнение

Sync replication в деталях

Как работает. Запись на primary не подтверждается, пока replica тоже не закоммитила. Distributed transaction protocol (two-phase commit или RAFT consensus). Replica всегда консистентна с primary; failover детерминирован.

Плюсы.

• RPO 0 — нулевая потеря данных в сценарии failover.
• Replica сразу готова — RTO определяется promotion + DNS, не data catch-up.
• Auditable — write trace содержит evidence, что обе регионы приняли.

Минусы.

• Network latency напрямую влияет на write performance. Cross-region sync write: минимум 50–100ms vs <5ms single-region.
• Cost ~2x primary infrastructure.
• Толерантность к network partition ограничена — если primary теряет связь с replica, записи блокируются (или принимают reduced consistency).
• Операционная сложность — процедуры failover должны обрабатывать предотвращение split-brain.

Когда обязательно. Customer-facing real-time financial flows; healthcare patient records; live trading systems. SwiftPay payouts подходят.

Async replication в деталях

Как работает. Запись подтверждается клиенту, когда primary committed; replica обновляется асинхронно, обычно WAL/binlog streaming. Replica lag зависит от network throughput, replica capacity, primary load.

Плюсы.

• Производительность записи на primary не затронута (нет ожидания replica).
• Cost ~1.2x primary.
• Толерантна к network partition — primary продолжает обслуживать; replica catches up при переподключении.

Минусы.

• RPO ненулевой — типично 5–60 min в зависимости от нагрузки. Под стрессом (Kafka topic spike, DB load test) репликация может значительно отставать.
• Replica может быть stale в момент failover — требуется аккуратная application logic (idempotent processing, replay).

Когда достаточно. Внутренний регуляторный репортинг (точность данных верифицируется ретроактивно); batch ML feature pipelines; non-real-time analytics. ECL pipeline SwiftCapital (daily run, retro-verifiable) подходит.

Daily backup в деталях

Как работает. Periodic snapshot — full или incremental — записан в durable storage (S3, vault-locked). Restoration загружает snapshot, применяет pending logs если incremental.

Плюсы.

• Cost минимальный — S3 + Glacier tiers; <$50/TB в год retention.
• Операционная простота — хорошо понятно, хорошо инструментировано (AWS Backup; Snowflake Time Travel + clone).
• Возможна длительная retention — 7y SOX vault lock vs operational replicas.

Минусы.

• RPO ≥ snapshot interval (обычно 24h, иногда 4–12h).
• RTO измеряется часами–сутками (snapshot retrieve + restore + validate).
• Point-in-time recovery ограничен snapshot intervals; недавние данные потеряны.

Когда достаточно. Внутренняя аналитика; справочные данные; архив; reporting datasets с нечастыми обновлениями. SwiftRide T+9M Tier-3 datasets — daily backup как основной recovery.

Выравнивание data RTO/RPO с process RTO/RPO

Критическое правило: tolerances data tier должны выровняться с process tolerances; ни драматически tighter, ни looser.

Драматически tighter — впустую

Если process RTO 8h (Tier-2 SwiftCapital) и data tier RTO 1h (sync replication), data tier даёт восстановление за 1h, но application восстанавливается 4h — 4h gap, данные готовы / application сломан. Инвестиция впустую; могли использовать async replication (RTO 4h), экономя cost.

Драматически looser — gap

Если process RTO 1h (Tier-1 SwiftPay) и data tier RTO 8h (async replication), data tier даёт восстановление за 8h, но process MTD 4h — процесс фейлится до того, как данные доступны. Аудитор видит alignment violation; кандидат на SOX material weakness.

Правильное выравнивание — буфер

Data tier RTO ≈ 0.5–0.7 × process RTO (данные готовы раньше, оставляют время на восстановление application + валидацию). Data tier RPO = process RPO (без отдельного учёта).

Таблица выравнивания SwiftRide T+9M:

Переговоры между бизнесом и инженерией

В реальности cost-impact decision вовлекает business + engineering + risk + finance. Рекомендуемый паттерн:

1. Engineering представляет 3 опции — sync ($1.8M), async ($600K), daily backup ($50K) с достижимыми RTO/RPO для каждой.
2. Business owner ссылается на BIA impact-over-time — час 1 = $50K, час 12 =$4.5M и т.д.
3. Risk function вычисляет ожидаемый годовой убыток — вероятность × impact, учитывает regulatory penalty range.
4. Finance одобряет capital allocation — ROI-математика защитима перед советом директоров.
5. Audit committee пересматривает решение — выравнивание с tier classification; документировать обоснование в decision log.

ECB RDARR Guide ECB RDARR Guide May 2024 ожидает «data quality management with KPIs and KRIs» — неявно включает трекинг RTO/RPO + drill outcomes. SwiftRide pre-IPO без regulated bank status напрямую не subject, но bank-partner subject ⇒ contractual flow-down.

Матрица tier-assignment SwiftRide

T+9M Continuity Committee одобрила tier matrix:

tier_matrix:
  - tier: Tier-1
    description: "Customer-facing real-time + financial reporting upstream"
    processes:
      - PROC-SWP-001 (driver payout)
      - PROC-MTC-001 (trip matching)
      - PROC-KYC-001 (real-time KYC)
      - PROC-AML-001 (transaction monitoring)
    data_rto_default: "2h"
    data_rpo_default: "5min"
    pattern_default: "Sync multi-region replica + Time Travel + cross-region S3 vault lock"
    annual_incremental_cost_estimate: "$2.4M (5 Tier-1 datastores)"

  - tier: Tier-2
    description: "Regulatory reporting + lending + non-real-time financial"
    processes:
      - PROC-CAP-001 (SwiftCapital loan portfolio)
      - PROC-IFRS9-001 (ECL daily run)
      - PROC-1099-001 (annual tax export)
      - PROC-BCBS-001 (capital reporting weekly)
    data_rto_default: "16h"
    data_rpo_default: "60min"
    pattern_default: "Async replica + cross-region snapshot 4h cadence"
    annual_incremental_cost_estimate: "$300K (4 Tier-2 datastores)"

  - tier: Tier-3
    description: "Internal analytics + reporting + reference data"
    processes:
      - PROC-ANALYTICS-001 to PROC-ANALYTICS-014
      - PROC-REF-001 (reference data)
      - PROC-DASH-001 (executive dashboards)
    data_rto_default: "72h"
    data_rpo_default: "24h"
    pattern_default: "Daily backup + S3 cross-region replication + Glacier 7y archive"
    annual_incremental_cost_estimate: "$80K (15 Tier-3 datastores)"

  total_incremental_dr_cost_annual: "$2.78M"
  governance_review_cadence: "Annual; ad-hoc на launching new product"

Эта матрица — одобрена Risk Committee + CFO + Board; задокументирована в SwiftRide IT Resilience Policy. Cost $2.78M annual — не тривиально; защищён против ~$50M month-burn IPO delay risk + ~$10M ожидаемого годового убытка от major DR events.

Anti-patterns

Единый recovery pattern для всех CDE

Паттерн: команда применяет one-size-fits-all — например, sync multi-region для всего «на всякий случай».

Почему плохо: 15 Tier-3 datasets на sync replication = ~$1M ненужного годового cost; затягивает операционное бремя engineering без business benefit. Обратное — daily backup для Tier-1 = SOX material weakness.

Fix: tier matrix дифференцирует; каждый CDE сопоставлен с дефолтом tier; отклонения документируются per CDE.

Вывод RTO по принципу «что даёт инфраструктура»

Паттерн: «у нас Aurora с async replica → RPO 5min для этого CDE». Tier classification reverse-engineered из возможностей инфраструктуры, не из business impact.

Почему плохо: обратная причинность; tier должен driver infrastructure choice, не наоборот. Может привести к Tier-1 CDE на async (gap) или Tier-3 CDE на sync (waste).

Fix: порядок вывода — process tier → data tier targets → infrastructure choice. Audit trail в реестре: «tier=Tier-1 derived from BIA process [list]; data RTO 2h target; infrastructure choice — sync replica → expected RTO 30min, expected RPO <1s; choice approved [date] [Risk Committee]».

RTO 0 потому что «у нас не может быть downtime»

Паттерн: business owner заявляет «у нас не может быть downtime — RTO 0».

Почему плохо: RTO 0 невозможен (любой failover занимает какое-то время, даже active-active). Утверждение отражает непонимание; инженер не может реализовать.

Fix: переоткрыть с реалистичными границами. «Какой максимально допустимый downtime, при котором бизнес выживает и regulatory deadlines не пропущены?». Обычно ответ 30 min — 4h после probing.

RPO 0 выведен из «никакая потеря данных не приемлема»

Паттерн: похожее — RPO 0 заявлен как бизнес-требование.

Почему плохо: RPO 0 требует sync replication, $$$. Часто запрос выведен из осторожной формулировки («no data loss»), не из реального бизнес-анализа. Может смягчиться к RPO 5 min, если бизнес понимает, что 5 min потерянных записей = $50K (Tier-1) vs$1.2M annual incremental cost sync.

Fix: пробить, что бизнес реально имеет в виду. «Если потеряем 5 минут записей — кого это затрагивает, и каков реальный импакт $$$?». Часто ответ раскрывает, что RPO 5 min достаточен.

Резюме

• Tier matrix — дефолтные RTO/RPO выведены из process tier. Data RTO обычно = 0.5–1.0 × process RTO (буфер для application recovery); Data RPO = process RPO (без буфера).
• Три семейства recovery patterns: sync ($$$, RPO 0), async ($, RPO 5–60min), daily backup ($, RPO 24h). Выбор driven by tier + BIA impact-over-time + cost analysis.
• Sync replication — оправдана только для Tier-1 (RPO 0 обязателен; импакт на час 1 уже материален; sync cost окупается избеганием единственного инцидента).
• Async replication — рабочая лошадка для Tier-2 (cost-effective; чистое восстановление; SLA достижим).
• Daily backup — дефолт Tier-3 (дёшево; SOX 7y retention через vault lock).
• Выравнивание data ↔ process tolerances — ни слишком tight (впустую), ни слишком loose (gap). Документировать обоснование вывода per CDE.
• DORA Art. 11 + ECB RDARR Guide + BCBS 239 Principle 5 — первичные regulatory anchors. DORA явно требует RTO/RPO для critical functions; BCBS 239 P5 включает crisis production timeliness.

В M6.4 раскроем стратегию переиспользования существующего BIA (обычно принадлежит Continuity Team в Risk function) для data programme — не проводить с нуля, а извлекать data-relevant entries и заполнять gaps.