📚 课程目录第4章 SLO计算与燃烧率

4. SLO 计算与燃烧率：SLO 燃烧率算法、燃烧速率窗口、多窗口燃烧率告警策略

SLO（Service Level Objective）是服务质量的目标值，而燃烧率（Burn Rate）是衡量 SLO 消耗速度的核心指标。当错误预算消耗过快时，燃烧率告警能够提前预警，避免 SLO 在窗口期末尾意外违约。本节将深入讲解燃烧率的数学原理、窗口计算方式以及多窗口组合告警策略。

4.1 燃烧率算法：从错误预算到燃烧速率

燃烧率定义为实际错误率与 SLO 允许错误率的比值。它量化了错误预算被消耗的快慢程度。

术语	定义	示例
错误预算	1 - SLO 目标值（如 99.9% 的 SLO，错误预算为 0.1%）	月度总请求 1000 万，允许错误 1 万次
实际错误率	在观测窗口内，错误请求数 / 总请求数	过去 1 小时内错误 500 次 / 总请求 10 万 = 0.5%
燃烧率	实际错误率 / 允许错误率	0.5% / 0.1% = 5x（表示以 5 倍速度消耗预算）

燃烧率公式：

BurnRate = (ErrorCount / TotalRequests) / (1 - SLO)

示例：
SLO = 99.9% → 允许错误率 = 0.001
窗口内错误率 = 0.005
BurnRate = 0.005 / 0.001 = 5.0

  关键理解： 燃烧率 = 1.0 表示以恰好填满错误预算的速度消耗；燃烧率 > 1.0 表示超速消耗，将在窗口期结束前耗尽预算。

4.2 燃烧速率窗口：时间维度下的预算消耗

燃烧率必须与时间窗口绑定才有意义。不同的窗口长度反映了不同时间尺度下的风险暴露程度。

短窗口（1-5 分钟）： 检测突发性故障，燃烧率极高（如 100x），用于即时告警。
中窗口（30 分钟 - 1 小时）： 检测持续性异常，燃烧率中等（如 10x），用于快速响应。
长窗口（6 小时 - 1 天）： 检测慢性退化，燃烧率较低（如 2x），用于趋势分析。

窗口与预算耗尽时间的关系：

预算耗尽时间 = 窗口长度 × (1 / BurnRate)

示例：
窗口 = 1 小时，BurnRate = 5x
预算耗尽时间 = 1h × (1/5) = 12 分钟

实践建议： 选择窗口长度时，确保窗口内包含足够的请求量以产生统计意义。对于低流量服务，窗口应适当延长。

4.3 多窗口燃烧率告警策略：组合检测与降噪

单一窗口的燃烧率告警容易产生误报（短窗口噪声）或漏报（长窗口延迟）。多窗口组合策略通过同时监控多个时间尺度的燃烧率，实现快速检测与高精度的平衡。

标准多窗口告警矩阵（以 99.9% SLO 为例）：

告警级别	窗口长度	燃烧率阈值	预算耗尽时间	响应要求
P0（严重）	1 小时	≥ 14.4x	~4 分钟	立即响应
P1（高）	6 小时	≥ 6x	~1 小时	15 分钟内响应
P2（中）	1 天	≥ 2x	~12 小时	2 小时内响应
P3（低）	7 天	≥ 1.2x	~5.8 天	日常排期

注意： 燃烧率阈值应根据服务的关键性和 SLO 严格程度调整。关键服务应使用更激进的阈值（如 P0 设为 10x 而非 14.4x）。

4.4 多窗口燃烧率告警架构

下图展示了多窗口燃烧率告警系统的核心组件与数据流：

4.5 多窗口组合逻辑与防抖动

多窗口告警并非简单叠加，而是通过组合逻辑和防抖动机制提升告警质量。

组合逻辑模式：

AND 模式： 短窗口 AND 长窗口同时触发才告警。适用于需要确认持续性的场景，减少误报。
OR 模式： 任一窗口触发即告警。适用于对延迟极度敏感的关键服务。
加权模式： 短窗口触发升级告警级别，长窗口触发降级或关闭。适用于自适应告警。

防抖动策略：

策略	描述	适用场景
持续触发	燃烧率连续 N 个评估周期超过阈值才告警	短窗口（如连续 3 个 1 分钟窗口）
冷却期	告警触发后，M 分钟内不再重复告警	所有窗口，避免告警风暴
滑动窗口平均	使用滑动平均燃烧率而非瞬时值	长窗口，平滑毛刺

4.6 燃烧率告警的分布式追踪集成

当燃烧率告警触发时，分布式追踪能够提供根因定位的上下文。下图展示了告警触发后的追踪分析流程：

集成最佳实践： 在告警负载中包含追踪查询链接，使运维人员能够一键跳转到对应时间窗口的追踪视图，将 MTTR 从分钟级缩短到秒级。

4.7 燃烧率告警配置示例

以下是一个基于 Prometheus 和 Alertmanager 的多窗口燃烧率告警配置片段：

groups:
  - name: slo_burn_rate
    rules:
      # 短窗口：1小时，燃烧率 ≥ 14.4x
      - alert: SLOHighBurnRate
        expr: |
          (
            rate(errors_total[1h])
            /
            rate(requests_total[1h])
          ) / (1 - 0.999) >= 14.4
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "SLO 燃烧率过高 ({{ $value | humanize }}x)"

      # 中窗口：6小时，燃烧率 ≥ 6x
      - alert: SLOMediumBurnRate
        expr: |
          (
            rate(errors_total[6h])
            /
            rate(requests_total[6h])
          ) / (1 - 0.999) >= 6
        for: 10m
        labels:
          severity: high
        annotations:
          summary: "SLO 燃烧率中等 ({{ $value | humanize }}x)"

      # 长窗口：1天，燃烧率 ≥ 2x
      - alert: SLOLowBurnRate
        expr: |
          (
            rate(errors_total[1d])
            /
            rate(requests_total[1d])
          ) / (1 - 0.999) >= 2
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "SLO 燃烧率偏低 ({{ $value | humanize }}x)"

  配置要点：
  for 子句实现防抖动，避免瞬时毛刺触发告警。
severity 标签用于告警分级和路由。
燃烧率阈值应根据 SLO 目标动态调整，99.99% 的 SLO 需要更激进的阈值。

4.8 燃烧率告警的常见陷阱与优化

陷阱	表现	优化方案
窗口过短	频繁误报，运维疲劳	延长窗口或增加持续触发次数
窗口过长	告警延迟，SLO 已违约才触发	增加短窗口组合，使用多级告警
忽略低流量	低流量时段燃烧率波动大	使用最小请求量阈值，低于阈值不计算
单一阈值	无法区分突发与慢性故障	采用多窗口、多阈值组合策略
未集成追踪	告警后仍需手动排查根因	在告警负载中嵌入追踪查询参数

通过合理配置燃烧率算法、选择适当的窗口长度、实施多窗口组合告警策略，并集成分布式追踪数据，团队能够在 SLO 违约发生前获得预警，并将 MTTR 降至最低。燃烧率告警不仅是 SLO 的守护者，更是可观测性体系中的核心决策引擎。