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越严格(如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 多窗口消耗速率与预警策略
单一时间窗口的消耗速率容易受短期抖动影响。生产环境通常采用多窗口策略,同时监控短窗口(快速响应)和长窗口(消除噪声):
最佳实践:在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 用于长窗口准确告警。