档案库 · 工作与做事的点子 · 运营决策 · 2019–2025
Atlassian 的无过失事后剖析：一次 10 万美元的故障如何变成自动化修复
当一次配置错误让 Atlassian 宕机 45 分钟时，公司进行了无过失事后剖析——没有解雇，没有指责，而是添加了自动化检查，让同样的问题无法重演。
Atlassian
当时的题目
Atlassian requires a written postmortem for every severity-1 and severity-2 incident. Its standing rule is 'always blameless': people are assumed to have done their best with the information they had, so the review chases process and system fixes instead of a scapegoat.
它是怎么成立的
无过失事后剖析是 Atlassian 对'团队如何从失败中学习而不自我摧毁'这一问题的回答。公司要求对每起一级或二级事故进行事后剖析，并在会议开始时提醒大家：事后剖析是无过失的，每个人都假定基于当时所知出于善意行事。
这条规则有具体证明。一名工程师曾在关键设备的配置文件中犯下语法错误，导致整个公司宕机 45 分钟——按 Atlassian 自己的估计损失'数十万美元'。团队没有惩罚该工程师，而是将人为错误视为系统设计问题，用五个为什么追溯根源，并找到了任何纪律都无法带来的修复：在加载配置前自动进行'能否启动'检查，并最终完全移除人对该配置的干预。
这种做法已经制度化，而非偶然。Atlassian 公开的《事故管理手册》详细说明了会议议程、追踪纠正措施的 Jira 工作流、带有 4 或 8 周服务级别目标的批准优先行动，以及公开的事后剖析博客以传播经验教训。其目标明确是文化层面的：消除被羞辱或解雇的恐惧，以便事故得到报告，根源得到发现。
妙在哪
- 无过失回顾能浮出恐惧会掩盖的信息——这是防止未来事故的唯一原料。
- 永久的系统修复胜过惩罚：配置错误现在不可能发生，而不是'绝不能再次发生'。
- 要求对一级和二级事故进行事后剖析，让学习成为常规而非英雄行为。
- 在 Jira 中跟踪每项纠正行动并设 SLO，把教训变成可交付的工作，而不是会议记录。
做出来什么
The engineer stayed and still contributes at Atlassian, and the outage — quantified at 'hundreds of thousands of dollars' — is now prevented by a quick technical check. Atlassian published the whole practice in its Incident Management Handbook, complete with templates, approvers and SLO-tracked priority actions, and credits Google and Etsy as its inspiration.
可以借走的
如果事故检讨可能毁掉一个人的职业生涯，人们就会隐瞒信息；如果检讨总能带来系统修复，人们就会把防止下次事故所需的真相告诉你。
后来
Atlassian 持续发布和更新其事故管理指南，包括模板和免费手册。无过失模式已成为软件行业的标准实践——Atlassian 的页面是被引用最多的指南之一。在公司内部，事后剖析对最高级别事故仍是强制要求，工程管理层会对未解决根因的报告进行审查，确保只有当某类故障真正被修复时，事故才会关闭。
资料来源
发现哪里写错了？告诉我们。
轮到你了
你刚读完一个点子。把你手上的题目说出来，看看谁接过同样的题。
免费账号 · 3 次免费提问 · 不用绑卡