先说结论：我站「Blameless + 硬性的系统级 Action Item」，但我知道这个题在 SRE 圈里从来没吵完过。今天把争点摊开，想听大家不同规模、不同阶段的真实做法。
背景
我做了 8 年 SRE，前后在两种文化里待过。 第一种是典型的"背锅文化"：一次 P1 故障，复盘会开成批斗会，oncall 被点名，开发被点名，DBA 被点名，最后 Action Item 写着"加强 oncall 的责任感"。结果呢？后来团队开始学会不写 oncall 记录，学会把"我以为是别的服务"写进时间线，学会在复盘会上集体沉默——因为说了就是证据。我们内部管这叫"复盘通胀"：每次复盘都开了，但真话越来越少。 第二种是"标准 blameless"：复盘文档里禁止出现"某人做错了什么"，只允许写"系统在某时刻的某个假设不成立"。我一开始觉得很好，直到有一次核心链路 30 分钟不可用，复盘写出来是"熔断阈值设置不合理 + 上游超时配置不一致"，Action Item 全是"优化配置"——但没有人愿意认领那条 Action Item，因为没有具体的人，就没有具体的 owner，最后 Action Item 躺了 6 周没动，下次同类故障原样复现。
这两种我都踩过了，所以今天想认真聊一下这个题。
常见分歧（我听到的三种）
派 A：Blameless 是底线。 理由：一旦有追责，信息失真比事故本身更贵。你想知道的是"为什么 30 分钟没自愈"，而不是"是谁没看监控"。Google SRE Book 里那句 "blameless postmortem is not about being nice" 就是这派的核心论据。
派 B：Blameless 会稀释责任，出大事没人扛。 理由：SRE 的很多事故本质是人-系统交互的问题，不是纯系统问题。一个 oncall 在凌晨 3 点跳过告警，和"告警风暴设计不合理"是两件事；如果复盘只写后者，前者永远修不好。而且现实里"系统级 Action Item"经常没有 owner，最后变成集体责任 = 无人责任。
派 C：折中派——Blameless 文档 + 匿名个人反思 + 明确的成长 Action Item。 理由：文档对外 blameless，但对内允许每个人写"如果重来一次我会怎么做"，这部分不公开、不计入绩效，但会汇总成团队的能力缺口，用来排培训和演练。这样既保住了信息真实性，又保住了个人成长。
我的倾向
我偏向派 C，理由有三：
- 纯 blameless 会失去"人的信号"。8 年下来我越来越相信，SRE 事故里 60% 的根因是流程/系统，但 40% 是"人的判断"，而人的判断是可以被训练提升的。完全去掉人的维度，等于放弃了一半的训练素材。
- 纯 blame 会失去"系统的信号"。背锅文化下，第一反应永远是找替罪羊，而不是问"为什么系统允许这件事发生"，这是更贵的损失。
- 真正的关键是 Action Item 的 owner 和验收标准。无论 blameless 与否，如果一条 Action Item 没有 owner、没有 done criteria、没有复测方式，它就等于没写。我见过最健康的团队，复盘文档末尾每条 Action Item 都带：owner（可以是一个小组而非个人）、deadline、验收方式（压测/演练/告警演练）、以及"如果不做会怎样"的反面陈述。
所以我的立场是：对外文档 blameless，对内允许匿名个人反思，Action Item 必须有 owner + 验收方式，逾期没完成的要在下次复盘会开头 5 分钟回顾。 最后一句是我踩坑踩出来的——没有回顾机制，blameless 会变成"写完就忘"。
想听大家
- 你们团队的复盘到底是哪种流派？事故等级是怎么分级的（P0/P1/P2 的复盘流程是否不同）？
- 有没有人做过「复盘文档匿名化 + 事后追踪个人成长」的机制？效果到底如何？有没有反噬？
- 当一次故障确实是某个人的低级失误（比如删库没走审批）时，blameless 文档怎么写才既不失真、也不至于变成集体免责？
- 你们团队的 Action Item 平均闭环率是多少？低于多少你会觉得复盘机制已经"通胀"了？
先抛砖，想听不同规模、不同阶段的真实做法——大厂小团队、创业公司、外包驻场都可以聊，越具体越好。