一、三个词的关系：BCM、BCP、BIA

这三个缩写经常被混用，但它们的层次完全不同：

理解它们的关系，关键是顺序：BIA 在最前面——不知道哪个业务最要紧、停多久会出事，就写不出有意义的 BCP。而在 BIA 之前，还要先划定范围与语境（哪些业务纳入范围、可接受的中断水平是多少）。顺序颠倒过来（先写计划再想【为什么要恢复这个系统】）的结果是，计划里塞满了技术步骤，却回答不了【为什么先恢复这个而不是那个】。

国际标准是 ISO 22301（业务连续性管理体系）。认证审核分三个阶段：阶段一查文档（体系有没有建起来）、阶段二查实施有效性（是不是真的在运行），此后每年监督审核、三年复评。

这里有一个常被忽略的点：BCM 认证的第一阶段和第二阶段差别很大。阶段一基本是【看文件】，阶段二要看的是运行证据——演练记录、评审记录、更新记录。很多组织能过阶段一，卡在阶段二，原因几乎都是同一件事：文件写得很完整，但没有真的演练过。

二、BIA 的三件产出

BIA 做完，至少要产出三样东西：

• 优先活动清单——停多久会出事的业务，按先后排序；
• RTO（恢复时间目标）——允许中断多久，例如 4 小时；
• RPO（恢复点目标）——允许丢多少数据，例如 15 分钟。

这三件东西里，【清单】最容易被做错。做错的典型方式是按【系统重要性】排，而不是按【业务影响】排。比如：把核心数据库排在第一位——但真正的问题是【哪些业务活动不能停】，数据库只是支撑它的手段之一。按业务活动排序的好处是，它会逼你回答一个更难但更有用的问题：这个活动停了，谁受影响、损失量级多大、有没有临时替代办法（手工流程、电话受理、外部备份供应商）。

RTO 和 RPO 是两个容易被混在一起的指标，区分方法很简单：RTO 管【停多久】（时间长度），RPO 管【丢多少】（数据量）。它们对应的技术手段也不同：RTO 靠冗余与切换速度（6-16），RPO 靠备份频率与复制方式。

三、停机损失与恢复目标：一张能给决策者看的表

把业务活动、每小时损失、当前 RTO、要求 RTO 放在一张表里，结论会立刻显现出来：

这张表的用法和直觉刚好相反：它不是让你去补所有差距最大的项，而是让你补【差距 × 单位损失】最大的项。看第五行：内部 OA 的差距是 0，因为它本来就不重要——要求 RTO 96 小时本身就是这个意思。 而第一行【在线收款】虽然只差 2 小时，但它每小时损失 20 万——这 2 小时的差距，价值远超第四行那 24 小时的差距。

这就是为什么 BIA 必须在技术方案之前做：如果先做技术方案，通常会从【哪个系统最容易修】开始；从 BIA 出发，才会从【哪个业务最贵】开始。

四、动手 Demo：算一笔账，看治理值不值

把风险换算成钱，是推动连续性投入最有效的方式：

over, loss_h = 6, 200000        # 过去一年累计超时 6 小时，每小时损失 20 万
exposed = over * loss_h         # 年暴露金额 1,200,000 元
invest = 900000                 # 达标改造预算
after = 1 * loss_h              # 改造后按超时 1 小时估
save = exposed - after          # 每年省下 1,000,000 元
payback = invest / save         # 静态回收期 0.90 年

实跑输出：

四、算一笔账：不达标花多少，治理要花多少
  假设在线收款当前 RTO 4 小时、目标 2 小时，
  过去一年因中断与切换失败，累计超时 6 小时。
  超时小时数            6 小时
  每小时损失            200,000 元
  年暴露金额            1,200,000 元
  达标改造预算          900,000 元
  改造后年暴露          200,000 元，按超时 1 小时估
  每年省下              1,000,000 元
  静态回收期            0.90 年
  → 结论：约 0.9 年回本，这个投入说得通。
     如果算出来是三十年、五十年，那就该重新讨论目标值，
     而不是硬上一套用不上的架构。

读这个输出：

