ops-investigate-alert

调查告警

通过提取指标、日志、跟踪信息和相关服务代码来调查监控告警。输入症状，输出根因假设。

适用场景

• 触发了监控告警，你需要弄清楚原因
• 值班工程师需要一个结构化的调查起点
• 告警噪声较多，你想判断它是否需要处理，还是误报

流程

1. 确认监控 MCP 是否可用

检查有哪些监控 MCP 服务可用。查找与监控平台（Datadog、Grafana、PagerDuty 等）相关的 mcp__* 工具。

推荐： Datadog MCP——它在一个平台中提供最全面的调查信息（监控器、指标、日志、跟踪信息和事件）。

如果没有监控 MCP 可用，请停止并显示：

错误：未找到监控 MCP 服务。 此技能需要监控 MCP 来查询告警数据。 推荐：在 Claude Code MCP 设置中添加 Datadog MCP。

另请检查以下可选工具：

• GitHub CLI (gh)——用于读取相关服务代码和近期部署
• Kubernetes MCP——用于检查 Pod 状态

记下哪些工具可用，并据此调整调查方式。

2. 解析输入

如果输入的是监控平台 URL：

• 从 URL 中提取监控器／告警 ID
• 继续执行第 3 步

如果输入的是告警名称或描述：

• 使用可用的监控 MCP 搜索监控器
• 如果有多个匹配项，列出它们并请用户确认要调查哪一个
• 如果仍未找到，请向用户询问更多详情

3. 获取监控器详情

检索监控器配置和当前状态：

• 监控器名称、类型和查询
• 当前状态（OK / Alert / Warn / No Data）
• 最近触发时间
• 受影响的服务和环境
• 告警消息和运行手册链接（如有）

4. 查询指标

获取触发告警的指标：

• 时间范围： 从触发前 1 小时到现在（或从触发前 1 小时到告警解除后 1 小时）
• 关注点： 异常、峰值、骤降、水平线、阈值越界
• 与监控器阈值进行比较，以了解严重程度

5. 分析日志

搜索受影响服务和环境的日志：

• 时间范围： 与第 4 步相同
• 关注点： 错误、堆栈跟踪、超时、连接失败、异常模式
• 按严重程度筛选： 先重点查看 ERROR 和 WARN 级别，必要时再扩大范围

6. 检查跟踪信息（如有）

搜索分布式跟踪信息：

• 按服务名称和时间范围筛选
• 关注点： 慢速 Span、错误 Span、异常延迟分布、下游调用失败

7. 检查基础设施（如有）

如果 Kubernetes MCP 或云 CLI 可用：

• Pod 状态、重启次数、OOM 终止
• 告警发生前后的资源使用情况（CPU、内存）
• 近期部署事件

如果无法使用（VPN、权限限制），请注明并继续使用可用数据。

8. 检查近期代码变更（如果 gh 可用）

gh auth status

如果已通过身份验证：

1. 根据服务名称确定代码仓库
2. 检查近期发布／标签，确认当前部署的版本：

   gh api repos/<org>/<service>/tags --jq '.[0:3] | .[] | {name: .name, sha: .commit.sha}'
   

3. 比较最近的 2 个标签之间的差异，查看最新版本中的变更：

   gh api repos/<org>/<service>/compare/<prev-tag>...<latest-tag> --jq '.commits[] | {sha: .sha[:7], message: .commit.message, author: .commit.author.name}'
   

4. 根据错误类型查看相关代码：
   • HTTP 错误 → 路由处理程序、中间件
   • DB 错误 → 查询代码、连接池
   • 超时错误 → 外部调用客户端、超时配置
   • OOM → 占用大量内存的操作、无界集合

绝不要创建、推送或修改标签。

9. 提交调查摘要

## Alert Investigation: <Alert Name>

**Status:** <OK / Alert / Warn / No Data>
**Service:** <service> | **Env:** <env>
**Triggered:** <timestamp> | **Duration:** <duration or "Ongoing">

### Metrics
<key observations — spike at X time, value Y vs threshold Z>

### Logs
<key log lines or patterns — N errors of type X, stack trace summary>

### Traces
<latency or error observations — if available>

### Infrastructure
<pod status, resource usage — if available>

### Recent Code Changes
<commits near trigger time, or "No recent changes" or "gh CLI not available">

### Root Cause Hypothesis
<best assessment based on available data — be explicit about confidence level>

### Recommended Next Steps
1. <most impactful action>
2. <secondary action>
3. <what to check if hypothesis is wrong>

如果数据不足以得出结论，请明确说明，并建议手动检查的内容（例如，检查 k8s 的 VPN 访问权限、直接查询 DB、向团队确认）。

交互风格

• 先给出数据，而非猜测——在提出假设前展示指标／日志／跟踪信息
• 明确说明置信度：“高置信度”“可能”“无法得出结论”
• 如果某一步没有得到数据，请说明并继续，不要臆测

规则

• 切勿跳过步骤 3-5（监控、指标、日志）——这是调查的核心
• 步骤 6-8（追踪、基础设施、代码）可根据工具可用情况选择是否执行
• 调查期间切勿创建、推送或修改标签或部署
• 最后始终呈现结构化摘要，即使调查没有明确结论

输出

直接在对话中呈现调查摘要。除非用户要求保存，否则不要输出文件。