1. 告警降噪概述
1.1 告警风暴的成因
在值班环境中，告警风暴（Alert Storm）是指短时间内大量无效、重复或低优先级告警同时涌入，导致值班人员无法识别真正需要处理的故障。其根本成因可归纳为以下四类：
| 成因类别 | 典型场景 | 影响 |
|---|---|---|
| 级联故障 | 底层基础设施（如网络交换机、数据库主库）故障，引发上层所有依赖服务告警 | 单点故障产生数百条衍生告警 |
| 阈值过窄 | CPU 使用率超过 70% 即告警，但业务高峰期正常波动即触发 | 告警量随业务流量线性增长 |
| 重复上报 | 同一故障被监控系统、自愈脚本、人工巡检同时发现并上报 | 告警去重机制缺失，重复率可达 60% 以上 |
| 配置缺失 | 新上线服务未配置告警聚合规则，直接使用默认全量告警 | 告警规则与业务实际脱节 |
关键数据： 据行业统计，值班环境中约 70%–85% 的告警属于非 actionable（无需人工处理）的噪声告警。告警风暴期间，MTTR（平均修复时间）可延长 3–5 倍。
1.2 降噪的核心目标
告警降噪并非简单减少告警数量，而是通过系统化的策略，让值班人员只关注 真正需要人工处理 的告警。核心目标可拆解为三个层次：
- 减少噪声量： 消除重复、自愈、已知问题等无需响应的告警，将告警量降低 60%–80%。
- 提升信噪比： 提高有效告警（actionable alert）在总告警中的占比，目标信噪比 > 0.8。
- 缩短认知时间： 通过聚合、关联、上下文增强，让值班人员在 30 秒内理解告警根因。
| 指标 | 降噪前（典型值） | 降噪后（目标值） | 说明 |
|---|---|---|---|
| 日均告警量 | 500–2000 条 | 50–200 条 | 减少 80%–90% |
| 有效告警占比 | 15%–30% | > 80% | 信噪比提升 3–5 倍 |
| MTTR | 45–90 分钟 | 15–30 分钟 | 缩短 50%–70% |
| 值班人员疲劳指数 | 高（频繁误报） | 低（聚焦关键） | 主观体验改善 |
降噪原则： 宁可漏报一次低风险告警，也不要误报十次噪声告警。降噪策略应优先保证关键告警的 100% 送达率。
1.3 基线核验在降噪中的定位
基线核验（Baseline Validation）是告警降噪体系中的 前置过滤层。它在告警触发后、通知值班人员之前，对告警进行快速校验：当前系统状态是否与预期基线一致？如果一致，则判定为噪声并自动抑制。
基线核验在降噪体系中的定位可用下图表示：
基线核验的典型应用场景包括：
- 时间基线： 对比当前指标与历史同期（如过去 7 天同一时段）的正常范围，避免因业务高峰误报。
- 依赖基线： 当上游服务故障时，下游告警自动抑制，直到上游恢复后再重新评估。
- 变更基线： 在发布窗口期间，放宽部分告警阈值，避免因部署过程中的短暂波动触发告警。
- 容量基线： 根据当前集群的冗余容量，判断资源使用率告警是否真正需要处理。
注意： 基线核验不是静态规则，需要定期根据业务变化、历史告警数据、值班反馈进行迭代优化。错误的基线配置可能导致关键告警被误抑制，造成故障漏报。