4. 业务影响分析（BIA）实战

业务影响分析（Business Impact Analysis，BIA）是灾备恢复设计的起点。它要回答三个问题：哪些AI业务功能一旦中断会造成实质损失？这些功能依赖哪些Databricks资产？中断多久、丢多少数据是可以接受的？如果跳过BIA直接去配置跨区域复制，往往会出现“备份了不重要的表、关键模型却没人管”的错配。

一、从业务功能出发，而不是从资产出发

BIA的第一步是列出AI业务功能，而不是先盘点Notebook和表。所谓AI业务功能，是指“对业务用户或下游系统产生可感知价值的一段AI能力”，例如“实时反欺诈评分”“每日个性化推荐生成”“客服工单自动分类”“信贷申请风险模型批量打分”。每个功能都要标注业务负责人、服务对象、中断后的直接后果（收入损失、合规风险、客户体验下降）以及是否有手工降级方案。

建议用“影响维度打分”来区分优先级，而不是凭感觉排序。常见维度包括：财务影响（每小时损失金额）、合规影响（是否触发监管上报时限）、客户影响（受影响用户规模）、运营影响（是否阻塞其他流程）。每个维度按1～5分打分，加权求和后得到业务关键度。例如某电商的“实时反欺诈评分”财务影响5分、合规影响4分、客户影响4分、运营影响5分，加权后明显高于“离线用户画像更新”，因此前者应进入最高恢复优先级。

二、把业务功能映射到Databricks资产

确定关键功能后，需要沿调用链向下拆解依赖。Databricks上的AI功能通常由四类资产构成：Notebook（开发与编排逻辑）、Job（调度与执行）、Model（注册在Unity Catalog或MLflow中的模型版本）、Feature Table（特征表，含离线特征与在线特征）。此外还要考虑底层依赖：Delta表、外部存储路径、Secret Scope、集群策略、服务连接等。

映射时建议采用“功能—资产—依赖”三层结构，并标注每项资产的关键属性：所在工作区、Catalog/Schema、是否跨区域、更新频率、上游数据源。下面这张图展示了一个典型AI业务功能的依赖拓扑，用于说明BIA中需要识别的对象与连接关系。

图中可以看到，同一个业务功能向下拆出了四类资产和四类底层依赖。BIA的价值就在于把“实时反欺诈评分”这个业务语言，翻译成“fraud_scoring_hourly Job + fraud_xgb v3 Model + user_txn_features Feature Table + 在线特征库”这样的技术清单，并逐项标注恢复要求。

三、设定RTO与RPO：从业务容忍度反推技术指标

RTO（Recovery Time Objective）是恢复时间目标，指业务中断后多长时间内必须恢复；RPO（Recovery Point Objective）是恢复点目标，指允许丢失多长时间的数据。两者都由业务容忍度决定，而不是由技术能力决定。技术团队可以评估“能不能做到”，但“需不需要做到”必须由业务方回答。

设定时建议分层分配，而不是给所有资产一个统一值。以“实时反欺诈评分”为例：业务方要求交易拦截不能中断超过15分钟，那么业务功能层RTO就是15分钟。但Job本身可以容忍30分钟，因为Job重跑后能补上评分；Model版本必须10分钟内可用且不能丢版本，因为模型是评分的核心逻辑；Feature Table的在线部分要求20分钟内恢复，离线部分可以放宽到1小时。RPO方面，实时评分允许丢失最近5分钟的交易特征，但模型版本RPO必须为0，因为模型版本丢失意味着无法复现评分结果，合规审计也无法通过。

这里有一个常见误区：把RPO等同于“备份频率”。备份频率只是手段，RPO是目标。如果业务要求RPO≤5分钟，而Delta表每小时才做一次快照，那就不满足要求，需要改用连续同步或更频繁的增量复制。反过来，如果某张表业务上允许丢失一天数据，就没必要为它配置分钟级复制，否则会浪费跨区域带宽和存储成本。

四、BIA交付物：一张可执行的资产—指标对照表

BIA的最终产出不是一份描述性报告，而是一张可以直接驱动灾备配置的对照表。表中每一行是一项Databricks资产，列包括：所属业务功能、资产类型、Unity Catalog全名、关键度、RTO、RPO、恢复方式（跨区域复制/快照/重建）、验证方式。下面给出一个可参考的示例结构，实际使用时按自己的资产清单填充。

这张表完成后，灾备方案就有了明确的输入：P0资产必须做跨区域同步，P1可以接受小时级恢复，P2可以用备份文件重建。后续的恢复演练、监控告警、成本预算，都可以围绕这张表展开。BIA不是一次性工作，业务功能变化、模型迭代、数据源调整后都需要重新评估，建议至少每季度复核一次关键度与RTO/RPO指标。