Введение

M6.1 закончилась SwiftPay BIA entry: процесс Tier-1, RTO 1h, RPO 5 min, упомянуты зависимости — три приложения и три CDE. Этот урок отвечает на конкретный вопрос: как нам перейти от process-level tolerances вниз к спецификациям восстановления на уровне данных? Continuity Team пишет BIA на уровне процесса; engineering team оперирует Snowflake account и Aurora cluster. Между ними — два слоя трансляции: application (microservices) и schema (database tables / dbt models / columns).

Без явной модели mapping, RTO/RPO для data tier выводятся «по интуиции», или вообще не выводятся (data team наследует то, что случайно применяется к инфраструктуре). Аудитор с walkthrough-вопросом PCAOB AS 2201 — «walk me end-to-end recovery от процесса признания выручки до конкретной колонки CDE» — получает тишину. CDE-SWR-003 driver_earnings_ledger без mapping = невидим в scope DR drill; первый реальный инцидент обнажает gap.

4-уровневая модель

Стандартная модель:

1. Process (владение бизнес-юнитом) — дискретная бизнес-активность. Владеет BIA entry; business owner = process owner. Пример SwiftRide: «Daily driver payout flow» (PROC-SWP-001).
2. Application (engineering ownership) — microservice / job / pipeline, реализующий процесс. Может быть один на процесс или несколько. Пример: driver-earnings-service, commission-reconciler, 1099-export-job.
3. Schema (data ownership) — database tables / dbt models / data structures, где живут CDE. Пример: fct_driver_earnings (Snowflake dbt model), swiftpay.payouts (Aurora OLTP).
4. Data / CDE (data owner ownership) — конкретная колонка / коллекция строк / поле, помеченное как CDE. Пример: gross_earnings_usd (CDE-SWR-003), commission_pct (CDE-SWR-006).

Параллельно идёт infrastructure layer — cloud accounts, регионы, storage volumes, сетевые пути. Инфраструктура режет поперёк schema layer (один Snowflake account содержит 100+ schemas); recovery patterns на уровне инфраструктуры влияют на много schemas/CDE одновременно.

Дерево выше показывает полную декомпозицию для CDE-SWR-003 в SwiftRide. Клик по разным узлам показывает RTO/RPO/владельца/recovery pattern на каждом уровне. Обратите внимание — tier распространяется сверху вниз: process Tier-1 → applications Tier-1 → schemas Tier-1 → data Tier-1. Mixed-tier пример (1099-export-job Tier-2) — приложение участвует в нескольких процессах, наследует worst-case в одном пути и более loose в другом.

Bottom-up vs top-down trace

Два направления mapping; обычно проводят оба и сверяют.

Bottom-up: data → schema → application → process

Начинается с где живут данные. Для CDE-SWR-003:

1. Data: колонка gross_earnings_usd в Snowflake-таблице DL_MARTS.FCT_DRIVER_EARNINGS.
2. Schema: dbt model fct_driver_earnings; SQL definition; upstream-зависимости — stg_trips.fare_usd × (1 - commission_pct).
3. Application: driver-earnings-service (Go microservice) реализует агрегацию; читает OLTP trips + commission_rules; публикует события driver.earnings.daily в Kafka; downstream-консьюмеры — commission-reconciler, 1099-export-job, swiftpay-api.
4. Process: driver-earnings-service участвует в процессах — daily driver payout flow (Tier-1), commission reconciliation (Tier-1), 1099 export (Tier-2), driver-earnings analytics dashboard (Tier-3).

Bottom-up раскрывает кардинальность процессов — одна CDE-колонка может питать несколько процессов с разными tier. Разрешение: data tier наследует worst-case (highest priority) tier среди всех потребляющих процессов. CDE-SWR-003 — Tier-1 (driven by payout flow), даже если используется в Tier-3 analytics параллельно.

