证据先于结论：一个CloudQ告警研判Skill 的设计、验证与度量

概述

告警能告诉你哪个对象报了异常。它不解释为什么会报，也不说明这批告警是同一件事的不同表现，还是几件互不相干的事。

值班人被卡住的地方其实在别处。判断「哪些要管、根因在哪」，这件事始终只能靠个人经验——经验长在人身上，人一走就带走了。

本文把这套判断逻辑抽出来，写成可被 CloudQ 调用的 Skill（cloudq-evidence-chain-rca）。降噪在它这里只是前置步骤，真正要做的是让每个结论都挂得上证据，并且说清证据差在哪里。

和常见的收敛类做法相比，有三处取舍不同：一个时间窗不等于一个事件；选定根因之前先做排除；结论按证据强度分级，而不是只给一个置信度数字。

文中的验证数据来自一套可复现的合成数据集，生成脚本与校验方法随文附上，任何人重跑应当得到一致结果。

一、问题：告警只告诉你哪里在响

设想一个多数运维团队都遇到过的场景。夜里一批定时任务集中运行，告警在一小时内堆到上千条。值班同事一条条翻，翻不出头绪，只能逐级往上叫人。

卡点往往不在告警本身，而在告警之外的三件事。

第一件，告警触发时间不等于故障起点。 阈值触发天然滞后。内存爬到越限需要时间，等第一条告警响起来，真实起点可能已经过去一两个小时。顺着告警时间查，方向从一开始就错了。

第二件，一个时间窗里可能不止一个事件。 两条平时各管各的业务线，底下共用同一个入口网关。告警只会分别报告各自在响，说不清它们之间有没有关系。这层依赖通常只在部分人的经验里。

第三件，结论强度说不清。 现有做法要么给一个置信度数字，要么干脆不给。看到结论的人无法判断这是「证据充分」还是「暂且这么认为」，也就没法决定下一步该不该据此行动。

告警量可以靠工具压下去。难的是判断本身，它长在人身上。

方案目标三条：判断可复用、结论可追溯、强度可分级。

非目标同样明确：不自动执行任何生产变更，不替代人做决策。

二、处理：一个 Skill，五步走完证据链

图 1：值班人报障后经五步产出证据链结论，结论需跨越人类授权线才进入处置环节。研判经验经知识抽取沉淀为 Skill 资产，并对标信通院六维。

CloudQ 的 Skill 采用业界通用的目录约定：一个 Skill 就是一个目录，内含 SKILL.md（YAML 元数据加 Markdown 指令正文），可按需挂载 references/、scripts/、assets/。元数据只有 name 和 description 两个字段，工具、步骤、边界、铁律全部写进正文。

这套流程来自一个追问：有经验的架构师远程接手时，实际按什么顺序做事？答案稳定地只有五步。

① 分案  →  ② 收敛  →  ③ 回溯  →  ④ 证伪  →  ⑤ 归因分级

① 分案。 先判断一个时间窗里是否包含多个独立事件。三条判据：两组告警涉及的实例之间没有依赖路径相连；两个异常起点之间隔有一段指标回归正常的区间；告警类型跨越互不相关的层级。满足任意一条即拆分。

② 收敛。 按「告警源加类型加时间邻近」聚类，同簇保留一条代表，过滤已知抖动与变更窗口告警。这里有个容易踩的坑：重复告警是原事件的重复上报，派生时会带前后抖动，若直接取簇内最早一条当代表，代表时间会被重复件前移，后面算「首条有效告警」就偏了。因此代表优先取有效告警本身。输出构成拆解并校验可加性：重复合并加已知抖动加变更窗口加保留有效，四项之和必须等于原始总数。

③ 回溯。 沿依赖图谱回溯上下游，划定故障域并记录传导方向。方向与依赖图不一致的标「方向存疑」并单列；拓扑缺失时故障域标「未知」，不做推测填充。

④ 证伪。 列出候选假设，不少于两个，对每个寻找反证：指标拐点是否最早、传导方向是否与依赖图一致、是否被指标回归区间隔开。未被排除的按拐点先后排序，最早者作为结论。两个假设都无法排除时同时输出，不强行二选一。

⑤ 归因分级。 按证据强度分三级输出。

2.1 三处设计取舍

只读是硬边界，不是配置项。 Skill 不挂载任何写工具，连重启都不做。处置动作以文本形式输出，授权后由人执行。这条边界直接决定使用者的信任曲线——它的价值只取决于判断准不准，和会不会闯祸无关。

