让AI辅助排障先建立证据链

AI 排查线上故障，最有价值的工作是替值班工程师收集证据：查指标、翻日志、对齐发布记录，再把可能原因按可信程度排出来。至于该不该回滚、是否切换数据库，仍然需要人判断。

这篇文章划出了一条实用边界：让 AI 加快调查，让权限限制执行，再用真实指标验证结果。它值得读的地方，是把「接入一个 AI SRE」拆成了可以检查的工程流程，也提醒我们：写出一段合理解释，距离找到根因还很远。

AI 能省下调查时间，却不能替你认定根因

作者把故障响应拆成两类工作。

第一类是调查：哪些服务受影响、什么时候开始异常、之前改了什么、请求慢在哪里。这些任务机械、分散，而且适合并行。人需要逐个打开仪表盘，Agent 可以同时查询指标、日志、调用链、发布历史和功能开关审计记录。原文认为，响应开始后的前 20 分钟，往往就花在这些事情上。

第二类是判断：是否回滚、叫醒谁、如何通知客户，以及如何处理业务取舍。例如，一个版本既引入故障，又修复了安全问题，是否回退就不能只靠模式匹配。

AI 擅长识别连接池耗尽、索引缺失、证书过期等已知模式；遇到陌生故障，它却可能编出一个听起来合理的解释。它还容易认准第一个符合现象的假设，漏掉多个因素叠加的情况。营销活动在 9:00 开始、支付供应商发过维护邮件，这些信息如果没有进入可读取的数据源，它也无从得知。

原文引用了一个具体测试：2025 年 8 月，ClickHouse 在 OpenTelemetry 演示应用中注入异常，让四个前沿模型通过 MCP server 访问可观测数据，结论是自主根因分析还没有成熟。

但原文没有提供模型名称、逐项成绩和完整实验条件。这能支持谨慎设计，不能直接推导出你们系统里的准确率。

AI 的解释要作为待验证的假设，而不是故障结论。

排查质量先取决于证据，再取决于模型

最容易出错的地方，是把告警时间当成故障开始时间。

告警通常在指标越过阈值后触发，真实异常可能已经持续了几分钟。Agent 应先从指标曲线定位异常起点，再向前留出余量，用同一时间窗口检查其他数据。否则，真正引发问题的变更可能刚好落在搜索范围之外。

接下来要收集的证据，可以按三条线组织：

• 沿请求路径找影响范围，从 APM 调用链和服务目录确认上下游，再检查数据库、队列、缓存和第三方依赖。
• 沿时间线找变化，包括发布、功能开关及其流量比例、配置与密钥变更、基础设施变更、数据库迁移、定时任务和自动扩缩容。
• 沿异常特征找差异，检查相对基线新增或明显增多的日志，以及慢请求、失败请求中的耗时位置，再关联历史事故和服务负责人。

这里的产物应该是一组带时间戳、能回到来源核对的事实。作者强调不要只抓「所有错误日志」，因为大量旧错误会淹没真正的新信号。

有了事实，才轮到假设排序。原文给出的示例是：功能开关在 09:41 从 10% 放到 100%，数据库 CPU 在 09:43 从 31% 升到 97%，93% 的慢调用片段都在等待同一个调用。

这条线索很强，但时间接近仍然不能证明因果。

一份可用的调查结果，还应写明高、中、低置信度，列出证据、排除项和推翻条件。比如「过去六小时没有发布」「支付供应商延迟正常」，能让接手的人知道哪些方向已经查过，避免再花 15 分钟反复怀疑发布。

还要区分根因和症状。连接池耗尽可能只是慢查询占住连接后的结果，单纯扩大连接池未必解决问题。若判断功能开关触发了慢查询，就应事先提出验证条件，例如关闭后五分钟内 CPU 是否下降。

执行成功之后，还要证明服务恢复

作者建议默认只给 Agent 只读权限，范围限于可观测数据、发布历史和功能开关审计记录。

