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

【背景】

做了 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 趋势

【冷启动与脏基线的具体做法——补充】

这是最容易被忽略、但决定 L2 能不能长期跑下去的两块：

1. 新服务冷启动：三阶段阈值递进

• D0~D3（无基线期）：只开 L1 绝对值，阈值偏松（比如错误率 > 2%、P99 > 500ms），目的是先攒 72h 干净数据，同时避免误报把团队脱敏。
• D4~D7（基线建立期）：L1 保持，L2 开始用「过去 3 天同时段 P50 ± 2×IQR」做软预警（IQR 比 σ 更抗离群点，冷启动期样本少，σ 会被一次毛刺拉爆）。
• D8+（稳态期）：L1/L2/L3 全开，基线窗口切到 7 天，L2 用 3×IQR 或 3σ。

2. 基线脏数据的自动剔除 基线本身是事故期数据是 L2 最经典的失效模式。三条硬规则：

• 事故窗口打标：事故复盘时把时间区间写入 incident_windows 表，基线计算时直接排除。
• 离群日剔除：基线窗口内单日 P99 > 全窗口 P99 × 2，或错误率 > 全窗口均值 × 5，这一天不进基线（用 IQR 而不是均值，避免"均值被脏数据拉高后反而不报警"）。
• 自动降级：如果基线窗口内有效天数 < 50%，L2 自动降级到 L1（用更松的绝对值），并打一个 baseline_degraded 标签——让团队看到"现在没有基线保护"这个事实，比无声失效好得多。

3. 版本迭代 / 业务变更时基线怎么刷新

• 小版本（同一业务逻辑）：基线不刷新，但打一个 version_change 标签，L2 报警时附带"距上次版本变更 X 小时"，让值班人判断是不是新版本带来的正常波动。
• 大版本 / 新业务上线：基线整体作废，重新走冷启动三阶段。不要尝试"新旧基线加权"——那种做法在业务形态变化大的时候会给出一个"两边都不像"的基线，比没有基线更糟。

【想听大家怎么选】

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

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