事故处理心得：大多数故障会自行恢复Notes on incidents

事故本身很无聊。在真正处理事故的过程中，你大部分时间都在等待：等另一个团队调查、等部署完成、等某个变更的结果显现出来，或者等被通知的人上线。这虽然令人紧张，但通常没什么可做的。

大多数事故会自行解决。人们喜欢分享那些英雄工程师临时想出巧妙方法立刻修复系统的事故故事。这种情况很少发生。设计良好的软件系统往往会自我恢复，而许多现代系统至少部分设计良好，因为它们由非常可靠的组件构建而成。如果服务器进程崩溃或内存泄漏，Kubernetes 会杀死该 pod 并重新启动它。如果服务过载并卡住，客户端（希望如此）会触发断路器并退避，直到其恢复。昂贵的操作临时激增通常只会填满队列，而不会让整个系统崩溃。我参与过的大多数事故——超过一半——如果没有人为干预，大约在同一时间也会自行恢复。

大多数解决事故的操作反而会让事故变得更糟。工程师们往往操之过急地试图解决问题。哦，队列大小很大？别担心，我马上在生产控制台上清理队列！不幸的是，我刚刚删除的一些作业正在执行重要的计费工作，而且不会自动重新排队，所以这个队列延迟事故现在也成了计费事故。这类操作的另一个经典案例是：“工程师强行部署一系列重部署来‘修复’某个看起来可疑的指标，结果这些并发部署给系统带来的压力远大于原本导致指标异常的原因”。

正因如此，你在事故中的第一反应应该是什么都不做。我曾在深夜被通知处理事故时，习惯先给自己倒一杯苏格兰威士忌再接入通话。这不仅仅是为了酒精的镇静作用：主要目的是通过一个仪式让自己相信我没有匆忙，在着手解决问题之前深呼吸一下、放松一下是可以的。泡杯茶或在屋里走一圈可能也有同样效果。

有效的解决事故的操作往往很枯燥。通常解决事故所需的操作——假设它没有自行解决——就是暂时禁用某个有问题的功能，直到系统恢复。这从来不是一个复杂的代码变更。通常有人花五分钟写好补丁，然后等一个小时进行审查、CI 和部署。如果你运气好，可能会写个“给它套个缓存”的代码变更。

在事故中，对系统的了解无可替代。五个优秀的工程师在事故电话中排查问题可能毫无进展，而一个半醉但熟悉代码库的人却能轻松进入并立即解决问题。这是因为解决事故的操作非常简单：如果你曾负责这个项目，很可能已经知道要检查并禁用哪个功能开关，或者要回滚哪个代码变更。

处理突发事件需要勇气。接到事件电话时可能会让人害怕。当工程师感到恐惧时，他们往往会寻求共识：含糊其辞，询问团队某项操作是否安全，互相推诿等等。但如果你掌握着系统知识，就必须果断决策。说“我要执行 X”，停顿三十秒，然后立刻动手。虽然通常来说让强势的管理者在事件会议上犹豫不决是弊大于利，但在这个特殊场景下反而可能有益——因为高管们非常习惯对那些他们不完全理解的技术方案直接下令：“好了，现在立刻执行”。

成功解决突发事件能积累大量政治资本。许多刚开始轮值的新手工程师都会惊讶地发现，即使是极其简单的修复（比如“关闭功能开关”）也会让经理和高管们感激不已。这是因为突发事件是非技术领导层直面他们对技术掌控力不足的唯一时刻之一。当团队正常开发产品时，副总裁有充分自由主导进程、做出决策。但一旦发生紧急事件，他们只能干坐着，完全信任自己的技术人员能把大家从危机中救出来。这种处境令人不安，尤其对于那些习惯在工作中行使一定权力的人来说更是如此。

然而，仅仅总是能解决突发事件本身并不能建立持久的权力地位。这听起来有点反直觉。毕竟，如果你总能搞定所有问题，难道不是不可或缺的吗？问题在于，解决突发事件的工作几乎总是高度技术性，以至于高管们根本无法看清全貌。他们只知道问题解决了，却分不清你是付出了 heroic effort（英勇努力），还是只是做了显而易见的事。而且他们也无法将你的成功归功于自己（这是最可靠地说服VP和总监支持你的方式），因为修复突发事件本就是分内之事，最好的情况从一开始就根本没发生过。

如果你喜欢这篇文章，欢迎订阅我的邮件更新以获取新内容，或在 Hacker News 上分享它。

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

通过习题集学习事件响应 很难教会优秀的事件响应能力。对生产环境系统的深入理解至关重要，但如何建立这种理解呢？我的方法是观察系统在各类事件期间的行为——包括仪表盘、日志和指标——并确保我真正理解了所见的异常活动。下面我将虚构一些事件场景，请大家思考可能出现的问题。我认为这类练习特别有用，尤其是针对特定团队或系统定制时。继续阅读...