灾备演练中的切换验证别当例行公事

上周跟三个做运维的朋友在街边撸串，聊到刚结束的季度灾备演练，三个人里有两个说，演练完直接收工，没人真去碰业务系统的核心接口。说真的，我见过太多团队的灾备演练，搞得像年会节目。领导在前面讲话，技术团队在后面按按钮，切完之后大屏上跳个”切换成功”的大字，所有人鼓掌，拍合影，发公众号通稿。至于切完之后系统能不能用？没人关心。

先搞清楚，切换完你验证的到底是什么

很多人对灾备演练中的切换验证有个天大的误会，觉得只要灾备中心的网络通了，应用服务进程起来了，就算验证合格。切换验证的核心从来不是链路通不通，是切过去之后的业务是不是真的能跑，有没有隐的数据不一致，有没有权限漏配，有没有缓存没同步的坑。之前碰到过一个团队，演练的时候把核心交易系统切到灾备中心，界面能打开，订单能提交，大家鼓掌收工。结果第二天真实故障切过去的时候，发现支付回调的地址还指着旧机房的IP，所有支付成功的订单都卡在待支付状态，折腾了四个小时才顺过来。

麻烦在于，这种坑从来不会在你ping通IP的时候跳出来。你只测登录页能不能打开，等于考试的时候只把名字写了就交卷。真实的用户请求是带各种参数的，是从前端到网关到应用层到数据库到第三方接口的全链路，哪一环没配对，最后都是用户那边实打实的报错。

别把验证环节搞成走流程的签字表

现在很多企业的灾备演练，验证环节就是一张打印的checklist，上面列了”应用启动正常””数据库连接正常”，每个项打个勾，找负责人签个字，就归档了。说白了，这张表最大的作用就是应付等保检查。我见过最离谱的checklist，上面的勾是演练前一天就提前打好的，所有人都知道，没人说破。为什么？因为真的测，太费时间了。切到灾备环境，你要测用户登录，要测订单创建，要测库存扣减，要测优惠券核销，要测短信发送，要测跟第三方支付的回调，一套流程跑下来，少说大半天。本来演练就占了周末大家的休息时间，谁愿意多熬这几个小时？

真正有效的切换验证，从来不是按表打勾，是要模拟真实用户的操作路径，甚至要故意找那些平时没人测的边角场景。比如什么边角场景？比如用户刚上传的头像，切完之后能不能正常显示；比如刚提交的批量导入任务，切到灾备之后是不是还在队列里跑；比如之前配置的跨域权限，切完之后前端的静态资源是不是还能正常加载。这些东西，你不主动测，永远不知道有坑。

验证的代价，从来比故障的代价低得多

很多人觉得，演练的时候费这么大劲测所有场景，太亏了。对吧？毕竟一年也就两次演练，哪那么巧就真出故障。但你想想，上次那个因为支付回调地址没改导致的故障，影响的是真实的交易，是用户投诉，是监管的整改通知，算下来的损失，比你演练的时候多花两三个小时测全链路，高了不知道多少倍。

说实话，我接触过的几个做的好的团队，演练的时候根本不搞什么隆重的切换仪式。切完之后，几个核心模块的owner直接上手跑自己负责的业务流，跑通了，报个数字，跑不通，当场记下来，演练完第一时间改。根本不需要什么人在旁边拍照片，不需要什么领导在会议室盯着大屏看切换进度。

很多人觉得灾备演练中的切换验证太复杂，要搞什么自动化测试平台，要写一堆脚本，投入太大。这事没那么玄。你哪怕没有自动化平台，找几个平时天天跟业务打交道的运营、客服、一线开发，切完之后，让他们像平时处理工单一样，走一遍自己日常的操作流程，比你十个运维在那ping半天路由器有用得多。上次碰到一个团队，切完之后让客服小姑娘上去试了一下自己平时查用户订单的后台，刚点进去就发现，所有用户的历史订单都显示空白。查了半天才发现，灾备库的从库同步，在半个月前就断了，因为当时的同步进程被误杀了，没人发现。要是没这一下试，真等出故障切过去，半个月的订单数据都查不到，那才叫麻烦。

下次再做灾备演练中的切换验证，别刚切完就着急开庆功会。多花点时间，多摸几个真实的业务场景。毕竟你演练的时候踩的坑，最后都会变成真实故障时救你一命的缓冲垫。