精品课件--力挽狂澜：业务连续性计划和灾难恢复

如果你在团队里负责系统稳定性，或者正在从测试、开发往运维方向转，迟早会遇到一个绕不开的问题：线上出了大故障，业务多久能恢复？这个问题听起来是技术问题，实际上考的是你有没有提前做过规划。这门《业务连续性计划和灾难恢复》讲的正是这件事——不是教你怎么敲命令，而是教你在故障发生之前，怎么把恢复这件事想清楚、写下来、演练到位。

这门课解决的是哪个工作场景

日常运维里有一类工作很容易被忽略：备份做了，但没验证过能不能恢复；应急预案写了，但没人真正跑过一遍；机房断电、数据库被误删、核心服务大面积不可用的时候，一群人临时开会决定先救哪个。这些场景的共同点是——出问题之前没人当回事，出问题之后全靠临场反应。

业务连续性计划（BCP）和灾难恢复（DR）要解决的，就是把这种临场反应变成有预案、有优先级、有责任人的流程。课程覆盖的是从风险评估、影响分析，到恢复目标设定、预案编写，再到演练和复盘这一整套思路。它不绑定某一家云厂商或某一款工具，讲的是一套可以落到你自己系统上的方法。

学完能独立做什么

• 能对自己负责的系统做一次业务影响分析，分清哪些服务断了必须立刻恢复、哪些可以等几个小时。
• 能写出可执行的恢复预案，包括恢复顺序、切换条件、联系人、验证步骤，而不是一份只有标题的文档。
• 能设定合理的 RTO 和 RPO 指标，并且知道这两个数字背后要付出多少成本，避免向老板承诺做不到的目标。
• 能组织一次恢复演练，并在演练后指出预案里哪些环节是纸上谈兵。

这些产出在面试和实际工作里都说得出口。尤其是转岗做运维的人，能讲清楚自己设计过一次恢复流程，比背一堆命令更有说服力。

资料适合什么基础的人

内容偏管理和流程，技术深度不算高，所以不要求你会写脚本或者懂底层存储原理。但建议满足两个前提：一是对所在系统的架构有基本了解，知道服务之间怎么调用、数据存在哪里；二是手上有真实系统可以对照着练，哪怕是公司内部的一套测试环境。完全没有接触过生产环境的人看这份资料，容易觉得都是概念，落不了地。

如果你已经是资深 SRE，日常就在做容量规划和故障演练，这份资料里的很多内容可能已经是你熟悉的做法，价值更多在于帮你把零散经验整理成体系。但对大部分测试、开发和初级运维来说，业务连续性这块往往是知识盲区，补上它有实际意义。

怎么用这份资料效率更高

不建议从头到尾一口气看完。可以按这个顺序：先看风险评估和影响分析的部分，拿自己手上的系统试着列一张服务清单，标出中断影响；再看恢复目标和预案编写，对照现有文档找差距；最后看演练相关内容，挑一个影响最小的服务先跑一次恢复测试。整个过程可能只需要几个晚上，但产出的东西是能直接用在工作的。

需要提醒的是，业务连续性不是一次性任务。系统架构变了、依赖的第三方服务换了、团队人员流动了，预案都要跟着更新。这份资料给的是方法和框架，真正要花的工夫在于定期维护。