用 AI 做事故复盘，时间线拼得挺快，根因却总是写歪

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

**把复盘写歪的人，多数不是被模型骗了，而是把”时间线上最先变红的那一项”当成了根因。**AI 拼时间线拼得又快又整齐，整齐本身就有说服力，于是一条”某点部署 → 某点错误率上升 → 某点回滚”的漂亮链条摆在面前，评审会上没人再问一句”这两件事之间凭什么是因果”。事故复盘真正值钱的部分——根因判定和改进项——恰恰是模型最容易给出貌似合理答案的地方。

先说清本篇和站内相邻两篇的分工。生产事故里 AI 的能力边界讲的是事故进行时该不该让 AI 上手、能碰哪些操作；Agent 执行过程的复现与回放讲的是怎么把一次 Agent 运行完整录下来以便事后重放。本篇管的是事故平息之后的那场复盘会：材料怎么让 AI 整理、结论为什么必须人来签字、哪些动作能验收。

一、先分清：复盘里 AI 能做到哪一步

复盘这件事拆开是四层，越往下越不能交出去。

**第一层，材料归集。**日志、监控截图、告警通知、发布记录、代码提交、值班群聊天记录、工单往来，分散在五六个系统里，时区还不一致。把这些统一成一份带时间戳的事件流，是纯体力活，AI 做得比人快，也比人耐心。这层可以放手。

**第二层，时间线对齐与叙述。**把事件流按秒排好，标出人的动作和系统的反应，写成一段人话叙述。AI 做得不错，但会犯两类错：把 UTC 和本地时间混排；把”日志里没有”当成”没发生”。这层可以交出去，但必须人复核时间基准和缺口。

**第三层，因果假设。**从”A 之后 B 发生了”跳到”A 导致了 B”。AI 在这里的输出是最流畅、也最不可信的。它给的是最常见的叙事模式，不是对你这套系统的判断。这层只能让它列候选，不能让它下结论。

**第四层，改进项与责任分配。**涉及取舍：加一道人工卡点会拖慢发布速度，加一层重试会放大下游压力，加一套监控要有人长期维护。这些取舍要拿团队的实际人力和优先级去换算，模型不掌握这些约束。这层完全归人。

一句判断标准：**这一步的输出如果错了，能不能靠读一遍就发现？**能，就可以让 AI 先做；不能，就必须人先做出结论，再让 AI 去挑毛病。

二、按顺序排查：从时间线缺口开始

复盘出问题，八成不是分析能力不行，是材料就有洞。按下面的顺序走。

**第一步，锁定时间基准。**先确定复盘用哪个时区，然后把所有材料的时间戳换算过去。日志里的 Unix 时间戳、监控面板的本地时间、聊天记录的客户端时间，很容易差出几个小时。换算随手可查：

python -c "import datetime,sys;ts=int(sys.argv[1]);print(datetime.datetime.fromtimestamp(ts,datetime.timezone.utc).isoformat())" 1784538000

**第二步，画出材料覆盖的时间窗，找缺口。**把每一类材料的起止时间列出来，你会发现日志只留了最近几天而事故起点更早，或者某台机器的日志压根没采上来。缺口必须在时间线里显式标注为”此段无数据”，而不是让 AI 用上下文把它圆过去。这是最容易被跳过的一步，也是后面所有误判的源头。

**第三步，把”变更清单”单独拉一份。**事故的成因绝大多数落在变更上：代码发布、配置改动、依赖升级、数据订正、上游方的调整。代码侧可以直接拉：

git log --since='2026-07-20 09:00' --until='2026-07-20 13:00' \
  --date=iso --pretty=format:'%h %ad %an %s'

配置和环境变量的改动往往不在 git 里，得去配置中心的操作审计里翻。翻不到就写”无审计记录”，别猜。相关的坑在配置项跨环境传递那篇里说得更细。

**第四步，把时间线和变更清单一起交给 AI，只要它做一件事：列出所有时间上相邻的”变更—异常”配对，并对每一对写出”如果这是因果，应该还能观察到什么”。**这一步的产出不是结论，是可验证的假设集合。人的活是逐条去验证那个”还能观察到什么”。

**第五步，验证假设。**能在测试环境复现的，复现；不能复现的，找旁证——同一变更是否在其他集群也生效了却没出事，异常是否在变更前的低流量时段其实已有苗头。旁证站不住，这条假设就降级为”疑似”，写进复盘文档时必须带上这两个字。

