BCP (业务连续性计划)

什么是 BCP（业务连续性计划）

BCP（Business Continuity Plan / 业务连续性计划）是在自然灾害、网络攻击、疫情等紧急情况发生时，最大限度减少业务中断，持续或快速恢复重要业务的计划。

BCP 的本质不是「保护一切」，而是在有限资源下事先决定「优先保护什么」。通过业务影响分析 (BIA: Business Impact Analysis) 识别重要业务，并为每项业务设定目标恢复时间 (RTO) 和目标恢复时点 (RPO)。随着勒索软件攻击导致系统全面停机等 IT 故障威胁业务连续性的案例增加，IT-BCP 的重要性逐年提高。

IT-BCP 的恢复策略与设计

在 IT-BCP 中，为每个系统定义 RTO 和 RPO，并据此选择恢复策略。

• 热备 (Hot Standby)：始终运行与生产环境同等的系统，故障时立即切换。RTO 在数分钟以内，但成本最高
• 温备 (Warm Standby)：以缩减配置的系统待命，故障时扩容并切换。RTO 为数十分钟到数小时
• 冷备 (Cold Standby)：仅保留备份数据，故障时从零构建系统。RTO 为数天，但成本最低

在云环境中，可以通过多区域或多可用区配置确保可用性。遵循 3-2-1 备份规则，将备份数据地理分散是基本做法。请将从备份恢复的步骤文档化，并定期进行恢复测试以验证有效性。

BCP 的制定步骤

要制定有效的 BCP，请按以下步骤依次推进。

1. 业务影响分析 (BIA)：盘点所有业务，评估停止时的财务和社会影响。为每项业务定义最大可容忍停机时间
2. 风险评估：评估地震、洪水、网络攻击、疫情等预期威胁的发生概率和影响程度
3. 恢复策略制定：为每项重要业务设定 RTO 和 RPO，在成本平衡中选择恢复方式
4. 计划文档编制：将启动标准、指挥体系、联络网、恢复步骤、备用场所确保方法文档化
5. 演练与审查：定期开展桌面推演和实地演练，验证计划的有效性

将与 CSIRT 和事件响应团队的协调步骤纳入 BCP，确保也能应对网络攻击场景。

防止 BCP 流于形式

BCP 不是制定完就结束，持续改进不可或缺。许多组织的 BCP 流于形式的原因是演练不足和更新停滞。

• 每年至少一次演练：桌面推演每半年一次，实地演练每年一次为目标。演练中发现的问题在 30 天内反映到计划中
• 组织变更时更新：人事调动、系统更新、场所变更时及时更新 BCP。联络网的陈旧化是最常见的形式化模式
• 从实际事件中学习：将实际发生的故障和事件的应对结果反馈到 BCP

将 BCP 文档保存在云存储中，同时准备打印版以便在离线环境下也能访问，这是实务上的要点。

BCP 的制定步骤与演练

制定有效的 BCP 需要按照系统化的步骤推进。临时拼凑的计划在实际紧急情况下无法发挥作用。

实施业务影响分析 (BIA)：BIA 是 BCP 制定的起点。盘点所有业务流程，从「财务损失」「客户影响」「法律风险」「声誉影响」4 个维度定量评估每个流程停止时的影响。通过此分析，明确在有限资源下应优先保护的业务。省略 BIA 而制定「保护一切」的计划，最终会变成哪项业务都无法充分保护的半吊子计划。

设定 RTO 和 RPO：基于 BIA 结果，为每项业务设定 RTO（目标恢复时间）和 RPO（目标恢复时点）。例如，电商订单系统 RTO 1 小时、RPO 5 分钟，内部报销系统 RTO 72 小时、RPO 24 小时，根据业务重要度进行区分。由于 RTO 和 RPO 与成本存在权衡关系，请获得管理层批准后决定。

桌面推演 (Tabletop Exercise)：相关人员聚集在会议室，针对特定场景（例如：勒索软件导致核心系统全面停机）口头模拟 BCP 的步骤。由于不需要实际停止系统，可以低成本频繁实施。演练中发现的典型问题包括联系方式过时、步骤模糊、负责人不在时的代理人未定义等。

年度审查周期：BCP 至少每年进行一次定期审查。审查中反映组织变更、系统更新、新威胁的出现，进行 BIA 的重新评估和 RTO/RPO 的妥当性验证。与 CSIRT 协作，将过去一年事件响应的教训反映到 BCP 中，持续提升计划的有效性。

常见误解

BCP 只有大企业才需要

中小企业更需要 BCP。与大企业相比经营体力有限，数天的业务停止可能直接导致倒闭。即使是适合规模的简易版 BCP，制定后恢复速度也会大不相同。

有了数据备份就不需要 BCP

备份只是 BCP 的一个要素。即使有备份，如果恢复步骤未整备、恢复环境不存在、负责人不在，也无法恢复。BCP 是全面覆盖人员、流程和技术的计划。

相关术语