事故的人类代价与缓解策略

[InfoQ 首页](https://www.infoq.com/ "InfoQ 首页")[演讲](https://www.infoq.com/presentations "演讲")事故的人类代价与缓解方法

观看演讲

时长：

51:40

/presentations/incident-response-mitigate/en/slides/Ky-1780404177426.jpg)

概述

Kyle Lexmond 解释了如何应对严重生产中断所带来的高压环境。他讨论了缓解措施与根因解决之间的关键区别，并分享了自己在惊心动魄的事故房间中的亲身经历。他还分享了一些宝贵的运营策略，包括克服认知过载、建立无责文化以及优化系统以实现更快恢复。

个人简介

Kyle Lexmond 是一位几乎成为软件工程师的人，他在大学期间偶然通过闲聊了解到站点可靠性工程（SRE），这彻底改变了他的人生轨迹。他曾任职于知名公司（Twitter、Amazon、Facebook）和小型公司（CBSA、Kik），他喜欢构建经过优化且高效的系统——在他接手后这些系统故障更少。

关于会议

软件正在改变世界。QCon San Francisco 通过促进开发者社区的知识传播与创新，赋能软件开发。作为实践者驱动的会议，QCon 旨在为技术团队负责人、架构师、工程总监和项目经理等影响团队创新的人士提供服务。

INFOQ 活动

• /filters:no_upscale()/sponsorship/eventsnotice/34b23b6d-548d-473c-9ac7-ec2f8ca684b1/resources/1GuardsquareWebinarJune11-Transcripts-1777545596301.png)2026 年 6 月 11 日，东部时间上午 10 点

#### 重新思考应用安全：为何编译器级安全正在改变架构对话

主讲人：Anton Baranenko - Guardsquare 产品经理

• /filters:no_upscale()/sponsorship/eventsnotice/7dd71c7c-4b0e-4760-b97d-232ac1816637/resources/1NeuBirdWebinarJune25-Transcripts-1777458459989.png)2026 年 6 月 25 日，东部时间下午 1 点

#### 构建自主可靠架构：将 AI 融入可观测性栈

主讲人：Justin Griffin - NeuBird AI 产品负责人

• /filters:no_upscale()/sponsorship/eventsnotice/0b46c1f1-7263-457d-82d9-12be6fa07fbd/resources/1DatadogWebinarJuly9-Transcripts-1779204853394.png)2026 年 7 月 9 日，东部时间中午 12 点

#### 人工智能时代日志的再思考

主讲人：Nicolas Jung - Datadog 日志产品经理

字幕

Kyle Lexmond： 我相信我们大多数人，如果不是全部，都听说过十月的 AWS 故障，或者几天后的 Azure 故障，或者周一的 Cloudflare 故障。我只想让你回想一下，在那些供应商云故障期间，你做了什么？你受到了怎样的影响？你当时是否在值班？是否被拉入了自己的事故管理流程？我想有些朋友可能能说：“好吧，这只是供应商的问题，我们只能等待。”另一些人可能则会说：“我们有灾难恢复策略，让我们应用它们并切换到其他地方。”我只是想让你回想一下当时的感觉。然后想象一下，相应供应商的事故处理过程是怎样的？

我是 Kyle，我在 Meta 担任生产工程师。我会稍微惹恼公司的招聘人员，因为我扮演的角色大致相当于 SRE 的角色——他们对此非常讲究，但请把我的角色理解为一名 SRE。今天我想谈谈事故，特别是那些给你留下深刻印象、久久难以忘怀的事故。

我将更多地关注事故中的人性化方面，并分享一些我所看到的东西，这些东西能让经历或生存一场事故变得更容易。我在科技行业工作已久，从 2010 年开始靠做技术工作谋生。我在 2013 年进入 Twitter 开始从事 SRE 工作，见证了大量事故。在准备本次演讲时，Lorin 让我描述一下在重大事故现场的感受。我不确定能否完全成功，但我一定会尽力而为。今天的演讲聚焦于我个人经历过的各种事故。我首先会向你们介绍我对事故的一些观点——这些观点源于我的经验。接着我会带你们回顾两个事故案例，试图传达那种身处事故现场的感受。最后，正如我之前提到的，我会分享一些希望能让经历事故变得更轻松的方法。本场演讲将不包含任何数字、日期或公司名称，除非这些信息对正面意义而言。部分原因是公司本身并不重要。正如我所说，我专注于事故中的人性化方面。我希望更多谈论时间线和我个人的经历。

什么是事故？

