很多团队不是不知道要做故障复盘。
他们的问题是：复盘太难写，也太容易写废。
故障刚恢复时，值班人要补业务，研发要修根因，Leader 要同步管理层，客服要回复客户。等真正开始写复盘报告，已经过去了几天。
这时候最常见的场景是：翻告警记录、翻群聊、翻监控截图、翻工单、问当时谁做了什么、凭记忆补时间线，最后写出一份看起来完整、但很难指导改进的报告。
这种复盘报告通常有两个问题。
第一，它像事故说明，不像改进工具。报告写了“发生了什么”，但没有讲清楚为什么发生、哪里响应慢、下一步谁来改。
第二，它太依赖人肉整理。每次都从空白页开始，复盘质量取决于当事人有没有时间、耐心和写作能力。
AI 可以解决一部分问题，但边界要说清楚。AI 不应该替团队下根因结论，也不应该替负责人承诺改进项。AI 最适合做的是：把已经存在的故障上下文整理成结构化初稿，让团队不用从空白页开始。
真正有价值的复盘，仍然需要人来判断根因、确认影响、制定行动项。
复盘报告不是追责文档
很多复盘写不好，是因为一开始就写错了方向。
故障发生后，大家最容易问：谁操作的？谁没看告警？谁没有及时升级？谁没有提前发现？
这些问题不是完全不能问。但如果复盘只停留在“谁做错了”，团队很快会学会隐藏信息。聊天记录不敢写，时间线不敢补，临时判断不敢承认，最后报告变成一份对外可交差的材料。
这对稳定性没有帮助。
复盘报告真正要回答三个问题：
发生了什么？
为什么会发生？
怎样避免下次再发生，或至少降低影响？
这里的“为什么”不是找一个人背锅，而是拆系统性原因：监控有没有及时发现，告警有没有进正确的协作空间，分派策略有没有命中正确值班人，通知是否送达，升级是否及时，Runbook 是否有效，恢复动作是否明确，客户和内部沟通是否及时，后续改进是否有人负责。
一份好复盘，应该让团队下一次处理相似故障时更快、更稳、更少依赖临场发挥。如果报告写完以后，唯一结论是“相关人员加强责任心”，那这份复盘基本没有价值。
一份复盘报告至少要包含什么
复盘报告不需要写得很文学。它要清楚、可验证、可跟踪。
Flashduty 的默认中文复盘模板包含六个章节：综述、根因分析、影响范围、处理时间线、改进措施、经验教训。这个结构对大多数团队已经够用。
综述
综述回答的是：没有参与处理的人，能不能在一分钟内看懂这次故障。
不要一上来贴日志，也不要写一堆内部缩写。更好的写法是：
2026-xx-xx xx:xx 至 xx:xx，支付服务因数据库连接池耗尽出现接口超时，影响部分订单支付请求。故障由 Prometheus 告警触发，支付 SRE 在 4 分钟内认领，随后通过扩容连接池和重启异常实例恢复服务。后续需要优化连接池水位告警、补充限流策略，并完善支付服务高并发压测。
这一段不需要特别长。它要交代时间、服务、现象、影响、响应、恢复和后续方向。
根因分析
根因分析最容易写成“数据库连接数过高”。这通常只是直接原因，不是根因。
更好的方式是分层写：
直接原因：数据库连接池耗尽，支付接口请求排队超时。
诱发因素：活动流量高于预估，连接池配置没有随容量扩展调整。
监控缺口：已有接口超时告警，但缺少连接池水位趋势告警。
流程问题：活动前压测没有覆盖当前流量模型。
这样写的好处是，改进项不会只剩“下次注意”，而是自然导向连接池配置调整、水位告警、活动前压测标准和扩容 Runbook。
根因分析不是为了显示团队多聪明，而是为了让改进措施对准问题。
影响范围
影响范围要尽量量化，不要只写“影响较大”。
更好的问题是：影响了哪些服务？影响了哪些用户或业务线？持续多久？失败请求量是多少？订单、支付、登录、消息、查询等核心链路是否受影响？有没有客户投诉或业务侧升级？是否触发状态页、客服通知或管理层同步？
如果暂时没有准确数字，也要写清楚口径：
影响范围基于支付服务 5xx 指标和订单状态回查估算，实际受影响订单数以后续数据核对为准。
复盘报告不是营销稿，不需要粉饰。
处理时间线
时间线是复盘的骨架。没有时间线，团队很难判断响应慢在哪里。
至少要记录这些节点：故障最早触发时间、告警进入平台时间、首次通知时间、首次认领时间、首次升级时间、关键排查判断、关键处置动作、服务恢复时间、故障关闭时间、状态页或业务同步时间。
时间线不是流水账。它要记录关键转折。比如“10:12 查看日志”价值不大，除非这个动作带来了判断。更好的写法是“10:12 通过日志确认超时集中在支付回调接口，排除网关故障”。
Flashduty 的故障详情页会记录触发、分派、通知、认领、暂缓、关闭、评论等动作。处理过程中写在时间线里的 Markdown 评论、图片和排查笔记，也会成为后续复盘素材。
这就是为什么复盘不能只在事后写。故障处理现场留下的记录越完整，复盘越不依赖记忆。
改进措施
改进措施是复盘报告里最重要的部分。很多复盘失败，就是因为行动项写得太虚。
加强监控。
优化系统。
完善流程。
提高响应速度。
这些都不能算改进措施。
好的改进项至少包含四个要素：要做什么，谁负责，什么时候完成，怎么验证完成。
比如：
为支付服务连接池水位增加 Warning 和 Critical 两级告警，负责人：张三，截止：2026-06-15，验收：生产环境能看到连接池使用率趋势，压测时能触发测试告警并进入 Flashduty 支付协作空间。
这样才是可跟踪的行动项。Flashduty 复盘报告里的跟进事项可以在草稿和已发布状态下继续编辑，因为复盘不是报告发布那一刻结束，而是改进项完成后才真正闭环。
经验教训
经验教训不是“以后要谨慎”。它应该提炼可以复用的判断。
比如：活动前压测不能只看平均 QPS，要覆盖峰值并发和下游连接池水位；Critical 告警不能只进群，必须进入主备值班和升级链路；重大故障应统一创建作战室；对外状态更新需要固定负责人，否则技术团队会被重复问询打断。
经验教训写得好，下一次相似故障发生时，团队会更快进入正确动作。写得不好，就会变成一段没人再看的总结。
AI 适合生成初稿，不适合替你做最终判断
用 AI 写复盘报告，最容易走偏。有些团队会期待 AI 直接告诉他们根因是什么、该怎么改。这很危险。
AI 看到的是已有上下文。上下文不完整，它就只能根据有限信息推断。时间线里没有写的动作、作战室里没有记录的决策、监控系统里没有接入的数据，AI 不可能凭空知道。
所以，AI 生成复盘报告的正确定位是：
整理材料。
生成结构。
补齐初稿。
降低写作成本。
提醒团队检查遗漏。
不是：
替代根因分析。
替负责人承诺行动项。
替团队做最终结论。
Flashduty 的 AI 辅助生成复盘报告，会基于你选择的模板结构，分析故障详情、标签、自定义字段、严重程度、响应人员、处理时间线，以及部分作战室聊天记录，自动生成一份初稿。
这非常适合解决“空白页问题”。但团队仍然要确认事实是否准确，补充 AI 没看到的业务影响，校准直接原因和根本原因，删除过度推断，把改进措施改成可执行行动项，让当事人和负责人共同确认。
AI 初稿写得越像“可直接发布”，越要小心。复盘报告不是为了写得顺，而是为了写得准。
AI 生成效果取决于故障上下文
AI 复盘质量不是由模型单独决定的，更大程度上取决于故障上下文是否完整。
如果故障里只有一个标题“服务异常”，AI 只能写出非常泛的内容。如果故障里有稳定标签、完整时间线、处理人员、评论、截图、监控链接、作战室讨论和最终关闭记录，AI 才能生成更接近真实情况的初稿。
想让 AI 复盘更有用，处理故障时就要开始积累材料。
第一，告警标签要规范。至少要有 service、env、severity、team、resource、check 这类基本标签。否则 AI 很难判断故障属于哪个服务、哪个环境、哪个对象。
第二，时间线要有关键评论。不要只依赖系统自动记录“已认领”“已关闭”。处理人应该在关键节点补充判断，比如“已排除网络问题”“回滚后错误率下降”“数据库连接数仍未恢复”。
第三，截图和链接要沉淀到故障详情。监控大盘、日志查询、变更记录、Runbook 链接，都应该尽量放在故障上下文里。Flashduty 的时间线评论支持 Markdown，也支持粘贴或上传图片。
第四，重大故障尽量使用作战室。Flashduty 作战室可以围绕故障创建专属 IM 群组，并把相关操作记录到时间线。AI 生成复盘报告时，可以读取飞书或 Slack 作战室聊天记录，前提是 IM 集成授予了相应权限。由于平台 API 限制，企业微信和钉钉暂不支持作战室聊天记录提取。
这不是为了让 AI “看更多隐私内容”，而是为了让复盘不再靠人事后翻聊天记录。需要读取聊天记录的场景，必须在团队内部明确授权范围、使用目的和数据安全要求。
模板决定了 AI 初稿的结构
很多人低估模板的作用。他们以为模板只是格式。
实际上，模板决定了团队复盘时会系统性思考哪些问题，也决定了 AI 生成内容的组织方式。
Flashduty 提供中英文内置模板。中文默认模板包含综述、根因分析、影响范围、处理时间线、改进措施、经验教训。对大多数团队来说，这是很好的起点。
不同业务也可以有自己的模板：支付业务可以增加资金影响、订单影响、客户投诉、补偿方案、风控判断；基础设施团队可以增加受影响集群、资源水位、变更关联、容量评估、自动化恢复建议；SaaS 产品可以增加状态页发布时间、客户通知记录、SLA 影响、客服话术、后续客户沟通计划。
自定义模板时，不要只写章节名。最好在每个章节下放一段填写指引。
比如“影响范围”章节，可以写一段指引：
请写明受影响服务、用户范围、业务影响、持续时间、数据口径。如果暂时没有精确数字，请说明估算方法和待确认项。
这对人有帮助，对 AI 也有帮助。模板越清晰，AI 越不容易写偏。
不要在故障关闭后才开始复盘
很多团队把复盘理解成“故障结束后写一篇报告”，这会让复盘天然滞后。
更好的方式是把复盘材料采集放进故障处理过程：故障发生时系统自动记录触发、通知、分派；值班人认领时记录首次响应时间；处理人排查时在时间线补充关键判断；多人协同时使用作战室承载讨论；状态沟通时记录状态页或业务同步节点；故障关闭后，基于这些材料生成复盘初稿。
这样复盘不是从零开始写，而是从已有事实中整理。
Flashduty 的故障详情页内置复盘编辑器。你不需要离开当前故障页面，就可以创建复盘、AI 生成、编辑标题、编辑内容、发布、重新编辑、删除，也可以导出 Markdown。
这会减少一个常见断点：故障处理在一个系统，复盘写在另一个文档，最后上下文丢了一半。
AI 初稿生成后，人工要重点审五件事
AI 初稿不是终稿。生成之后，人工至少要审五件事。
第一，事实是否准确。时间、服务、人员、状态、严重程度、持续时长都要核对。跨时区团队还要统一时间口径。
第二，影响范围是否被低估。订单失败、支付重试、客服投诉、客户 SLA、外部合作方影响，不一定都在故障时间线里，业务负责人需要补充。
第三，根因是否过度推断。AI 可能会把时间上相邻的事件写成因果关系。可以让 AI 提供线索，但不能把 AI 推断当结论。
第四，改进措施是否可执行。把“优化监控”改成具体动作，把“完善流程”改成具体流程，把“加强值班”改成具体值班表和升级策略。每个行动项都要有负责人、截止时间和验收方式。
第五，报告是否能被复用。如果新人读完以后仍然不知道下次该怎么做，说明报告没有把经验转成知识。可以补充 Runbook 链接、监控大盘链接、关键查询语句、状态页沟通模板和升级路径。
哪些故障需要复盘
不是所有故障都要写完整复盘报告。如果每条 Info 告警都要求复盘，团队很快会把复盘当成负担。
更合理的方式是设定复盘触发标准：
Critical 级别故障默认复盘。
影响用户或核心业务的故障必须复盘。
MTTR 超过阈值的故障需要复盘。
未按预期升级或无人认领的故障需要复盘。
重复发生的同类故障需要复盘。
重大变更后引发的故障需要复盘。
客户投诉或 SLA 相关故障需要复盘。
Flashduty 分析看板里的 MTTA、MTTR、响应比例、中断次数、告警 TOP 等指标，可以帮助团队判断哪些故障值得深入复盘：MTTA 高，重点看通知、分派和值班；MTTR 高，重点看恢复手段、Runbook、依赖和架构；中断次数高，重点看告警降噪和升级策略；同一告警检查项反复进入 TOP，重点看规则质量或服务稳定性。
这比按感觉挑故障更可靠。
一套可直接使用的复盘写作流程
可以把故障复盘设计成固定流程。
T+0：故障关闭
T+1：创建复盘草稿，AI 生成初稿
T+2：当事人补充事实和影响范围
T+3：召开复盘会，确认根因和行动项
T+5：发布复盘报告
T+14：检查改进项完成情况
具体天数可以按团队调整，关键是不要让复盘无限期拖延。复盘真正的验收不是报告发布，而是行动项完成。
试用时怎么验证 AI 复盘是否有价值
如果正在试用 Flashduty，不建议只点一下 AI 生成按钮。那样很难判断它是否真的能减少复盘成本。
更好的验证方式是跑一次真实或模拟完整流程：选择一个真实业务告警源，触发一条 Critical 测试故障，让值班人通过 App、IM 或语音认领，在处理过程中补充几条时间线评论；如果是重大故障演练，创建作战室并记录讨论；关闭故障后创建复盘报告，选择默认模板或业务模板，使用 AI 生成初稿，再让处理人和负责人一起修改。
验证标准可以很具体：
AI 是否正确还原了故障时间线？
是否能识别受影响服务和关键资源？
是否把认领、升级、关闭等动作整理进报告？
是否遗漏业务影响？
是否有过度推断？
人工修改成本比从零写低多少？
改进项能否落到负责人、截止时间和验收方式？
如果 AI 初稿只能写出一堆泛泛而谈的内容，不一定是 AI 没用，也可能是故障上下文太少。AI 复盘的价值，往往会倒逼团队把故障处理过程记录得更好。
用 Flashduty 做复盘，适合从专业版能力开始验证
Flashduty 的故障复盘、AI 辅助生成复盘报告、作战室等能力属于 On-call 专业版能力。这类能力最适合中大型团队验证。
复盘低效通常不是小团队的第一痛点。小团队靠几个人口头同步还能撑一段时间。但当团队变大、服务变多、故障参与人变多，复盘就会变成一个系统问题。
典型信号包括：复盘会总是拖延，复盘报告质量不稳定，时间线经常靠回忆，改进项没有负责人，同类故障重复发生，管理者看不到故障处理投入，重大故障沟通散落在多个群。
如果这些问题已经出现，就不应该只优化文档模板。你需要把告警、响应、时间线、作战室、复盘和行动项放到同一条链路里。
Flashduty 的切入点是：不替换现有监控系统，先接入一个真实告警源，把故障处理过程沉淀下来，再用 AI 生成复盘初稿，最后让团队把初稿变成可发布、可跟踪的复盘报告。
这比单独找一个 AI 写作工具更可靠。AI 写作工具看不到故障对象、通知记录、认领时间、升级过程、关联告警和作战室上下文。没有上下文，AI 只能写模板化文本；有上下文，AI 才能成为复盘流程的一部分。
最后：AI 不是复盘负责人
故障复盘报告怎么写？核心不是文笔，而是事实、结构、根因和行动项。
AI 可以帮你整理事实，生成结构，减少空白页焦虑，把时间线和上下文变成初稿。
但 AI 不能替团队承担判断。根因要由技术负责人确认，影响要由业务和数据口径确认，行动项要由负责人承诺，报告要由团队发布，改进要被持续跟踪。
这才是 AI 生成复盘报告的正确方式。
不是让 AI 写一篇看起来专业的事故报告，而是让 AI 把团队已经发生的处理过程整理出来，帮助团队更快进入真正重要的讨论：为什么会发生，下一次怎么不再发生。
先选一个真实故障，生成一份复盘初稿，再让团队一起把它改成可以发布的报告。你会很快知道：复盘低效到底是写作问题，还是故障响应过程本身没有留下足够上下文。
