文摘摘要：本文复盘了一次支付回调服务 P95 延迟告警的排查过程，记录如何用 Gemini 3.5 Flash 辅助整理脱敏日志、监控摘要、测试报告和发布记录。文章重点介绍日志切片、Prompt 约束、时间线生成、可疑原因排序、证据与反证区分、复盘初稿生成等流程，并强调 AI 只适合做线索归纳和排查辅助，根因确认仍需依赖人工验证、SQL 执行计划、代码 Diff、监控数据和团队评审。

上周有个比较典型的线上问题：支付回调服务在 20 分钟内连续触发 P95 延迟告警，监控面板上看得到抖动，但没有直接宕机；应用日志、Nginx 日志、MQ 消费延迟、数据库慢查询、测试环境回归报告散在几个地方。以前遇到这种情况，我一般是手动 grep、拼时间线、再找研发和测试对齐，过程不复杂，但很耗人。

这次我尝试把 Gemini 3.5 Flash 放进排查流程里。为了减少不同模型之间来回切换的成本，我把同一批脱敏日志放在一个多模型聚合环境里观察过，测试环境是 https://ouai.me，它可以在同一界面切换 ChatGPT、Claude、Gemini、Grok 等模型，比较适合同题复跑、文档整理、代码分析和任务拆解。

这篇不是模型排行榜，也不是说 AI 能代替 SRE 或后端排障。我的结论更克制一点：Gemini 3.5 Flash 适合做“快速归纳 + 时间线整理 + 可疑点排序”，但最终判断仍然要回到监控数据、代码变更、压测结果和人工 Review。

问题场景：告警很多，但没人能马上说清主因

这次异常发生在一个 Java / Spring Boot 服务上，链路大致是：

支付网关 -> Nginx -> payment-callback-service -> Kafka -> order-service -> MySQL

告警现象包括：

• payment-callback-service P95 延迟从 180ms 涨到 1.8s；
• Kafka 某个 topic 出现短暂堆积；
• MySQL 有几条慢查询，但不是持续性爆发；
• Nginx 502 很少，不像服务整体不可用；
• 最近一次上线改过回调幂等逻辑；
• 测试环境没有复现，但回归报告里有一条“重复回调场景耗时增加”。

这类问题麻烦在于：每个单点都像原因，又都不像最终原因。人工排查时，大家很容易围绕自己熟悉的领域下判断：后端怀疑数据库，测试怀疑幂等逻辑，运维怀疑 Kafka，产品只关心订单状态有没有错。

所以我把 AI 的任务定义得很窄：不要让它给最终结论，只让它帮我整理线索。

核心模块一：先做日志脱敏和切片，不要整包丢给模型

生产日志不能直接交给 AI。即使只是内部辅助分析，也要先做脱敏和裁剪。

我保留的信息只有这些：

保留字段	用途
时间戳	拼接异常时间线
traceId 哈希后片段	关联同一请求链路
服务名	判断异常发生位置
接口名抽象值	区分回调、查询、补偿任务
状态码	判断失败类型
耗时区间	分析延迟变化
异常类型	判断错误类别
Kafka lag 区间	判断消息堆积影响

我会移除或替换：

• 用户手机号、邮箱、姓名；
• 真实订单号、支付流水号；
• 商户号、渠道号；
• 内部 IP、机器名；
• 数据库连接串；
• 完整 token、签名、密钥；
• 真实网关地址和供应商名称。

脱敏后，日志片段大概长这样：

2026-xx-xx 10:12:03.231 service=payment-callback trace=t_8f31 api=callback_pay status=200 cost=186ms msg=received callback
2026-xx-xx 10:12:04.018 service=payment-callback trace=t_8f31 api=callback_pay status=200 cost=1680ms msg=idempotent_check slow
2026-xx-xx 10:12:04.552 service=payment-callback trace=t_8f31 event=kafka_send topic=pay_callback cost=320ms
2026-xx-xx 10:12:05.102 service=order-service trace=t_8f31 event=consume_callback cost=220ms

这里有个经验：不要一次性把几万行日志都丢进去。更稳的方式是按时间窗口切片，例如：

• 异常前 10 分钟；
• 告警开始后 10 分钟；
• 告警高峰期 10 分钟；
• 告警恢复后 10 分钟。

然后让模型只比较这些窗口里的差异。

核心模块二：给 Gemini 3.5 Flash 的 Prompt 要限制角色和输出格式

第一次我问得比较随意：

帮我分析这批日志，找出线上延迟升高的原因。

结果输出看起来很完整，但有不少“经验性推测”，比如直接说数据库连接池耗尽、Kafka broker 异常。这些在日志里并没有明确证据。

后来我改成下面这种 Prompt：

你是一个 SRE 辅助分析助手。
请根据下面脱敏后的日志、监控摘要和测试报告片段，整理“可疑原因清单”。