首先，你如何定义“事件”？我个人认为，“事件”这个词有点过于沉重了。不过，我必须承认，如果在发生事件和不发生事件之间做出选择，我会更倾向于不发生事件。话虽如此，作为 SRE 的典型代表，我通常可以引用《Google 站点可靠性工程》这本书作为大多数问题的参考文献[cite: 1]。当我准备这次演讲时，我心想：“他们肯定对‘事件’有明确定义吧？”结果让我惊讶的是，他们并没有给出“事件”的具体定义——这似乎更像是那种“当你看到它时，你就知道它是事件”的模糊概念。对我来说，构成一个事件的三个因素是：第一，这是一个影响业务的事件；某个指标正朝着错误的方向剧烈变动。第二，这个事件需要立即响应。要么该指标是一个早期预警信号，你需要尽快介入修复，以免情况恶化；要么某个高管说过：“这个事情需要监控，一旦低于某个阈值，就必须处理。”第三，事件必须被缓解，以阻止其影响并让一切恢复正常。对于刚接触事件的新手，我想特别指出，最后一点至关重要：你不是在解决问题本身，而只是在缓解影响，让客户感知不到影响。我要说，这与我真正关心的事件有所不同——这是一种非常企业化的定义，即整个业务都关心事件的发生。对我个人而言，我关心的事件还有一个额外因素，那就是我或我的团队需要负责去缓解它。

关于事件的个人观点

这引出了我在“身处事件现场”这一部分的第一个观点。你在事件中会感受到巨大的压力。我对事件的区分本质上取决于我感受到多少压力去缓解它。粗略地说，你可以把这种压力理解为：压力大小与事件严重程度以及我是否需要亲自去解决它成正比。这种压力来自多个方面：首先是个人荣誉感，“我的服务宕机了，不行，我得赶紧去修复！”其次是职业层面，其他人依赖我的服务，而它现在不可用，我不想让他们失望，我应该去修复它。还有公司层面的压力——重大事件对公司形象通常是不利的。这促使我得出自己的论点：为什么我关心事件，因为我对此负有责任。

我喜欢认为自己认真对待事件。这在一定程度上出于自我利益——我相信任何事件背后都有值得学习的地方，尤其是在我对自己系统认知模型的理解上。在当前条件下，系统是否按我预期的方式反应？如果是，太好了，我有了更具体的证据；如果不是，那我就必须更新我对系统的认知模型，使其匹配现实发生的情况。另一方面，这也是专业精神的一部分：从商业角度讲，是的，事件对业务来说看起来很糟糕，但我的服务内部和外部都有很多人依赖它。我希望尽可能让别人的日子过得更好，而我的服务宕机显然不会带来这种效果。我预计大多数人也会出于类似动机关心事件。

我也认为你的动机会随着时间推移而改变。作为一名刚毕业进入行业的新人，我更多地将压力放在个人荣誉感上——比如，“我的服务宕机了，不行，我得登录检查一下。” 这种心态很容易导致我本人的倦怠。随着我职位越来越高，这种源于个人荣誉感的压力在我心中的比重逐渐减轻了。

身处事件之中

基于以上思考，我现在要转向讨论实际身处事件中的体验。正如你可能猜到的，既然我提到了压力，那么压力将是贯穿整个事件的主要体验。在高压环境下，你会感到紧张、焦虑，思维也容易变得混乱。回想一下云服务中断的例子：如果你亲身受到影响，你当时的感觉如何？再想想供应商的战情室里，他们的氛围又是怎样的？无论怎样，在事件响应过程中，你的首要目标始终是“缓解”——让事件的影响中止。你会不断思考诸如：系统是如何运作的？有没有功能开关可以关闭故障的功能？如果另一个你所依赖的系统崩溃了，能否绕开它？你最快能在多长时间内让客户不再受到任何影响？最关键的是——你能否在众目睽睽之下、高压状态下完成所有这些操作？

事件一：持续过载

我们来谈谈第一个事件。这个事件实际上塑造了我对事件管理的看法，原因有两个：一是它发生在我的职业生涯早期；二是当时出现了很多问题。背景信息如下：这是一个支持某款产品运行的服务，该产品每秒处理数百万次请求（QPS）。我的服务可以关闭而不影响主服务的可靠性，但用户体验会明显下降。我的故事始于清晨九点——这很重要，因为这一次我是东海岸时间，正在朋友家做客。大部分团队成员和当班人员都在温哥华或西海岸。我通过 IRC 收到一条警报通知。那时我还是个初级工程师，仍专注于系统本身，此刻我正处于清醒状态。

不一定非得请事假，但可以说：如果我上班，那这一天就算作工作日，就不必再请事假了。早上我在线上，也在 IRC 上。看到警报来了，我知道轮班人员马上就要被叫醒。那我为什么不先帮忙处理一下，看看情况如何？我过去调查，发现大约一半的机器在某个可用区（AZ）都宕机了，看起来像是断电了。我知道怎么解决——我们有相应的操作手册。我把它拉出来开始执行。一小时后，我已经按照操作手册完成了所有步骤，但那个 AZ 又在修复完成后约五分钟内再次失败。我再试一次，结果还是一样。这是第三次发生了。显然，这根本不是电力问题。这时候，我说：“这很可能是一起事故，我们得正式宣布。”因为是事故，大家就会在我们的事故仪表盘上看到它，然后陆续有人加入进来。

