演练类型大揭秘：计划内 vs 计划外

很多团队做恢复演练，上来就问「我们该怎么做？」。我通常会反问一句：「你先想清楚，这次演练是计划内的，还是计划外的？」

这两个词听起来简单，但背后的设计思路、风险控制、甚至团队的心理状态，完全不一样。我见过不少事故，就是因为把计划外演练当计划内做，结果现场一片混乱。

今天咱们就把这两类演练掰开揉碎，讲清楚它们各自适合什么场景，以及怎么落地。

一、计划内演练：可控的「压力测试」

计划内演练，说白了就是提前定好时间、定好范围、定好步骤的演练。比如每个季度做一次数据库主从切换，或者每半年做一次全链路容灾演练。

适用场景：

• 验证标准操作流程（SOP）的完整性
• 测试灾备系统的可用性（比如备库是否真的能接管）
• 培训新员工，让他们熟悉应急流程
• 合规审计要求（金融、医疗等行业常见）

我个人习惯，计划内演练一定要有「剧本」。这个剧本不是死板的，而是包含多个分支路径。举个例子：

# 计划内演练剧本片段（MySQL主从切换）
步骤1：通知所有相关方（提前15分钟）
步骤2：检查主库延迟 < 10秒
步骤3：设置主库只读
步骤4：等待从库追平延迟
步骤5：提升从库为主库
步骤6：修改DNS/连接串
步骤7：验证读写正常
步骤8：回滚预案（如果切换失败）

嗯，这里要注意：剧本里必须包含「回滚步骤」。我在项目中遇到过，有人做切换演练时只准备了正向流程，结果切换后业务报错，一群人慌了半小时才想起来怎么切回去。那次之后，我要求所有计划内演练的剧本，回滚步骤必须写在正向步骤的旁边。

二、计划外演练：突袭式的「实战检验」

计划外演练，就是「搞突然袭击」。没人知道今天会出问题，甚至没人知道这是一次演练。比如突然杀掉一个核心进程，或者模拟网络分区。

适用场景：

• 检验团队的应急响应速度
• 测试监控告警是否真的能触发
• 验证值班人员的故障定界能力
• 发现「流程死角」——那些平时没人注意的环节

我曾经在一次计划外演练中，故意把一台Nginx的配置文件改错。结果监控告警5分钟后才发出，值班同学看到告警后，第一反应是「重启大法」，重启后问题依旧，又花了20分钟才定位到是配置问题。那次演练暴露了三个问题：监控阈值太宽松、值班人员缺乏配置检查意识、没有配置版本回滚的快速手段。

你看，计划外演练的价值就在这里——它不验证你的文档写得多漂亮，它验证的是真实情况下，你的团队和系统到底行不行。

三、两类演练的核心差异对比

你想想看，如果一个团队只做计划内演练，那他们永远不知道真实故障来临时，自己的反应有多慢。反过来，如果只做计划外演练，团队会一直处于紧张状态，反而容易出错。我的建议是：计划内演练占70%，计划外演练占30%，这个比例比较健康。

四、如何选择？一张流程图帮你理清

下面这张图，是我自己总结的演练类型选择逻辑。每次做演练规划时，我都会先过一遍这个流程。

这个流程的核心就一句话：先想清楚你要验证什么，再选演练类型。别一上来就说「我们做个演练吧」，那样很容易做成形式主义。

五、实战中的组合策略

说实话，真正成熟的团队不会只做一种演练。我见过最好的做法是「组合拳」：

1. 季度计划内演练：验证灾备系统的可用性，更新SOP文档
2. 月度小范围计划内演练：针对某个组件做切换测试，比如Redis哨兵切换
3. 每季度一次计划外演练：不通知具体时间，只通知「本周内会有一次演练」
4. 半年一次「盲演」：连执行者都不知道，只有演练设计者知道

我记得有一次，我们做盲演时，值班同学收到告警后，第一反应不是去查问题，而是先给组长打电话。组长当时在开会没接，结果耽误了10分钟。那次之后，我们修改了值班制度，要求值班人员必须先做初步定界，再升级。你看，这种改进，只有计划外演练才能逼出来。

六、避坑总结

最后，把我在项目中踩过的坑，列成清单给你参考：

• 计划内演练最大的坑：剧本写得太完美，但实际环境跟剧本不一样。我曾经遇到过，剧本里写的IP地址跟实际差了最后一位，结果切换脚本跑错了机器。所以计划内演练前，一定要做环境预检。
• 计划外演练最大的坑：没有安全边界。我见过有人直接在生产环境做网络分区演练，结果影响了线上用户。计划外演练一定要有「熔断机制」——一旦发现影响超过预期，立刻停止。
• 两类演练共同的坑：不复盘。演练完了，大家说「没事了」，然后该干嘛干嘛。那这次演练就白做了。每次演练后，必须产出改进项，并且跟踪闭环。

好了，这一章的内容就到这里。记住：计划内演练让你「会做」，计划外演练让你「敢做」。两者结合，才是真正的恢复能力。