三、判别表：常见现象与处置

现象	大概率成因	怎么验证	处置动作
AI 拼的时间线里事件顺序明显反了	材料时区不一致，或日志采集端有缓冲延迟	挑一条同时出现在两个系统里的事件，对比两边时间戳差值	统一换算到同一时区后重拼；采集延迟稳定的话在时间线里标注偏移量
根因写得很顺，但改进项落不下去	根因停在了现象层（如”服务不可用”），没到可干预层	对根因问一句”针对这句话我明天能改什么”，答不上来就是没到底	人工往下追问，直到落到某个具体的代码分支、配置项或流程环节
同一批材料，两次让 AI 分析给出不同根因	材料本身不足以支撑唯一结论	把两次结论并排，看分歧点是否都落在缺数据的时段	停止分析，先补数据；补不到就在文档里并列两个假设，不硬选
时间线里有一段完全空白却被叙述得很连贯	模型用常见故障模式填补了缺口	拿叙述里的每句话回查材料，逐句标出处	无出处的句子整句删除，改写为”此段无数据”
复盘结论指向某个人的操作失误	归因停在了人，没到系统防护缺失	问”换个人在同样的信息条件下会不会也这么做”	会，就把根因改写为防护缺失；改进项对准卡点和可见性，不对准人
明明回滚了，指标却没立刻恢复	存在缓存、连接池、已污染的数据或下游重试堆积	看回滚生效时刻与指标拐点的间隔，比对缓存过期与连接回收周期	时间线上把”回滚动作”和”回滚生效”拆成两个事件，别当一件事
涉及外部服务的报错（429/500）被直接判为对方的锅	我方重试策略放大了请求量	统计事故窗口内我方出站请求量与平时的倍数关系	先核自己的重试与并发，再谈对方；相关处置见接口超时与中断

表里最值得警惕的是倒数第三行。把根因写成”某人操作失误”，复盘就结束了，因为改进项只能写”加强培训”。而真正该问的是：为什么这个操作没有二次确认、为什么错了没有立刻可见、为什么恢复要靠人的记忆。

四、可执行的做法与验收动作

**做法一：材料入库前先脱敏。**日志里带着密钥、令牌、用户手机号是常态，整批粘给外部模型服务就是一次数据外泄。脱敏用固定规则做，别靠人眼扫。验收动作：脱敏后的样本随机抽若干行，用正则回查是否还有形如密钥的长串。这块的完整思路见日志里的敏感信息处理。

**做法二：给 AI 的每一句结论都要求带出处。**要求格式是”结论 + 支撑它的原始行”。验收动作：随机抽三条结论，把出处那几行拉出来自己读一遍，看是否真能推出那个结论。抽三条里错一条，这份产出整体退回重做，不要只改那一条。

**做法三：根因用”往下追问”的方式收敛，而不是让 AI 一次给结论。**人提出一个候选根因，让 AI 扮演质疑方，专门找这个结论站不住的地方。这个方向比让它直接给答案可靠得多，因为挑错比立论容易验证。

**做法四：改进项必须带主人、期限和验收条件三样。**没有验收条件的改进项，下次同类事故还会原样再写一遍。验收条件要能被观测到，比如”某告警在测试环境注入故障后能在预期时间内触发”，而不是”提升稳定性”。

**做法五：复盘文档的结论段落由人手写。**前面的材料整理、时间线、假设列表都可以是 AI 产出，但”我们认为根因是什么、我们决定改什么”这两段必须是人自己敲的。这不是仪式感，是因为写的过程会逼你发现自己其实还没想清楚。

五、什么情况下别再折腾

复盘也会陷进去。出现下面任何一条，停手。

**止损点一：材料缺口超过事故时长的一小半。**关键时段没有日志、没有指标、没有操作记录，再怎么分析都是编故事。这时候正确的做法是把复盘的产出改成”我们无法定位根因”，同时把改进项全部指向可观测性——补日志、补审计、补留存。承认查不出来，比编一个根因诚实，也更有用。

**止损点二：连续两轮验证都推翻了当前的最优假设。**说明思路方向有问题，继续在同一条线上加材料是浪费。退回到时间线，从被忽略的那类材料重新起（通常是配置改动、上游方变更、定时任务）。