• 0.9 年回本，这是一个很容易通过的提案。关键在【每小时损失】这个参数。它在不同业务之间差别可以到两个数量级（交易类系统每小时可能几十万，内部办公系统每小时可能只有几千）——所以这个参数必须由业务方提供，不能由 IT 拍。如果 IT 自己估，通常会用【人均工资】去算，结果严重低估。
• 最后那句话是本段最重要的提醒：如果算出来的回收期是三十年、五十年，那结论不是【这个投入不值】，而是【你定的 RTO 目标可能与业务损失不相称】。正确的动作是回去重新讨论目标值——因为 RTO 越短，成本越接近指数上升（从 4 小时压到 2 小时，和从 1 小时压到 30 分钟，代价完全不同）。这也是 6-16 里【2N 常常算不过账】的同一个逻辑。

五、审计最常见的三个缺口

这三个缺口几乎可以在每一份连续性审计报告里看到：

• 演练——计划写了但从未测过，或桌面推演只确认了【看起来合理】；
• 更新——BIA 做完之后再没随组织变化更新过；
• 资源——计划只说【恢复什么】，没说【用谁的资源、找谁、谁有权拍板】。

第一个缺口占的比重最大，原因很现实：演练会占用业务部门的时间，而收益是【没有发生的事】——所以在资源紧张时，它总是第一个被推迟的。 但要理解一件事：演练的主要目的不是【验证技术方案能不能用】（那个靠技术灾备测试就能做到），而是暴露组织层面的问题——比如：凌晨两点谁能授权启用备用站点？供应商的紧急联系方式是不是已经失效？恢复手册里提到的那个工具，现在的版本还能不能跑？ 这些问题只有真练才会浮出来，而且几乎每次都会浮出来几个。

六、⚠️ 2026 现状

• 【周期与成本】。 小型组织典型是 8 到 16 周，中型 3 到 5 个月，大型 5 到 9 个月以上（也有按【小型 3~6 个月、中型 6~9 个月、大型 9~18 个月】的口径，差别在于是否包含认证阶段）。编排时间时要留出两个大头：① BIA 需要业务部门配合（这通常是排期里最不可控的部分）；② 演练需要安排窗口。把这两件事排进年度计划，比把它排进项目计划更现实。
• 【BIA 最常颠覆假设】。 实践中最常见的发现是：看起来关键的 IT 系统其实是次要的，看起来平常的手工流程或供应商关系才是真正的约束。举两个真实出现的例子：① 某业务看似依赖核心系统，实际上停服后靠电话与纸质单据还能维持几天（这意味着它的真实 RTO 可以放宽）；② 某业务看似简单，但它依赖一个只有两名员工的供应商提供的数据接口，而这个供应商没有灾备（这意味着真正的瓶颈在供应商，而不是在你自己的系统里）。所以 BIA 一定要问到【这条业务链条上还依赖谁】。
• 【演练有六种形式，别只做桌面推演】。 桌面推演（口头讨论）、走查（按步骤逐条核对）、模拟演练（不切换真实的系统）、技术灾备测试（真的切换）、全规模演练（真实切换并让业务参与）、以及把演练结果回写进计划的复盘。 一个务实的组合是：桌面推演每季度、技术灾备测试每半年到每年、全规模演练每年一次。关键是最后一环：演练结束必须有【计划修订】的产出——如果连续几次演练的结论都是【计划没问题】，那大概率是演练设计得太简单了。
• 【常见错误清单】。 把连续性规划当成 IT 一家的事；定不切实际的恢复目标；计划不做测试；与供应商和第三方脱节；员工缺乏认知培训。 这五条里，第一条是根源：一旦规划由 IT 独立完成，业务方就变成了【被告知的对象】，BIA 里的【每小时损失】只能由 IT 猜，供应商依赖不会被提及，演练时业务方也不会配合——后面四条几乎都是第一条的衍生。

30 秒实验

今天做两个动作，各 15 秒：

1. 问自己一个问题：如果明天早上公司办公楼不能进，你所在的工作能在多久之后恢复？靠什么恢复？ 如果答案是【没想过】或【应该很快吧】，那说明 BCP 目前只存在于假设中——注意这个场景甚至不需要天灾，一次消防检查、一次区域停电、一次封路就能造成。
2. 列一下你所在业务链条上【只有一家、且没有备用】的依赖。可以是某个供应商、某条专线、某个人。这一类单点依赖，通常比【服务器会不会坏】更值得先处理——因为服务器的冗余已经被讲了很多年，而供应商层面的单点往往没人管。

