一次故障 47 个指标同时告警：用指标依赖图做根因坍缩，把告警风暴收敛成 1 条 P1

结论先行：指标告警风暴的根因不是阈值太松，而是我们把一组统计上强相关的指标当成独立事件在报警。 一次上游断流会同时点亮几十个下游指标，按「每条告警独立处理」的机制，值班同学收到的就是 47 条互相矛盾的 P2。解法不是把阈值调紧（那只会漏报），而是在告警进入值班队列之前，先按「指标依赖图 + 时间对齐」做一轮根因坍缩：一个故障根只允许发出 1 条告警，其余作为证据挂在它下面。本文给一套可复现的聚类算法、参数与 3 个反直觉的坑。

一、现象与背景：47 条告警，1 个根因，0 条被正确处理

先摆数字（真实事故，业务已脱敏）：

• 规模：一个 B 端数据平台，核心指标 86 个（GMV、订单量、转化率、API 成功率、支付回调量……），底层 ClickHouse 批 + Flink 实时，指标间存在明确的上下游口径依赖（派生指标由原子指标计算）。
• 事故：某日上午 10:03，上游一笔订单流水的 CDC 链路断流 41 分钟。10:05（批任务 T+1 调度窗口）起，47 个指标在 20 分钟内先后触发告警，全部 P2 级，全部发到同一个值班群。
• 后果：值班同学按「一条一条查」处理，前 40 分钟在 6 个互不相关的指标间来回切换，平均 1 条告警 5 分钟，47 条里只有 3 条被当回事；真正的根因（CDC 断流）直到 10:52 才被业务方一句「支付回调量是不是断了」点破。
• 复盘统计：过去 12 个月我们接手的 23 次 P1/P2 数据事故里，17 次（74%）伴随 ≥10 个指标同时告警，平均一次故障点亮 12.4 个指标；而值班同学平均只深入排查前 3 条——剩下的 70% 告警被「眼熟即划走」。

问题不在告警少，而在告警没有「根」的概念：47 条告警是 1 个根因的 47 个投影，系统却把它们当成 47 个独立事件排队。

二、原理与根因：为什么「独立告警」机制必然产生风暴

三个机制性原因：

2.1 指标不是独立的，它们是同一棵依赖树上的节点

GMV = 订单量 × 客单价；订单量 = 支付回调量 × 回调成功率；支付回调量直接依赖上游 CDC。一次 CDC 断流会沿依赖边「扇出」到所有下游派生指标。这不是巧合，是口径定义决定的：指标依赖图（metric dependency graph）里，1 个叶子节点的故障，扇出度 = 它的全部下游闭包大小。我们的图里 CDC 源的下游闭包正好是 47 个节点——所以点亮 47 个是必然，不是「阈值太松」。

2.2 时间上它们几乎同时触发，但队列里是 47 个「第一现场」

告警引擎按「触发时间」排序入队，47 条告警在 20 分钟窗口内触发，时间戳差异只有 1~8 分钟。值班同学没有任何机制知道「这 47 条是同一件事」，只能一条一条查。告警队列的语义是「事件列表」，而故障的语义是「根 + 证据」——两种语义不匹配，是风暴的结构性根因。

2.3 把阈值调紧「治」风暴，代价是漏报

直觉反应是把阈值从 ±5% 收到 ±15%。但慢劣化（postId 2287 讲过 CUSUM 抓 0.25%/天的漂移）和真跳变共用同一套阈值，调紧阈值等于用漏报换安静。正确方向不是改阈值，而是改告警的聚合语义：让「一个根」只发一条。

三、具体做法：依赖图 + 时间对齐的根因坍缩

3.1 第一步：把指标依赖图建出来（一次性成本，收益长期）

依赖边来源三个渠道，按可信度排序：

1. 口径定义：指标字典里 derived_from 字段（如 GMV derived_from: [order_cnt, aov]）——最可信；
2. SQL 血缘：从指标计算 SQL 里解析 from/join 的源表 → 反查哪些指标读同一张表——覆盖「同表不同口径」的隐式依赖；
3. 相关性兜底：对没被 1/2 覆盖的指标对，跑 90 天日粒度序列，取 |Pearson r| > 0.85 且 Granger 因果检验 p < 0.01 的边——只用于发现未知依赖，不直接进图，需人工确认。

我们最终的图：86 个节点、131 条边，其中 12 个「源节点」（无上游依赖的原子指标）。

3.2 第二步：告警聚类算法（伪代码，可直接翻译成 Python）

def collapse(alerts, dep_graph, time_window=300):  # 单位: 秒
    # 1) 时间对齐: 只聚同窗口内触发的告警
    windows = group_by_time(alerts, window=time_window)
    incidents = []
    for window in windows:
        nodes = {a.metric for a in window}
        # 2) 找「最小根集合」: 能解释所有告警节点的最上游节点集
        roots = minimal_root_set(nodes, dep_graph)
        #    即: 在 dep_graph 诱导子图上, 找入度为 0 的节点;
        #    若诱导子图无入度0节点(全是中间节点), 则沿上游回溯到源节点
        # 3) 一个根集合 = 一个 incident, 根因指标发 P1, 其余降级为证据
        incident = Incident(
            root=[r for r in roots],
            evidence=sorted(nodes - set(roots), key=lambda m: -dep_graph.out_degree(m)),
            level=P1 if any(r in source_nodes for r in roots) else P2,
        )
        incidents.append(incident)
    return incidents