Bottom-up — практичная точка входа для data teams: они начинают со знания структуры данных (каталог Snowflake, dbt graph, OpenLineage events) и работают вверх. OpenLineage column-level lineage (см. M5.8) делает первую половину trace автоматизируемой.

Top-down: process → application → schema → data

Начинается с BIA entry. Для PROC-SWP-001:

1. Process: «Daily driver payout flow» Tier-1; RTO 1h, RPO 5 min.
2. Application: какие microservices/jobs реализуют процесс? driver-earnings-service + commission-reconciler + swiftpay-api + bank-partner-webhook-handler.
3. Schema: какие tables/models используют эти приложения? DL_MARTS.FCT_DRIVER_EARNINGS, DL_STAGING.STG_TRIPS, SWIFTPAY.PAYOUTS (Aurora), SWIFTPAY.RECON_RUNS, DL_MARTS.COMMISSION_RULES_LIVE.
4. Data: какие CDE-колонки живут в этих schemas? CDE-SWR-003 (gross_earnings_usd), CDE-SWR-006 (commission_pct), CDE-SWR-008 (payout_amount_usd), CDE-SWR-009 (payout_status).

Top-down — обычная точка входа для Continuity Team / Risk function: они начинают с инвентаризации бизнес-процессов (output BIA) и спускаются вниз. Сложная часть top-down — граф зависимостей приложений (что реализует процесс); легко упустить, если процесс не задокументирован или multi-team.

Сверка обоих направлений

Два trace должны сойтись. Если bottom-up находит CDE-SWR-012 в output commission-reconciler, но top-down BIA entry для PROC-SWP-001 не указывает CDE-SWR-012 в зависимостях — gap. Либо:

• BIA entry неполный — CDE-SWR-012 действительно критичен для процесса, добавь.
• CDE-SWR-012 ошибочно помечен как используемый в этом приложении — проверь фактическое потребление (queries, lineage events), вероятно false positive.
• Scope процесса неясен — определи край точно (включает ли «payout flow» reconciliation? нет — это отдельный процесс).

Итераций сверки обычно 3–5 на крупный CDE; результат — чистый dependency graph, задокументированный в реестре.

Кардинальность — один процесс — много приложений — много CDE

Mapping не 1:1. Реалистичная кардинальность:

• Один процесс — много приложений — типично. PROC-SWP-001 реализован через ~5 microservices. Если один из них фейлится, процесс деградирует.
• Одно приложение — много CDE — обычно. driver-earnings-service затрагивает ~12 CDE-колонок в 4 таблицах.
• Один CDE — много процессов — обычно. CDE-SWR-003 в 4 процессах (см. KnowledgeCheck выше).
• Один процесс — много CDE — обычно. PROC-SWP-001 зависит от CDE-SWR-003 (gross), CDE-SWR-006 (commission), CDE-SWR-008 (payout amount), CDE-SWR-009 (status), CDE-SWR-011 (KYC reference).

Граф между уровнями — many-to-many; рассматривать как граф зависимостей, а не дерево. Материализуется как таблица в реестре:

# registry table: cde_process_mapping
- cde_id: CDE-SWR-003
  processes:
    - process_id: PROC-SWP-001
      role: "primary"
      tier_contribution: "Tier-1"
    - process_id: PROC-RECON-001
      role: "input"
      tier_contribution: "Tier-1"
    - process_id: PROC-1099-001
      role: "input"
      tier_contribution: "Tier-2"
    - process_id: PROC-ANALYTICS-007
      role: "reporting"
      tier_contribution: "Tier-3"
  derived_data_tier: "Tier-1"  # worst-case

Эта таблица поддерживается как часть CDE registry (M4.5 data model); обновляется при изменении lineage (OpenLineage automation) или при изменении scope процесса.

Документирование — как записывать mapping

Два артефакта.

Запись mapping per CDE

YAML встроен в реестр:

