你会做些什么来防止同一类 incident 再次发生？

Question

Accepted Answer

运行一次**无指责的 postmortem**，找到系统性原因，然后把它转化为**具体、有人负责、被追踪**的行动项 —— 并验证它们真的落地。目标不是找谁来背锅；而是改变系统，让同一类失败变得不可能发生或能自我检测。

## 核心循环

1. **无指责的 postmortem。** 构建一条诚实的时间线：发生了什么、何时检测到、如何响应、影响是什么。指责会扼杀你所需要的真相。
2. **挖到系统性原因**，而非触发器。“一位工程师推了一个错误的 config”是触发器；“config 没有校验，也没有分级 rollout”才是原因。用 **Five Whys**，但停在系统层面，永远不要停在某个人身上。
3. **生成多层防护**，而非单一修复：
   - **预防** —— 让失败不可能发生（校验、类型、护栏）。
   - **检测** —— 更早抓住它（告警、SLO、合成检查）。
   - **缓解** —— 限制爆炸半径（rollback、flag、熔断器）。
4. **指派负责人和截止日期。** 没有负责人的行动项是一个愿望。把它们当作真实工作放进 backlog 里追踪。
5. **验证并闭环。** 修复上线了吗？它能否抓住最初那次？MTTR 和检测真的改善了吗？

## 取舍与陷阱

- **产出文档而非变更的 postmortem** —— 最常见的失败。没有跟进到底，意味着你会再次遇见同一个 incident。
- **过度修复具体症状**，而那一类 bug 仍然敞着。修那个类别，而不只是这一个实例。
- 不断堆检测却不调优带来的**告警疲劳**；嘈杂的告警会被无视，下一个 incident 就溜过去了。
- **指责文化**会把上报逼入地下；你会失去那些最便宜的教训 —— 近失（near-miss）。
- 把**重复 incident 当作流程失败的信号**，而非坏运气 —— 把复发当作一个指标来追踪。

## 为什么这很重要

incident 是你已经付过的学费；唯一的浪费是不从中学习。一个系统化地防止复发的团队每个季度都更可靠，而一个只会救火的团队会永远重历同样的宕机。建立这个学习循环 —— 以及在其中保持诚实的安全感 —— 是 Tech Lead 能留下的最持久的东西之一。