流量对齐的 burn rate 告警分级：凌晨 14x 与高峰 14x 的严重度差异怎么算？
作者：许墨白-600｜技术文档工程师｜15 年经验 关键词：SLO、burn rate、告警分级、流量对齐、错误预算
一、现象与背景：流量差异下的 burn rate 误报
C 端电商主链路，对外承诺 P99 < 300ms，30 天 SLO 窗口，错误预算 0.05%。入口 QPS 有极强的日内周期：凌晨 0–6 点约 80 QPS，上午 10–14 点约 650 QPS，相差 8 倍。延迟分布也随流量走——低峰期后端连接池/缓存命中都很宽裕，P99 常在 90–130ms；高峰期 P99 基线本身就在 220–260ms 附近贴着 SLO 跑。
告警用 Google SRE Book 多窗口 burn rate：fast 1h/2h @ 14.4x（page），slow 6h/3d @ 3x（ticket），公式是标准那套「窗口内错误率 / 允许错误率」。
现象
- 凌晨 1 小时 P99 抖到 320ms（错误率约 0.7%），按标准公式算 burn rate ≈ 14x，直接 page。但同样 0.7% 错误率发生在上午高峰，对 30 天预算的实际消耗只相当于凌晨的 1/8（因为分母是请求数，不是时间）。
- 反过来，凌晨误报我们目前只能 mute，但 mute 之后真故障也一起被压掉了；上个月凌晨一次真实的下游超时（持续 40 分钟，烧掉全月预算约 3%）就是被值班同学当成「夜间抖动」关掉的。
- 团队里两种声音：一种说「错误预算本来就是按请求数算的，公式已经天然按流量加权，不用改」；另一种说「那 page 的『严重度』没加权，凌晨一次 page 和高峰一次 page 被同等对待，值班响应成本完全不对等」。
二、原理与根因：流量对齐的 burn rate 为何需要分级
burn rate 的计算本质上是错误预算的消耗比例，而错误预算的消耗比例 = (实际错误数 / 允许错误数) × 100%。
但流量差异导致两个关键点：
- 错误预算的绝对消耗：低峰时，同样的错误率，消耗的预算远低于高峰。
- 告警严重度的感知成本：值班同学对凌晨 page 的响应成本远高于高峰期。
因此，告警分级需要在 burn rate 计算的基础上叠加流量权重，以实现「流量对齐」。
三、具体做法：流量对齐的 burn rate 分级公式
我们提出一个公式，用于计算不同流量时段下的 burn rate 的严重度权重：
严重度权重 = (burn rate) × (流量占比) / (最大流量占比)
其中：
- burn rate：由 Google SRE Book 公式计算得出（如 14x）。
- 流量占比：当前时段的流量占全天流量的比例（如凌晨 12%）。
- 最大流量占比：全天流量的最大值（如高峰时段 87.5%）。
例如，凌晨 14x 的 burn rate，流量占比 12%，最大流量占比 87.5%：
严重度权重 = 14 × 12% / 87.5% ≈ 1.92
这个权重值可以用于告警分级：
- 严重度权重 < 1 → 静默
- 1 ≤ 严重度权重 < 3 → ticket
- 3 ≤ 严重度权重 < 6 → page
- 严重度权重 ≥ 6 → 优先 page
四、踩过的坑或反直觉之处
- 流量占比的准确性：必须确保流量占比是基于真实数据计算的，不能主观估算。
- 最大流量占比的动态调整：高峰期流量占比可能随季节或促销活动波动，需定期更新。
- 告警系统的实现复杂度：需在 Prometheus 中编写规则，动态计算流量占比并调整严重度权重。
五、结论与可复用清单
-
流量对齐的 burn rate 分级公式：
严重度权重 = (burn rate) × (流量占比) / (最大流量占比) -
告警分级规则：
| 严重度权重 | 告警级别 | 操作 | |---|---|---| | < 1 | 静默 | 无需响应 | | 1 ≤ 严重度权重 < 3 | ticket | 生成 ticket，值班同学查看 | | 3 ≤ 严重度权重 < 6 | page | 生成 page，值班同学响应 | | 严重度权重 ≥ 6 | 优先 page | 紧急响应 |
-
流量占比的计算方式：使用 Prometheus 的
rate()函数计算每小时的流量占比。 -
最大流量占比的更新频率：建议每周或每月更新一次，以适应业务变化。
通过这个方法，可以实现「流量对齐」的 burn rate 告警分级，既保证了错误预算的合理使用，又降低了值班同学的响应成本。