要求：
1. 不要给最终结论；
2. 只基于输入材料分析，不要补充材料中没有的系统信息；
3. 把“有证据支持”和“只是推测”分开；
4. 按时间线整理异常出现顺序；
5. 输出 JSON，字段包括：
   - timeline：关键事件时间线
   - evidence：有证据支持的现象
   - suspects：可疑原因，包含置信度、证据、反证、需要人工确认的数据
   - missing_info：还缺哪些信息
   - next_checks：建议人工下一步检查项

这类 Prompt 的重点不是“写得复杂”，而是把模型限制在辅助分析范围里。尤其是：

• 不要最终结论；
• 区分证据和推测；
• 要求反证；
• 要求缺失信息；
• 输出结构化结果。

Gemini 3.5 Flash 在这种结构化整理上响应很快，适合反复调整输入窗口和 Prompt。它不一定每次都给出最深的根因分析，但能快速把散乱线索压成一份可讨论的清单。

核心模块三：让模型先排“嫌疑顺序”，再人工验证

模型给出的可疑原因清单，我不会直接接受，而是转成排查表。

示例输出整理后大致如下：

可疑原因	证据	反证	人工检查
幂等检查耗时上升	多条日志出现 idempotent_check slow，时间与告警吻合	不是所有请求都慢	查幂等表索引、SQL 执行计划
Kafka 发送耗时增加	部分 trace 中 kafka_send 从几十 ms 到 300ms+	lag 是短暂堆积，不是持续恶化	查 broker 指标、网络抖动
MySQL 慢查询影响回调	告警窗口有慢查询	慢查询量不高	查慢 SQL 是否与幂等逻辑相关
下游 order-service 消费变慢	消费耗时略升	回调服务延迟先出现	确认是否因上游堆积传导
Nginx 层问题	有少量 502	数量太少	仅作为边缘检查项

真正推进排障的是这张表，而不是 AI 的自然语言解释。

最后我们人工确认的结果是：上线后幂等检查逻辑新增了一个组合条件，但索引没有覆盖；高峰期重复回调增加后，幂等查询耗时被放大，导致回调服务处理时间上升，并进一步带来 Kafka 短暂堆积。也就是说，Kafka 和慢查询都出现了，但主线还是幂等查询路径。

这正好说明 AI 在排障中的位置：它帮你缩小搜索范围，但不能替你跑 SQL、看执行计划、回滚验证。

辅助模块一：把测试报告也喂进去，能少走弯路

这次有个关键线索来自测试环境回归报告：

重复支付回调场景：
预期：第二次回调命中幂等逻辑，快速返回
结果：接口返回成功，但耗时从 120ms 上升到 650ms
备注：测试环境数据量较小，未判定为阻塞问题

单看这条记录，可能不会引起足够重视。但和生产日志合在一起看，它就变成了非常重要的证据。

我会用这样的 Prompt 让模型对齐测试报告和生产现象：

请比较“生产异常日志”和“测试回归报告”之间是否存在相互印证的线索。

要求：
1. 找出相同接口、相同逻辑路径、相同异常现象；
2. 不要把测试环境现象直接等同于生产原因；
3. 标出哪些测试用例需要补充数据量、并发量或边界条件；
4. 输出为表格。

得到的表格通常对测试同事也有帮助：

生产现象	测试报告线索	是否印证	需要补测
幂等检查耗时上升	重复回调场景耗时增加	部分印证	大数据量幂等表
Kafka 短暂堆积	测试未覆盖消息堆积	不足	并发回调 + 消费延迟
慢查询出现	测试环境数据量较小	不足	导入接近生产规模数据

这个动作不复杂，但能把“测试环境没复现”改成“测试环境没覆盖足够条件”，讨论质量会高很多。

辅助模块二：让 AI 生成复盘初稿，但必须保留证据链

事故复盘文档最怕两种情况：一种是写成流水账，另一种是写成甩锅材料。AI 可以帮助起草，但一定要要求它基于证据链。

Prompt 示例：

请根据下面的时间线、排查记录和最终人工确认结果，生成一份故障复盘初稿。

结构：
1. 影响范围
2. 时间线
3. 直接原因
4. 触发条件
5. 为什么测试阶段未发现
6. 修复动作
7. 长期改进项

要求：
- 不要夸大影响；
- 不要归因到个人；
- 每个结论都要对应证据；
- 对不确定内容标记“需进一步确认”。

生成后我会重点检查：

• 时间是否准确；
• 影响范围有没有被夸大；
• 根因是否和人工确认一致；
• 是否把推测写成事实；
• 改进项是否可执行。

比如“加强测试”这种话没意义，应该改成：

为重复回调幂等场景增加大数据量压测用例；
上线前检查涉及高频查询路径的索引覆盖情况；
将 idempotent_check cost 纳入业务埋点监控。

辅助模块三：成本敏感时，把任务拆给不同模型或不同轮次

Gemini 3.5 Flash 的优势之一是响应速度较快，适合做多轮摘要、分类、结构化提取。但复杂根因分析不能只靠模型速度。

我的实际流程会拆成几轮：

