上周跟某城商行的技术负责人吃饭，他刚结束季度灾备演练，衬衫袖子还卷着，说演练结束当天晚上组里人全去吃烤串，没人想复盘。
没人真的想搞演练。毕竟谁愿意牺牲周末或者凌晨的休息时间，对着一堆脚本按步骤点来点去，最后写个几千字的报告交差，换不来任何实际的业务增长，搞不好还要被业务部门追着骂”影响正常干活”。
没人愿意在大半夜被叫起来切流量
这事的矛盾从根上就解不开。你要是把演练安排在工作日的九点到下午五点，业务部门第一个跳出来反对——正对着客户做方案呢，正赶上大促的流量高峰呢，你说要切流量做灾备，出了问题算谁的？你要是把演练安排在凌晨两三点，技术组的人怨声载道。上次有个运维本来在陪发烧的女儿去儿童医院挂急诊，接到主管的电话说要回来参与切流量，当场就把电话挂了，说今天就算被开除，也得等女儿退了烧再说。
大部分团队的灾备演练，本质是在”业务损失”和”团队怨气”之间找最能凑活的平衡点。没人敢说自己选的时间是完美的，能做到”两边都能接受”就算是把前期协调的功夫做足了。
很多人觉得协调时间就是灾备演练里最麻烦的环节，其实根本不是。
你以为的走流程，其实藏着最多的暗坑
我见过太多团队的灾备演练，提前一周就把所有步骤排得明明白白，谁负责切数据库，谁负责通知客服部门，谁负责写演练报告，连每一步的时间点都精确到分钟。到了演练当天，所有人按脚本走一遍，切流量，跑个十分钟业务，再切回来，报告一交，就算完成了季度KPI。
麻烦在于，这种演练除了能应付监管的检查，啥用都没有。
之前碰到过一个做在线教育的团队，搞年度灾备演练的时候，按脚本把核心用户库切到异地机房，刚切完就发现，异地库的同步停了整整八个月。原因是之前负责配置同步任务的工程师离职了，交接文档里根本没提这个任务，新接手的人压根不知道有这么个同步链路。还有更离谱的，切完流量跑业务，发现异地机房的出口带宽还是三年前老业务的配置，现在新上的直播课功能一压测，直接把带宽打满，学生端的画面卡成PPT，最后演练不得不提前终止，整个团队熬到凌晨五点，啥问题都没查出来，灰溜溜回去补带宽配置。
灾备演练里最没用的，就是提前一周把所有步骤排好，连每一步谁按哪个键都写进脚本里——因为真出实际故障的时候，根本没人给你留按脚本一步步走的时间。机房着火了，光缆被施工队挖断了，勒索病毒把核心文件加密了，这些突发状况不会提前一周给你发通知，让你把相关的人都喊齐了，把脚本摆到桌面上再发生。
很多人吐槽灾备演练是形式主义，其实真不是演练本身有问题，是你把演练做成了形式。你连故意制造点随机故障的胆子都没有，怎么能指望真出事的时候，团队能顺顺利利把业务救回来？
别把云厂商的兜底当成自己的灾备能力
这两年跟很多技术负责人聊天，总能听到类似的说法：”我们都把业务跑在云上了，云厂商有跨区容灾，有故障兜底，我们还费那劲搞灾备演练干嘛？”
说白了，这就是把别人的责任当成了自己的能力。
之前有个做家居电商的朋友，前两年把所有业务迁到云上，觉得买了最高等级的容灾服务，就彻底高枕无忧了。去年赶上某云厂商单区的硬件故障，整个可用区断了三个小时，他才发现自己的应用从代码到配置，全是写死在这个可用区的参数，根本没法自动切到备用区。眼睁睁看着三个小时没法下单，后台的客诉消息刷了几千条，最后算下来的直接损失，够他们团队做十次全链路灾备演练。
灾备演练的核心，从来不是证明你买的容灾服务有多好用，是你得自己摸清楚：从核心机房出问题，到所有业务在备用节点跑通，到底要花多久？哪些环节是你自己能控制的，哪些环节是要靠第三方配合的？哪些依赖的服务，在故障发生的时候根本调不通？
说真的，我见过很多技术团队，平时总觉得灾备演练是额外的负担，直到真的碰到一次实打实的故障。之前那个城商行的技术负责人说，前年他们核心机房的消防系统误喷，把半机房的服务器全浇了，因为三个月前刚做过一次无脚本的灾备演练，整个切换流程只花了47分钟，大部分用户甚至没察觉到服务中断。演练结束当天，老板直接批了三倍的团建经费，整个技术组拉着行李箱去海边待了三天，比之前任何一次按流程走的团建都痛快。
谁也不想真的碰到机房着火、光缆被挖断的糟心事，但只要你做过几次实打实的灾备演练，你就知道：平时花的那点时间，熬的那几个夜，在真出事的时候，全是能把你从坑里拉出来的底气。