oodle-triage

Oodle 故障排查 — 右侧可观测性

将告警转化为证据，而非叙述。此技能会收集生产环境上下文，并以严谨的方式创建工单。它会补上左侧开启的闭环：读取近期 PR 上的 O11y Change Context 清单，将触发的告警与可能导致该告警的变更关联起来。

首要原则： 每一步都要区分已证实和推断所得。确认的症状、最有可能的假设，以及确切缺失的证据，胜过基于相关性编造的整齐根因故事。先有证据，再下结论。

模式

• 模式 A — 故障排查上下文： 输入为单条告警、跟踪器工单 ID 或症状描述 → 生成上下文报告，并可选择更新工单。
• 模式 B — 自动值班故障排查： 输入为时间窗口（以及跟踪器父级问题）→ 枚举所有触发的告警、去重，并创建或更新子问题。专为按 /loop 周期运行而设计。

如果输入指定了一条告警、一个工单或一种症状，请使用模式 A。如果输入要求排查某个时间窗口内的情况，或“所有触发的告警”，请使用模式 B（该模式会针对每条告警复用模式 A）。

发现（首先执行）

按能力和工具形态解析后端，切勿使用硬编码的服务名称（名称可能各不相同：oodle-ai-us1、ap1、staging、dev 或客户自定义名称）。

• 可观测性 MCP — 查找用于告警/监控器、指标（PromQL）查询、日志和追踪的工具。如果工具套件符合 Oodle 的形态，请使用精简路径：选择拥有该服务的环境，并在适用时（例如 Kubernetes 调试、告警噪声分析）先加载匹配的 load_skill__* 工作流，再进行底层调用。
• 问题跟踪器 MCP — 查找正在使用的问题跟踪器。下文以 Linear 为例；Jira 与之类似（问题 → 子问题、状态、评论均可对应映射）。
• 如果缺少某个后端，请根据现有信号开展工作，并说明缺口。

模式 A — 分诊上下文

1. 以书面形式确认事实依据。 如果收到工单，先获取工单以明确范围。 在查询任何内容之前，先确定服务／组件、集群／环境、Pod、容器和准确的时间窗口。 将时间窗口转换为UTC 和报告者的本地时区两种时间——悄无声息地混用时区是典型错误。
2. **先用确凿信号确认症状，再提出理论：**重启／OOM 原因、错误率、延迟、资源使用量与限制值的对比、事件日志。用一句话说明已确认的症状；之后的内容都属于解释。
3. 通过代码了解监测埋点。 阅读相关服务代码，确认实际的指标名称、日志字符串和 Span 属性——不要猜测。明确记录捕获了什么以及未捕获什么；了解缺失的信息，就能知道遥测无法回答哪些问题。
4. 交叉比对各类遥测数据——不要依赖单一来源。指标（按所有有助于定位责任的维度分组：服务、租户、操作、Pod、状态）、调用链路上调用方和被调用方的日志（查看 ERROR／WARN 和访问日志；若找不到报告中提及的日志，则扩大筛选范围）、端到端链路追踪，以及资源问题对应的性能分析数据。
5. 关联近期变更（在此闭环）。 查找近期修改过告警服务的 PR（通过 GitHub 或 Linear MCP；若没有 GitHub MCP，则使用 gh CLI），并阅读其 O11y 变更上下文区块。watch 项和 type 用于聚焦假设（watch: N+1 ... 会成为首要假设）；guarded-by 用于确认告警与代码之间的关联；gaps 则说明遥测从未被设计用于提供哪些证据。
6. 为每项发现标注 Confirmed | Inferred | Unknown。 配置的上限或默认值不等于测量结果；同时发生不代表因果关系。积极尝试用一项测量结果证伪首要假设——排除一个候选原因比增加支持证据更有价值。
7. 无法确认时，停止推断，并列出按优先级排序的缺失证据： 对每项说明它能确认／排除哪个假设、可能在哪里找到，以及是否可访问。然后请求解决优先级最高的阻碍，而不是继续猜测。

输出——一份简短、诚实的报告：已确认的症状（含 UTC 和本地时间戳）、归因（在证据支持的范围内说明责任方／事物／位置）、首要假设（明确区分已证实与推断）、已排除项（附测量结果）、缺失证据（按优先级排序）。主动提出将报告作为评论发布到跟踪工单中。

模式 B — 自动值班分诊

对每条告警执行模式 A 的调查，并按枚举 → 抑制 → 去重 → 创建工单的流程处理。创建前必须严格进行匹配检查，确保重跑时绝不会重复创建工单。

1. 枚举时间窗口内触发的告警——即达到 firing 状态的告警实例。**绝不要把 pending／尚未满足条件的告警视为已触发：**它们不会发送通知，因此不应分诊或创建工单。通过告警状态信号或触发历史确认告警确实已触发。
2. 补充信息：当前是否仍处于活动状态、噪声类别（抖动／风暴／持续触发／自动恢复／边界情况）、约 7 天内的触发次数、是否已静默？（是否存在匹配此告警监控项及范围的有效静默规则），以及是否已路由？（该监控项是否会通知任何人，还是未路由）。
3. 抑制已静默和未路由的告警——它们不是需要值班人员处理的信号。不要为它们创建工单。如果某条现存工单对应的告警现在已静默或未路由，则添加说明原因的评论（静默规则 ID + 匹配器，或未路由监控项 ID）后关闭工单。只抑制具体实例，不要抑制整个告警类别——路由按监控项和环境分别配置。
4. 合并风暴——同一监控项的多个序列同时触发时，将其视为一条逻辑告警，并创建一张工单，而不是 N 张。
5. 使用模式 A 调查每条不同的已触发告警，调查深度按严重程度调整。清单关联分析用于判断可能原因并提出修复建议。
6. 根据以指纹为依据的语义匹配，与工单跟踪系统中的记录去重并创建工单：无匹配项 → 创建；匹配的工单处于打开状态 → 评论中记录此次新发生事件；匹配的工单已关闭 → 重新打开并评论。根据严重程度设置优先级。写入失败时重试一次；绝不要留下只创建了一半的重复工单。重跑同一时间窗口应具有幂等性。

指纹块

每张创建的工单都带有稳定的指纹，以便后续运行时匹配。保持格式不变：

## Fingerprint
- env: <env>
- monitor: <monitor id/name>
- scope: <key=value scope labels>
- links: <deep links to the backend>

通用性与 Oodle 专用实现

处理原则与供应商无关：区分已确认与推断的信息、仅枚举已触发的告警、抑制已静默／未路由的噪声、合并风暴、按指纹去重，以及清单关联分析，这些都适用于任何后端。具体机制则因后端而异：Oodle 提供类似 ALERTS 的状态指标、带类型匹配器的 muting_rules，以及监控项路由标志；其他供应商的 MCP 则提供各自的等效机制。存在等效机制时就使用；若确实不存在某个概念，则跳过相应步骤——绝不要臆造后端并不具备的机制。

对于 Oodle CLI 路径，如果深入查询有帮助，请使用 oodle-metrics、 oodle-logs 和 oodle-traces，而不是在此处重复介绍。