串联 AI 助手排障，用证据支撑根因分析

我们的监控仪表盘一直显示，一切正常。在生产环境的 Kubernetes 平台上，整整一周，所有 namespace 加起来只记录到八次容器重启。

与此同时，客户的反馈却不断涌入：正在进行的实时通话会突然中断。

这两件事都完全属实。仪表盘回答的问题，和用户实际遇到的问题并不是同一个。要找出两者之间的脱节，我们需要串联四个各有所长的 AI 助手，提出精准的取证问题，并坚守一条不可妥协的规则：助手说的任何话，只有得到可执行查询、原始日志行或可核验的平台事件支持，才能算作证据。

下面介绍这次调查的工作流、帮助我们找到真实数据的 prompt，以及如何组织事后的根因分析（Root Cause Analysis，RCA），让技术负责人、支持团队和审计人员都能真正信赖它。

每个助手都只能看到故障的一个侧面

使用 AI 辅助排障时，最大的错误就是让一个模型诊断整个分布式系统。

遥测数据揭示故障造成的影响。

云控制平面揭示外部触发因素。

代码库揭示设计意图。

没有任何单个工具或 context window，能够同时对这三个层面拥有端到端的可见性。

如果你的可观测性信号来自 Datadog、Honeycomb 或 New Relic，工作流仍然相同：从遥测数据入手，定位平台边界，再检查应用约定的行为。

调查循环

1. 打开任何工具之前，先明确问题陈述

调查能走多远，严格受限于最初的问题陈述有多精准。我每次都会使用下面这个结构化模板：

Incident summary: <what users or the platform report, 1-2 sentences>
Timeframe: <start UTC> to <end UTC> (include first user symptom and last known good state)
Scope: <clusters, namespaces, services, cloud providers>
Current dashboard signal: <e.g., container restart count across namespaces>
What does not match: <e.g., users report dropped audio streams, but pod restarts remain near zero>
Focus areas: <pod lifecycle, node events, provider timeouts, latency spikes, deploy history>
Constraints: <which logs are ingested vs. which signals are uncollected>
Output requested: UTC timeline, hypothesis list with status, confidence level, evidence gaps, next steps

其中最关键的一行是“What does not match”。它迫使你准确界定矛盾所在，并直接引出那个能暴露仪表盘盲区的问题：如果用户的反馈属实，哪个指标应该反映出这个问题？我们为什么没有跟踪它？

2. 开展由假设驱动的调查

在 Grafana Cloud 中，将 Assistant Workspace 切换到 Investigation 模式，并提供结构化的问题陈述。

专门的调查工具会查询指标、日志和 trace，同时维护一棵持续更新的假设树，状态包括待验证、根因、症状、已证伪或受阻。关键在于，每项发现都链接到其背后的 PromQL 或 LogQL 查询。

这一步的最佳实践：

• **使用 /ask 迭代推进：**提出有针对性的补充问题，无需重置整个上下文。
• **主动证伪薄弱假设：**LLM 容易固守第一个看似合理的解释。如果某个推测经不起负载指标的检验，就明确将它标记为已证伪。
• **遵守权限边界：**工具只能查询 service account 有权访问的数据。

3. 将证据缺口转化为有针对性的平台问题

扎实的初步调查应该以一份明确的证据缺口清单收尾。不要用假设掩盖这些缺口，而应将每个缺口交给负责相应领域的平台工具：

4. 使用精确时间戳查询控制平面，并要求返回原始数据

模糊的 prompt 会诱发对话中的幻觉。把精确的时间戳、集群 ID 和资源组直接提供给平台助手：

For AKS cluster <cluster-name> in resource group <rg-name>:
1. What is the provisioning state of node pool <pool-name> and when did it last change?
2. List upgrade, scale, and drain operations between <start UTC> and <end UTC>,
   including trigger source (user, auto-upgrade, maintenance schedule).
3. For the failed operation at <timestamp UTC>, provide the exact error code, 
   error message, and the specific pod or PodDisruptionBudget that blocked the drain.
4. Output raw Activity Log and Resource Health events for this window.
Do not provide a high-level summary. Return exact logs with timestamps and operation IDs.

