测试应急预案

凌晨两点，测试监控大屏上突然跳出一片红。应急预案不是测试渐变，是应急预案瞬间全红的那种。我盯着屏幕愣了三秒——核心网关的测试QPS从八千直接掉到零。手机开始震，应急预案运维群里已经炸了。测试这就是应急预案我第一次真正启动测试应急预案的时刻，之前演练过三回，测试真来的应急预案时候手还是抖的。

测试应急预案这东西，测试写出来容易，应急预案用起来是测试另一回事。我见过太多团队把预案文档往Confluence一扔，应急预案半年没人点开过。测试真出事的时候，大家第一反应是翻聊天记录找上次谁处理的，而不是去查预案。所以我现在判断一个预案有没有用，标准很简单：凌晨三点被叫醒的人，能不能在五分钟内照着它开始干活。

先搞清楚什么算“紧急”

不是所有测试事故都配得上“应急”两个字。用例跑失败了、环境挂了、数据脏了——这些是日常。真正的应急场景我归纳下来就三类：一是测试环境彻底不可用，且短时间恢复不了；二是测试数据泄露或污染了生产数据；三是压测把生产拖垮了。第三类最要命，我亲身经历过一次，压测流量没隔离干净，直接打到生产库上，DBA打电话过来的时候声音都是变形的。

把边界划清楚，预案才不会变成一本什么都往里塞的废话合集。

联系人表要写在第一页

别搞什么组织架构图。就写：谁，什么情况下打他电话，备选是谁。我见过一份预案，联系人写了十二个，真出事打过去一半在开会一半已离职。现在我们的做法是每季度更新一次，而且只保留三个关键角色：环境负责人、数据负责人、决策人。其他人进群就行，不用单独列。

有个细节：电话号码不要只写企业微信。断网的时候你登不上。写手机号，写两个。

恢复步骤要具体到命令

“重启服务”这种话等于没说。哪个服务？在哪台机器？用什么命令？重启之前要不要先摘流量？我现在的预案里直接贴命令，连参数都写好。比如回滚测试库：sh rollback_test_db.sh --env=staging --snapshot=20240612_0200。执行的人不需要思考，复制粘贴回车。听着有点蠢，但凌晨三点人的脑子就是不太转的。

另一个坑：别假设执行的人熟悉系统。写预案的时候默认看的人是个刚入职两周的新人，他只知道怎么登堡垒机，其余一概不知。按这个标准写，老手看着觉得啰嗦，但真到用的时候不会卡壳。

决策点比操作步骤更重要

操作步骤是线性的，但事故从来不按剧本走。预案里必须留出“如果A没效果，转B”的分支。比如环境恢复：先尝试重启容器，五分钟没起来就切备用集群，备用集群也拉不起来就直接通知全员暂停测试。每个分支写清楚判断条件和时间窗口。没有时间窗口的预案就是耍流氓——等半小时再切备用，黄花菜都凉了。

我个人的经验是，决策点最好控制在三个以内。太多了执行的人会犹豫，犹豫就会败北。

事后别急着写复盘

事故处理完，所有人第一反应是赶紧写复盘报告交差。我建议缓一天。刚处理完的时候记忆是混乱的，写出来的东西全是情绪。第二天再坐下来，把时间线捋一遍，你会发现很多当时觉得“没办法只能这样”的决策，其实有更好的选择。复盘不是交作业，是给自己下次省命。

预案也一样，每次用完必须改。哪条命令报错了、哪个联系人打不通、哪个判断条件写得太模糊——全部标出来，当场改掉。我们现在的预案已经迭代到第七版，每一条修改背后都是一次真实的半夜惊魂。

说到底，测试应急预案不是给别人看的文档，是给自己写的保命手册。写得糙一点没关系，但每句话都得能落地。凌晨三点，没人想读一篇论文，大家只想赶紧把环境搞回来然后回去睡觉。