告警阈值应该用「绝对值」还是「基线偏差」：你的团队到底选哪个？为什么？

【背景】

做了 10 年数据分析与指标体系搭建，一个反复被问的问题：告警阈值到底怎么定？

最常见的两种做法：

做法 A：绝对值

• P99 > 200ms 报警
• 错误率 > 1% 报警
• 队列长度 > 1000 报警

优点：简单、可解释、新人上手快。 缺点：同一阈值在不同时段意义完全不同。白天 200ms 可能是正常波动，凌晨 200ms 可能是真事故。

做法 B：基线偏差

• 与过去 7 天同时段均值比，偏差 > 3σ 报警
• 同比 / 环比超过 X% 报警
• 动态阈值，基于历史数据自动调整

优点：能适应业务周期（早晚高峰、周末效应）。 缺点：实现复杂，冷启动期没有基线，而且「基线本身就是事故期数据」时会失效。

【我的倾向与理由】

我的经验是：分层混合，不选边。

• L1 硬下限：用绝对值兜底。比如错误率 > 5%、P99 > 1s、队列 > 10000——这些是「业务不可用」的硬边界，不依赖历史数据。
• L2 软预警：用基线偏差。比如 P99 比同时段基线高 40%、错误率比基线高 3 倍——这些是「正在恶化」的 leading 信号。
• L3 趋势：用斜率 / 加速度。比如 P99 在过去 10 分钟线性上升且斜率 > 阈值——这是「即将恶化」的早期信号。

关键原则：L1 保证不漏，L2 保证不吵，L3 保证有提前量。

但具体选哪个、阈值怎么定，高度依赖你的业务特征：

• 流量稳定的批处理系统 → 绝对值够用
• 强周期性的 C 端业务 → 必须用基线偏差
• 流量波动大但业务关键 → 需要 L3 趋势

【想听大家怎么选】

1. 你们线上的告警阈值是绝对值、基线偏差、还是混合？比例大概怎么分？
2. 基线数据窗口你们怎么取？7 天？30 天？遇到版本迭代 / 业务变更时基线怎么刷新？
3. 有没有遇到过「基线本身是脏数据」导致告警失效的案例？怎么处理的？
4. 对于新上线、没有历史数据的服务，你们怎么冷启动告警阈值？

欢迎带上你的具体场景（业务类型、流量特征、告警工具）来聊，越具体越好。