2. 风险评估与业务影响分析：识别关键业务功能、评估中断影响、确定恢复优先级
好，咱们进入正题。
风险评估和业务影响分析，说白了就是回答三个问题：什么东西不能停？停了会怎样？先救哪个？
我见过不少团队，一上来就买设备、搭灾备，结果发现最核心的业务根本没覆盖到。嗯，这就是典型的「方向错了，跑得再快也没用」。
2.1 识别关键业务功能
这一步是地基。地基歪了，后面全白搭。
我个人习惯，先拉一个业务功能清单。别怕多，把能想到的都列出来。比如电子交易系统，可能有：
- 用户登录与认证
- 行情数据推送
- 订单接收与校验
- 撮合引擎
- 资金结算
- 风控检查
- 历史查询
- 报表生成
然后，咱们得给这些功能打个分。怎么打？我建议从两个维度看：业务价值和中断容忍度。
| 业务功能 | 业务价值（高/中/低） | 中断容忍度（分钟/小时/天） |
|---|---|---|
| 撮合引擎 | 高 | 分钟级 |
| 行情推送 | 高 | 秒级 |
| 资金结算 | 高 | 小时级 |
| 历史查询 | 中 | 天级 |
| 报表生成 | 低 | 天级 |
你看，撮合引擎和行情推送，中断几分钟就可能引发连锁反应。但报表生成晚一天，其实问题不大。
2.2 评估中断影响
关键功能找出来了，接下来算算「如果它挂了，会怎样」。
评估影响，我一般从四个角度切入：
- 财务损失：直接的经济损失，比如交易手续费、罚款、赔偿。
- 监管合规：会不会违反监管要求？比如证监会要求交易数据必须实时报送。
- 客户体验：用户会不会流失？口碑会不会崩？
- 品牌声誉：这个比较虚，但往往最致命。一次重大事故，可能几年都缓不过来。
举个例子。撮合引擎中断30分钟，财务损失可能是几百万的手续费，监管那边可能要吃罚单，客户会疯狂投诉，媒体一报道，品牌形象直接受损。
你想想看，这些影响不是孤立的。它们会叠加，会放大。所以评估的时候，别只算经济账。
2.3 确定恢复优先级
好，现在我们知道哪些功能重要，也知道它们中断后影响多大。下一步就是排个先后顺序。
恢复优先级，说白了就是「先救谁，后救谁」。我习惯用RTO（恢复时间目标）和RPO（恢复点目标）来量化。
- RTO：从故障发生到业务恢复，最多能等多久？
- RPO：能容忍丢失多少数据？比如丢1秒的数据，还是丢1分钟的数据？
咱们还是拿电子交易系统举例：
| 业务功能 | RTO | RPO | 恢复优先级 |
|---|---|---|---|
| 撮合引擎 | 5分钟 | 0（零丢失） | P0（最高） |
| 行情推送 | 1分钟 | 1秒 | P0 |
| 资金结算 | 1小时 | 5分钟 | P1 |
| 历史查询 | 4小时 | 1小时 | P2 |
| 报表生成 | 24小时 | 1天 | P3 |
你看，P0级别的功能，RTO和RPO都非常苛刻。这意味着，你的灾备方案必须为它们「开小灶」。比如撮合引擎，可能需要做同城双活，甚至异地多活。而报表生成，做个简单的冷备就够了。
嗯，这里要注意一点。优先级不是一成不变的。业务在发展，监管在变化，技术也在更新。我建议每半年重新评估一次。我在项目中遇到过，一个原本P2的功能，因为监管新规，突然变成了P0。如果还按老方案走，那就等着挨罚吧。
2.4 知识体系总览
说了这么多，咱们用一张图把核心逻辑串起来。这样你脑子里会有一个清晰的框架。
这张图把咱们刚才讲的三步串起来了。从左到右，先识别，再评估，最后定优先级。然后根据优先级，去分配资源、设计恢复方案。别忘了底部的循环箭头——定期复盘，动态调整。
好，这一章的内容就到这儿。记住，风险评估和业务影响分析不是一次性的工作。它应该像体检一样，定期做，持续做。只有这样，你的业务连续性计划才能真正落地，而不是停留在PPT里。