事故管理反常识：多数干预让事态更糟，先静观其变

事故的真相：等待与自愈

事故管理这件事，我做了十几年，最深的感受是：事故本身无聊透顶。你被page叫醒，冲进电话会议，然后呢？等。等另一个团队排查，等一次部署跑完，等某个变更的结果显现出来，等那个被叫醒的同事上线。整个过程压力很大，但你能做的事其实很少来源：OG。

更让人难以接受的是，大多数事故根本不需要你出手。我参加过的所有事故电话会议里，超过一半的情况是，什么都不做，系统自己就好了，而且恢复的时间和有人干预时几乎一样。这不是运气好，而是现代软件系统在设计上就自带自愈能力。服务器进程崩溃或内存泄漏？Kubernetes会自动杀掉这个pod并重新拉起一个。服务过载、请求堵塞？客户端会触发熔断器，主动退避，直到系统恢复。某个昂贵操作的流量临时暴涨？结果通常只是队列被填满，系统整体不会垮来源：OG。

这些机制每天都在后台默默运行，不产生任何戏剧性。它们的存在意味着，你半夜被叫醒时面临的大部分“紧急情况”，其实是一台已经在自我修复的机器，而你只是一个旁观者。

反直觉发现：大多数“修复”让事故更糟

但人不是这么想的。大多数事故解决操作，实际上会让事故变得更糟。这是我在无数次事后复盘里得出的结论。工程师太急着修东西了。队列积压太大？别慌，我进生产控制台把队列清空。问题是，你清掉的队列里可能躺着正在执行的重要计费任务，而这些任务不会自动重新入队。于是，一个队列延迟事故，在你按下清空按钮的瞬间，升级成了计费事故来源：OG。

另一种经典操作是强制redeploy。看到某个指标不对劲，工程师立刻连续部署几个版本试图“修复”。但并发部署给系统带来的压力，远超那个指标本身异常的根源。指标为什么不对劲，还没查清楚，系统已经被你自己的部署压垮了。我见过太多这样的案例，操作者的本意是解决问题，实际效果却是给系统又捅了一刀来源：OG。

这些错误有一个共同根源：工程师跳得太快了。看到异常，手就痒，条件反射式地想要“做点什么”，而不是先弄清楚到底发生了什么。

应对策略与多源对比：第一件事是什么都不做

基于这个判断，我的做法是：事故里的第一步，就是什么都不做。这不是消极怠工，而是一种纪律。以前我夜里被page叫醒，习惯先给自己倒一杯威士忌，再进电话会议。酒精的镇定作用只是一小部分原因，更重要的是，我需要一个仪式来强迫自己承认：我没有在赶时间，先深呼吸几下再跳进问题里是完全可以的。泡杯茶或者绕房子走一圈，效果一样来源：OG。

这个观点和行业主流叙事是相反的。人们喜欢讲“英雄工程师”的故事：某次事故中，一个天才临场发挥，想出一个巧妙的修复，系统瞬间恢复。这种故事我听过很多，但现实中几乎从未发生过。真正的英雄不是那些创造奇迹的人，而是那些坐在那里，忍住不碰键盘的人来源：OG。

有意思的是，这篇文章在Hacker News上几乎没什么动静，只有1个点，0条评论。我反复看了几遍，觉得这个数据本身就是一种讽刺。事故管理里最反常识、最值得讨论的观点，得到的关注反而最少。也许是因为“什么都不做”太不性感了，无法满足人们听故事的需求。但事故处理不是表演，有效的事故解决操作往往很乏味。如果事故无法自行恢复，真正需要你做的事，通常是临时禁用某个功能，或者回滚一次变更，仅此而已。这种操作毫无戏剧性，却远比那些花哨的“修复”有效来源：OG。

我不确定这个结论在每一个公司、每一类系统上都成立，但在我经历过的所有事故里，它反复得到验证。下次你的page响了，不妨先给自己倒杯威士忌再上线。

原文：

Notes on Incidents · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月14日