事故沟通：故障当下的对话方法

• 引言 — 恢复只是一半的工作
• 事故指挥官 — 不亲自修复的人
• 状态更新的节奏 — 没有消息也要按点敲
• 三个问题 — 每次更新都必须回答的内容
• 不追责的事后分析 — 追究系统，而不是人
• 5 Whys — 从症状到根本原因
• 面向客户的沟通 vs 面向内部的沟通
• 镇定 — 语气决定房间里的空气
• 结语
• 参考资料

引言 — 恢复只是一半的工作

凌晨 3 点，寻呼机响了。支付 API 不断吐出 5xx 错误，仪表盘一片通红。你翻查日志，缩小原因范围，准备回滚。到这里为止，都是你受过训练的工作。然而这只是工作的一半。

另一半是对话。告诉团队现在发生了什么，理清谁负责什么，向客户传达情况，回答高管反复追问的「现在情况怎么样了」。做不好这一半，一场技术上 20 分钟就能解决的短暂故障，就会演变成拖上一整天的信任危机。人们各自握着不同的信息重复劳动，客户在沉默中想象最坏的情况，恢复结束后「到底发生了什么」这个问题还会被追问好几天。

本文讨论的正是那另一半。我们会谈到事故指挥官这一角色、状态更新的节奏、每次更新都必须回答的三个问题、不追责的事后分析与 5 Whys、面向客户与面向内部的不同沟通方式，以及支撑这一切的镇定。

事故指挥官 — 不亲自修复的人

在混乱的故障响应中，最先需要的是一位协调者。这个人被称为事故指挥官(Incident Commander，以下简称 IC)。IC 的核心是自相矛盾的。

IC 的工作不是修复故障，而是协调修复故障的人。

IC 一旦亲自抓起键盘扎进调试，协调者就消失了。于是没有人掌握全局，多个人重复追查同一个假设，也没有人向客户或高管传达情况。IC 必须保持双手空闲，才能做出决策、分配资源、掌管沟通。

有效的响应会清晰地划分角色。规模较小的故障中，一个人可以身兼数职，但角色本身在概念上应当是分离的。

• 事故指挥官(IC)：统筹整个响应的单一指挥者。做决策、分派任务、确定优先级。不亲自动手修复。
• 沟通负责人(comms lead)：负责对外和向上的沟通。状态页更新、客户公告、高管汇报，让 IC 和响应团队从沟通负担中解放出来。
• 运维/领域专家(ops, subject-matter expert)：真正动手诊断和修复问题的人。最了解该系统的工程师属于这一类。
• 记录员(scribe)：记录时间线。实时记下几点几分发生了什么、做了什么决定、尝试了什么。这份记录后来会成为事后分析的骨架。

这个结构的力量在于认知负荷的分散。如果一个人一边诊断问题，一边还要写客户公告、回答高管的问题，三件事都会做得很粗糙。分开角色后，每个人才能专注于一件事。而且所有人都必须清楚地知道谁是 IC。「现在由我来指挥」这样一句明确的宣告，能让十个人手忙脚乱的频道瞬间归位。

状态更新的节奏 — 没有消息也要按点敲

故障期间的沉默不是信息的缺失，而是焦虑的放大器。状态更新一旦变得稀疏，旁观者就会开始想象「是不是大家都放弃了」「情况是不是更糟了」。所以良好事故沟通的核心原则是这样的。

即便没有新消息，也要以规律的节奏更新。

这通常被称为鼓点(drumbeat)。根据严重程度定下 15 分钟、30 分钟、60 分钟这样的周期，并且遵守这个周期。即便在没有进展的周期里，也要说「仍在调查原因，暂无新进展」。这一句话传达的信号是「我们仍在这里，没有放弃这个问题」。这远比沉默更让人安心。

这里有一个决定性的习惯，就是明确说出下一次更新的时间并信守承诺。每次更新都以这样一句话结尾。

• 「下次更新在 14:30。」
• 「30 分钟后有进一步消息，最迟 15:00。」

这样一来，旁观的人就知道下一条消息什么时候来，也就不会在这段时间里不停刷新频道，或反复追问负责人「现在怎么样了」。而这是一个承诺。如果说了 14:30，那 14:30 就必须发出点什么，哪怕内容只是「仍在调查中，下次更新在 15:00」。一旦错过说出口的时间，你辛苦建立起来的信任就会开始崩塌。

三个问题 — 每次更新都必须回答的内容

面对空白的输入框不知从何写起状态更新时，只需记住三个问题。好的更新永远会回答这三点。

