工程师总结事故处理经验：多数事故可自行恢复

事故是无聊的。在事故处理过程中，你实际做的大部分事情其实就是等待：等其他团队调查，等部署完成，等某个变更的效果显现出来，或者等被呼叫的其他人上线。压力很大，但通常并没有太多事情可做。

大多数事故会自行解决。人们喜欢分享那些英雄工程师即兴发挥、用巧妙修复瞬间恢复系统的战斗故事。但这种情况很少发生。设计良好的软件系统往往能自行恢复，而许多现代系统至少部分设计良好，因为它们是由真正可靠的组件构建而成的。如果服务器进程崩溃或内存泄漏，Kubernetes 会杀掉 Pod 并重新启动它。如果服务过载并卡住，客户端（希望如此）会触发熔断器并退避，直到服务恢复。昂贵操作的临时峰值通常只会填满队列，而不是拖垮整个系统。我参与过的大多数事故呼叫——远超一半——即使没有任何人工干预，也会在大致相同的时间内自行恢复。

大多数事故处理操作反而会让事故变得更糟。工程师们太急于解决事故了。哦，队列大小巨大？别担心，我就在生产控制台里，我来清空队列！不幸的是，我刚刚清除的一些作业正在执行重要的计费工作，而且不会自动重新入队，所以这个队列延迟事故现在也变成了计费事故。这个类别中的另一个经典案例是“工程师强制进行一系列重新部署来‘修复’一个看起来令人担忧的指标，而并发的部署给系统带来的压力远远超过了导致指标看起来异常的任何原因”。

因此，在事故中你应该做的第一件事就是什么都不做。当我深夜被呼叫时，我过去习惯在加入电话会议前给自己倒一杯苏格兰威士忌。这只有一部分是为了酒精的镇静效果：主要原因是有一个仪式可以让我经历一遍，说服自己我没有在匆忙行事，在跳入问题之前花几口气放松一下是可以的。泡一杯茶或者在房子里走一圈可能也同样有效。

有效的事故处理操作往往是乏味的。通常，解决事故所需的操作——假设它不会自行解决——是暂时禁用某个有问题的功能，直到系统恢复。这从来都不是复杂的代码更改。通常有人花五分钟整理补丁，然后花一个小时等待审查、CI 和部署。如果你非常幸运，你会写一个“给它包一个缓存”的代码更改。

在事故中，对系统的了解是无可替代的。五个强壮的工程师可以在事故电话会议上进行故障排除而毫无进展，而一个半醉的、熟悉代码库的工程师可以悠然走进来并立即解决问题。这是因为解决事故的操作类型非常简单：如果你一直是参与该项目的人，你可能已经确切知道要检查和禁用哪个功能标志，或者要回滚哪个代码更改。

解决事故需要勇气。事故电话会议可能很吓人。当工程师们害怕时，他们往往会寻求共识：对冲自己的陈述，询问团队是否同意某个特定行动方案是安全的，互相推诿，等等。但如果你是那个了解系统的人，你必须果断。说“我要做 X”，等三十秒，然后去做。虽然让一个有权势的经理在事故电话会议上坐立不安通常是净负面的，但这是少数可能有所帮助的情况之一——高管们非常习惯于对他们并不完全理解的技术行动方案说“好的，现在就做”。

解决事故能积累大量政治资本。我认为许多刚接触值班的工程师会感到惊讶的一件事是，经理和高管们对 even 非常简单的修复（即“关闭功能标志”）有多么感激。这是因为事故是非技术领导层直接面对他们对技术领域缺乏控制的少数时刻之一。当团队在构建产品时，你的 VP 有很大的自由来指导流程和做出决策。但当有活跃的事故时，他们只能坐在那里，相信他们的技术员工会把他们从火坑里拉出来。这是一个可怕的情况，特别是对于习惯于在工作场所行使一定程度权力的人来说。

然而，总是解决事故（本身）并不是一个持久的权力地位。这有点反直觉。如果你总是在解决事故，你难道不是不可或缺的吗？问题在于，解决事故的工作几乎总是技术性太强，以至于对高管们完全不透明。他们知道事故已经解决，但他们不知道你是做了英勇的努力还是仅仅做了显而易见的事情。他们也无法把你的成功说成是他们的（这始终是让 VP 和总监站在你这边的最可靠方式），因为事故被期望得到修复，而且最好根本就没有发生事故。

编辑：我收到了一封有趣的读者邮件，说根据他们的经验，事故通常不会自行消失。结果发现他们通常在我规模更小的公司工作。我怀疑这是系统规模的问题：大型科技公司拥有更庞大的系统，有更多的第三方依赖，所以出现故障并自行恢复的情况更为常见。

我不再需要这样做了，因为我不再像以前那样对事故如此紧张。

如果你喜欢这篇文章，可以考虑订阅关于我新文章的邮件更新，或者在 Hacker News 上分享它。

这里有一篇相关文章的预览，它与这篇文章共享标签。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）