AI 生成的摘要永远不能作为事故证据。务必提取并保存原始事件 payload。

5. 将原始发现反馈回去，更新假设

不要手动对照不同聊天窗口中的内容，而是将平台输出反馈给负责遥测数据的主助手：

New raw evidence from Azure Control Plane (timestamps in UTC):
<paste raw log/event entries>

Task: Update the active investigation. Re-evaluate each hypothesis status, 
update confidence ratings, close resolved evidence gaps, and list remaining unknowns.
Preserve all earlier evidence. Cite this data source as Azure Activity Log.

不要在助手之间传递调查发现的摘要。摘要会丢掉关键细节，同时人为抬高结论的确定性。经过两次转手，你排查的就成了一场 AI 传话游戏。

6. 检查应用代码（只读）

当平台指标与控制平面事件相互印证后，再通过只读 MCP server 接入 coding Agent，例如 Claude Code 或 GitHub Copilot。

例如，使用严格的只读参数连接 Grafana MCP server：

claude mcp add-json "grafana" '{
  "command": "mcp-grafana",
  "args": ["--disable-write"],
  "env": {
    "GRAFANA_URL": "<your-grafana-url>",
    "GRAFANA_SERVICE_ACCOUNT_TOKEN": "<viewer-level-token>"
  }
}'

提出调查问题，而不是要求修改代码：

Read-only investigation. Do not modify files.
1. Inspect how <service> handles SIGTERM. Is there an active preStop hook or custom terminationGracePeriodSeconds?
2. Map container image tag <tag> to its commit and inspect changes affecting connection draining.
3. Locate where log string "<exact error message>" is defined and what conditional branches trigger it.
4. For each proposed mitigation, identify the exact YAML or source files that would need adjustments.
Cite exact repository paths and line numbers for all assertions.

代码检查只能证明设计意图。任何仅从代码推导出的结论，在得到生产日志确认之前，都应归类为推断。

7. 对根因开展红队审查

在最终确定结论之前，开启一个全新、隔离的会话，对调查发现提出质疑：

Act as a skeptical Principal SRE reviewing this incident RCA draft. 
Identify the three strongest alternative explanations for these symptoms, 
highlight any claims stated with higher confidence than the raw evidence supports, 
and point out any remaining data gaps.

为不同读者设计 RCA

如果一份 RCA 只有撰写它的工程师才能看懂，它就无法为组织创造价值。

让事故复盘经得起核验的最佳实践

• **以三句话的管理层摘要开篇：**说明发生了什么故障、根因是什么，以及当前的修复状态。

• **明确标注每一项陈述：**已观测：由遥测数据或日志行直接确认。推断：从架构上看与遥测数据一致，但缺少直接的 trace 验证。未验证：依赖第三方反馈，尚待取证核实。

  • **已观测：**由遥测数据或日志行直接确认。
  • **推断：**从架构上看与遥测数据一致，但缺少直接的 trace 验证。
  • **未验证：**依赖第三方反馈，尚待取证核实。

• **记录已证伪的假设：**记录哪些事情没有发生，可以避免后续响应人员在死胡同里浪费精力。

• **让行动项具体可执行：**把“添加 PDB 告警”改为“部署 PDB Prometheus exporter 规则；指派给 @infra；在本次 Sprint 结束前，通过在 staging 环境执行 cordon 测试完成验证”。

• **通过验证完成闭环：**复盘文档合并，并不代表事故已经解决。只有部署后重新运行那些发现最初异常的查询，结果不再出现异常，事故才算解决。

AI 调查在生产环境中的约束

• **从设计上保证只读：**AI 助手负责查询和综合分析。变更只能由工程师通过标准 GitOps 工作流审批。
• **手动重新运行关键查询：**接受 AI 生成的结论之前，务必亲自运行其背后的两到三个数据库查询或 PromQL 查询。
• **严格清除敏感信息：**绝不要把 API token、连接字符串或客户 PII 粘贴到 prompt 中。
• **助手不是证据来源：**绝不要在 RCA 中写“助手发现……”。应该引用日志行、PromQL 指标或云活动日志条目。

如果你使用了不同的助手工作流，或者在多云环境中开展事故调查，欢迎在下方评论区分享你的方法。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。