故障复盘实操指南：Gemini 3.5 Flash从群聊日志到RCA
上次线上故障复盘，一开始就被一个现实问题卡住：真正棘手的，从来不是“让 AI 写一篇复盘”，而是如何把散落在群聊、告警、日志片段、工单备注和接口监控截图里的信息，整合成一条经得起反复推敲的时间线。以前全靠人工翻记录，半天下来，结论还容易被一句“这个时间点对不上”直接推翻。
这次复盘我们主要借助 Gemini 3.5 Flash 进行信息压缩和结构化处理，中途也将同一批脱敏后的数据，放到一个多模型聚合环境中交叉验证。需要明确一点：工具只提供环境，关键仍在于任务拆分、数据脱敏和人工校验。
这篇文章更像一次工作流复盘，适合运维/SRE、后端开发、测试工程师及技术负责人参考。场景并不是让模型替你“判断根因”，而是让 Gemini 3.5 Flash 在那些高频、低风险、可验证的环节发挥作用：整理资料、抽取时间线、生成待确认问题、辅助撰写 RCA 初稿。
这次故障复盘为什么一开始就翻车
故障背景并不复杂：某个订单查询接口在周一上午出现 P95 延迟抖动，部分用户反馈列表页加载缓慢。监控数据显示，服务没有整体宕机，CPU 也未打满，但接口耗时突然从 200ms 左右飙升到 1.5s 以上。
一开始，我们把脱敏后的告警信息、几段日志和群聊记录直接丢给模型，指令是“分析故障原因并写复盘”。输出看起来像模像样：
- 根因：数据库慢查询；
- 影响：订单列表查询变慢；
- 修复：增加索引；
- 预防：完善监控。
问题在于，当时还没有确认是否真的是数据库索引导致的。更糟糕的是，模型把一个“讨论中的假设”直接写成了“最终根因”。如果这份内容直接进入复盘文档，后续评审必定会被打回来。
事后才意识到，RCA 不是作文题。AI 在这里不应该先给结论，而应该先帮人把证据整理清楚。
核心模块一：先把资料分层，不让模型直接下判断
我们将输入材料分为四类，每一类都先完成脱敏处理：
| 材料类型 | 示例 | 处理方式 |
|---|---|---|
| 告警记录 | 接口耗时、错误率、数据库连接数 | 保留时间、指标名、变化趋势 |
| 应用日志 | TraceId、接口名、耗时、异常摘要 | 去掉用户 ID、手机号、订单号 |
| 群聊记录 | 排查过程、临时结论、操作动作 | 标注发言角色，不保留真实姓名 |
| 工单备注 | 影响范围、恢复时间、后续任务 | 保留事实，删除客户敏感信息 |
然后，给 Gemini 3.5 Flash 的第一个任务不是“分析根因”，而是：
你是故障复盘资料整理助手。下面是脱敏后的告警、日志摘要、群聊记录和工单备注。
请只做信息结构化，不要判断最终根因。
输出：
1. 按时间顺序整理事件时间线；
2. 标记每条信息来源：告警 / 日志 / 群聊 / 工单；
3. 区分“事实”“猜测”“已执行操作”“待确认问题”；
4. 如果时间点冲突，请列出冲突位置，不要自行修正；
5. 不要补充输入材料中没有出现的信息。这个 Prompt 的关键在于“不要判断最终根因”。在故障复盘里，过早给出结论风险极高。模型的长处在于快速整理大量信息，但最终的责任判断必须由工程师结合监控、代码、变更记录和业务背景来确认。
核心模块二：让 Gemini 3.5 Flash 先产出时间线，而不是复盘全文
第一次有效输出是一个时间线表格，格式如下：
| 时间 | 事件 | 来源 | 类型 | 备注 |
|---|---|---|---|---|
| 09:58 | 订单查询接口 P95 延迟开始升高 | 告警 | 事实 | 从 200ms 上升到 800ms |
| 10:03 | 用户反馈列表页加载慢 | 工单 | 事实 | 影响部分区域用户 |
| 10:06 | 研发发现订单查询服务无明显错误率上升 | 群聊 | 事实 | 错误率未同步升高 |
| 10:12 | 有人怀疑数据库慢查询 | 群聊 | 猜测 | 尚未提供慢查询证据 |
| 10:18 | 连接池等待时间升高 | 监控 | 事实 | 需核对数据库侧指标 |
| 10:25 | 临时扩容应用实例 | 群聊 | 已执行操作 | 延迟略有下降但未恢复 |
| 10:41 | 回滚上午 09:40 的查询逻辑变更 | 工单 | 已执行操作 | 延迟恢复至正常区间 |
这张表远比直接生成复盘报告更有价值。因为它明确区分了“事实”和“猜测”，也将排查动作与恢复动作分离开来。
实际使用时，会让模型再做一轮检查：
请审查上面的时间线：
1. 哪些结论缺少证据？
2. 哪些时间点可能存在因果关系，但不能直接确认？
3. 哪些信息需要从监控、代码提交、数据库审计或发布记录中补证？
4. 请不要写最终根因，只列核查清单。这一步非常适合 Gemini 3.5 Flash。它响应速度快，适合对同一份材料进行多轮结构变换：时间线、问题清单、证据缺口、复盘大纲。它不一定能替你完成最深入的推理，但能显著减少人工在材料堆里反复翻找的时间。
核心模块三：用“证据矩阵”约束 RCA 初稿
当时间线和证据基本清晰后，才进入 RCA 初稿阶段。这里没有让模型自由发挥，而是先准备一个证据矩阵：
| 候选原因 | 支持证据 | 反证 / 疑点 | 结论状态 |
|---|---|---|---|
| 数据库慢查询 | 连接池等待升高；部分 SQL 耗时增加 | 慢查询开始时间晚于接口耗时升高 | 待确认 |
| 应用实例不足 | 扩容后延迟略降 | CPU、内存不高，不能解释全部问题 | 非主因可能 |
| 查询逻辑变更 | 回滚后恢复；变更时间接近故障开始 | 需核对具体代码差异 | 高度相关 |
| 外部依赖波动 | 无明确错误率上升 | 缺少外部接口耗时证据 | 暂无证据 |
然后再给 Gemini 3.5 Flash：
请基于下面的时间线和证据矩阵，生成一份故障复盘初稿。
要求：
1. 只使用已提供证据；
2. 根因表述必须体现确定性等级，例如“已确认”“高度相关”“待补证”；
3. 不要把猜测写成事实；
4. 复盘结构包括：背景、影响范围、时间线、根因分析、处置过程、改进项；
5. 改进项要能落地，避免“加强监控”这类空泛表达；
6. 输出后附上一段“仍需人工确认的问题”。这样得到的文档质量会稳定很多。它不再像模板作文，而更像一份可以进入评审的初稿。
辅助模块一：日志和代码片段要先脱敏再输入
这个要点大家应该都明白，但实际工作中还是容易图省事。尤其在故障发生后，急于快速定位问题，很容易直接把日志、SQL、配置贴给模型。
正确的做法是保留分析所需的结构，同时去掉敏感内容：
原始日志：
2025-xx-xx 10:14:22 userId=8362 phone=138xxxx orderNo=OD2025xxxx
/api/order/list cost=1532ms traceId=abc123 sql=select ...
脱敏后：
2025-xx-xx 10:14:22 userId=[USER_ID] phone=[PHONE] orderNo=[ORDER_NO]
/api/order/list cost=1532ms traceId=[TRACE_ID_A] sql=[SQL_TEMPLATE_1]如果需要分析 SQL，也尽量提供“结构化模板”，避免出现真实客户数据：
SELECT columns
FROM order_table
WHERE user_id = ?
AND status IN (?, ?)
ORDER BY create_time DESC
LIMIT ?, ?;模型不需要知道真实的手机号、订单号或客户名称。如果输入中包含公司内部地址、密钥、Token、客户合同、医疗信息或金融账户等内容，必须提前处理，不能图省事。
辅助模块二：把输出当“待验证假设”，不要当结论
我们把 AI 的输出划分为三个等级：
- 可直接采用的结构化结果：比如时间线表格、字段归类、待确认问题列表；
- 需要人工确认的分析结果：比如候选根因、影响范围、改进项优先级；
- 不能直接采用的责任判断：比如最终事故定级、责任归属、对外口径、客户赔付建议。
Gemini 3.5 Flash 在第一类和第二类任务上表现非常实用，尤其适合快速将混乱的材料整理成“人能审”的形态。但第三类必须由团队按流程确认。
这里有一个小技巧：让模型在每个结论后面标注证据来源。
请在每个分析结论后标注：
- 证据来源；
- 证据强度：强 / 中 / 弱；
- 是否需要人工确认；
- 如果缺证，请说明缺什么证据。这样做的好处是，评审会上不会只看到一段漂亮的文字，而是能清晰地了解它依赖哪些材料。
辅助模块三：多模型交叉验证适合放在“疑点清单”阶段
不建议每个环节都做多模型对比，这样太耗时，也容易把流程复杂化。比较合适的节点是在“疑点清单”阶段。
例如，针对同一份资料，让不同模型回答：
请只找这份故障资料中可能存在的矛盾、缺证和因果跳跃。
不要写复盘稿，不要给最终根因。如果多个模型都指出“回滚时间与恢复时间高度接近，但缺少代码差异说明”，那么这个点就值得优先补证。如果只有一个模型提出了某个很大胆的推断，就先当作假设，不要直接写进 RCA。
多模型的意义不是通过投票来决定真相，而是扩大审查视角。真正的结论仍然要回到监控、代码、发布记录和业务事实中确认。
一个可复用的故障复盘工作流
后来，我们将这套流程固化成了 7 步：
- 收集材料：告警、日志、监控截图说明、群聊记录、工单、发布记录；
- 脱敏处理：删除个人信息、客户信息、密钥、内部敏感地址；
- 结构化整理：让 Gemini 3.5 Flash 输出时间线和信息分类；
- 标记证据等级：区分事实、猜测、操作、待确认问题；
- 补证：回到监控、代码提交、数据库指标、发布平台查原始资料；
- 生成 RCA 初稿：严格要求只基于已确认材料；
- 人工评审：技术负责人、相关研发、运维、测试共同确认结论和改进项。
如果要进一步工程化，可以把 Prompt 固化到团队文档模板中。例如，每次故障都按相同格式提交资料，模型负责生成初版时间线，值班同学负责校验，复盘负责人再组织评审。这样 AI 就不是临时的救火工具，而是流程中的一个标准整理环节。
常见误区
1. 让模型直接写“事故根因”
这是最容易出错的用法。根因分析必须基于证据链，而不是基于语言的合理性。模型生成得越流畅，越要警惕它把假设写成了事实。
2. 把群聊里的猜测当证据
群聊记录很有价值，但它记录的是排查过程，不等于最终事实。建议让模型把群聊内容单独标记为“猜测”“动作”或“确认信息”。
3. 复盘文档只写“加强监控”
“加强监控”不是可执行改进项。更好的写法是：
- 为
/api/order/list增加 P95、P99 延迟告警； - 对查询逻辑变更增加压测门禁；
- 慢查询超过 500ms 自动关联 TraceId；
- 发布后 30 分钟内自动对比核心接口基线。
4. 忽略测试和回归验证
如果故障与代码变更有关，复盘里应该明确后续的测试如何补强：单元测试、接口压测、灰度验证、回滚演练，至少要能确保同类问题不再发生。
适合 Gemini 3.5 Flash 的任务边界
结合本次使用经验，对 Gemini 3.5 Flash 的定位已经非常明确：
适合：
- 大量文本资料的快速归纳；
- 时间线整理；
- 会议纪要和群聊记录的结构化；
- 故障复盘大纲生成；
- 风险点、疑点、待确认问题的提取；
- 多轮轻量改写和格式转换。
不适合直接承担：
- 最终根因判断；
- 事故责任认定；
- 未经验证的代码修改；
- 对外公告的最终口径；
- 涉及法律、金融、医疗等领域的专业责任判断。
它的价值不在于替代 SRE 或研发负责人，而是把资料从“散乱状态”推进到“可审查状态”。这一步看似不起眼，但对复盘质量的影响却非常大。
结尾：先从低风险、可验证的环节开始
如果团队还没有系统性地使用 AI 进行故障复盘，不建议一开始就让模型写完整的 RCA。更稳妥的起点是三个低风险任务：
- 整理时间线；
- 提取待确认问题；
- 生成复盘文档大纲。
这三件事都容易人工验证，也不涉及最终责任判断。等流程稳定后，再把证据矩阵、改进项拆解、评审清单逐步加入进来。
Gemini 3.5 Flash 这类模型在故障复盘中的最佳角色，是“资料整理员 + 疑点提醒器 + 初稿助手”。真正的结论仍然要回到原始监控、代码变更、数据库记录、测试结果和团队评审中去。只要守住脱敏、验证和人工责任链这三条底线，它确实能把一次混乱的故障复盘，变成一套更可控、更可复用的工程流程。