2. 业务影响分析与关键业务识别
业务影响分析（Business Impact Analysis，BIA）是业务连续性管理体系的起点，也是后续恢复策略、资源投入和演练设计的依据。它的核心任务不是“把所有系统列一遍”，而是回答三个问题：哪些业务功能一旦中断会真正造成不可接受的后果？这些后果随时间如何恶化？支撑它们的关键资源、依赖关系和恢复目标是什么？只有把这三件事说清楚，RTO、RPO、MTD 才有设定依据，关键业务分级才有客观标准。
一、BIA 的输入、方法与输出
BIA 的输入通常包括：业务流程清单与责任部门、财务与运营数据、合同与监管要求、历史中断事件记录、IT 资产与配置管理数据。方法上建议采用“自上而下分解 + 自下而上验证”的双向路径：先由业务部门识别业务功能，再向下拆解到支撑它的流程、人员、系统、数据、供应商和设施；随后由技术团队反向确认这些资源是否真实存在、是否有单点、是否已有冗余。
分析过程一般按以下顺序推进：
- 识别业务功能：以“对外交付的价值”为单位，而不是以部门或系统为单位。例如“在线支付受理”“订单履约”“客服工单处理”“工资发放”。
- 确定影响维度与量化口径：常见维度包括财务损失、客户流失、监管处罚、安全与合规、声誉、员工无法作业等。每个维度要给出可比较的口径，例如“每小时损失金额”“受影响客户数”“监管上报时限”。
- 建立影响时间曲线：对每个业务功能，分别评估中断 1 小时、4 小时、8 小时、24 小时、72 小时后的影响等级，形成随时间递增的影响曲线。
- 推导 MTD：影响达到“不可接受”阈值的时间点即为最大可容忍中断时间（MTD）。
- 设定 RTO 与 RPO：RTO 必须小于 MTD，并预留检测、决策、切换和验证的时间；RPO 由数据可丢失容忍度决定，通常与数据产生频率和业务对账周期相关。
- 映射依赖关系：把业务功能与支撑资源建立多对多关系，识别共享依赖和单点故障。
- 分级与评审：按影响和 MTD 对业务功能分级，由业务负责人签字确认，并定期复核。
输出物通常包括：业务功能清单与分级表、影响时间曲线、RTO/RPO/MTD 目标表、依赖关系矩阵、关键资源清单以及 BIA 报告。这些输出直接决定后续恢复优先级和资源投入。
二、关键业务功能分级
分级不能只看“系统重要不重要”，而应综合影响严重度与时间敏感性。一个实用的分级方法是：先按 MTD 划分时间紧迫度，再按影响维度划分后果严重度，最后形成分级矩阵。例如：
| 级别 | MTD 参考 | 影响特征 | 典型示例 |
|---|---|---|---|
| 一级（关键） | ≤ 4 小时 | 直接造成重大财务损失、监管违规或大面积客户不可用 | 在线支付、核心交易、身份认证 |
| 二级（重要） | ≤ 24 小时 | 显著影响运营效率或客户体验，可短期人工兜底 | 订单查询、客服工单、报表推送 |
| 三级（一般） | ≤ 72 小时 | 影响有限，可延后恢复 | 内部知识库、非实时分析 |
| 四级（低） | > 72 小时 | 可暂停或降级运行 | 测试环境、历史归档查询 |
分级结果必须与业务负责人确认，并明确“降级运行”的边界。例如一级业务在 RTO 内无法完全恢复时，是否允许只恢复查询、暂停写入，或只服务部分客户，这些都要在 BIA 阶段写清楚，否则恢复时会陷入无依据的临时决策。
三、RTO、RPO 与 MTD 的定义与设定
三个指标常被混用，必须严格区分：
- MTD（Maximum Tolerable Downtime）：业务中断后，影响达到不可接受程度的最长时间。它是业务容忍上限，由业务方定义。
- RTO（Recovery Time Objective）：从故障发生到业务功能恢复到可接受水平的目标时间。RTO 必须小于 MTD，差额用于检测、决策、切换和验证。
- RPO（Recovery Point Objective）：允许丢失的数据时间窗口，即恢复后数据最多回退到多久之前。RPO 决定备份频率、复制方式和日志保留策略。
设定时建议遵循“业务定目标、技术定能力、差距定投入”的顺序。例如某在线支付业务，业务方确认中断 2 小时后开始出现客户投诉和监管关注，4 小时后影响不可接受，则 MTD 可定为 4 小时；考虑检测与切换约需 30 分钟，RTO 可设为 2 小时；交易数据要求可对账、不可重复扣款，RPO 设为 5 分钟。技术侧再评估现有备份与复制能力是否满足，若不满足则形成改进项。
四、依赖关系映射
依赖关系映射是把业务功能与支撑资源连接起来的关键步骤。建议至少覆盖以下层次：业务功能 → 业务流程 → 应用系统 → 数据与接口 → 基础设施（计算、存储、网络）→ 人员与供应商 → 设施与外部服务。映射时重点关注三类风险：共享依赖（多个关键业务依赖同一数据库或同一网络出口）、单点故障（无冗余的组件）和隐性依赖（未登记但实际被调用的接口、脚本、证书、DNS）。
下图展示了一个简化的依赖关系与恢复目标映射示例，用于说明业务功能、支撑资源、RTO/RPO 与 MTD 之间的对应关系。
映射完成后，应形成一份可维护的依赖矩阵，并至少每半年或在重大架构变更后复核一次。对于识别出的共享依赖和单点，要明确是接受、规避、转移还是降低，并落实到具体的恢复策略中。例如上图中的第三方支付通道属于外部单点，可考虑接入备用通道、设置交易排队与补偿机制，并在 RTO 内验证切换流程。
五、从 BIA 到恢复策略的衔接
BIA 的最终价值在于驱动恢复策略。分级为一级的业务功能，其 RTO 和 RPO 应优先获得资源保障，通常对应双活、热备或快速切换方案；二级可采用温备或人工降级；三级、四级可采用备份恢复或延后处理。同时，BIA 结果应直接输入到应急预案、演练场景和供应商管理要求中，例如要求关键供应商提供同等水平的 RTO 承诺和切换证明。
综上，BIA 不是一次性文档，而是一个持续校准的过程。通过明确业务功能、量化影响曲线、设定 MTD/RTO/RPO 并映射依赖关系，组织才能把有限的恢复资源投入到真正关键的业务上，并为后续的连续性策略、演练和治理提供可验证的依据。