很多团队不是不知道要做故障复盘，而是复盘太难写，也太容易写废。故障刚恢复，值班人要补业务，研发要修根因，Leader 要同步管理层，客服要回复客户。等真正开始写复盘报告，已经过去几天，大家只能翻告警记录、翻群聊、翻监控截图、翻工单，再凭记忆补时间线。
最后写出来的报告经常看起来完整，但对下一次故障帮助不大。它记录了“发生了什么”，却没有讲清楚为什么发生、响应链路哪里慢、哪些系统能力缺失、谁来改、什么时候改完。更糟的是，有些复盘只剩几句“加强监控、完善流程、提高意识”，下次类似故障还是从头再来。
AI 可以解决一部分问题，但边界要说清楚。AI 适合整理时间线、告警上下文、战情室聊天记录、影响范围和报告初稿；它不应该替团队做最终根因判断，也不能替负责人承诺改进项。复盘不是写报告，而是把事故变成组织学习。AI 能帮你少从空白页开始，但不能替你承担改进责任。
复盘不是追责，也不是归档
复盘写不好，常常是因为目标错了。事故之后，团队最容易问“谁操作的、谁没看告警、谁没有升级、谁没有提前发现”。这些问题不是完全不能问，但如果复盘只围绕个人责任，大家很快会学会隐藏信息，时间线不敢写，临时判断不敢承认，报告变成一份对外可交差的材料。
真正有价值的复盘，要回答三个问题：发生了什么，为什么会发生，怎样避免下次再发生或降低影响。这里的“为什么”不是找一个人背锅，而是拆系统性原因。监控有没有及时发现，告警有没有进入正确响应流程，分派策略是否命中正确值班人，通知是否送达，升级是否及时，Runbook 是否有效，恢复动作是否明确，业务和客户沟通是否及时，改进项是否可跟踪。
如果复盘结束后，团队下一次处理相似故障仍然只能靠同一批人、同一套临场经验、同样的群聊问答，那报告写得再长也没有真正产生价值。
一份好复盘至少要有八个部分
复盘报告不需要写得文学化，但必须清楚、可验证、可跟踪。一个比较稳妥的结构包括八个部分：摘要、影响、时间线、根因、处理过程、做得好、待改进、行动项。
摘要回答“没参与处理的人能不能一分钟看懂”。它要交代故障时间、受影响服务、主要现象、影响范围、响应和恢复动作、后续方向。不要一上来贴日志，也不要写一堆内部缩写。
影响回答“用户和业务受了什么影响”。影响范围要尽量量化，包括影响服务、用户范围、失败请求量、业务损失、客户投诉、状态页或客服同步情况。如果暂时没有准确数字，也要写清楚估算口径和待核实项。复盘不是营销稿，不需要粉饰。
时间线是骨架。至少要记录故障最早触发时间、告警进入平台时间、首次通知时间、首次认领时间、首次升级时间、关键判断、关键处置动作、服务恢复时间、故障关闭时间、业务或客户同步时间。时间线不是流水账，重点是关键转折。比如“10:12 通过日志确认超时集中在支付回调接口，排除网关故障”，比“10:12 查看日志”更有价值。
根因要分层写。直接原因可能是数据库连接池耗尽，但诱发因素可能是活动流量高于预估，监控缺口可能是缺少连接池水位告警，流程问题可能是活动前压测没有覆盖当前流量模型。只有这样，改进项才不会只剩“下次注意”。
处理过程要说明团队如何发现、判断、止损和恢复。做得好要记录，不是为了表扬，而是为了沉淀可复用动作，比如及时回滚、正确升级、状态同步清楚。待改进要具体，不要写成情绪判断。行动项则必须包含做什么、谁负责、什么时候完成、怎么验收。
常见坏复盘：只有时间线，没有改进责任
坏复盘有几种常见样子。第一种是流水账型，记录了很多时间点，但没有判断。比如“10:01 告警，10:03 处理，10:20 恢复”，却看不出为什么 10:03 到 10:20 之间花了这么久。
第二种是截图堆叠型，贴了很多大盘、日志和群聊截图，但没有把证据串起来。读者看完知道“当时很忙”，但不知道哪条证据支持根因判断。
第三种是单点根因型，把“数据库连接数高”“服务重启”“代码 bug”当作最终根因，不继续追问为什么监控没有提前发现、为什么容量评估没覆盖、为什么发布前没有检测、为什么回滚路径不清楚。
第四种是行动项虚化型，写“加强监控、完善流程、提升意识、优化系统”。这些都不是行动项，因为没有 owner、截止日期和验收方式。真正可执行的写法应该是：“为支付服务连接池水位增加 Warning 和 Critical 两级告警，负责人张三，截止 2026-07-15，验收方式是在压测环境触发测试告警并进入支付响应空间。”
第五种是报告归档型。报告发布后没人跟进，行动项没有进入下个月的治理计划，告警规则、Runbook、知识库、值班策略和 AI 上下文都没有更新。这样的复盘只是在保存事故记忆，没有改变系统。
AI 适合生成初稿，但最终报告必须由人确认
Flashduty 的 AI 辅助复盘生成，会基于模板结构，分析关联 Incident 的标签、自定义字段、严重程度、响应人员、响应时间线，以及部分战情室聊天记录，生成一份初稿。这对解决“空白页问题”很有价值。很多团队复盘拖延，不是因为没有观点，而是整理材料太耗时。
AI 最适合做五件事。第一，整理事件和响应时间线，把触发、通知、认领、升级、关闭、评论和关键状态变化串起来。第二，总结告警上下文，包括严重级别、关联告警、影响对象和标签。第三，归纳战情室讨论，把关键判断、排查方向和处置动作提取出来。第四，按模板生成结构化初稿，减少从零写作的成本。第五，提醒团队补充缺失信息，比如影响范围、根因证据、行动项 owner 和截止日期。
但 AI 初稿不是最终报告。团队仍然要确认事实是否准确，补充 AI 看不到的业务影响，校准直接原因和根本原因，删除过度推断，把改进措施改成可执行行动项，并让相关 owner 共同确认。AI 初稿写得越顺，越要小心，因为复盘报告不是为了读起来像一篇文章，而是为了把事实和责任写准。
上下文决定 AI 复盘质量
AI 复盘质量不只取决于模型。它更取决于事故现场有没有留下结构化上下文。
Flashduty 的 Incident 模型里，事件、告警和故障是分层的；Incident 有严重级别、处理进度、状态、标签、响应人员、通知记录和时间线。War Room 能把事故协作放到专属 IM 群里，成员变更、状态同步和相关操作会进入时间线。AI 生成复盘时，如果能读取 Incident 详情、响应时间线和战情室讨论，初稿就会比事后翻群聊更完整。
Flashcat 的 FlashAI 则可以补充观测侧证据。北极星说明业务指标何时异常，灭火图说明哪些对象飘红，日志和 Trace 说明错误和慢调用集中在哪里，事件墙说明异常前后有哪些发布、配置和运行时事件。这些分析过程和报告，可以作为复盘里的根因证据和技术时间线。
也就是说，AI 复盘不是一个孤立写作功能。前面告警、响应、战情室、观测分析记录得越完整，后面 AI 初稿越接近事实。事故现场不记录，事后 AI 也只能根据残缺材料推断。
如何把复盘行动项反哺系统
复盘真正的价值，在报告发布之后。每个行动项都应该反向进入系统，而不是停留在文档里。
如果问题是漏报，就回到告警规则和北极星指标，补充关键业务指标、阈值、同环比、数据中断检测或对象卡片告警。如果问题是误报或噪声，就回到告警降噪，调整去重、聚合、抑制、静默、路由和标签质量。如果问题是判断慢，就回到灭火图、下钻规则、事件墙和 runbook，把排障路径补到平台里。
如果问题是没人接，就回到 Flashduty 的值班表、升级策略、通知渠道和认领机制，检查主备值班、超时未响应、升级触发和人员负载。如果问题是协作乱，就把重大故障引入战情室，统一处理现场和状态同步。如果问题是 AI SRE 输出不够具体，就补知识包、历史案例、工具权限和对象上下文。
一个好行动项应该有四个字段：动作、负责人、截止日期、验收方式。没有这四个字段，就很容易变成愿望。复盘会议上最重要的不是把报告逐字读完，而是确认这些行动项能不能进入下一个迭代、下个月治理指标或平台配置。
落地时怎么做
第一步，统一复盘模板。模板至少包括摘要、影响、时间线、根因、处理过程、做得好、待改进、行动项。模板不要太复杂，否则团队会为了填表而填表。
第二步，要求事故处理中写时间线。关键判断、排查结论、回滚、扩容、切流、状态同步、外部沟通，都尽量写在 Incident 时间线或战情室里。不要等事故结束后靠记忆补。
第三步，让 AI 生成初稿。用 AI 把 Incident 详情、响应时间线和战情室上下文整理成模板初稿，先解决材料整理和结构问题。
第四步，人工校准。由 SRE、服务 owner、业务负责人共同确认事实、影响、根因和行动项。AI 负责初稿，人负责结论。
第五步，跟踪行动项。把行动项同步到告警规则、Runbook、知识库、值班策略、灭火图下钻、事件接入或 AI SRE 知识包。复盘完成不是报告发布，而是行动项验收。
总结：AI 可以帮你写快一点，但不能让团队学得更少
故障复盘不是写一份漂亮报告，而是把一次事故变成系统改进。AI 可以整理时间线、提取战情室讨论、生成结构化初稿、提醒缺失信息，减少人从空白页开始的成本。但根因判断、影响确认、改进优先级、负责人承诺和验收方式，必须由团队承担。
下一步可以很小：选最近一次真实 Incident，体验一次 AI 复盘初稿生成。不要直接发布，拿它做复盘底稿，逐段确认事实、补充证据、修改行动项。你会很快看出来，团队缺的是写作时间，还是事故现场本身没有留下足够上下文。