我们有内核团队的人，也有自动化团队的人，大家都在深入排查。我们检查服务器上的 dmesg 日志，为什么这些机器会关机？内核日志里有没有线索？指标数据中有没有显示某一点之后它们突然消失、停止上报？在那之前它们在做什么？我们开始挖掘，试图搞清楚是什么让这些机器与众不同？为什么只有这些机器出问题？我们当时没有意识到的是，这个问题其实正在扩散。故障机器的数量大致保持稳定，但具体是哪些机器在出问题却不断变化。

一个小时后，我面临时间压力，必须赶去机场。与此同时，轮班人员也陆续加入进来，问我各种问题：“到底发生了什么？”“我们在做什么？”“为什么会这样？”我们还在继续排查问题。

并没有一个明确的交接时刻。我正走向地铁站，手机拿出来，一边看 IRC 里的最新消息，一边回复别人。穿过隧道时网络暂时断开，等重新连上时，十分钟后我才收到剩下的 IRC 消息，发现还有好几个需要回复的问题。你可以看到这里的时间压力有多大。我正在赶路，还得过安检，赶飞机。此时轮班人员还在说：“你已经在这次事故里待了90分钟了，进展在哪里？我们还没任何进展，还在原地踏步。”

快进一会儿。我通过了安检，到了机场，航班即将登机广播响起。此刻我穿着牛仔裤。

越来越多的人加入了会议，试图弄清状况。影响范围已扩大，越来越明显。我甚至到了要亲自去航空公司柜台，对工作人员说：“非常抱歉，我正在进行一场极其重要的电话会议，能不能帮我取消登机手续？”几年后，我和一位同事聊起这次事故，回忆往事，他记得我当时确实是在机场。我心想：“是啊，这么多年过去了，我还好奇那位值机助理当时是怎么想的？她会不会觉得我是个疯子？希望我不是唯一一个在安检后走到她面前说‘对不起，我有个电话，麻烦取消登机’的人。我可能永远都不会知道，也再也不会见到她了。”

多年后，这件事仍是我记忆中最鲜明的例子之一——那些在事故中留下深刻印象的小细节，总会在脑海中浮现。至于事故本身，我们依然没有解决问题。现在我们意识到，这不只是单个 AZ 的问题，而是整个区域内的多个 AZ 都受影响。更令人惊讶的是，我们还有三个其他区域也遭遇了同样的问题。此时我们不断引入更多人手，试图搞清楚到底出了什么问题？为什么会这样？

鉴于已经加入的所有人，我现在只能坐在旁边观望了。虽然我仍是第一个响应者，所以还得继续回应大家的问题，比如：“是的，不，我们几个小时前在这里试过这个方法；我们也尝试过修复那个自动重启机器的脚本，因为当时机器太多导致速率限制；我们一小时前已经解决了这个问题。”

我仍在做些协调工作，把大家和我们之前做过的事情联系起来。又过了两个小时，我已经筋疲力尽，心里发慌。从第一次警报触发到现在，已经过去六个小时了；从我宣布这是个事故到现在，也已经五个小时了。我们仍未解决问题。目前的成功率徘徊在40%左右。我们现在已经理解了症状——这是滚动式过载，新上线的服务器恢复后又被压垮，因为流量负载太大。但我们还不知道根本原因。

我至今最清晰的记忆，就是那时我坐在机场的长椅上，心想：“我们可是这套系统的专家啊！”

我们这里有参与系统构建的所有人，可我们连系统的基本原理都不太懂，根本不知道哪里出了问题。这就是我至今仍无法忘怀的那个瞬间——那一刻我问自己：“我们该怎么办？”人们开始讨论“核选项”——这是一种极端手段。这是一个滚动式过载问题。我们尝试降低负载、防火墙隔离、拒绝客户端请求……但都没用。系统没有恢复迹象。

这里的“核选项”就是直接关闭服务，完全屏蔽所有请求，然后重启服务，再慢慢解除防火墙。但在分布式系统中，这种“缓慢解除防火墙”的方式极其敏感，让人难以信任。既然如此，是的，这确实是终极方案，但大家还在思考：有没有更好的办法？

我们能做什么？现在是时候把各种方案往墙上扔，看看哪些可能真正解决问题，再决定是否采取最终措施。快进两个小时后，我们几乎已经放弃。我们已将两个区域隔离并重新启动，但它们都失败了。此时，事件负责人说：“我们必须做出抉择——要么继续，要么停止。我们必须解决这个问题。我们尝试过增量式修复，但都没奏效。”就在毫无预兆的情况下，一位原系统编写者、后来转岗又被拉回本次会议的人（因为他对系统部分架构仍很熟悉）突然有了一个想法。他去调整健康检查机制，说：“好吧，就始终报告‘健康’状态，不要说自己过载，也不要报告任何其他内容，只持续声明自己是健康的。”这样就能强制流量均匀分配到各台机器上。

