灾备演练是藏在机房深处的真考题

上周跟南京本地某银行的运维主管吃鸭血粉丝，他刚结束季度灾备演练，汤都没喝两口就开始吐槽。说预案写了37页，流程走得比春晚彩排还顺，真到切备用节点的时候，才发现备用库的账号密码还是去年项目上线时设的，三个月前安全部统一改密码，没人同步给灾备组。卡了四十分钟才登进去，演练结束的复盘会上，没人担责，都说是”跨部门协同的小问题”。

演练的坑从来不在预案里

见过太多预案，把RTO、RPO的数字标得像高考分数线，精确到秒，真跑起来全是窟窿。有的备用机房的网络带宽是按五年前的业务量配的，现在流量翻了三倍，切过去直接堵死。有的备份数据从来没校验过，真要恢复的时候，才发现快照文件是损坏的，原因是去年存储阵列换了控制器，没人改备份脚本的参数。

没人会提前记这些。写预案的人不会蹲在机房理三个月的线缆，跑流程的人不会去翻备份脚本的日志。很多公司的演练，本质是”按剧本走一遍过场”，大家都怕出问题，都想顺顺利利拍完照交差，至于真遇到故障能不能扛住，没人敢问。

没人愿意为演练的“意外”买单

这才是最核心的矛盾。你要练的是”天塌下来怎么办”，但没人敢真的把天捅个窟窿。 去年听一个做电商的运维说，他们前年做全量灾备切换演练，刚把流量导到备用机房，才发现支付通道的加密密钥没同步，直接卡了三千多笔待支付订单，用户投诉电话打爆了客服热线。最后整个运维团队扣了季度绩效，老板直接拍板，以后演练就做桌面推演，对着PPT念流程就行，别碰生产系统。 现在他们的演练，每年都是开两小时会，把预案从头到尾读一遍，签个字就结束。三年下来，备用机房的服务器都积灰了，真遇到主机房断电，能不能切过去，谁心里都没底。

说白了，灾备演练从来不是技术问题，是责任问题。你要是真搞全量切换，出了故障影响业务，谁背锅？要是走形式走流程，就算真出事，也是”预案没考虑到”，谁都不用担责。换你是运维负责人，你选哪个？

真正有用的演练，都带点“不讲理”

我见过最实在的一家，是做本地政务服务系统的。上次演练，负责人提前一周谁都没通知，演练当天直接让保安把主机房的总闸拉了。在场的几个年轻运维当时脸都白了，手里的咖啡都洒了。 最后他们把整个系统切到备用机房，只用了47分钟。比预案上写的2小时RTO快了整整一倍。事后复盘才知道，之前预案里留的那一个多小时的缓冲，是为了走审批流程、开故障通报、同步客服话术，真急眼了，这些流程全可以往后放，先把系统跑起来再说。 真正的灾备能力，从来不是PPT上印的数字，是你遇到真故障时，哪怕手忙脚乱，也能把事办成的反应速度。 后来跟那个负责人聊，他说现在他们每季度都搞一次”盲演”，不提前通知，不定时间，有时候是拔网线，有时候是删核心库的测试数据，就是要练出那种”不管出什么乱子，都能兜住”的底气。 上周又碰到那个银行的运维主管，他说今年的演练，他们直接跳过了桌面推演，第一次切了全量的查询流量，虽然中间出了两个小问题，但好歹都兜住了。 他说，以前总觉得演练是给领导看的，现在才明白，灾备演练练的不是流程，是你自己的命。真到机房断电、服务器宕机的那天，你手里的预案、你平时练过的操作，才是能让你下班回家的东西。