用途：在发生生产事故、服务降级、险兆事件或反复出现的问题后，主导一次无指责复盘，从事件中学习并提升系统韧性，同时把经验分享给跨团队。
主要能力：按步骤引导复盘流程。第一步收集原始数据，包括导出日志（kubectl logs）、Prometheus 指标快照（curl 查询 query_range）和告警历史（amtool alert query）；第二步按分钟级重建时间线，记录时间、事件、来源与操作者；第三步用 Five Whys 或鱼骨图识别直接原因、贡献因素与系统性问题；第四步生成带负责人、截止时间和优先级的行动项；第五步按模板撰写并分发报告，包含摘要、影响、根因、时间线、做得好之处、经验教训与预防措施；第六步在站会或回顾中跟踪行动项，可用 gh issue create 创建工单并设置周期性提醒。
必要输入：事故详情（起止时间、受影响服务、严重级别）；事故窗口内的日志、指标与告警访问权限。可选输入：响应期间使用的 runbook、沟通记录（Slack、PagerDuty）。
适用场景：生产事故后复盘、险兆事件分析、反复问题调查、跨团队经验分享。
限制与注意：资料未提供具体收费、平台支持范围或自动化程度。若数据不完整需在报告中标注缺口；时间戳不一致时应确保各系统使用 NTP 并统一 UTC；分析不应止于“某人犯错”，需追问系统为何允许该错误；行动项必须具体可执行，避免“改进监控”这类模糊表述；报告建议在事故后 48 小时内分发，并安排 4 周后的跟进评审。