第2章 业务连续性管理框架：BCM、ITSCM与DR的关系
很多人刚接触这个领域的时候，容易把BCM、ITSCM和DR混为一谈。说白了，这三个东西层次不同，但又是上下级关系。我在很多项目里都看到过这种混乱——业务部门觉得IT能搞定一切，IT部门又觉得只要把数据备份了就算完事。结果一演练，发现根本不是那么回事。
咱们先搞清楚这三者的定义，然后你自然就明白它们之间的协作关系了。
2.1 概念速览
业务连续性管理（BCM），是站在企业最高层的视角。它不关心你用什么技术，只关心一件事：业务能不能持续运转。BCM的产出是一套业务连续性计划（BCP），里面定义了核心业务流程、关键恢复目标，以及危机时刻的管理决策机制。
IT服务连续性管理（ITSCM），就落地了一层。它是IT部门用来支撑BCM的手段。ITSCM的核心是保证IT服务在灾难发生后能按约定的水平恢复。它的产出包括IT服务连续性计划和IT恢复手册。
灾难恢复（DR），是最底层、最技术化的那个。它专门处理IT基础设施和应用的恢复——机房断电了怎么办？数据库坏了怎么切？DR的产出就是咱们常说的灾难恢复计划（DRP），里面写得清清楚楚：谁按哪个按钮，在什么时间点做什么事。
关键区分
- BCM 管业务，面向 CEO / 董事会。
- ITSCM 管 IT 服务，面向 CIO / IT 总监。
- DR 管基础设施，面向运维工程师 / DBA。
2.2 它们怎么协作？
我拿一个实际场景给你讲。假设你是一家电商公司的运维负责人。突然某一天，核心机房因为市政施工挖断了光缆。
第一步：BCM 层面
业务连续性委员会马上介入。判断：当前“下单”流程受影响了吗？影响程度多大？CEO 拍板，启动 BCP 中的“严重事件响应流程”。决策是：优先保障支付和订单系统恢复，营销推广活动先停掉。
第二步：ITSCM 层面
IT 服务经理拿到决策指令，核对 ITSCM 计划：支付系统的 RTO 是 2 小时，RPO 是 5 分钟。确认当前灾备环境正常，向运维团队下达切换指令。
第三步：DR 层面
运维团队直接照着 DRP 操作：停止主中心服务，启动备中心数据库，验证数据一致性，切换 DNS 流量。所有操作有明确的步骤和检查点。
你发现没有？没有 BCM 的决策，IT 服务经理不知道该切哪个系统；没有 ITSCM 的目标定义，运维团队不知道要恢复到什么程度；没有 DRP 的具体操作，一切都停留在纸面上。这三个层次是层层支撑、缺一不可的。
2.3 各层面的核心要素
为了让你快速抓住重点，我把每个管理域的核心要素整理成了一张表。你在实际编写计划的时候，可以对照这张表检查自己有没有遗漏。
| 管理域 | 核心目标 | 主要输出 | 关键指标 | 审查频率 |
|---|---|---|---|---|
| BCM | 保障核心业务持续运营 | BCP、危机沟通计划 | 业务RTO、业务RPO | 年度评审 + 季度更新 |
| ITSCM | 保障关键IT服务恢复 | IT连续性计划、服务目录 | 服务RTO、服务RPO | 年度评审 + 重大变更后更新 |
| DR | 保障基础设施与应用恢复 | DRP、运行手册、配置数据 | 系统RTO、系统RPO | 每次演练后更新 + 季度评审 |
我的个人习惯：不要试图用一个计划覆盖所有层面。我见过最糟糕的做法是把BCP写得跟运维操作手册一样厚，结果根本没法用。BCP应该薄，责任明确、决策流程清晰就够了；DRP必须厚，每一步都写清楚，才算合格。
2.4 避坑指南
我不止一次看到组织栽在同一个坑里，这里总结几个高频雷区：
- BCM 和 DR 脱节——业务要求 4 小时恢复，IT 的 DRP 是按 8 小时设计的。这就是典型的各干各的，最后演练时业务部门才发现系统切是切回来了，但根本达不到业务要求。
- ITSCM 成了摆设——ITSCM 计划写得很漂亮，但没人维护。服务目录半年不更新，新增的系统根本不在计划里。我曾经被临时拉去救火，发现一个核心支付系统竟然没纳入 ITSCM 范围，只因为上线时忘了通知负责 BCM 的同事。
- 忽略基础设施依赖——你以为把应用切到备中心就完事了？网络策略、防火墙规则、DNS 解析、甚至空调和电力，哪个没准备都可能导致恢复失败。
- 演练只走形式——每年一次桌面推演，大家会议室里聊聊就结束了。真正的故障可不会按剧本走。建议做实战演练，关掉半个机房，看团队能不能在规定时间内恢复。
2.5 知识体系关系图
下面这张图把三个层面的层级关系和关键产出示意出来了。你可以用它来向团队解释整体架构，也可以贴在项目看板上随时参考。
特别注意：很多组织把BCM、ITSCM和DR写进同一份文档里，我建议你尽量不要这么做。原因很简单——它们的目标受众不一样，更新频率也不一样。分卷管理，各卷独立更新，看起来更专业，用起来也更顺手。我曾经见过一个项目，为了“整合”把三个计划揉在一起，结果业务部门找不到决策流程，运维部门翻不到操作步骤，真出事的时候谁都不满意。
2.6 整合的实践要点
明白了理论框架，咱们看看怎么落地。在实际工作中，你要组织好三者之间的这个协作关系：
- 建立翻译机制——业务部门说的“4小时恢复订单系统”，翻译成IT语言就是：应用集群RTO 2小时，数据库RTO 3小时，网络切换30分钟。再由DRP细化为：第1步启备用Web节点（30min），第2步切数据库主备（120min），第3步验证数据一致性（30min），第4步切换DNS（30min）。
- 统一演练节奏——每年至少一次全员参与的实战演练。不光是IT部门关起门来练，业务、法务、公关都要参与。我经历过最有效的演练是“盲测”——提前不告诉任何人，模拟真实故障发生，看大家反应。
- 建立反馈回路——演练或真实故障后的复盘，一定要从DR层反馈到ITSCM层，再反馈到BCM层。DR发现某个系统恢复时间超标，很可能意味着ITSCM定的RTO不合理，或者BCM的优先级判断需要调整。
一个小工具推荐：我习惯用一个简单的二维矩阵表格来映射业务系统、IT服务与基础设施的关系。纵轴是业务功能（如：订单处理），横轴是依赖的IT服务和基础设施（如：支付网关、数据库集群、网络带宽）。这样一张表的价值，真出事的时候你就知道了——能帮你快速定位该恢复哪些东西，哪些可以放一放。
好了，这一章的核心就是搞懂BCM、ITSCM和DR这三个层次的定位与协作。记住一句话：战略层定方向，战术层定目标，执行层定操作。三层对齐了，灾难恢复才真的可靠。