事故复盘（Postmortem）到底该「无责」还是「追责」？SLO 门禁该不该卡发布？

背景 做了 8 年 SRE，复盘事故是绕不开的日常。我经历过两个极端：

• 早期团队，复盘会开成"批斗会"，最后大家都学会了写模糊的根因（"网络抖动""第三方不稳定"），复盘文档没人再翻，同类问题半年后又炸一次；
• 后来换的团队，全程 blameless，写得很漂亮，但出事故的模块连续三次"意外"，复盘结论都是"流程问题"，最后没人背 KPI，改进项（Action Item）完成率不到 30%，SRE 自己默默把那个模块的告警阈值调松了——这不叫无责，这叫失责。

最近一次真实案例：某核心链路 P99 劣化事故，代码变更本身符合规范，但发布时该服务的错误预算已耗尽 96%，系统没有任何机制拦下这次发布。复盘时开发说"预算是 SRE 的事"，SRE 说"预算告警只发了邮件"，最后结论是"加强协作"。三个月后同样的剧本又演了一遍。

常见分歧

1. blameless 的边界在哪？ 无责 ≠ 无后果。"明知故犯"（比如绕过变更窗口、关闭监控静默上线）和"能力盲区导致的失误"是不是应该区别对待？
2. Action Item 谁来兜底？ 复盘会产出一堆待办，挂到谁头上？挂个人（容易甩锅/推诿）还是挂团队（容易无人认领）？有没有人真的做过 AI 项完成率追踪？
3. SLO/错误预算该不该硬卡发布？ 我的做法是预算耗尽 80% 进"黄色"（发布需 TL 审批）、耗尽 95% 进"红色"（默认冻结，解冻需书面例外），但开发侧普遍反弹："预算是统计指标，不是 SLA，凭什么卡我上线？"
4. 复盘文档写给谁看？ 写给当事团队（深度但没人看）还是写给全组织（通俗但失真）？我们试过公开化，结果变成"事故博物馆"，新人入职读了一堆，但改进项早已过期。

我的倾向与理由

• 倾向 "程序性追责"而非"人格性追责"：不追问"谁写错了"，但必须追问"哪道防线失效了"——评审、测试、灰度、监控，哪一层漏了，那一层的 owner 要对防线本身负责。这样既保护了写代码的人，又让"防线"有真实的责任人。
• 倾向 SLO 门禁分级卡发布，且例外要留痕可追溯。理由：预算耗尽还照常发布，本质是把风险转嫁给线上用户；留痕的价值在于事后可以统计"例外发布"的故障率——如果数据证明例外发布故障率显著更高，那这条规则就有数据背书，而不是 SRE 拍脑袋。
• 倾向 复盘文档"双版本"：内部版含时间线、代码 diff、决策过程（给当事团队）；对外版只保留"失效的防线 + 改进项 + 状态"（给全组织，且改进项必须有 owner 和截止日期，超期自动升级）。

想听大家聊聊

1. 你们团队的复盘是 blameless 还是半追责？"绕过流程上线"这种事，你们实际怎么处理的？（说点真的，别只说制度）
2. 错误预算卡发布，你们试过吗？开发侧的反弹集中在哪？最后是怎么收场的？
3. Action Item 超期，你们有没有真正有效的升级机制？还是最后都靠 SRE 手动催？
4. 有没有人做过"例外发布 vs 正常发布"的故障率对比？数据是什么样？

欢迎带具体案例来吵，纯制度宣讲的就不必了。