因果以指标拐点为准，不以告警触发时间为准。 阈值滞后会把起点认晚。这是本 Skill 与常规做法最根本的分野。

确定性计算交给脚本，不交给模型。 守恒校验与时序对齐由脚本执行。模型会算错总数，而总数错一位，后面全部结论都不可信。

图 2：从 ChatOps 入口到数据底座的五层结构。只读边界为横切约束，全链路不挂载写接口；守恒校验等确定性计算下沉至 scripts 由脚本执行，模型只消费脚本处理后的结果。

2.2 一条来自安全运营的经验

「先排除、后选择」这个顺序，不是为云运维现想的。

在安全运营领域，面对一批可疑事件，成熟的分析流程会先逐一排除那些证据上站不住的几条，剩下的才是要处置的对象。挑最像攻击的那一条下手，看起来快，实际常把真正的入口漏掉。

把这条经验搬到告警研判上，得到的就是第四步：证伪优先于证实。直接选「最可能的」会忽略反证，看着合理，站不住。

三、成效：一次可复现的验证

3.1 为什么用合成数据集

本 Skill 的验证不依赖企业真实数据。原因有两条。真实告警数据通常不可对外提供；更重要的是，可复现本身就是资产属性的一部分，一个别人无法重跑验证的 Skill，很难称为可复用的行业资产。

因此本文构造了一套合成数据集：定义一张 7 节点三层拓扑（网关到业务服务到数据层），注入一条根因（某网关实例内存持续爬升直至触顶），并派生三类噪音——重复上报、已知抖动、变更窗口告警。全部随机过程固定种子。

3.2 七项自洽性校验

数据集生成后必须通过七项校验，否则不进入诊断环节。

3.3 诊断输出

自然语言唤起后，Skill 返回（实跑输出，未做删减）：

【分案】
本窗口识别为 1 个独立事件
判据 1 实例连通性：涉及实例位于同一连通域，不拆
判据 2 指标回归区间：未发现异常后回归基线的区间，不拆
判据 3 层级跨越：告警跨越 edge、biz 层，层间存在依赖路径，不拆
​
【收敛结果】
原始 1468 条，有效 43 条（收敛率 97.07%）
构成：重复合并 1204 ｜ 已知抖动 168 ｜ 变更窗口 53 ｜ 保留有效 43
守恒校验：1204 + 168 + 53 + 43 = 1468（脚本校验通过）
​
【关键时序】
00:18　svc-gateway-01　mem_used_pct 拐点（真实起点）
02:05　首条有效告警触发（滞后 1h47m）
02:33　svc-gateway-01 触顶，同刻 svc-order-01 p99_latency_ms 由约 178ms 拐至 4.3s
​
【候选假设与证伪】
H1 svc-gateway-01 mem_used_pct —— 保留
　　拐点 00:18 为全窗口最早异常点，无更早点反证
　　其余异常实例 svc-order-01 位于其下游，传导方向与依赖图一致
　　不存在将其与其他异常隔开的指标回归区间
H2 svc-gateway-02 —— 排除
　　无指标时序，不存在可定位的拐点，无证据支持其作为根因
H3 svc-inventory-01 —— 排除
　　无指标时序，不存在可定位的拐点，无证据支持其作为根因
H4 svc-order-01 p99_latency_ms —— 排除
　　拐点 02:33 晚于最早异常点 00:18
　　存在其他异常实例不在其下游，以其为根因则传导方向与依赖图相反
　　不存在将其与其他异常隔开的指标回归区间
​
【结论】
svc-gateway-01 mem_used_pct 异常增长并触顶（证据强度：直接证据，置信度 0.93）
证据：指标拐点 ✓、依赖方向 ✓、告警分布 ✓（svc-gateway-01 在有效告警中占比最高，26/43）
传导影响：svc-order-01 的指标拐点与触顶同刻发生，属该根因的传导结果，非独立根因
证据缺口：无法区分「容量不足」与「代码级资源泄漏」，需 heap dump 与 GC 日志，超出本 Skill 证据范围
置信度未更高的原因：存在 1 项证据范围外未定论，补到之后可由 0.93 提至 0.95
​
【下一步（只读，处置需你确认）】
采集 svc-gateway-01 的 heap dump 与 GC 日志——这是目前唯一未定论环节

三处值得停一下。

分案的结论是「一个事件」，但三条判据仍逐条给出不拆的理由。这一步即使结论是不用拆，也必须留下记录，否则事后无从判断当时到底有没有想过这件事。

