3. 业务影响分析与恢复目标设定
灾备方案最容易犯的错误，是先选技术、再找理由。正确的顺序恰好相反：先弄清楚"业务停多久会出事、数据丢多少会出事"，再让 Azure 的服务等级目标（SLO）去匹配这些数字。业务影响分析（BIA）就是完成这一步的方法论，它把模糊的"很重要"翻译成可度量、可验证、可写入 SLA 的 RTO 与 RPO。
一、BIA 的核心产出：不是文档，而是三张对应关系
BIA 的完整过程通常包含资产梳理、影响评估、依赖分析、目标设定四个环节，但真正决定灾备架构的，是它最终产出的三张对应关系：
- 业务功能 → 支撑系统：哪些应用、数据库、接口共同支撑一个业务功能，缺一不可；
- 业务功能 → 中断影响曲线：停机 15 分钟、1 小时、4 小时、24 小时分别造成什么后果；
- 业务功能 → RTO/RPO 目标：由影响曲线反推出可接受的最大停机时间与最大数据丢失窗口。
只有第三张表落到具体数字，后面的 Azure 架构选型才有依据。否则"高可用"只是一个形容词。
二、识别关键业务功能与依赖关系
识别关键功能时，不要从服务器清单出发，而要从"谁在用、用来做什么"出发。以一家在线零售企业为例，其业务功能可拆为：商品浏览、下单支付、订单履约、会员积分、客服工单、财务对账。其中商品浏览与下单支付直接产生收入，属于关键功能；财务对账虽不实时产生收入，但受监管约束，同样不可长时间中断。
依赖关系是 BIA 中最容易被低估的部分。一个"下单支付"功能，表面看只有一个 Web 前端，实际依赖链可能包括：
- Azure App Service 承载的前端与订单 API；
- Azure SQL Database 存储订单与库存；
- Azure Service Bus 传递支付回调与履约消息；
- Microsoft Entra ID 提供登录鉴权；
- 第三方支付网关（外部依赖，不受本方控制）。
依赖分析要区分强依赖与弱依赖：强依赖缺失会导致功能完全不可用，弱依赖缺失只造成体验降级。例如积分服务不可用时，下单仍可继续，只是不累计积分——这类功能就不应被赋予与支付同等级的 RTO，否则会白白抬高灾备成本。
三、量化 RTO 与 RPO
RTO（Recovery Time Objective）是业务可容忍的中断时长，RPO（Recovery Point Objective）是可容忍的数据丢失时间窗口。两者必须由业务方确认，而不是由 IT 单方面拍板。常用的量化方法是"影响分级 + 时间阈值"：
| 影响等级 | 典型后果 | 建议 RTO | 建议 RPO |
|---|---|---|---|
| 一级（致命） | 收入中断、监管违规、品牌受损 | ≤ 15 分钟 | ≤ 1 分钟 |
| 二级（严重） | 部分业务受阻、客户投诉上升 | ≤ 1 小时 | ≤ 15 分钟 |
| 三级（一般） | 内部效率下降，外部无感 | ≤ 8 小时 | ≤ 4 小时 |
| 四级（轻微） | 可延后处理 | ≤ 24 小时 | ≤ 24 小时 |
表中数值为示例性参考，实际取值需结合行业监管要求与企业风险偏好调整。需要注意的是，RTO 与 RPO 是业务目标，不是技术指标；技术侧只能承诺"能否达成"，不能替业务决定"应该定多少"。
四、把 RTO/RPO 映射到 Azure 服务等级目标
Azure 各服务的 SLA 与内建复制能力差异很大，映射时要同时看三件事：服务的可用性 SLA、数据复制机制、以及跨区域恢复能力。以下为常见映射示例：
- RTO ≤ 15 分钟、RPO ≤ 1 分钟：Azure SQL Database 业务关键层 + 自动故障转移组，配合 Azure Site Recovery 或主动-主动部署；
- RTO ≤ 1 小时、RPO ≤ 15 分钟：Azure SQL Database 标准层异地复制（Geo-Replication），App Service 多区域部署 + Azure Front Door 流量切换；
- RTO ≤ 8 小时、RPO ≤ 4 小时：Azure Backup 定期备份 + 按需恢复，App Service 单区域但启用区域冗余；
- RTO ≤ 24 小时：仅依赖 Azure Backup 与基础设施即代码（IaC）重建。
映射过程中有一个关键约束：Azure 的 SLA 是承诺值，不是保证值。例如某服务 SLA 为 99.95%，意味着每月约 22 分钟不可用，若业务 RTO 要求 15 分钟，单靠该服务就不足以达标，必须叠加多区域或主动-主动架构。因此映射的实质是"用架构冗余去覆盖 SLA 缺口"。
五、BIA 到 Azure 目标的完整映射链路
下图展示从业务功能出发，经依赖识别、影响分级，最终落到 Azure 服务与架构选择的完整链路。图中同时标出了强依赖与弱依赖的分叉，以及 RTO/RPO 目标如何反向约束架构层级。
六、常见误区与落地建议
第一，把 RTO 当成"技术恢复时间"。RTO 是从业务中断开始到业务恢复可用的总时长，包含故障发现、决策、切换、验证等环节，技术切换往往只占其中一部分。若只优化切换速度而忽略决策流程，实际 RTO 仍会超标。
第二，所有系统用同一个 RTO。这会导致成本失控。正确做法是按影响等级分层，一级系统用主动-主动或故障转移组，三级系统用备份恢复即可。
第三，忽略外部依赖。第三方支付网关、DNS、证书颁发机构都不在 Azure SLA 覆盖范围内，BIA 中应单独标注并准备降级方案，例如支付失败时切换备用通道或进入排队重试。
落地时建议把 BIA 结果整理成一份可维护的映射表，字段至少包含：业务功能、影响等级、强/弱依赖清单、RTO、RPO、对应 Azure 服务与架构、验证方式、责任人。这份表既是灾备设计的输入，也是后续演练与审计的依据。当业务发生变化时，只需更新表中对应行，即可重新推导架构是否需要调整。