1. 我们知道什么 (what do we know) — 目前已经确认的事实。什么受到了影响，影响范围有多大。不要把事实和推测混在一起，只把确认过的内容当作事实来陈述。
2. 我们正在做什么 (what are we doing) — 正在进行的处置措施。正在验证哪个假设，已经应用了哪些缓解措施，下一步是什么。
3. 下次更新是什么时候 (when's the next update) — 前面强调过的那个承诺。必须包含明确的时间。

这三个问题之所以是个好框架，是因为它恰好就是旁观者真正想知道的全部内容。人们不需要堆栈跟踪或内部争论。现在情况如何、是否有人在处理、什么时候能再听到消息 — 只要知道这些，人们就能安心。

在分诊初期，快速确立「我们知道什么」尤其重要。举例来说，仅仅区分是 5xx 错误激增还是 4xx 激增，就能判断问题出在服务端还是客户端。当状态码的含义一时想不清楚时，手边放一份类似 HTTP 状态码 的参考资料快速查一下，就能避免朝错误方向浪费 30 分钟。

真实的内部 Slack 更新是这样的。它回答了全部三个问题，并钉死了下次更新的时间。

[事故 #4021] 支付 API 故障 — 更新 3 (14:05)

我们知道什么:
  - 自 14:00 起,支付授权 API 约 40% 的请求以 5xx 失败。
  - 原因已缩小到今天 13:50 部署的支付服务 v2.7.3。
  - 浏览、购物车等其他功能不受影响。

我们正在做什么:
  - 正在回滚到 v2.7.2(部署流水线运行中,预计 ~14:15 完成)。
  - 回滚后将监控授权成功率是否恢复。

影响:
  - 新的支付尝试失败或挂起。未观察到数据丢失。

下次更新: 14:20,或回滚完成后立即更新(以更早者为准)。
IC: 金英柱 / Comms: 李瑞俊

一旦这套格式刻进身体里，即便凌晨 3 点头脑昏沉，也能像填空一样写出更新。

不追责的事后分析 — 追究系统，而不是人

故障结束后，要写一份事后分析(postmortem)。这里最重要的原则是不追责(blameless)。

不追责事后分析的要点，不是找出犯错的人，而是追究让那个错误成为可能的系统与流程。如果一名工程师错误地部署了配置文件导致故障，该问的问题不是「是谁干的」，而是「为什么我们的系统会允许一个人的一次失误就击垮整个系统」。为什么验证环节没能拦住它?为什么错误的配置能如此轻易地一路到达生产环境?为什么回滚花了那么久?

这个原则之所以务实，靠的不是道德，而是信息的质量。在追责文化中，没有人愿意说出真相。一个人如果知道承认失误会招来惩罚，就会模糊时间线，隐瞒自己按下过什么，变得有防御性。于是系统真正的弱点永远不会暴露出来，同样的故障会在另一个人手中重演。

反过来，如果存在心理安全感(psychological safety)，人们就会诚实地表达。只有能坦率地说出「我执行了这条命令，我忽略了这个警告，我没有检查这一部分」，才能在那个确切的地方立起护栏。诚实的时间线只能来自心理安全感，而没有诚实的时间线，就没有真正的教训。

一份不追责的事后分析大致应当回答以下内容。

• 发生了什么：基于事实的时间线(记录员的记录在这里最能发挥作用)。
• 影响是什么：持续了多久，影响了多少用户/请求，以何种形式呈现。
• 为什么会发生：根本原因。是条件和系统，而不是人。
• 如何检测/响应的：哪些做得好，哪些慢了。
• 如何防止复发：具体的、有负责人和期限的行动项。

5 Whys — 从症状到根本原因

深挖根本原因的经典技巧是5 Whys(五个为什么)。这个方法源自丰田生产方式，做法很简单。从表面症状出发，反复追问「为什么?」，一层层下降到更深的原因。

举个例子。

1. 支付 API 失败了。为什么? — 支付服务耗尽了数据库连接。
2. 为什么会耗尽连接? — 一条慢查询长时间占用连接不释放。
3. 为什么查询会慢? — 新增的查询扫描了一个没有索引的列。
4. 为什么会在没有索引的情况下部署? — 代码评审没有检查查询的执行计划。
5. 为什么评审会漏掉这一点? — 没有用来评审执行计划的检查清单或自动检查。

到第五个「为什么」，你抵达的地方已经和最初的「API 失败了」完全不同。真正该修的不是支付服务，而是没能拦住这条危险查询的评审流程。这就是 5 Whys 的力量。它不是缝补症状，而是让你一路下降到产生这个症状的条件。

不过 5 Whys 有明确的局限，不要盲目迷信它。

• 原因通常不止一个。 现实中的故障往往是多个原因叠加造成的。只顺着一条「为什么」的线索往下追，会漏掉其他的促成因素。实际上，一个「为什么」可能有好几个分支答案，所以比起 5 Whys，把原因像树一样铺展开来往往更准确。
• 「5」不是一个神奇的数字。 你可能三次就到了，也可能需要七次。不要执着于次数。
• 如果答案停在一个人身上，说明挖错了方向。 停在「为什么?因为他犯了错」就滑向了追责。必须再往前一步，追问「为什么那个失误会成为可能」，才能触及系统层面。

5 Whys 是构建思考的一个好起点，但它不是唯一的工具。复杂的故障需要更广阔的视野，同时看到多个原因之间的相互作用。

面向客户的沟通 vs 面向内部的沟通

故障期间沟通中常见的错误，是对不同的听众说同样的话。面向客户的沟通与面向内部的沟通，在目的、所需的信息、乃至语气上都不同。

客户想要的是三件事：影响(什么功能不能用)、预计恢复时间(ETA)，以及确认与致歉(确认我们已经知晓并正在处理)。客户不关心你的内部架构，也不关心是哪个微服务的连接池耗尽了。这类内部细节只会制造困惑和不必要的担忧。面向客户的公告应当清晰、朴素、有同理心。

内部则恰恰相反。响应团队和高管想要的是技术真相。精确的错误率、可疑的原因、试过什么和失败了什么、回滚需要多长时间。在这里，连不确定性也应当诚实地共享。「很可能是原因，但尚未确认」这样的措辞，在内部是有用的信息。反过来，如果把这种未加工的细节抛给客户，买到的不是信任，而是不安。

把两者并列比较，是这样的。

核心在于翻译。沟通负责人把内部频道中流动的、未加工的技术真相，翻译成客户所需要的影响、ETA 和致歉再发出去。同一件事，面对不同的听众，必须变成完全不同的句子。

镇定 — 语气决定房间里的空气

最后，谈一谈技巧之前的态度。在故障响应中，IC 的镇定是会传染的。而它的反面，也就是慌乱，同样会传染。

如果 IC 打字急促、声音提高、散发出「大事不妙」的气场，整个响应团队都会吸收这种紧张。紧张的人会做出仓促的决定，不经确认就执行命令，犯下错误。反过来，如果 IC 用平静的声音说「好，我们一步一步来。先确认影响范围」，整个房间的心跳都会慢下来。人们重新找回思考的余裕，更好的判断也从这份余裕中产生。

语气不只是措辞的问题，而是左右响应质量的实质变量。危机应对现场长期流传的一句格言，很好地道出了这一点。

慢即是稳，稳即是快。(Slow is smooth, smooth is fast.)

这听起来像悖论，却是真的。急躁会导致失误，而失误需要花更多时间去挽回。宁可放慢一拍、精确行动，这份从容最终会成为最快的路径。越是紧急的时刻，越要调整一次呼吸，把下一步动作说出声来(「现在开始回滚到 v2.7.2」)，对不可逆的操作再确认一遍 — 这就是 IC 需要在房间里种下的节奏。

镇定不是压抑情绪，而是一种给团队留出思考空间的领导力工具。你镇定，团队就会镇定。而镇定的团队能更快、更安全地结束故障。

结语

故障爆发时，我们本能地扑向代码。但正如本文所见，技术性的恢复只是工作的一半。另一半是对话。一位腾出双手的事故指挥官分好角色，一份即便没有消息也按点敲响的状态更新平息焦虑，三个问题让每次更新都清晰，一份不追责的事后分析留下诚实的教训，面向客户与面向内部的不同翻译分别安抚各自的听众。而在这一切之下，铺垫着 IC 的镇定。

好的事故沟通无法阻止故障发生。故障终究会发生。但它究竟是以一场 20 分钟的技术问题收场，还是演变成拖上一整天的信任危机，由对话决定。恢复只是一半的工作。把另一半做好的团队，反而会在故障之后变得更强。

参考资料

• Google SRE Book — Managing Incidents: https://sre.google/sre-book/managing-incidents/
• Google SRE Book — Postmortem Culture: Learning from Failure: https://sre.google/sre-book/postmortem-culture/
• PagerDuty Incident Response Documentation: https://response.pagerduty.com/
• Atlassian Incident Management Handbook: https://www.atlassian.com/incident-management
• Five whys(概念整理): https://en.wikipedia.org/wiki/Five_whys