cde_id: CDE-SWR-003
name: "driver_earnings_ledger.gross_earnings_usd"
data_tier: Tier-1
processes: [PROC-SWP-001, PROC-RECON-001, PROC-1099-001, PROC-ANALYTICS-007]
applications: [driver-earnings-service, commission-reconciler, 1099-export-job, looker-payouts-dashboard]
schemas:
  - dl_marts.fct_driver_earnings (Snowflake; primary)
  - swiftpay.payouts (Aurora; downstream feed)
infrastructure:
  - account: snowflake/swr-prod
  - account: aws/swiftpay-prod
  - storage: s3://swr-cde-evidence (audit log)
rto: 2h  # tighter than process RTO 1h — buffer
rpo: 5min
recovery_pattern: "Time Travel + reprocess_driver_earnings DAG; cross-region failover via account aliasing"
last_validated_drill: "2026-Q1 DR drill — actual RTO 47min, RPO 0"

Таблица зависимостей per process

Более широкий вид, владелец — Continuity Team:

process_id: PROC-SWP-001
applications: [...]
schemas: [...]
cdes: [CDE-SWR-003, CDE-SWR-006, CDE-SWR-008, CDE-SWR-009, CDE-SWR-011]
infrastructure: [snowflake/swr-prod, aws/swiftpay-prod, confluent/swr-events]
upstream_processes: [PROC-MTC-001 (trip matching), PROC-KYC-001 (KYC)]
downstream_processes: [PROC-1099-001, PROC-ANALYTICS-007]

Два артефакта кросс-ссылаются. Один — view с CDE; другой — view с процесса. Обновление одного → распространение в другой через tooling (OpenMetadata custom property; Atlas relationship type; кастомная link-таблица).

Запись infrastructure layer

DORA DORA Art. 8 требует «classification of ICT assets supporting critical or important functions». SwiftRide T+9M поддерживает ICT-asset inventory параллельно с CDE registry, cross-referenced. Каждый asset (cloud account, регион, storage volume, network path) помечен с tier, поддерживаемыми процессами, hosted CDE, recovery pattern. Audit walkthrough становится совместной навигацией — аудитор выбирает CDE-SWR-003 → каскад к hosted ICT assets → recovery patterns видимы.

Пример SwiftRide — полное mapping для driver_earnings_ledger

Объединение всех уровней. Дерево выше уже визуализирует; здесь — нарратив.

Process layer. Daily driver payout flow (PROC-SWP-001) — владеет CFO Office (Carlos как Finance Lead). Tier-1; RTO 1h; RPO 5 min; MTD 4h; MTPD 24h.

Application layer. Три приложения участвуют:

• driver-earnings-service (Go) — оркестрирует агрегацию. Hot-standby multi-AZ; Argo Rollouts blue-green; RTO <1h.
• commission-reconciler (Python) — daily reconciliation. Airflow DAG, идемпотентный. Hot-standby DAG во вторичном регионе.
• 1099-export-job (Python) — annual IRS export. Cold-standby — ручной рестарт достаточно; Tier-2.

Schema layer. Material schemas:

• dl_marts.fct_driver_earnings (Snowflake dbt mart) — primary-локация CDE. Time Travel 90d + Fail-Safe 7d. Cross-region replication 3 региона (EU-WEST-1, EU-CENTRAL-1, US-EAST-1).
• swiftpay.payouts (Aurora) — downstream ledger. Aurora Global Database sync replica. RPO <1 min.
• audit.recon_runs (Snowflake) — reconciliation evidence. Иммутабельная, mirrored в S3 Object Lock 7y.

Data layer. CDE-колонки:

• gross_earnings_usd (CDE-SWR-003) — основной revenue input. Tier-1.
• commission_pct (CDE-SWR-006) — множитель формулы. Tier-1.
• payout_amount_usd (CDE-SWR-008) — downstream sum. Tier-1.

Infrastructure layer. Cloud accounts:

• Snowflake account swr-prod (3 региона, replication enabled).
• AWS account swiftpay-prod (multi-AZ Aurora, multi-region S3).
• Confluent Cloud cluster swr-events (Kafka topic driver.earnings.daily).