这一节要带走的一句是：连续性管理与安全防护有一个根本差别——攻击可以靠防住概率来降低风险，天灾只能靠准备来缩短影响；所以这一节的所有动作，重心都在【事后多久能回来】，而不是【能不能拦住】。

常见误区

1. 错误：BCP 就是 IT 的灾备方案，做好数据备份就够了。——纠正：数据备份只是 BCP 里的一小块，而且是最技术的那一块。BCP 要覆盖的是整条业务链：人（谁来判断、谁来决策、谁在什么情况下可以启用备用方案）、流程（手工替代方案是什么）、场地（备用办公点在哪）、外部依赖（供应商、物流、支付通道）、以及沟通（怎么通知员工、客户、监管）。 判断一份 BCP 是否只做了 IT 部分，有个简单的检验方法：看它有没有【没有系统时怎么办】的内容——比如【系统不可用期间，订单用纸质单据受理，事后 24 小时内补录】。如果通篇都是系统切换步骤、没有手工替代方案，那它实际上只是一份灾备方案，不是连续性计划。 顺带说一下为什么手工替代方案重要：它直接决定了你的 RTO 能不能放宽——有可行的手工替代时，【4 小时恢复】就不是必须的，成本可以大幅下降。

2. 错误：BIA 是一次性工作，做完就不用管了。——纠正：BIA 是三个数字（优先活动、RTO、RPO）的来源，而这三个数字都会随业务变化。举个具体例子：去年【客服热线】的要求 RTO 是 8 小时，今年因为上了在线客服、客服热线变成了主要受理渠道之一，它的要求 RTO 可能就要压到 4 小时——如果 BIA 没更新，你的连续性投入方向就是错的（投在了已经不那么重要的地方）。 另一个常见变化源是【依赖关系变了】：某项业务原来人工处理，现在完全依赖某个系统，那么它的容错能力其实是下降的。 务实做法是把 BIA 复核挂到两个触发条件上：① 年度管理评审（6-2 里的 Check 动作）；② 重大变更（新系统上线、渠道调整、合并分立、主要供应商变更）。

3. 错误：桌面推演就行，真实切换风险太大。——纠正：两者解决的不是同一类问题，而且桌面推演有一个结构性盲区。桌面推演测的是【计划在逻辑上通不通】——它的参与者在会议室里看着文档回答【如果这样，你会怎么做】，这个过程很快、成本很低，但对【操作细节是否失效】完全无感（因为没有人去真的执行那条命令、真的去联系那个供应商）。技术灾备测试测的是【技术方案真的能切吗】；全规模演练测的是【业务能不能在切换后的系统上真的干活】。实务上的折中是：桌面推演保持高频（每季度），技术灾备测试做到半年到一年一次，全规模演练一年一次、可以只针对最关键的 1~2 条业务。 另外要接受一个前提：演练一定会暴露问题，而且偶尔会造成轻微的生产影响——这是它的成本，也是它的价值；如果一场演练什么也没暴露、也没有任何风险，那它大概率只是在走过场。

4. 错误：演练报告写完就归档，下次演练再重新开始。——纠正：演练最重要的产出是【计划修订】，而不是那份报告。正确的闭环是：演练 → 发现差距 → 修订 BCP（或补资源）→ 下次演练验证这个修订有没有效。 如果缺了【修订】这一环，就会出现一种很典型的循环：每年的演练都发现同样几个问题（比如【备用站点的账号没准备好】【某供应商联系方式失效】），每年都写在报告里，每年都没有人去改。 原因通常是【发现的问题没有落到具体的人和日期上】——所以演练复盘的输出格式，最好直接沿用 6-3 里那三要素：谁、在什么日期之前、交付什么。

• ☐ 下一节（6-8 什么才是正确的风险应对）

相关笔记

• 电商网站中的信用卡管理 —— 上一篇：把安全要求写进合同的支付行业标准
• 什么才是正确的风险应对 —— 下一篇：风险处置的四选一，BCP 是其中一种手段
• 确保可用性 —— 可用性的技术那一半：UPS 与双重化
• 成本、便利性、安全性的考量 —— 恢复目标定在哪里，本质上是成本与损失的取舍
• 🛡️ 网络与信息安全 · 索引 —— 全课路线图