直到今天，我依然不知道他是如何想到这个办法的。也许他翻阅了另一份事故报告，发现谷歌曾有过类似事件，并从中找到了解决方案：“这和我们遇到的情况非常相似，他们是怎么解决的？他们这么做的。我们试试看吧。”这或许就是发生的事。也可能是因为他对系统足够熟悉，只是在事件进行到半小时时才被拉入会议，从而突然灵光一现。不管怎样，无论他如何想到这一点，我们花了大约15分钟实施修复方案：推送代码、触发自动部署，然后五分钟后就开始看到恢复迹象。那时我仍在机场长椅上，筋疲力尽地瘫坐着，心想：“终于结束了，谢天谢地！”虽然还有很多清理工作要做，但重点在于——我们成功遏制了此次事件。

我们能够达到这样一个节点：可以说问题基本解决了，下游用户不再受影响。我们的成功请求指标开始回升至100%。我们宣布事件已被遏制。所有人松了一口气：“好啦，这场八小时的噩梦总算结束了，明天早上再处理吧。”事件在夜间得到控制。我终于登上了刚预订的新航班，我想那可能是机场最后一班离港航班，而回到家时我已经累得不行，第二天上午十一点才肯起床睡个懒觉。这正是长期事故带来的身心代价的缩影——高压环境下的生理反应。回顾这次事件，从开始到遏制阶段的过程，最突出的问题就是压力巨大。

对我而言，这次事件最显著的特点是：作为服务所有者，我们几乎被自身的混乱所麻痹。六个小时过去了，问题仍未解决，我们不禁怀疑：“我们是不是都在演傻瓜？我们真的懂自己在干什么吗？”确实有几个地方本可以做得更好。我是第一响应人，这没问题，但我同时还要兼顾多项任务并调查问题。我应该做的，是明确指出：“情况显然越来越严重了，我们有专业的事件经理，请把他叫进来，让他负责协调分工。让其他人专注沟通联络，而不是继续调查。”我也表现出了所谓“沉浸于当前任务”的典型特征——完全忽略周围环境，缺乏态势感知能力。我没有意识到不同服务器正在相继宕机，也没有察觉另一个可用区（AZ）也在崩溃。我倒是注意到另一个区域失效了，但那也只是因为有人提醒我说：“两个AZ已宕机，第三个也快挂了！怎么回事？”我才恍然大悟：“原来问题蔓延开了！为什么我没意识到？”我失去了对整体局势的掌控。此外，我还承受着巨大的时间压力——必须赶去机场搭飞机。我本应主动交接给值班人员，明确说：“我现在要撤了，这是目前进展，接下来你接手，赶紧拉更多人进来。”我也未能及时、充分地向上级汇报，导致关键人员迟迟未加入事件处理。如果我在事件发生的头两小时内就把系统原始设计者拉进来，那么45分钟内就能找到解决方案——这场八小时的事故会不会就此避免？我倾向于认为答案是肯定的。可惜，我永远无法知道真相了。

另外，在整个事件过程中，当值的值班人员曾问：“我该不该再拉更多人进来？”当时大家一致回答：“是的，你应该这么做！为什么不默认这样做呢？如果你搞不清楚状况，就要果断拉人进来，尽快搞清楚发生了什么。”另一个问题是缺乏共享状态信息。我经常花大量时间回应别人：“是的，不是，我们90分钟前试过这个方法；两小时前也试过那个方案……这是最初的状态，现在降级成了这样，这是趋势图。”

每次新成员加入事件会议，我们都不得不快速复述当前状况。最后，在所有这些经历中，我要特别强调的是：对参与应对的人们保持同理心。正如我所说，这是我第一次经历重大事故，也是第一次遭遇如此漫长的事件。我们根本不知道发生了什么，甚至直到五个小时后才弄清楚原来是滚动过载现象。你可以反驳说：“是的，我们本该早点发现。”但当时我们正忙于调查各种可能性，没有清晰的根因，直到人们能把零散数据点串联起来，才能得出结论：“这就是发生的事情，这就是我们看到滚动过载的原因。”这就是第一个事件的核心：高压、高压力。即使到现在，我的心率监测器仍然显示心跳飙升。

事件2 - 指标失败，负载均衡流量

让我们继续谈谈第二起事件。这起事件有点有趣，因为我间接导致了这次事故。好消息是，它的发生时间线要短得多。这件事发生在第一起事件数月之后。我有所进步，更清楚该怎么做。在开始之前，我批准了一位团队成员的拉取请求。我们正在尝试在不同框架之间迁移。这次迁移是我们六个服务中的最后一个。我们已经成功完成了五个，这是第六个。我们做了大量准备工作，而这次改动只是几行代码就能完成切换。

我看了看，心想：“是的，这是个老框架了，我们不再熟悉它了。很可能哪里会出问题。”