Полное mapping позволяет audit walkthrough: «покажите, как CDE-SWR-003 восстанавливается, если Snowflake EU-WEST-1 фейлится» → engineering team демонстрирует: account aliasing flip → secondary-регион promote (Time Travel сохранил данные до 90d до failure) → re-run dbt models from staged source data; full recovery 47 минут по Q1 drill; CDE-SWR-003 RTO 2h target выполнен.

Anti-patterns

Mapping сделан один раз, никогда не обновляется

Паттерн: первичная CDE inventory строит mapping table; далее игнорируется. Application stack эволюционирует (microservices split, monoliths refactored, dbt models renamed) — mapping ссылается на устаревшие имена.

Почему плохо: drill-упражнения фейлятся при реальном инциденте — инженер следует runbook к приложению, которого больше не существует.

Fix: обновление mapping привязано к событиям OpenLineage. CI gate (M5.8), детектящий schema changes, постит impact analysis включая требование refresh mapping. Quarterly review cadence с Continuity Team.

CDE помечен, но mapping не записан

Паттерн: CDE registry помечает driver_earnings_ledger как CDE-SWR-003; ссылки на processes/applications/infrastructure пусты («TBD»). Не наследует ничего от BIA tier.

Почему плохо: RTO/RPO data tier не документирован; DR drills не включают этот CDE; первый реальный инцидент раскрывает невидимый CDE.

Fix: validation gate реестра — нельзя сохранить CDE entry без заполненных ссылок processes + applications + schemas + infrastructure. Пустой placeholder явно заблокирован.

Tier inheritance предполагается неявным

Паттерн: команда говорит «процесс Tier-1 → все CDE в этом процессе Tier-1, документировать не надо».

Почему плохо: неоднозначность при cross-process CDE (один CDE в 4 процессах — см. KnowledgeCheck). Без явного правила derivation (worst-case), конфликты tier; некоторые команды предполагают среднее, некоторые — primary process.

Fix: задокументированная политика derivation (worst-case среди потребляющих процессов); реестр хранит поле derived_data_tier отдельно от поля inherited_from, перечисляющего все contributing processes; audit trail видим.

Infrastructure layer оставлен на platform team

Паттерн: data team делает mapping process → application → schema → data; останавливается. Инфраструктура предполагается «проблемой платформы».

Почему плохо: recovery patterns инфраструктуры определяют фактически достижимый RTO/RPO. Snowflake account без cross-region replication = Tier-3 максимум независимо от того, что заявляет schema layer. Mapping не включает инфраструктуру → назначение tier фиктивно.

Fix: infrastructure layer включён в mapping table; joint review с Platform Engineering; явное поле recovery pattern на каждый infrastructure asset. M6.5 показывает фактическую интеграцию с BCP.

Резюме

• 4-уровневое mapping: process → application → schema → data; параллельно infrastructure. Tier распространяется сверху вниз; data tier наследует worst-case среди всех потребляющих процессов.
• Bottom-up (data → process) и top-down (process → data) traces должны сойтись. Итерации сверки выявляют gaps в BIA или в lineage.
• Кардинальность many-to-many. Документировать как граф зависимостей, не дерево. Таблица реестра per CDE и per process; кросс-ссылка.
• DORA Art. 8 ICT-asset inventory + BCBS 239 Principle 2 data architecture — первичные regulatory anchors. ECB RDARR Guide May 2024 ожидает интегрированную архитектуру.
• Infrastructure layer нельзя опустить — фактическая recovery capability определяется уровнем инфраструктуры.
• Обновление mapping — автоматизировано через OpenLineage где возможно; quarterly review минимум; не оставлять устаревшим.

В M6.3 раскроем, как выводить RTO/RPO targets per CDE — tier-based defaults, cost-impact tradeoff, математика синхронной vs асинхронной репликации, выравнивание data tolerances с process tolerances.