修复建议则走另一条路径：明确执行什么、预期效果是什么、怎么撤销，再由人批准，通过权限受限的执行通道操作并记录批准者。代码修改以 pull request 提交，照常接受审查。

原文只给自动执行留了很窄的口子：结果可验证、操作可逆、影响范围可控。关闭十分钟前刚调整的功能开关可能符合条件，数据库故障切换则不符合。即使满足条件，也应在团队多次观察到同一建议正确之后，逐项开放权限。

这套边界能限制误判造成的损失。错误建议可能浪费几分钟，错误操作却可能丢掉处理中请求，或者把一个事故变成两个。

命令执行成功，只能证明动作完成，不能证明事故结束。

作者要求在行动前定义恢复标准，例如错误率低于告警阈值、接近基线，并连续保持十分钟。还应同时观察原因信号和症状信号：如果假设是慢查询，预期顺序应是数据库 CPU 下降，随后延迟改善，最后错误减少。

如果错误率降了，CPU 却没变，就需要继续解释。若结账服务十分钟后仍未恢复，Agent 应明确报告修复无效，重新检查其他假设。

这些时间点也应该进入复盘：异常起点、告警、首次评估、执行动作和确认恢复。时间线优先取自指标及审计记录，聊天适合补充决策理由，不能拿「有人发现问题的时间」代替「问题发生的时间」。

复盘中还要分开事实与推断。CPU 在 09:43 达到 97% 是观测，功能开关导致慢查询是结论，需要证据支持。责任分析应落到缺失索引、全量前缺少数据库影响检查等系统条件上。行动项由 AI 提建议，人确认负责人，最后像审代码一样审阅并合并文档。

我的判断

我认同这套流程，因为它把 AI 的输出变成了可核查的材料。尤其是「排除了什么」和「什么证据会推翻假设」，比一段自信的根因描述更有用。

但文章给出的主要是工程经验和产品能力描述，没有提供采用整套流程前后的对照数据。它没有证明具体能节省多少响应时间，也没有给出建议自动执行的安全成功率。

恢复验证同样要保留一点怀疑：撤销变更后指标恢复，会显著增强因果判断；如果同期还有流量回落或其他修复，也不能据此认定找到了唯一根因。

作者对平均恢复时间（MTTR）的提醒很实在。原文引用 Google 的 2021 年报告，以及 Courtney Nash 在 SREcon22 Americas 围绕公开事故库 VOID 的研究，指出事故时长分布偏斜，月度平均值很容易被一次长故障左右。更合适的是看逐次恢复时长、中位数和高百分位，同时跟踪 Agent 更直接控制的两项：告警到首次评估的时间，以及首位假设最终是否正确。

选型方面，作者倾向先买再自建。按原文截至 2026 年 10 月 10 日的厂商资料，Datadog Bits AI SRE 在当前文档中称为 Bits Investigation；incident.io、Rootly、PagerDuty、FireHydrant 和 Resolve.ai 分别覆盖调查、修复审批或复盘等环节。这是厂商资料汇总，并非横向实测。Freshworks 宣布收购 FireHydrant 的消息，也不能代替能力评估。

如果数据已经集中在一个平台，采购通常更容易起步。证据跨多个工具、遥测不能离开自身环境，或审批规则必须精确执行时，自建才有更明确的理由。

能拿来做什么

• 为 Node 服务排查先统一时间窗口，把异常指标、发布、功能开关、慢查询和调用链放到一起，并明确标出无法访问的数据源。
• 固定 AI 调查报告格式，要求每个假设都带证据、置信度、排除项和推翻条件，让值班工程师能快速核查。
• 把执行权限与调查权限拆开，先让 Agent 提交修复建议或 pull request；每次操作前写好撤销办法和指标恢复标准。
• 记录每次事故的首次评估耗时、首位假设命中情况和确认恢复时间，结合事故详情评估收益，避免仅凭月度 MTTR 决定是否扩大权限。