1. 告警降噪概述：告警风暴的成因、降噪的核心目标、基线核验在 on-call 中的价值
1.1 告警风暴的成因
告警风暴（Alert Storm）是 on-call 值班中最具破坏力的现象之一。当系统在短时间内产生大量重复、无效或低优先级的告警时，值班工程师的注意力被稀释，真正需要处理的故障反而被淹没。告警风暴的根源可归纳为以下四类：
| 成因类别 | 典型场景 | 影响 |
|---|---|---|
| 级联故障 | 数据库主库宕机 → 上游应用超时 → 所有 API 返回 5xx → 每个服务都触发告警 | 单点故障扩散为全链路告警洪流 |
| 阈值过窄 | CPU 使用率 > 70% 即告警，但业务高峰期常态 80% | 大量误报导致工程师产生告警疲劳 |
| 重复告警 | 同一错误日志每分钟上报一次，每次生成独立告警 | 告警数量呈线性或指数增长 |
| 缺乏依赖关系 | 上下游服务各自独立告警，未做因果关联 | 值班人员需手动关联多个告警才能定位根因 |
关键数据： 根据行业统计，超过 60% 的 on-call 告警属于重复或误报，真正需要人工介入的告警占比不足 15%。
1.2 降噪的核心目标
告警降噪不是简单地减少告警数量，而是通过系统化的手段提升告警的信噪比，让每一条告警都具备可操作性。降噪的核心目标可拆解为三个层次：
- 去重与聚合：将相同根因的重复告警合并为一条事件，避免值班人员反复处理同一问题。
- 优先级排序：根据影响范围、紧急程度、业务重要性对告警进行分级，确保关键告警优先处理。
- 上下文增强：为告警附加依赖关系、历史趋势、变更记录等上下文信息，缩短 MTTR（平均修复时间）。
| 降噪层次 | 输入 | 输出 | 典型技术 |
|---|---|---|---|
| L1：去重聚合 | 原始告警流（可能 1000 条/分钟） | 事件分组（10-50 组） | 指纹哈希、时间窗口聚合 |
| L2：优先级排序 | 事件分组列表 | P0/P1/P2/P3 分级队列 | 影响度评分、SLO 偏差计算 |
| L3：上下文增强 | 分级告警事件 | 可执行告警卡片 | CMDB 关联、变更事件回溯 |
实践建议： 降噪的最终目标是让值班人员每次轮班处理的告警数不超过 5 条，且每条告警都附带明确的处置建议。
1.3 基线核验在 on-call 中的价值
基线核验（Baseline Validation）是告警降噪体系中的关键前置环节。它通过持续验证系统指标是否处于预期基线范围内，在告警产生之前就过滤掉因基线漂移导致的误报。基线核验在 on-call 值班中的核心价值体现在以下三个方面：
- 前置过滤：在告警规则触发前，先校验当前指标是否偏离基线。若指标在基线范围内，即使触发阈值也不产生告警，避免因业务周期性波动导致的误报。
- 动态适应：基线随业务负载、时间窗口、版本发布自动调整，无需人工频繁修改告警阈值。
- 自动化集成：基线核验可作为 on-call 自动化流程的入口，当基线偏离时自动触发诊断脚本或扩容操作，减少人工介入。
常见误区： 基线核验不是静态阈值。静态阈值（如 CPU > 90%）无法适应业务波峰波谷，而基线核验基于历史数据动态计算，能区分"异常"和"正常波动"。
1.4 基线核验 vs 传统告警规则
| 对比维度 | 传统告警规则 | 基线核验 |
|---|---|---|
| 阈值设定 | 人工固定阈值 | 动态基线（均值 ± 标准差） |
| 适应能力 | 需频繁手动调整 | 自动适应业务周期 |
| 误报率 | 30%-50% | 5%-15% |
| 值班负担 | 高（大量误报需人工确认） | 低（基线内告警自动抑制） |
| 自动化集成 | 仅触发通知 | 可触发自愈脚本或扩容动作 |