3. 风险评估与业务影响分析：识别关键业务与影响等级

说实话，很多人一听到「灾难恢复」，第一反应就是买硬件、搭机房、做备份。这其实是个误区。

你想想看，如果连哪些业务最重要、能停多久、损失多少都说不清楚，那后面的技术方案就是空中楼阁。我早年吃过这个亏——花了三个月搭好的异地容灾，结果董事长问「备用系统能保哪些业务」时，我一句话答不上来。嗯，从那以后，每一份 DR 方案我都是从风险评估和业务影响分析开始的。

3.1 先搞清楚：谁才是关键业务？

要做风险评估，第一步是回答这个问题：哪些业务不能断？

你不可能给所有系统都配同等级别的保护。成本不允许，技术上也犯不着。说白了，你得有个优先级的排序。

我个人习惯把关键业务分三个等级：

• 关键级（Critical）：中断 15 分钟以上就造成重大财务损失或合规风险，比如交易系统、支付网关。
• 重要级（Important）：可容忍停机 4 小时，但超过 8 小时会影响客户信任和运营效率，比如订单管理、客户服务。
• 一般级（Normal）：停机 24–48 小时也可以接受，比如内部 OA、报表系统。

这里有个坑——不要只看系统本身。我在项目中遇到过很多次争论，运维说「这个备份系统很重要」，业务部门说「这不过是个日志平台」。怎么判断？我建议拉着业务负责人，一个一个系统过，问三个问题：

• 这个系统停掉，一小时的收入损失是多少？
• 有没有合规要求限制停机时间？（比如 GDPR、PCI-DSS）
• 停掉之后，下游系统会不会跟着瘫痪？

3.2 业务影响分析：量化才能管理

风险分级是定性的，但灾难恢复需要定量指标。这里有两个你绕不开的概念：RTO 和 RPO。

RTO（恢复时间目标），就是你系统挂了，能停多久。RPO（恢复点目标），就是你能接受丢多少数据。

举个例子：假设支付系统的 RTO 是 15 分钟，RPO 是 0。这代表系统一旦宕机，你必须在 15 分钟内恢复上线，而且数据不能丢。你想想看，这得靠同步复制、热备、甚至多活架构才能做到。

反过来，OA 系统的 RTO 可以放宽到 24 小时，RPO 可以接受丢失一天的数据。那冷备 + 每日快照就足够了。

3.3 风险评估：不只是看概率

识别完关键业务，下一步是评估它们面临的风险。我常用的方法是做个简单的风险矩阵：横轴是发生概率，纵轴是影响程度。

• 高概率 + 高影响（比如机房电力不稳导致核心数据库宕机）：必须优先防护，上双路供电 + 异地容灾。
• 高概率 + 低影响（比如某个内部工具频繁重启）：可以自动化恢复，不投入冗余资源。
• 低概率 + 高影响（比如地震、火灾）：需要预案和定期演练，不能因为概率低就不管。
• 低概率 + 低影响：接受风险，不投入额外成本。

我曾经帮一家金融客户做评估，发现他们的风险矩阵上「核心数据库」被标为低概率高影响。但后来一查，那个机房的 UPS 已经三年没测试了，电池组早就失效了。所以你看，概率这个东西，要根据实际环境修正。别只看基准数据。

3.4 输出物：你真正需要拿到的文档

整个分析阶段做完，最终输出应该是三份东西：

1. 关键业务清单：按优先级排序，附带对应的 RTO/RPO。
2. 风险登记册：列出每个系统面临的主要风险、概率等级、影响等级、当前控制措施。
3. 恢复策略建议：对不同等级的系统给出初步的技术恢复路径（比如热备、温备、冷备、云端灾备）。

我自己在项目中习惯把这些文档放在一个 Git 仓库里，每次变更都留记录。不仅方便审计，也能追踪每次风险评估的改动。

3.5 一张图看懂本章核心逻辑

下面这张图展示了从「识别关键业务」到「确定恢复策略」的完整流程。你可以把它当作 DR 规划的起点。

这张图就是整个风险评估和业务影响分析的骨架。你做完这一步，后面所有的灾备设计、技术选型、演练计划都有了依据。相信我，把这一步走扎实，后续会顺利得多。