【背景：一次让我当场下不来台的复盘会】
先说个真事。去年双 11 前一周，我们一个结算服务挂了 11 分钟。事后拉复盘会，气氛一开始很"政治正确"：大家齐刷刷说"是流程问题、是架构问题、是监控没覆盖"，没人提谁。可改进项写完，一周后我去查——零落地。
原因很简单：改进项写的是"加强发布前检查""完善告警覆盖"，但没有一条落到具体的人头上，于是没人认领、没人验收，最后全变成 PPT 里的正确废话。
那天晚上我失眠了，想明白一件事：blameless 的初衷是好的，但**"不指向人"和"没人负责"之间，只隔了一张改进项认领表**。我们踩的坑，恰恰是滑到了后者。
【常见分歧：我见过三种做法】
做法一：纯 blameless 派。 "追责会让人不敢报、不敢说真话，复盘会变成甩锅大会。" 这个我认同前半句。我见过一个团队，复盘会上主管一句"这谁的锅"，后面所有人开始只说现象不说不利自己的事实，连"我其实没跑集成测试"这种关键信息都被咽回去了。复盘一旦变成审判，你得到的就是二手信息。
做法二：纯追责派。 "不追责就是和稀泥，责任不到人就没有改进动力。" 这话也对——上面那个"零落地"的反例，本质就是没人负责。可我又见过一个反例：某团队每次复盘必点一个"直接责任人"，结果那个同事离职了，团队里剩下的人开始互相抢着把问题往流程上推，因为谁认领改进项谁就是下一根"避雷针"。
做法三：折中派（也是我现在用的）。 blameless 不等于不改进，而是把矛头从"人"转向"系统 / 流程 / 工具"；但边界要划清——"过程 blameless + 结果问责"。
【我的倾向与理由】
我现在的做法，打个比方：复盘像看 CT 片子，你要看的是病灶（系统缺陷），不是骂那个端片子的护士。
具体分两层：
- 过程层 blameless：谁写的代码、谁点的发布、谁漏的告警，这些不当定责依据。因为绝大多数 P0 不是"某个人蠢"，而是"系统允许蠢发生"——没有灰度、没有熔断、没有可观测性兜底。
- 结果层问责：但改进项必须落到 owner + deadline + 验收标准，并且 owner 可以是"当初写代码的人"——不是惩罚他，而是他最懂怎么改。认领 ≠ 背锅。
关键那条线我划在："能力 / 流程缺陷" blameless，"明知故犯"问责。 比如——没跑测试就发生产（流程缺陷，blameless）；还是手动把生产库删了、且绕过所有审批（明知故犯，该问责）。前者你骂人只会让他下次更不敢报，后者你宽容了就是在鼓励。
【想听大家：你们团队到底怎么定调？】
抛几个我特别想听真实答案的：
- 你们复盘会，是真的没人提责任，还是"有人提了但被主管压下去"？这两种"blameless"差别很大。
- 有没有过追责到个人反而把改进落地了的案例？还是追责只带来了离职？
- 改进项"落到人头上"之后，谁来验收？我见过太多改进项 owner 是自己、验收人也是自己，等于没验收。
- 你们怎么划"过程缺陷 vs 明知故犯"这条线？有没有可操作的判据，而不是靠复盘会当场吵架？
我先把自己的底牌亮这：我站"过程 blameless + 结果问责 + 改进项强制落到 owner"。欢迎拍砖，尤其是那些踩过"追责把团队搞散了"或"blameless 把改进搞丢了"的兄弟，你们的血泪经验比我的值钱。