线上故障后的组织复盘（不是技术复盘）

一句话速记

技术复盘关心”代码哪里写错了”（第二根因），组织复盘关心**“什么样的流程、决策、信息断层让这个错误被写出来、被合入、被上线而且没有被拦住”（第一根因和超前 2 年）。组织复盘的目标不是追责，是找出系统的漏洞**——每次故障都是你的工程质量体系的一次免费安全测试，不学就浪费了。

通俗解释（5 分钟版）

技术复盘：
  "这个 OOM 是因为 ThreadLocal 没 remove —— 修了。"
  → 关注的是这次的具体 bug 和 fix

组织复盘：
  "我理解代码为什么会写错。但我们接着问：
   ① 为什么 code review 没发现？（是没有 checklist 还是
      reviewer 太忙？如果是后者——TL 是不是在 review
      工作量里没给足够时间？）
   ② 为什么 CI 没测出来？（没有 ThreadLocal 泄漏的测试？
      还是测试覆盖不到这类场景？）
   ③ 为什么灰度放量了 30 分钟后才炸？（Old 区一直接近
      临界点——为什么没有提前告警？）
   ④ 团队里其他人有没有同样的问题？（排查了 5 个服务，
      发现 2 个也有同样的 ThreadLocal 没 remove 的模式）
   
   所以我们要改的不只是这行代码。
   我们要改的：
     - Code review checklist 增加一条
     - CI 流水线增加一个 ThreadLocal 泄漏检测
     - 监控告警阈值从 Old > 95% 调低到 85%
     - 写一个 AutoCleanupThreadLocal 包装类让以后不可能再犯"

关键细节

组织复盘的五问

1. 信息问：错误是什么时候被引入的？
   - 写代码的那一天
   - 不是上线的那一天！

   "这个 bug 是 6 周前写下的。为什么这 6 周里我们没有发现？"
   → 如果代码在 review 阶段、CI 阶段、灰度阶段被发现的概率
     分别是 30%、80%、95%——为什么这次三道防线全漏了？

2. 防线问：每一道你自认为的防线为什么没拦住这次错误？
   - Code Review：为什么没发现？
   - CI/CD：为什么没测出来？
   - 灰度/金丝雀：为什么没抓到？
   - 监控告警：为什么是用户先发现的而不是你先发现的？
   
   （如果答案是"我们根本没有这道防线"——
    那就是你这季度最大的改进优先级）

3. 信息问：做决策的人在关键时刻有没有掌握到必要的信息？
   - 那个写 bug 的工程师，在写的时候知不知道
     ThreadLocal 需要 remove？
     → 如果不知道：培训/文档/工具提示缺失
     → 如果知道但忘了：有没有机制帮 TA 记住？
        （代码模板/linter 自动检查/工具封装）

4. 范围问：这个问题有没有在其他服务/团队里存在？
   - 5 个服务里搜了一圈，2 个有同样的问题模式
   → 你的问题是团队的还是系统的？

5. 速度问：从"事件发生"到"被发现"到"被修复"，
   你的响应速度够快吗？
   - 被用户发现的：你的监控比用户慢了多久？
   - 修复用了多久？有没有因为信息不全或权限不足
     而拖延？

组织改进行动项

每个改进必须具体、必须有人做、必须有期限：

坏例子：
  "我们要加强 code review 质量。"
  → 谁做？怎么做？什么时候做完？没写 = 不会做

好例子：
  "代码 review checklist 增加一条：涉及 ThreadLocal 的
  代码必须确认 finally 里有 remove。在团队 wiki 上更新。
  责任人：老王；完成时间：本周五。"
  → 下周五开会时，老王能不能说"做完了"是清晰的

改进行动分为三类：

1. 时间防护（拦住它别再进入主干）：
   linter 规则、CI 检查、单元测试、review checklist

2. 空间防护（拦住它到不了生产）：  
   灰度放量、金丝雀、影子流量、预发环境
   
3. 观察防护（在它伤人之前发现它）：
   监控告警、异常检测、每周巡查

组织复盘会的组织

参与人：
  - 值班/oncall 人（这次故障的经历者）
  - 故障相关的 TL（不一定是直接写代码的人）
  - 相关方的 TL（如果有跨团队影响）
  - 不需要全团队参加
  （如果团队有 10 个人，不要让 8 个无关的人旁听）

时长：30-45 分钟（不是 2 小时）
  
会前准备：
  - 事故的时间线已经理清（精确到分钟）
  - 技术根因已定位（到代码行）
  - 改进建议草稿已有（不需要在会上动脑想）

会中议程：
  1. 故事（5 分钟）：oncall 人讲一遍时间线
  2. 防线扫描（15 分钟）：每一道防线为什么没拦住
  3. 行动项（10 分钟）：最多 3 个改进行动项

会后：
  - 发事故复盘记录到团队（不只是参加的几个人）
  - 下次复盘会第一件事：检查上次的行动项完成了吗？

延伸追问

• Q：小故障也需要组织复盘吗？ → 不需要每次都做。但同样类型的故障第二次出现时，必须做——因为第一次你认为它是”偶发的”，第二次证明你的防线有系统性漏洞。
• Q：复盘会上有人开始互相指责怎么办？ → 立刻打断，要求”到此为止，会后单独聊”。复盘会的规则是：只讨论”怎么会这样”（系统层面），不讨论”这是谁的错”（个人层面）。如果你没信心控制住这个边界，会前先和关键人单独沟通。
• Q：怎么确保复盘不变成走过场？ → 看行动项。如果连续 3 次复盘的行动项都按时完成了——是真的。如果每次都是”要加强 code review”没有 Owner 没有 deadline——你在走过场。

我的记法

• 组织复盘 vs 技术复盘：技术复盘问”代码错哪了”（第二根因），组织复盘问”防线为什么全漏了”（第一根因）
• 五问：信息、防线、决策、范围、速度
• 行动项三要素：Owner + 截止日 + 可验证（下个月开会时能不能说”做完了”）
• 一句话：「每次故障都是一次免费的安全测试——你花 2 小时做复盘，省的是下次同样的故障再花 2 周」

状态

• 已背速记
• 能讲通俗版
• 能答追问