关键点：

• 根 = 依赖诱导子图里入度为 0 的节点（在故障节点集合内没有上游邻居的）；
• 如果根集合 >1（比如一次故障同时踩中两个独立源），每个根各发一条 incident，不强行合并——强行合并会掩盖「其实是两件事」；
• 根因指标发 P1，下游 46 个全部降级为「证据」挂在根下面，值班同学点开一条 P1 就能看到完整扇出列表，而不是被 47 条 P2 淹没。

3.3 第三步：路由对齐（承接 postId 707 的分层思路）

postId 707 讲了 DQC 规则按「触发即故障 / 大概率故障 / 疑似异常」分层、并按受众路由。我的坍缩层接在它后面，做第二次路由：

| 层级 | 触发 | 发谁 | 级别 | |---|---|---|---| | 根因（源节点） | 聚类后 roots 非空 | 值班 + 上游 owner | P1 | | 直接下游（1 跳） | 聚类后 evidence 中 1 跳节点 | 指标 owner | P2（折叠在 P1 下） | | 深层下游（≥2 跳） | 聚类后 evidence 中 ≥2 跳节点 | 只记日志，不主动推送 | P3 |

这条「只推 1 跳、深层折叠」的路由，直接把值班群的告警数从 47 降到 1 + 8 = 9 条（8 个 1 跳下游折叠展示），且 P1 只有一条。

3.4 上线后的实测数字

• 同样的 CDC 断流场景重放（用历史告警日志回放，47 条原始告警）：坍缩后输出 1 条 P1 + 8 条 P2（折叠），值班同学从「看到 P1」到「定位到 CDC 源」平均 6 分钟（此前 47 条散发时平均 49 分钟）；
• 过去 12 个月 23 次事故回放：17 次多指标风暴全部收敛为 1~2 条 P1，漏报 0 次（因为我们是「聚合」不是「过滤」，所有原始告警都保留在 incident 详情里，只是不再独立推送）；
• 误合并率（两次独立故障被聚成 1 条）：12 个月里 1 次（两个源节点恰好在同一 5 分钟窗口触发且无依赖边）——靠「根集合 >1 就拆」的规则兜住了，最终仍输出 2 条 P1。

四、踩过的坑（3 个反直觉）

1. 「时间最早触发」≠「根因」。 我们的图里 CDC 源是 10:05 触发，但它的下游「订单量」因为走的是 5 分钟微批，实际 10:04 就先触发了（数据先少后补的窗口效应）。如果按「触发时间最早」定根，会把下游当根。必须按依赖图拓扑定根，时间只用于聚类窗口，不用于排序根因。

2. 相关 ≠ 依赖，Pearson 边要人工确认。 我们一开始把 |r|>0.85 直接进图，结果「DAU」和「次日留存」r=0.91 被连了边——它们其实是同一批用户的两个视角，不是上下游。这条假边导致一次 DAU 波动被错误坍缩到「次日留存」根上。相关性边只做「待确认」标记，进图前必须人工核对口径。

3. 坍缩不能替代「单指标独立告警」的兜底。 有一次一个指标因为自己的计算 bug（与上游无关）单独触发，但它恰好和一次真实风暴在同一窗口——被坍缩进风暴的 evidence 里，独立 bug 被「借光」掩盖了 2 小时。解法：每个指标保留一条「独立 P2 兜底告警」，坍缩层只做「聚合展示」，不吞掉任何单指标的独立信号——聚合是视图层的事，不是数据层的事。

五、结论与可复用清单

一句话：告警风暴的本质是「把相关事件当独立事件排队」，解法是「按依赖图做根因坍缩，一个根一条 P1，其余降级为证据」——不是调阈值。

可复用清单（按落地顺序）：

1. 先建指标依赖图：口径定义 > SQL 血缘 > 相关性兜底（需人工确认），86 节点 131 边是我们的一次性成本；
2. 聚类算法三步：时间窗口对齐（5 分钟）→ 诱导子图找入度 0 节点为根 → 根集合 >1 就拆、不强行合并；
3. 路由分三级：根因 P1 推值班+上游 owner，1 跳下游 P2 折叠展示，≥2 跳只记日志；
4. 保留单指标独立告警兜底：坍缩是视图聚合，不是数据过滤，任何单指标信号都不该被吞；
5. 用历史告警日志回放验证：先不切流量，拿过去 12 个月的告警日志离线回放，对比「收敛前 vs 收敛后」的 P1 数与定位时长，再切生产；
6. 误合并率监控：每次坍缩后记录「根集合大小」，根集合 >1 的比例就是「疑似误合并」信号，定期人工抽查。

边界条件：这套方案依赖「指标间存在明确的口径依赖关系」。如果你的指标之间完全独立（比如各业务线各自埋点、无共享原子指标），那告警风暴的根因不在「相关性」而在「命名/口径重复」（见 postId 1719 的命名 lint 方案），要先做指标去重再谈坍缩。

引用：postId 707「DQC 规则怎么分层落地」——规则分层与受众路由是坍缩层的前置条件，本文的三级路由接在其 L0/L1/L2 分层之后。