我们唯一知道它出了问题的时候，就是有人联系我们。我当时的想法是：肯定会有某个依赖于这个框架某些细微行为差异的人。我们已经做了测试，一切看起来正常。前五个都没问题，那就继续吧。我有点先见之明。同事提交了PR并合并了他的更改。Kubernetes自动部署器抓取了它并应用了变更。大约10分钟后，全球负载均衡团队宣布发生事故，因为他们在区域间分配流量所使用的指标突然消失了——不是显示为零，而是完全停止报告。这意味着什么？在他们的系统中，这意味着退回到默认值。

现在有些区域流量过载，有些区域却空闲无事。他们开启了一起事故。我现在已订阅了公司内部的事故通知频道。我看到了事故通报，心想：“这是相邻团队的事。”听起来像是我们刚刚迁移的服务框架。会不会是我刚批准的那个PR引起的？我加入事故聊天频道，链接了那个PR，并说：“我打算回滚这个变更，以防万一。” 一段时间过去了。这里有个糟糕的地方：我实际上无法自己回滚这个变更。工具链发生了变化，我不熟悉新工具。我尝试了一下，但毫无进展。我回到事故聊天频道，请求帮助。不幸的是，消息太多，我的请求被忽略了。

之后，我查看了一下，发现这个人我认识。他大概在源码控制领域工作。我在下一条消息里@他：“@person，能帮我回滚这个PR吗？” 太棒了。他成功处理了此事，推送了回滚变更。再次，我们的自动部署器抓取了这个变更并应用了它。系统恢复正常。我们完全化解了危机。整个过程不到半小时，我们就从检测到事故声明、被拉入协助，再到解决问题，一气呵成。这里仍有一些地方可以做得更好。在这次事故后的立即阶段，其实造成了相当大的内部中断。西雅图生产工程团队甚至下令让写PR的人和我，为我们各自最爱的饮品下单，并送到我们家里。

这确实是一个凝聚团队情感的时刻——很多人受到了影响，大家团结在一起。我们意识到，至少部分责任在于那些造成事故的人，我们要对他们表现出同理心。好的一面是，除了我未能及时回滚PR之外，这次事故实际上是个正面案例。从响应速度来看，他们检测问题非常迅速，事故声明也非常快，而且正确的人被及时拉入（无论是通过监控聊天还是适当升级），整个过程很快。虽然不是最快解决的事故之一，但在30分钟内解决算是相当不错了。事后，全球负载均衡团队回去调查了自己的系统，思考如何提高对这类故障的韧性：我们该如何避免在这种情况下失败？我们是否应该保留上次看到的值并发出警报？

这一决策源于他们在事故复盘期间自行进行的调查。他们并没有简单地认为“那个团队改了框架，他们需要修复”，然后就等着他们自己去修。不，他们主动调查了自己的系统，因为他们能够明确地说：“这个系统没有按我们预期的方式运行。我们该如何让它按我们期望的方式，或者更准确地说，按我们想要的方式运行？” 我把这作为一次正面事故案例引用，因为在三周后，类似的事情再次发生——这次指标又消失了，但不是我的团队。他们收到警报：“出问题了！” 幸运的是，由于他们在从审查到下一次事故的时间段内，优先处理了所需变更，完成了开发并上线，最终一切顺利。

我认为这就是我们希望从事故中吸取的经验教训：每一次事故都是一个学习机会。如果我们愿意投入时间和精力去探究：“我们能从中学到什么？” 那么我们就能改进系统。

让事故生命周期更美好

进入第三部分，如何让你的事故处理过程更顺畅？首先，我们来谈谈在事故发生前可以采取哪些措施。我将介绍一个叫做“瑞士奶酪模型”的概念——系统中存在多层防护机制，其设计初衷是：即使某一层防护失效或出现故障，下一层仍能起到保护作用，避免整个系统崩溃，并防止影响他人。我最喜欢的事故类型，其实是那些根本不会发生的事故——因为我们提前识别了潜在风险，主动思考：“我们该如何设计系统，让这类事故从根源上就不存在？”我们的基础架构和工具本身就能杜绝此类事故的发生。

然而，有些问题无法通过设计彻底消除，这时就需要引入“瑞士奶酪模型”，思考我们还能增加哪些防护层。

单个防护层本身不足以覆盖所有风险。核心思想在于构建多重防护层，从而确保任何单一故障都不会造成系统性影响。这更多是一个系统设计层面的问题：你希望系统具备怎样的容错能力？预期会遇到哪些类型的故障？能否快速恢复？比如，在数据进入系统时，你可能会想：“如果指标数据突然失败怎么办？”你可以先思考更宏观的问题：我们从哪些外部源获取数据？如果这些数据损坏或缺失，系统该如何应对？这样你就能判断出哪些情况需要特别关注并制定应对方案。

我也要指出，多重防护确实会增加系统的复杂度。那么，当“复杂度”与“韧性”之间需要权衡时，你究竟该选择哪个平衡点？某些情况下，我会建议有意识地管理风险。例如，去思考你的数据来源有哪些？如果这些来源失效会发生什么？不要只盯着具体的接口或数据入口，而是先从宏观类别入手思考。我个人发现，这种方式能帮你捕捉到更多潜在问题——尤其是那些你原本没意识到自己正在处理的数据来源。你需要深入代码库，梳理清楚到底有哪些数据在流动。

