寓言
同一场暴雨，两份截然不同的损失单
城东有两栋相邻的写字楼。A 楼的物业团队投资了双路供电和异地备份机房，暴雨导致地下室进水时，他们四十分钟内把服务器切到了备用节点，数据全部恢复。A 楼当天下午 IT 系统就正常了。
B 楼的业主看了 A 楼的方案，也配了备用机房和灾备切换脚本，认为自己做好了充分准备。暴雨那天，B 楼的系统同样在半小时内恢复了运行。两家从 IT 角度看几乎打平。
真正的差距出现在灾后第三天。A 楼的租户照常接单、发货、收款——因为他们在灾备计划之外还留了一套手动作业流程：纸质工单模板、备用通信渠道、关键客户的分级联络表。切换备用机房的那四十分钟里，前线同事已经在用备份流程继续履约。
B 楼的租户就没这么幸运。系统恢复了，但仓库不知道哪些订单已经承诺给客户，销售拿不到最新的库存数据，财务无法确认暴雨前后的回款归属。IT 恢复得越快，业务混乱反而暴露得越彻底——机器在跑，但没人知道该跑什么。
事后复盘，B 楼才发现一个根本区别：灾备脚本只管机房里的东西——服务器、数据库、网络链路。但业务连续性管的是机房外面的东西——人怎么继续工作、客户怎么不被晾着、合同义务怎么不被中断。两边的恢复时间表完全不同。
A 楼的物业主管后来在行业分享会上讲得直白：灾备是让机器重新开机，业务连续性是让开机之后的机器有正确的指令可以执行。光开机不配指令，等于把混乱自动化了。
这件事之后，评估楼宇的灾害应对方案，从一份 IT 灾备清单变成了两份独立的文件：一份写机房恢复时间，一份写业务功能恢复顺序。两份文件各自有负责人，各自有演练周期。演习时 IT 先跑通，然后业务团队在恢复后的系统上验证能不能完成一笔真实订单——缺一不可。 这张表后来贴在调度室门口。