事故复盘文档的"根因"到底写到多细：动作层、机制层还是决策层？

背景

我做了 10 年技术文档工程，其中相当一部分工作是帮团队沉淀故障复盘（postmortem）。这两年越来越强烈的一个感受是：社区把大量精力花在"怎么写得漂亮、怎么定责"上，却很少正面讨论"根因写到哪一层才算写完"。社区里关于 P99、超时重试、Kafka 幂等的排查文章很多，但"复盘文档本身的质量标准"几乎没有共识。今天想把这个分歧摆到台面上。

几种常见做法（我观察到的三种）

• 做法 A：动作层（Action-oriented）。根因写成"连接池配小了""超时设错了"，Action Item 就是"调大连接池到 50""超时改成 500ms"。优点是快、好落地、好闭环；缺点是换个场景照样翻车，因为没回答"为什么当时会这么配"。
• 做法 B：机制层（Mechanism）。在 A 的基础上追问一层："为什么默认值是 10？为什么没人 review 这个参数？"Action Item 变成"建立连接池参数的评审 checklist / 默认值模板"。优点是能防住同类问题；缺点是周期长、很多团队嫌重，最后 checklist 写了没人看。
• 做法 C：决策层（Decision）。再追问一层："当时做这个决策的上下文是什么？谁拍的板？信息够不够？"Action Item 变成流程与职责层面的改动（比如变更评审、on-call 权限、SLO 归属）。优点是最根本；缺点是最难写，而且离"blameless"边界最近，写不好就变成甩锅。

我的倾向

我倾向 B 为默认深度，C 为触发条件：默认复盘必须落到机制层（能回答"下次同类问题会不会再发生"），只有当机制层查出来"参数本身没错，是决策流程错了"时才上升到 C。理由有三：

1. 从文档工程角度看，A 层根因本质是"工单"，不是"文档"——它不可复用、不可检索、不可沉淀；
2. B 层的产出物（checklist、默认值模板、参数基线）是可以进 onboarding 和 wiki 的，长期复利最高；
3. C 层涉及人的决策，写得太细容易触发防御心态，写得太粗又等于没写，所以应该作为"升级机制"而非默认要求。

同时我坚持一条纪律：根因描述必须能"反向复现"——任何一个没参与事故的人，拿着根因段落能大致推出"如果我是当事人，当时会做出同样的选择"。做不到这一条的复盘，我认为都只算 A 层。

想听大家聊聊

• 你们团队的复盘文档，根因通常写到哪一层？是默认就有规范，还是每次复盘临时定？
• 机制层（B）的 checklist 你们怎么防止"写完没人看"？有没有把它绑进 CI / 发布流程 / onboarding 的成功案例？
• 决策层（C）你们怎么在 blameless 文化下写，才既够深又不变成甩锅？有没有你们团队认可的"红线措辞"？
• 一个具体场景：一个 P99 抖动事故，最后发现是"新同学按旧 wiki 把超时配成了 200ms，而旧 wiki 没标'该值不适用于高 QPS 场景'"——这种根因你归到哪一层？Action Item 写什么？