4. 误差预算概念:数学定义、与SLO/SLI的关系、预算消耗速率

误差预算(Error Budget)是SRE实践中连接可靠性目标与变更速度的核心量化工具。它本质上是一个可容忍的失败额度——在SLO规定的周期内,系统允许发生多少次或多少比例的故障。一旦预算耗尽,团队应主动冻结高风险变更,优先投入稳定性工作。

4.1 误差预算的数学定义

误差预算的数学定义建立在SLO与SLI的差值之上。设SLO目标为 \( T \)(例如99.9%),SLI实际值为 \( S \),则误差预算 \( B \) 的计算方式如下:

指标 符号 说明 示例
SLO目标 \( T \) 承诺的可靠性百分比 99.9%
SLI实际值 \( S \) 当前观测到的成功率 99.95%
总预算 \( B_{total} \) \( 1 - T \)(周期内允许的最大失败比例) 0.1%
已消耗预算 \( B_{consumed} \) \( 1 - S \)(实际发生的失败比例) 0.05%
剩余预算 \( B_{remaining} \) \( B_{total} - B_{consumed} \) 0.05%

核心公式:

Error Budget = 1 - SLO_target
Remaining Budget = (1 - SLO_target) - (1 - SLI_actual)
                = SLI_actual - SLO_target

当 SLI_actual > SLO_target 时,剩余预算为正,系统处于健康状态;当 SLI_actual < SLO_target 时,预算为负,表示已超支。

关键理解:误差预算不是“剩余可用故障次数”,而是剩余可容忍的失败比例。在滚动窗口(如30天)内,预算会随时间自然恢复——只要后续表现优于SLO,就能重新积累额度。

4.2 误差预算与SLO/SLI的关系

三者的关系可以概括为“SLI测量现状,SLO设定边界,误差预算量化差距”。下图展示了它们之间的闭环联动:

误差预算与SLO/SLI关系图 SLI(服务等级指标) 实际观测:请求成功率 SLO(服务等级目标) 承诺边界:99.9% 误差预算 可容忍失败额度 对比 推导 预算耗尽 → 冻结变更 变更决策 发布 / 回滚 / 限速 变更影响SLI 闭环逻辑 SLI 实测 → 对比 SLO → 计算误差预算 → 指导变更决策 → 变更影响 SLI → 重新测量
实践要点:SLO越严格(如99.99%),误差预算越小(0.01%),团队对故障的容忍度越低。反之,宽松的SLO(如99.5%)提供更大的预算空间,允许更频繁的变更。

4.3 预算消耗速率

预算消耗速率(Burn Rate)衡量误差预算被消耗的快慢,是早期预警的关键指标。它定义为实际失败率与SLO允许的最大失败率之比:

Burn Rate = (1 - SLI_actual) / (1 - SLO_target)

示例:
SLO = 99.9% → 允许失败率 = 0.1%
SLI = 99.7% → 实际失败率 = 0.3%
Burn Rate = 0.3% / 0.1% = 3.0

消耗速率的意义在于:

  • Burn Rate = 1.0:恰好以SLO允许的速度消耗预算,周期结束时预算刚好用完。
  • Burn Rate > 1.0:预算消耗过快,若不干预,将在周期结束前耗尽。
  • Burn Rate < 1.0:预算消耗较慢,系统有富余容量。

下表展示了不同消耗速率下的预警阈值与响应动作:

消耗速率范围 预警级别 预计耗尽时间 推荐动作
0 ~ 1.0 正常 > 窗口周期 常规运维,无需干预
1.0 ~ 2.0 警告 50% ~ 100% 窗口 排查根因,准备回滚方案
2.0 ~ 5.0 严重 20% ~ 50% 窗口 立即降级或回滚,冻结非关键变更
> 5.0 危急 < 20% 窗口 全量回滚,启动应急响应

在PromQL中,消耗速率可以通过以下表达式计算:

# 30分钟窗口的消耗速率
burn_rate_30m = (1 - avg_over_time(sli_success_ratio[30m])) / (1 - slo_target)

# 多窗口多速率告警(示例:1小时窗口,速率 > 2)
alert: HighBurnRate
expr: (1 - avg_over_time(sli_success_ratio[1h])) / (1 - 0.999) > 2
for: 5m
labels:
  severity: critical
annotations:
  summary: "误差预算消耗速率过高 ({{ $value | humanize }})"
常见陷阱:仅监控剩余预算百分比可能滞后——当预算还剩50%时,若消耗速率高达10x,实际剩余时间只有窗口的5%。务必同时监控消耗速率和预计耗尽时间,而非仅看值。

4.4 多窗口消耗速率与预警策略

单一时间窗口的消耗速率容易受短期抖动影响。生产环境通常采用多窗口策略,同时监控短窗口(快速响应)和长窗口(消除噪声):

多窗口消耗速率预警策略 短窗口(5分钟) 快速检测突发故障 阈值:Burn Rate > 10 中窗口(30分钟) 平衡灵敏度与稳定性 阈值:Burn Rate > 3 长窗口(6小时) 消除短期噪声 阈值:Burn Rate > 1.5 多窗口组合告警逻辑 任意窗口触发 → 生成对应严重级别的告警 短窗口告警:快速响应,但可能误报 长窗口告警:准确率高,但响应延迟 推荐:短窗口 + 长窗口 组合,兼顾速度与准确
最佳实践:在Prometheus中配置多窗口消耗速率告警时,建议使用 avg_over_time 配合不同时间范围,并设置 for 子句防止抖动。例如:
avg_over_time(sli_failure_ratio[5m]) / (1 - slo_target) > 10 用于短窗口快速告警;
avg_over_time(sli_failure_ratio[6h]) / (1 - slo_target) > 1.5 用于长窗口准确告警。