同时，也有一些工具可以帮助你理解系统内部的数据流。这些工具通常因公司而异，取决于你们如何实现自己的系统架构。回到第二个事故案例，这类问题往往只有当你主动、有意识地思考时才会被发现。你要问自己：我获取的是什么信息？从哪里获取？如果数据异常或失效，又该如何处理？思考系统的边界——你调用了哪些外部服务？几周前我经历的一个事故就是如此：某个模块本不该失败，但我们的代码没有真正保护它。或者更准确地说，我们假设远程服务可能失败，于是加了一个 try-except 包裹。结果却漏掉了某个异常——这个异常触发后直接导致系统崩溃。事后我们回看才发现：“等等，为什么我们没捕获这个异常？”

这其实属于另一类错误。部分原因是技术债积累已久，也有一部分是我们根本没意识到这个问题的存在，因此感到意外。这就要求你对系统要有相当程度的理解。这也是权衡的关键所在：我们当初确实没有跟进那个迁移任务，现在不得不为此付出代价。这种权衡也是经济性的体现——不可能为每一个可能的风险都部署防护措施。唯一例外的情况是：你拥有无限资源——无限的时间、人力、预算，且没有任何截止日期。只有在这种理想条件下，你才能实现“绝对可靠”。作为系统的所有者，你需要决定：什么时候才算“够了”？

聚焦于最关键的部分：你最有可能遇到故障的地方在哪里？集中精力解决这些关键点。

另外，在事故发生前，还应移除那些鼓励人们隐瞒事故的激励机制。这源于我在不同公司的工作经验：有些公司对事故持非常负面的态度——“绝不能申报事故”，或者“一旦申报事故，你半个季度的奖金就会被扣掉”。那团队里还有谁愿意主动报告事故呢？答案是否定的——所有人只会说：“这只是个 bug 修复。”成功率百分之零。你只需要打个补丁就行。这种思维模式显然适得其反。

首先，你需要申报事故，以便吸引相关人员参与进来——特别是早期介入。如果你在值班，最好设置 SLI（服务级别指标）。当某个阈值被突破时，系统可以自动触发事故声明，并拉取更多人手共同调查：“SLI 被突破了，肯定出了问题，我们一起来排查原因。”

有时你只是偶然发现一些异常现象，这时候也需要判断：“这算不算事故？”进行简短调查后，再决定是否真的需要启动事故流程。在 Meta，我的团队曾尝试推动一种理念：开放事故比不开放更安全——让更多人的眼睛看到问题。如果最终判定这是一个误报，我们在事故管理系统中专门设有一个选项：“标记为误报”，并附上说明：“这是我们最初认为是事故的原因，但实际上并非真正的事故。”

那里存在大量的认知安全。就像我们知道自己声明事件不会受到惩罚，那么为什么不在那时就声明事件呢？我已非常具体地在团队内部推动了这一点，因为我相信，将事件作为协调枢纽的实用性是无可比拟的，因为其他团队可以这样说：“好吧，那边有个事件，可能影响到我们的团队。如果他们有事件，那大概就是这个原因，我们去问问他们”，而不是第二支团队自己进行调查，然后再回到我们团队时，发现“出了问题”。这其实归结于协调方面的问题。你应该明确划分事件中的角色和职责。正如我之前提到的，在我的第一个事件中，我喜欢的一点是有一个专门的事件经理，但我们没有及时、充分地升级，以便能尽早拉他们进来。

他们只参与高严重性事件。我们本该做的，是当影响范围扩大时，立即把他们拉进来。他们的专职事件经理角色能够减轻我的负担——我不必再反复回答诸如“是的，不，我们已经做过这件事”之类的问题。他们能代表我们接受其他团队的问题，比如：“这会影响你们吗？我们会把它加入事件管理。” 作为响应者，我不必再去思考这些事情。这也引申出另一个观点：在事件期间应共享信息。这再次印证了我的协作观点——协作有助于应对事件。尽可能多地协作，分享你所看到的数据。其他人可能会因此获得关于事故原因的想法。

我见过的最佳例子就是 Google Docs 或其他平台上的实时协同编辑界面。当你正在做某事时，只需在文档里留下一个简短备注：“这是我看到的情况。这是仪表板链接。我认为目前发生的是什么。接下来你要做的调查是……” 简洁明了，20秒内完成，这样人们就能说：“这是最新进展。我们现在要去哪里。” 这对将来回顾事件也非常有帮助，让你理解自己做了什么、为什么这么做、为何成功或失败。我还想强调一点：指责不是这个过程中有用的部分。那个惩罚开启事件的组织，是的，我发现人们通常并不是有意要搞砸工作。

