AI 辅助排查线上问题：从报错日志到定位根因的四步法

线上出问题最怕的不是报错本身，而是时间压力下无从下手：日志几千行、监控曲线一堆、群里消息刷个不停。大模型出现后，排查第一次可以做到“机器先读日志、人只做判断”。本文分享一套我在值班时跑通的 AI 辅助排查流程：先让 AI 收敛线索，再由人按步骤验证根因。

一、排查先定级：不要一上来就翻日志

收到告警先做两件事，三十秒内完成：

1. 定影响面：报错的是全部用户还是个别用户？是核心链路还是边缘功能？影响面决定要不要立刻降级或回滚；
2. 定时间窗：问题从几点几分开始？最近一次发布、配置变更、流量高峰分别在什么时间？时间窗是排查的锚点，没有它日志就是大海捞针。

定级之后再决定投入：全量故障先止血（降级、回滚、扩容），个别报错再慢慢查。顺序反了，就会一边救火一边翻日志，两头都慢。

二、第一步：把“原始材料”喂给 AI，而不是只问一句“怎么了”

只贴一句报错问 AI“怎么办”，得到的回答多半是通用建议。我的做法是先准备四样材料，一次性交给 AI：

• 报错原文：完整的堆栈或错误信息，不要只截最后一行；
• 时间线：故障开始时间、最近一次发布/变更时间、流量异常时间；
• 相关日志片段：报错前后 5 分钟内的关键日志，截取含请求 ID 的那几十行即可；
• 最近的改动：本次发布改了哪些文件、哪几个接口。

材料给全，AI 才能做真正的关联分析，而不是猜。我常用的开场指令是：“你是线上故障排查助手。以下是报错、日志和时间线，请先列出最可能的三个根因并按可能性排序，每个根因给出一条可验证的证据链，不要直接给修复方案。”

三、第二步：让 AI 收敛线索，人逐条验证

以一次真实的线上故障为例：用户反馈下单接口偶发 500，错误率约 3%，持续半小时。AI 读完日志后给出三个候选根因：

1. 数据库连接池打满：错误日志里出现大量“connection timeout”，且时间点与流量高峰重合；
2. 下游支付接口超时：超时日志集中在支付调用环节，但只占报错的 20%；
3. 新上线的风控规则误拦截：部分报错请求都命中了同一条风控规则。

我按 AI 给的证据链逐条验证：查连接池监控，活跃连接数在故障时段确实顶满；查支付超时占比，确实只有两成；查风控规则日志，被拦截的请求和报错请求并不完全重合。结论很清楚：主因是连接池打满，支付超时是连带现象，风控规则是误报。这一步 AI 的价值是“把三千行日志收敛成三条可验证的假设”，验证本身必须人来做。

四、第三步：修完先验证，再写复盘

定位到根因后，修复之前先问 AI 一个问题：“如果按这个方案修，还可能引入什么新问题？”这一步经常能拦住想当然的修复。比如这次连接池打满，粗暴地调大连接数可能压垮数据库，AI 提醒后我们改成“缩短空闲连接回收时间 + 给非核心接口加限流”，既缓解了故障，又没把压力传导给数据库。

修复上线后要做三件事：

• 观察至少 15 分钟，确认错误率回落到基线，监控曲线恢复正常；
• 保留证据：故障时间线、关键日志截图、修复前后的监控对比，全部贴进复盘文档；
• 写复盘：只写三点——根因是什么、为什么没早发现、下次如何更快发现。复盘超过一页就没人看。

五、一个可直接套用的排查提示词模板

你是线上故障排查助手。先分析，后给方案。

输入材料：

1. 报错原文：[粘贴完整报错/堆栈]
2. 时间线：故障开始 [时间]，最近发布 [时间]，最近变更 [时间]
3. 日志片段：[粘贴报错前后 5 分钟关键日志，含请求 ID]
4. 最近改动：[列出本次发布改动的文件/接口]

输出要求：

1. 按可能性排序，列出最可能的三个根因；
2. 每个根因给一条可验证的证据链（去哪里查、查什么指标、期望看到什么）；
3. 给出止血方案和根治方案，分开写；
4. 指出修复方案可能引入的新风险。

不要只给结论，每条判断都要说明依据。

六、效果与注意事项

按这套流程，我们团队的平均定位时间从 40 分钟左右压到 15 分钟以内，值班同学第一次遇到陌生报错也不再慌。但有三条红线必须守住：AI 的根因判断不能直接当结论，每一条都要有监控或日志证据；涉及资金、支付、订单状态的修复，必须人逐行确认改动再上线；生产环境的任何操作（重启、回滚、改配置）都要走审批，AI 的建议不能代替流程。

AI 不会替值班同学对线上负责，它只是把“从几千行日志里找线索”这一步变快了。判断哪个是真根因、修复会不会引出新问题，仍然是人的工作。把判断留给人，把收敛交给 AI，这才是 AI 辅助排查线上问题的正确分工。