候选假设四个，保留一个。被排除的三个各有理由：两个根本没有指标时序，拿不出拐点证据；一个拐点更晚且传导方向相反。排除的依据是反证，不是「哪个更像」。

置信度 0.93 有计算口径，不是拍出来的。直接证据基准 0.95，存在 1 项证据范围外未定论（无法区分容量不足与代码级泄漏），扣 0.02；补上 heap dump 与 GC 日志后可回到 0.95。间接证据与假设一律不输出置信度。

同样一批告警，人工排查容易把异常起点认在首条告警上，也就是 02:05。Skill 把起点前推到 00:18，提前 107 分钟。

3.4 成本对照

对照口径：1469 次 = 1 次全量告警查询加逐条 1468 次验证，这是不做收敛时的最小调用规模。本 Skill 的 7 次构成为 1 次告警查询、2 次拓扑查询（分案一次、回溯一次）、4 次指标查询（故障域内每个实例一次）。

回溯与指标查询都在收敛之后触发，调用规模随 43 条增长，而不是随 1468 条增长。

3.5 在线可确证部分：一次账号级巡检

凭证配置完成后，CloudQ 完成了一次账号级巡检，扫描覆盖两个地域，输出资源清单与风险清单。

资源清单

风险清单（节选，按 P0/P1/P2 分级，每条附实测依据）

这台机器是按最短路径临时开通的验证环境，安全组与登录方式都用了默认最宽配置，文章提交后即销毁。风险清单里 P0、P1 的几条，正是这种「先跑通再收紧」的开通过程留下的。

其中一条值得单独展开。

账号下配置了两个告警策略组（CPU 80% 与 95%、内存 95%、磁盘 80% 与 95%），接收组数量却是 0。这意味着即使 CPU 打满、磁盘写满，告警触发后也不会有任何渠道通知到人。

这是一种典型的哑巴监控。它比完全没有监控更危险，因为使用者以为自己有。告警治理的第一道关口在收敛算法之前：先确认告警真的能到达人。这一条如果不做扫描，靠翻控制台很难发现，策略页面上写着「已配置」，一切看起来都正常。

另有一条从反面印证了同一条原则。主机内存使用率在 40 分钟内由 8.44% 单调上升至 9.14%，Skill 判定为 page cache 增长，不构成故障起点，没有据此告警。若以「指标在涨」作为判据，这里会产生一次误报。单调上升不等于真实拐点。

本节边界说明（如实列出，不做补全）

• 账号内告警历史为 0 条，从未触发过。在线环节因此未能演示真实告警的收敛与根因定位，该部分由本地合成数据集验证，见 3.1 至 3.4。
• 账号内仅 CVM 与 MySQL 两类资源，分处两个地域且内网不通，不存在服务依赖拓扑，graph.trace 未产生有效内容。依赖回溯一节以本地构造拓扑验证。
• 在线巡检体现的是 CloudQ 的架构感知与风险确证能力；本 Skill 的收敛与证伪链路主要依赖本地可复现数据集完成。

四、对标信通院《云上 Agent 基准度量模型》六维

关于不写的数字。 本文刻意不提供「效率提升 N 倍」「MTTR 缩短 X%」这类结论。验证环境为单节点，故障样本为单次构造，样本量撑不起统计结论。这里提供的是一次完整实录、每格检查方法和可复现校验机制。等样本积累到可统计规模再补数字，比现在给一个站不住的数字更值钱。

五、经验总结：五条带得走的

1. 值得固化的是判断顺序本身。 能力定义越泛，越不可审计。把「先证伪后证实」写进 SKILL.md，它就从个人习惯变成了可检查的步骤。

2. 一个时间窗不等于一个事件。 这是本次最容易出错也最容易被忽略的一环。多事件合并归因，得到的根因一定是错的，而且错得很像真的。

3. 模型与脚本各干各的。 守恒、时序对齐这类确定性计算交给脚本。模型会算错总数，而总数错一位，后面全部结论都不可信。

4. 强度不够就降级标注。 达不到直接证据的，不许写成结论。「间接证据」和「假设」不是失败，是诚实，使用者据此才知道该不该行动。

5. 降级优于中断，边界写在明处。 缺拓扑就标「未知」，缺指标就降到间接证据。可信的前提是知道自己不知道什么。

跨场景迁移

本 Skill 的骨架与行业无关，行业属性收敛在三个文件里。

写在最后

这套东西的本质，是把「该先干什么」从个人经验变成一份流程、一个 Skill、几个脚本。

