用途：在 P1/P2 事故后（必做）、P3 事故（可选）、重复问题或“差点出事”场景下，进行无追责复盘，追流程不追人，追问“为什么系统允许这个错误发生”。
主要能力：提供完整复盘流程——事故关闭后 24 小时内由 IC 发起并收集时间线、日志、指标；用模板写 Postmortem 文档，时间线精确到分钟；召开 30~60 分钟复盘会议（IC、相关工程师、PM）；分配改进项并录入 Jira/Linear；每周跟踪状态，下次复盘回看上次改进项；沉淀到 field-journal、Runbook、告警规则与 pitfalls。
5 Whys：每个 Why 需有证据，不停在“人犯了错”，追到系统/流程层面。示例：用户无法登录→认证服务 500→Redis 连接超时→Redis 内存满→未配置 maxmemory-policy；根因为 Redis 配置缺失加无内存告警，而非“运维忘了配置”。
改进项分类：检测改进（新增告警、降低阈值、增加监控覆盖）、预防改进（代码/配置修复、流程改进、自动化检查）、缓解改进（降级、限流、灾备切换、回滚加速）、响应改进（Runbook 更新、告警路由与升级路径优化）。
配套模板：templates/postmortem-template.md，含摘要、时间线、5 Whys、改进项。
质量自检：24~72 小时内完成、时间线精确到分钟、5 Whys 到系统层面、不追责、改进项有负责人与截止时间且可执行、公开透明、沉淀到 field-journal、更新 Runbook 与告警规则。
常见坑：追责导致团队不敢报告；5 Whys 停在表面；改进项太宽泛；改进项不跟踪；只写文档不开会；拖延两周后记忆模糊；不公开；不回看上次改进项。
协作：上游 incident-response 提供事故记录；下游 on-call-runbook、reliability-engineering、field-journal、devops-engineer monitoring-alerting 分别用于 Runbook、SLO/错误预算、经验沉淀与告警改进。