1. 日志清洗：脚本完成，不交给模型；
2. 窗口摘要：让 Gemini 3.5 Flash 快速归纳每个时间段；
3. 时间线拼接：继续用同一模型输出结构化 JSON；
4. 可疑点排序：让模型列证据、反证和缺失信息；
5. 人工验证：查监控、SQL、代码 diff、发布记录；
6. 复盘初稿：模型生成，人工改写；
7. 最终评审：研发、测试、SRE 一起确认。

如果是特别复杂的事故，我会把结构化结果再交给其他模型做一次“挑错”，但不会搞成模型投票。不同模型的价值在于发现遗漏，而不是替团队做最终判断。

一个可复用的 Gemini 3.5 Flash 排障 Prompt 模板

下面这个模板可以直接改：

你是一个线上问题排查助手，任务是帮助整理线索，而不是给最终结论。

输入材料包括：
- 脱敏应用日志
- 监控摘要
- 测试报告片段
- 最近变更记录

请输出：
1. 异常时间线；
2. 与告警时间吻合的现象；
3. 可疑原因清单，按优先级排序；
4. 每个可疑原因的证据、反证、置信度；
5. 需要人工继续确认的数据；
6. 建议下一步排查动作。

限制：
- 不要编造日志中没有的服务、接口、数据库表；
- 不要把推测写成事实；
- 如果证据不足，明确写“证据不足”；
- 输出 Markdown 表格；
- 最后给出 5 条以内的人工检查建议。

如果你希望结果更容易被程序处理，可以把输出改成 JSON：

{
  "timeline": [],
  "confirmed_observations": [],
  "suspects": [
    {
      "name": "",
      "confidence": "",
      "evidence": [],
      "counter_evidence": [],
      "manual_checks": []
    }
  ],
  "missing_info": [],
  "next_actions": []
}

结构化输出的好处是后续可以沉淀到故障复盘系统、知识库或工单里。

验收标准：怎么判断 AI 分析有没有用

我给这类 AI 输出设了几个简单标准：

验收项	合格标准
时间线	能覆盖告警前、告警中、恢复后三个阶段
证据区分	明确区分事实、推测和缺失信息
可疑点排序	排名前几项能对应真实日志或监控
反证意识	不只列原因，也列为什么可能不是
可执行性	下一步检查能落到 SQL、监控、代码 diff 或压测
安全性	不包含敏感数据、真实客户信息和内部密钥
可复核性	人工能根据输出回到原始材料核对

如果 AI 输出只是“可能是数据库、网络、缓存、队列问题”，那价值很低。真正有用的输出应该能告诉你：为什么怀疑它、证据在哪、还缺什么、下一步查哪张图或哪段代码。

常见误区

1. 直接把生产日志原样贴给模型

不建议。日志里很容易带出用户信息、内部地址、token、订单号、商户信息。先脱敏，再抽样，再分析。

2. 让 AI 直接判断根因

AI 可以辅助归因，但根因必须由人工结合监控、代码、配置、发布记录确认。尤其是线上事故，复盘文档不能只引用模型输出。

3. 忽略测试报告里的“小异常”

测试环境没复现，不代表线索没价值。低数据量、低并发下的轻微耗时增加，放到生产高峰可能会被放大。

4. Prompt 写得越长越好

不一定。排障类 Prompt 最重要的是约束边界：不编造、不下最终结论、区分证据和推测、输出可验证检查项。

风险边界和团队落地建议

在公司内部落地这类流程时，建议先从低风险场景开始，例如：

• 历史事故复盘；
• 脱敏后的测试日志分析；
• 压测报告整理；
• 非敏感告警摘要；
• 研发自测阶段的异常归类。

不要一开始就把实时生产全量日志、客户数据、合同信息、金融交易明细、医疗记录等内容交给 AI。涉及金融、医疗、政务、教育等场景时，AI 只能作为辅助整理工具，不能替代专业人员做最终判断。

对研发团队来说，比较稳的落地方式是：

1. 用脚本完成日志清洗和脱敏；
2. 用 Gemini 3.5 Flash 做快速摘要和可疑点整理；
3. 用固定模板要求模型输出证据、反证和缺失信息；
4. 人工验证 SQL、监控、代码 diff 和配置；
5. 把确认后的结论沉淀到复盘文档和测试用例中。

结尾：把 AI 放在“整理线索”的位置上

这次排障后，我对 Gemini 3.5 Flash 的定位更明确了：它不适合被当成线上事故的裁判，但适合当一个不知疲倦的日志整理助手。尤其在日志、监控、测试报告、发布记录分散的时候，它能快速帮你拼出时间线，把可疑点按证据强弱排出来。

如果你是后端开发、测试工程师或 SRE，建议先选一个历史问题做离线实验：准备一批脱敏日志，写清楚输出格式，让模型只做线索整理，再对照真实复盘看它漏了什么、猜错了什么。这样比直接把它接进生产流程稳得多。

AI 能提高排查效率，但线上质量最终还是靠监控、测试、代码审查、发布流程和人的责任心。把边界划清楚，它才更像一个可靠的工程助手，而不是另一个需要排查的不确定因素。