如何撰写不含指责性语言的事故复盘报告

我永远不会忘记我的第一次事故复盘会议。当时我还是一名初级工程师，服务器在假日促销活动期间凌晨三点崩溃了。报告开篇写道：“约翰在没有进行适当审查的情况下部署了有缺陷的代码。”约翰就坐在我旁边。房间里的紧张气氛浓厚得仿佛能用刀切开。

那份报告没有解决任何问题。它只是让每个人都产生了防御心理。

事实是这样的：事故复盘不是为了指责他人，而是为了构建更完善的系统。当你使用指责性语言时，你会扼杀好奇心。人们不再问“为什么会发生这种情况？”，而是开始问“我如何避免被指责？”这与你想要的结果背道而驰。

让我向你展示如何撰写真正有效的事故复盘报告。

为什么指责性语言会失效

指责性语言起初听起来似乎合情合理。“鲍勃忘记运行迁移脚本。”“莎拉没有检查日志。”“质量保证团队漏掉了这个错误。”

但问题在于：当你指责个人时，他们会产生防御心理。他们会隐瞒错误。他们不再在会议上发言。于是，六个月后同样的事故再次发生——只是涉及的人员不同而已。

我在三家不同的公司目睹过这种情况。那些使用指责性语言的公司反复遭遇相同的停机事故。而那些专注于系统改进的公司？它们确实变得更好了。

目标不是归咎责任，而是理解事件链，以便下次能够打断它。

让我详细介绍一下我实际使用的流程。它基于我从 BeLikeNative 学到的一个框架——这是一个专注于技术写作中清晰、中立沟通的资源平台。

在动笔之前，先收集时间线。不要包含观点——只记录发生了什么、何时发生以及发生的顺序。

糟糕的写法：“因为团队匆忙行事，导致部署出错。”
良好的写法：“14:32，触发了部署操作。14:35，错误率飙升至 45%。”

注意到区别了吗？第一种写法是在归咎责任。第二种写法是在描述事件。

记录下每一个时间戳、每一次变更、每一条警报。坚持使用可观察的事实。你可以稍后再对它们进行解读。

这是最难的部分。我们天生倾向于说“谁做错了什么”。相反，应专注于“发生了什么”。

用“未”代替“未能”。用“未响应”代替“忽视”。用“促成”或“导致”代替“造成”。

以下是我撰写的一份真实事故复盘报告中的示例：

修改前：“值班工程师未能在 15 分钟内升级警报。”
修改后：“警报未在 15 分钟内得到升级。当时，值班工程师正在处理另一起事故。”

第二种版本讲述了相同的故事，但没有让任何人难堪。而且它揭示了真正的问题：工程师工作负荷过重。

“五个为什么”技法很简单。从事故开始，连续问五次“为什么”。但诀窍在于：不要停留在人为错误上。

让我给你一个示例：

看到发生了什么吗？根本原因不是“鲍勃写了一个糟糕的查询”，而是“部署流水线缺乏时机审查”。这是一个系统问题，而不是个人问题。