一、先说我遇到的那次
2022年11月10号晚上23点47分，我在一家做母婴用品的小公司盯双11。手机弹出第一条告警的时候我正在泡面。前端商详页库存显示正常，但下单接口成功率从99.2%掉到31%。客服群里开始有人发截图，一个妈妈说「抢了三次都失败了」。
我当时做了三件事：给技术负责人打电话、在老板群里发了句「在查」、然后……然后我就不知道干什么了，盯着监控面板看数字往下掉。这个「不知道干什么」的状态持续了大概二十分钟。后来复盘，真正造成损失的不是那半小时的故障，是我在这段时间里做的两个错误决定：一是让客服统一回复「系统繁忙请稍后再试」，二是没在第一时间把活动页库存改成「补货中」。前者让用户反复重试，把31%的成功率又往下压了一截；后者让两百多单下了但没货，第二天得一个个打电话解释。
有意思的是，这个故障最后查出来，是三个月前一次数据库配置调整留下的隐患。它不是突发，它是一颗已经躺在那里九十天的雷，只是那天晚上被踩响了。
二、GitLab和AWS的两个案例，讲的是同一件事的两面
2017年1月31日，GitLab的一个工程师删数据库目录时，因为终端窗口切错，在primary库上执行了删除命令，约300GB数据没了。他们准备了5个备份恢复渠道，结果4个因为各种原因失效——有的备份压根没跑成功，有的版本不匹配。最后起作用的是一个LVM快照，恢复过程大约18小时，丢了6小时的数据。整个过程他们在YouTube上直播。
同年2月28日，AWS us-east-1区域出过一次更大的事故。一名工程师排查计费系统问题时执行命令，本来只想停掉少量服务器，输入的时候多打了一个字符，结果把S3的索引和放置子系统搞下线了，前后4个小时。
这两个案例经常被拿来讲「人不可靠」。但我看到的是另一面：GitLab那台primary被误删，暴露的是他们5个备份渠道里有4个是「纸面备份」——写在文档里，从来没验证过。AWS那个多打的字符，暴露的是生产环境命令没有二次确认机制。区别在哪？GitLab是「我们的预案看起来很多」，AWS是「我们的预案只有一条路」。前者的危险是虚假安全感，后者的危险是单点。
我后来待过的一家公司，钉钉群里有个「应急预案」文件夹，里面11个文档，最新一次更新时间是2019年。这大概就是GitLab式的安全感。
三、我把突发分成三类，判断标准是「这件事有没有前兆」
第一类：欠账型。 特征是你能在故障时间里找到它的「生日」。配置漂移、没还的技术债、某个一直报错但被忽略的监控、一个离职同事留下的「别碰这个脚本」。这类占我见过的八成以上。判断方法很简单：问一句「这个问题三个月前存在吗」，如果答案是「存在，只是没爆」，它就是欠账。
第二类：传导型。 不是你的系统坏了，是别人的。上游供应商接口挂了、云厂商机房空调坏了、支付通道风控误杀。2022年12月18日阿里云香港Region C的制冷设备故障，影响的是一大批自己根本没做错什么的企业。这类你控制不了它发生，只能控制「多久发现」和「有没有备胎」。
第三类：真·黑天鹅。 概率极低、完全没预兆。比如2024年7月19日CrowdStrike一次普通的传感器更新，导致全球约850万台Windows设备蓝屏，航空公司、医院、银行一起停摆。这类事你能做的其实不多，最多是别把鸡蛋放一个篮子——但小公司通常只有那一个篮子。
分类的意义在于：第一类该做的是还债，第二类该做的是冗余，第三类该做的是……接受。很多人把三类混在一起处理，用「加强责任心」「提高警惕」来应对所有情况，结果是该修的没修，该买的备份没买，该睡觉的时候在群里发「大家注意一下」。
四、具体怎么做：三个数字和两个动作
说点能落地的。
15分钟。 从第一条告警到有人明确说出「我是这次故障的负责人」，不要超过15分钟。不是「我们在查」，是「我负责，现在同步一下目前知道的信息」。我在的那家公司后来定了个规矩：P0故障，5分钟内必须有人在故障群里发第一条信息，内容只有三行——现象、影响范围、当前负责人。
3个人。 故障处理小组的最小配置是三个角色：一个指挥，只做决策和对外沟通，不碰键盘；一个动手，改配置、回滚、重启；一个记录，记时间线、做了什么、什么结果。一个人又当指挥又动手，最容易干的事就是越改越乱。我们那次双11就是，技术负责人一边查日志一边接电话一边在群里回复，最后回滚晚了一个小时。
双人复核。 所有生产环境变更，两个人看，一个人执行。AWS那个多打的字符，如果屏幕前有第二个人念一遍命令，大概率能拦住。GitLab那次如果终端提示符足够明显，也许不会切错窗口。这两个都是成本极低、收益极高的措施，但很多公司嫌麻烦。
两个动作：把预案做短，把备份做真。 应急预案超过两页纸，故障时没人看。我现在的做法是一页A4：谁打电话给谁、第一件事做什么、哪个按钮点下去会回滚。另外，备份这东西只有恢复成功了才叫备份，没验证过的叫心理安慰。建议每季度做一次真实的恢复演练，哪怕只恢复一张表。
五、最后说个可能不太讨喜的观点
有些突发状况，其实不该被「解决」，该被允许发生。
我见过一家公司，为了防止线上事故，搞了七层审批，发一个版本要签五个字。结果是所有人都学会了「提前一周准备材料、把风险写小一点」，事故没少，只是变得更隐蔽——真出问题的时候，因为流程太慢，恢复反而更久。
还有一个更隐蔽的代价：如果所有突发都被完美处理，团队会慢慢默认「反正会有人兜底」。我待过一个组，每次线上出问题都是同一个大哥凌晨爬起来修，修了两年他离职了，整个组在三个月里连续崩了四次。那两年里没人成长，因为突发状况被一个人消化掉了。
所以我的看法是：突发的价值不在于你能不能零损失地扛过去，而在于它暴露了什么。欠账型的突发，暴露的是你拖延了什么；传导型的突发，暴露的是你依赖了谁；黑天鹅型的突发，暴露的是你有多脆。
每次故障之后，我习惯问三个问题：这件事三个月前有没有苗头？如果我们只有一半人手，还能不能处理？下次它再来的时候，我们希望自己哪里不一样？
第一个问题答不上来，说明复盘没做到位。第二个问题答不上来，说明流程依赖了某个不可替代的人。第三个问题答不上来，那这次故障大概率白出了。