它不替人做决定，也不碰写操作。它能做的，是在人拍板之前把证据摆齐，把缺口标出来。

附录 A：SKILL.md 全文

---
name: cloudq-evidence-chain-rca
description: 对云上告警做分案、收敛与证据链根因定位。先按时间窗拆分独立事件，再聚类降噪，随后列出候选假设逐一证伪而非直接选最可能者，按证据强度分级输出结论并显式标注证据缺口。当用户提到「告警太多」「告警风暴」「降噪」「根因定位」「为什么一直报警」「这几个是不是一回事」时使用。仅执行只读诊断，处置动作一律回用户侧授权确认。
---
​
# 证据链告警研判
​
## 定位
​
本 Skill 不负责「把告警变少」，只负责一件事：**让每一个结论都挂得上证据，并且说清证据不足之处。**
​
它与常规收敛类 Skill 的分工是：收敛回答「哪些要管」，本 Skill 回答「为什么是它、凭什么这么说、还差什么」。具体地，它补上三个容易被跳过的环节：
​
| 环节 | 常规做法 | 本 Skill 做法 |
|---|---|---|
| 一个时间窗内多个独立事件 | 合并成一次告警风暴处理 | 先分案，逐案独立归因 |
| 选定根因 | 选出最可能的一个 | 列候选假设，逐一证伪，剩下的即为结论 |
| 结论强度 | 给一个置信度 | 按证据强度分级，并标注缺口 |
​
适用范围：具备服务依赖拓扑、指标可与告警对齐、存在变更记录的云上环境。
​
不适用：无拓扑的单机环境、纯业务埋点告警、需要执行变更的场景。
​
## 工具与证据边界
​
可用工具：`cloudq.alert.query`、`cloudq.graph.trace`、`cloudq.metric.query`。
​
证据分四类，强度不同：
​
| 类别 | 来源 | 强度 | 说明 |
|---|---|---|---|
| 指标时序 | 资源与服务指标 | **直接** | 可定位真实拐点，是因果判定的主要依据 |
| 依赖拓扑 | 服务调用与资源依赖 | **直接** | 用于划故障域、判传导方向 |
| 告警分布 | 告警本身 | **间接** | 只能说明哪个对象在报异常，不能单独定因果 |
| 变更记录 | 发布、扩缩容、配置变更 | **间接** | 用于解释「为什么是现在」，也用于过滤告警 |
​
以下信号**不在证据范围内**，不得作为结论依据：应用日志、进程快照、业务埋点、变更工单正文。需要范围外证据才能定论时，只输出假设并标注「待验证」。
​
**边界原则**：宁可少取，不冒险。范围外证据一律不补全。
​
## 执行步骤
​
### 第一步：分案
​
按时间窗内的告警分布，判断是否包含多个独立事件。判据有三条，满足任意一条即拆分：
​
1. 存在两组告警，其涉及实例无依赖路径相连
2. 存在两个异常起点，中间隔有一段指标回归正常的区间
3. 告警类型跨越互不相关的层级（如基础设施层与业务层同时告警且无传导关系）
​
分案结果必须在输出中显式列出。无法判断时，按「一案」处理并标注「未分案，可能是多事件叠加」。
​
### 第二步：收敛
​
1. 按「告警源 + 类型 + 时间邻近」聚类，同簇留一条代表。
2. 过滤已知抖动与变更窗口告警。
3. **输出构成拆解并校验可加性**：重复合并 + 已知抖动 + 变更窗口 + 保留有效 = 原始总数。
​
**该校验由脚本执行，不由模型计算。** 模型会算错总数，而总数错一位，后面全部结论都不可信。
​
### 第三步：回溯
​
1. 以有效告警实例为起点，沿图谱回溯上下游。
2. 划故障域：告警密度最高且位于依赖链上游的节点集合。
3. 记录传导方向。方向与依赖图不一致的标「方向存疑」并单列。
4. 拓扑缺失时，故障域标「未知」，不做推测填充。
​
### 第四步：证伪
​
列出候选假设（不少于两个），对每个假设寻找**反证**：
​
1. 检查其指标拐点是否早于其他候选。不是最早的直接排除。
2. 检查传导方向是否与依赖图一致。方向相反的直接排除。
3. 检查是否存在指标回归正常的区间将其与其他事件隔开。有则标「可能独立」。
​
**证伪优先于证实。** 未被排除的假设按拐点先后排序，最早者作为结论。若两个假设都无法排除，同时输出并说明差异原因，不强行二选一。
​
### 第五步：归因与分级
​
给结论标证据强度，三级：
​
| 级别 | 判据 | 输出要求 |
|---|---|---|
| **直接证据** | 指标拐点 + 依赖方向 + 告警分布三者一致 | 给置信度，说明「为什么不是更高」 |
| **间接证据** | 仅告警分布与拓扑吻合，缺指标拐点 | 标「待验证」，列出缺哪种指标 |
| **假设** | 现有证据无法排除其他可能 | 明确标「假设」，只给下一步取证方向 |
​
## 安全边界
​
- 全流程只读，不执行重启、扩容、配置变更、限流调整等写操作。
- 处置建议与诊断结论分离输出，处置一律回用户侧授权确认。
- 确定性计算（守恒校验、脱敏、时序对齐）交给脚本，模型只消费脚本处理后的结果。
​
## 铁律
​
1. **因果先后以指标拐点为准，不以告警触发时间为准。** 阈值触发存在滞后，以告警时间定因果会把起点认晚。
2. **一个时间窗不等于一个事件。** 多事件必须先分案，合并归因会得出错误根因。
3. **先证伪，后证实。** 直接选「最可能的」会忽略反证，看似合理实则不可靠。
4. **构成必须可加，且由脚本校验。** 模型不碰总数。
5. **强度不够就降级标注。** 达不到直接证据的，不许写成结论。
6. **不确定就上报缺口，不编造证据链。** 只说「缺什么、补到之后能定论什么」。
7. **不跨域归因。** 无依赖路径的告警不得合并为一个根因。
​
## 输出格式
​
```
【分案】
本窗口识别为 N 个独立事件：事件① <涉及实例与类型>；事件② …
判据：<为什么拆 / 为什么不拆>
​
【收敛结果】
原始 X 条 → 有效 Y 条（收敛率 Z%）
构成：重复合并 a ｜ 已知抖动 b ｜ 变更窗口 c ｜ 保留有效 d
守恒校验：a + b + c + d = X（脚本校验通过 / 不通过）
​
【关键时序】
<时刻> <实例> <指标> 拐点（真实起点）
<时刻> 首条告警触发（滞后 <时长>）
<时刻> <下游> <指标> 拐点
​
【候选假设与证伪】
H1 <描述> —— 排除 / 保留（理由：<反证或支持>）
H2 <描述> —— 排除 / 保留（理由：…）
​
【结论】
<实例> <异常描述>（证据强度：直接 / 间接 / 假设，置信度 0.XX）
传导影响：<哪些属衍生>
证据缺口：<缺什么，补到之后能定论什么>
​
【下一步（只读，处置需你确认）】
<唯一还需补的证据>
```
​
## 降级策略
​
| 缺失项 | 降级方式 |
|---|---|
| 无拓扑 | 跳过回溯，故障域标「未知」，仅做时序归因，注明结论强度下降 |
| 无指标 | 结论最高只能到「间接证据」，明确不输出置信度 |
| 无变更记录 | 变更窗口过滤跳过，标注「有效数可能偏高」 |
| 同窗多事件但证据不足分案 | 按一案处理，标注「可能是多事件叠加」 |
| 两假设均无法排除 | 同时输出，说明差异，不二选一 |
​
## references 使用说明
​
按需加载，不进主流程：
​
- `references/evidence-rules.md` —— 证据分级细则与典型反证模式
- `references/topology-patterns.md` —— 常见依赖形态与传导方向判定要点
​
主流程五步固定，不因参考资料增减而改变。

附录 B：数据集构造与校验

• scripts/gen_dataset.py：数据集生成加七项自洽性校验，随机种子固定为 20261019
• scripts/run_triage.py：五步执行器加运行指标采集
• scripts/scrub.py：确定性脱敏，六类泄露面（IP、资源 ID、地域、密钥、邮箱、UIN）
• scripts/out/dataset.json：1468 条告警、7 节点拓扑、480 分钟指标时序
• scripts/out/validation_report.md：七项校验报告
• scripts/out/triage_result.md：五步诊断输出（即 3.3 节所引）
• references/evidence-rules.md：证据分级细则、置信度计算口径、六种典型反证模式
• references/topology-patterns.md：五类依赖形态与传导方向判定要点

复现步骤：

python gen_dataset.py    # 生成数据集与校验报告
python run_triage.py     # 执行五步诊断与指标采集

两次执行后 dataset.json 的 MD5 应当完全一致。