基于像“X号人员提交了这个 bug，破坏了我们的系统”这样的理由来分配责任毫无意义。在事件过程中纠结于如何责怪他们，只会浪费本可用于解决问题的时间。你可以使用事实陈述，例如“这个 diff 被部署了，并导致了故障传播”。必要时，无需提及具体人员。在事件回顾中，某人做了什么事通常不如系统为何允许这种情况发生的根本原因重要。你不能指望人类总是百分之百准确。你必须承认“人为错误是预期之中的”，那么该如何防范它？

最后，在开头我提到了《Google SRE 手册》[cite: 1]。这本书涵盖了大量相同的内容。如果你想了解更多，这是我迄今为止找到的最佳公开资源，特别是关于“管理事件”的章节，其网址为：sre.google/sre-book/managing-incidents/[cite: 1]。

总结

综合以上所有内容，我现在将总结一下我对事件处理的方法。我会直接说明，我的目标不是零事件，而是零高严重性事件。在事件发生前，我们每半周期都会进行系统审查，比如：“哪些依赖关系发生了变化？”或者“我们能否改进系统？” 我设定了一个健康的值班期望：收到的警报信号强、可操作性强，我们拥有实际可用的操作手册（不只是指向维基页面的死链接）。我们已经建立了一些阈值，使事件声明自动触发。我仍在完善这部分，但正逐步实现。

这对新加入团队的人尤其有帮助，他们不一定有足够的信心主动说：“这是一个事件，我要开一个。” 最后，一般情况下，鼓励整个团队订阅事件通知，尤其是高严重性事件，即使它们并非直接来自合作团队。在事件过程中，如果任何预期被违反，我会记下待事后修复的问题，确保不会丢失这些信息。如果是我在开始值班时发生的事件，我会在团队聊天频道中发布一条消息提醒大家。如果我不确定发生了什么，我会向我认为了解情况的人升级。

如果存在影响超出当前边界（如某个 AZ）的风险，我会升级给值班的事件经理，告知他们：“这可能会变成更大的事件，我们需要拉入更多人。” 最后，如果我们需要超过三个人参与，我会确保建立一个共享文档，让每个人都能记录自己的信息、想法、数据点等。理想情况下，我会请别人专门负责更新文档，而非直接参与调查本身。

我还想快速补充一下重复事件的问题。这通常是值得特别关注的具体案例。我发现，这通常意味着系统中的某些部分你并未完全理解。

这是系统中一个值得重新审视的部分，特别是如果你的任务待办列表里有需要去修复的问题。此时正是应用“此类事件绝不能再发生”这一驱动开发原则的关键时刻。当你观察他人的事件时，请记住自己过往经历中的教训，或借鉴我的经验，并对正在响应事件的人们抱持同理心——因为事后显而易见的事情，在当时往往并不清晰。

我期望我们能朝这个方向努力。我在团队语境下曾提及过这一点：我的团队在过去九个月里规模翻了一倍，新成员已加入团队，但尚未完全建立起有效的值班响应机制。部分原因在于文化层面。

这将是一系列内部培训活动，我会鼓励大家打破“不愿开启事件”的习惯。在这里，没有惩罚，不必担心。我们也会组织一些内部培训，比如“厄运轮盘”，通过回顾过去的事件（例如当收到告警X时发生了什么），帮助新人熟悉值班流程和我们所负责的服务。

关键要点

我希望你带走以下三个要点：

第一，事件本身并非必然糟糕。我认为我已经谈得相当充分了——它们可以是学习机会，也足以支撑我们重新调整部分工作的优先级。

第二，你的事件管理流程应高度聚焦于“缓解措施”。任何对该流程的改进都应以缩短“缓解时间”为目标。

第三，尽管如此，始终要记住：我们终究是人。请记住，回应事件的是人类。考虑他们承受的压力，不要给自己或他人增添不必要的压力。

问答环节

参与者1： 我喜欢你们采用的“瑞士奶酪模型”，但我很好奇：你们是否在测试自己的假设？是否使用某种韧性测试来验证这些假设，确保这不是空想？

Kyle Lexmond： 最简单的方式可能是说，我们将其中一些测试编码为集成测试，或将部分测试纳入我们的集成测试框架。我们有一个内部框架，试图实现某种特定术语的功能——本质上就是声明某个依赖项，然后在集成测试中切断网络访问，从而检验当该依赖不可达时会发生什么？系统能否优雅失败？我们是否有效测试了在类似故障场景下是否达到预期结果？除此之外，我们并没有做太多这类工作。大部分仍停留在系统设计层面，我们会说：“好吧，让我们更深入地思考整个系统。” 我希望有一天能达到这样的境界——在我看来，AWS在这方面是行业标杆，他们能够明确地说：“是的，我们已经将实现简化到某个具体的解决方案，数学上证明我们不会再出现此类中断。”

我个人认为，我们还达不到那个水平。这取决于投入多少精力与获得的收益之间的权衡。如果某项技术是在Meta内部得到良好支持的，那可能会改变我的看法——比如，如果存在一个被内部广泛支持的方案，我们大概率会采纳它。