**止损点三：讨论开始围绕”是谁的责任”打转。**技术复盘和责任认定是两件事，混在一起两件都做不好。当会议出现这个苗头，明确宣布本场只出技术结论，责任问题另开。

**回滚点：如果复盘是为了决定要不要恢复某个被临时关掉的功能，而根因未明，默认保持关闭。**先补上能在下次出事时看清现场的观测手段，再考虑打开。宁可少一个功能，不要在盲区里赌第二次。

**换条路的判断依据：如果同一类事故在一段时间内反复出现三次以上，且每次复盘都给出不同根因，问题多半不在具体某次事故，而在架构或流程。**这时候该做的不是第四次复盘，是一次针对这个模块的专项梳理。

六、避坑清单

**坑一：把 AI 整理的时间线直接当成事实基础。**为什么会踩——时间线格式整齐、时间戳精确到秒，看起来就像原始数据的搬运，人会不自觉降低戒心。怎么避——要求每个事件后面挂上来源标识（哪个文件、哪条日志、哪个系统），复核时按来源抽查，而不是通读一遍觉得顺就过。

**坑二：让 AI 一次读完全部材料再出结论。**为什么会踩——图省事，觉得一次给全上下文最完整。实际上材料一多，靠后的内容权重会被稀释，模型倾向于抓住开头和结尾的信息编织叙事。怎么避——分阶段：先只做归集，再只做排序，再只做假设枚举，每一步的产出人先验收再进下一步。上下文管理的通用做法可参考上下文污染的识别与清理。

**坑三：用模型生成的”相似历史事故”当旁证。**为什么会踩——它写得很像真的，甚至会带上时间和影响范围。但你的内部事故库它并不知道，输出的多半是合成物。怎么避——历史事故只从自家事故库检索，检索结果由人贴进来；模型只允许对你贴进来的内容做比对。

**坑四：忽略”回滚动作”与”回滚生效”之间的时间差。**为什么会踩——发布系统显示回滚成功的那一刻很显眼，容易被当作分界线。但缓存、连接池、消息积压都会让影响延续下去。怎么避——时间线上强制把这两个事件分开记录，中间的间隔单独解释一句。

**坑五：把日志缺失当成系统正常。**为什么会踩——分析的时候只看得到有的东西，看不见的自然不进入视野。怎么避——在时间线里为每一类材料画一条覆盖区间，空白段显式画出来，让缺口和事件同样可见。

**坑六：复盘文档写完就归档，改进项没人跟。**为什么会踩——事故过去了，注意力回到业务上，改进项没有进入日常的任务系统。怎么避——复盘会散会前，改进项当场进任务系统并指定主人，会议记录里只留链接不留正文，避免出现两份不同步的版本。

**坑七：把海外工具当作可以随手接入的一环。**为什么会踩——看到的教程默认能直连，就在流程里写死了。实际情况是这类服务的官方条款对中国大陆有区域限制，不支持直连使用；市面上存在第三方中转，但稳定性、合规性和数据流向都由你自己承担，不宜写进正式流程。怎么避——涉及事故材料这类敏感数据的环节，优先用你所在组织已经完成合规评估的方案。

**坑八：让 AI 帮忙”润色”根因表述。**为什么会踩——想让文档读起来专业一点。润色的结果通常是把带条件的判断改成不带条件的断言，“疑似""在某某前提下”这些限定词会被磨掉。怎么避——结论段落禁止润色；要润色只润事实叙述部分，改完用 diff 逐处对照。

收束

事故复盘的产出质量，取决于两件事：材料够不够完整，以及有没有人愿意为结论签字。AI 把第一件事的成本压下来了，这是实打实的价值——材料归集这道纯体力活的耗时能明显往下走，具体压缩到什么程度取决于你的材料散在几个系统、格式统不统一，得自己拿一次真实复盘去量。但它没有、也不该改变第二件事。谁签字，谁就得能回答”如果这个根因是错的，代价是什么”。

散会前对着下面这几条过一遍：

• 时间线里的每个事件是否都有可回查的来源？
• 材料缺口是否被显式标注，而不是被叙述填平？
• 根因是否落到了可干预的具体环节，而不是停在现象或某个人身上？
• 每条改进项是否都有主人、期限和可观测的验收条件？
• 结论段落是不是人自己写的？

五条里有一条答不上来，这份复盘就先别发出去。日志留存和可观测性的地基如果不牢，下一次你还会在同一个地方卡住，可以先看Agent 可观察日志的设计把地基补上。