参与者2： 我的问题是关于你在第一次参与事件时的经验，以及那次影响范围巨大的事件通常会吸引大量关注，意味着沟通渠道众多、直接消息频繁。你从这次经历中学到了哪些方法论，用于判断优先与谁沟通、当前最应优先处理哪些响应？

Kyle Lexmond： 最简单的做法就是在事件过程中亲自实践。在宣布事件前，我会直接向相关人员发送消息——一部分是在团队群聊中，另一部分则是通过一对一或小群体私聊进行。我们只是把讨论限制在这些小范围内。一旦宣布事件，系统会自动创建一个事件频道。此时我们必须有意识地将所有正在进行的沟通转移到这个事件频道中。我还想强调一点，我们原本预期所有沟通都会集中到这个事件频道。这也是共享文档和事件管理工具发挥作用的地方——它们可以帮助追踪进展。同时我也曾在此阶段表现不佳，比如有人提问时，我会回答：“是/否，你进来问这个问题。我们之前讨论过五页内容，请回滚查看这里，点开这个链接。” 这部分是我当时做得不够好的地方。现在我觉得自己处理得更好了。

参与者3： 你提到要建立一种更开放的文化氛围，让人们不再犹豫是否开启事件。那么对于相反的问题——即人们会为了修补Bug或甚至提出新功能请求而主动创建事件——你有什么建议？如何应对这种情况？你对此类问题的哲学立场是什么？

Kyle Lexmond： 我的理念是，谁是事件负责人？如果另一个团队有一个他们想部署的修复补丁，他们不能创建一个事件并将其分配给我方团队。他们必须自己拥有该事件，并将我方团队作为协作团队拉入其中。具体操作方式是，他们必须在自己的空间内为自己的团队创建事件，他们仍然是事件负责人，然后他们会拉入我方团队的值班人员，例如：“我们这个服务使用了此 PR，需要紧急修复漏洞。” 我方团队的值班人员可以接收请求并采取行动。他们不需要跟进后续工作，比如无需提交事件报告；理想情况下，如果修复失败且需要再次处理，也不必再分配任务。

我们回到那个团队时，可能会听到类似“这怎么搞坏了？”的质疑——这在官僚层面会引发一些反弹。你希望事情这样发生，就必须完成必要的流程手续。实际上，这种情况很多时候表现为“误报标签”（false positive tag）。大多数严重性级别从 1 到 3 级，1 级是最严重的。我们还设有一个 SEV-4 级别——看到它你根本不必在意，颜色是灰色。这是低风险级别，我们用它作为协调事件。这并非坏事，我同意如果频繁创建事件可能确实是个问题。我发现的解决方案很简单：如果有任何额外开销，就把它推回发起事件的那个团队身上。

参与者 4： 我是一名事件经理，主要负责接收信号并协调多个团队解决问题。我注意到的一个主要问题是，当我选择某个服务（比如某个应用崩溃）作为故障点时，通常那个团队其实无事可做——因为后端或跨职能团队的问题导致了故障。我常收到的反对意见是：“为什么我的应用出现在故障列表里？我根本没做任何事。” 我必须这么做，因为用户不会去检查数据库或机器——他们会直接寻找应用。这是一个大问题：我必须选择应用作为故障点，但实际修复是由其他团队完成的。即使我们查看报告，出问题的团队也不会出现在指标中。这在整个行业都是个普遍问题。您有什么建议来优化这个流程吗？

Kyle Lexmond： 我的第一个想法是，是否有可能改进这些指标？你可以指出：“我们向这个服务发出了多少次请求？成功响应了多少次？” 因为其他团队可能没有 SLI（服务等级指标），他们甚至不知道自己的服务已宕机。你可能只使用了他们服务中的一个小组件，而他们的成功率是“九个九”，你恰好是那缺失的“第十个九”。这最终归结为能否说清楚：“我们的监控显示这个服务有问题。你们的服务呢？请提供你们正在监控的指标。你们能去修复它们吗？” 这就需要两个团队的管理层合作沟通：“这是我们看到的情况，这对我们的系统造成了什么影响？能否把相关指标加入你们的 SLI？” 很遗憾，我没有更好的答案，除了让双方管理者直接对话。

参与者 5： 您如何看待管理领导层或领导沟通的一般经验？您对此有何体会？

Kyle Lexmond： 高管层介入任何事件都令人担忧——立刻带来压力、压力、压力。但这并不总是坏事。如果某次事件足够重大以至于高管亲自到场，我会立即要求事件经理去和他们沟通。如果我是事件经理，我会主动去和他们谈。此时，我不应再专注于调查，而是应该处理他们的请求。这也是我建议的做法：我会私下与他们沟通，而不是让他们在主事件聊天频道发言。

查看更多 [带字幕的演讲](https://www.infoq.com/transcripts/presentations/)

录制于：

2026 年 6 月 2 日