2. SLO 预算定义:错误预算的概念、计算公式与消耗机制
错误预算(Error Budget)是 SLO 驱动运维的核心量化工具。它将抽象的“可靠性目标”转化为一个可消耗、可追踪的数值指标,让团队能够基于数据做出发布、回滚、暂停变更等决策。本节从概念、计算公式、消耗速率和窗口期四个维度展开。
2.1 错误预算的核心概念
错误预算定义为:在 SLO 时间窗口内,系统允许发生故障或性能降级的总时间(或总事件数)。它本质上是“不可用预算”——只要消耗未超限,服务就处于 SLO 合规状态。
| 概念 | 说明 | 示例(99.9% SLO,30天窗口) |
|---|---|---|
| 总时间窗口 | SLO 评估的时间长度 | 30 天 = 2,592,000 秒 |
| SLO 目标 | 期望达到的可用性百分比 | 99.9% |
| 错误预算 | 允许的最大不可用时间 | 2,592,000 × (1 - 0.999) = 2,592 秒 ≈ 43.2 分钟 |
| 消耗量 | 实际发生的不可用时间 | 累计故障时长(如 1,200 秒) |
| 剩余预算 | 错误预算 - 消耗量 | 2,592 - 1,200 = 1,392 秒 |
关键认知:错误预算不是“可用预算”,而是“允许出错的额度”。100% 可用性意味着零错误预算,这在实践中既不现实也不经济。错误预算的存在,让团队可以在预算充足时加速迭代,在预算紧张时收紧变更。
2.2 错误预算的计算公式
错误预算的计算分为两个步骤:预算总量计算和实时消耗计算。
2.2.1 预算总量公式
ErrorBudget_total = TotalTime_window × (1 - SLO_target)
其中:
TotalTime_window = 窗口期总时长(秒)
SLO_target = 目标可用性(小数形式,如 0.999)
示例:对于 99.95% SLO、7 天窗口:
TotalTime_window = 7 × 24 × 3600 = 604,800 秒
ErrorBudget_total = 604,800 × (1 - 0.9995) = 604,800 × 0.0005 = 302.4 秒 ≈ 5 分钟
2.2.2 实时消耗公式
消耗量基于 SLI(服务等级指标)的实际测量值计算:
ErrorBudget_consumed = TotalTime_window × (1 - SLI_actual)
其中:
SLI_actual = 当前窗口内实际测量的可用性(小数形式)
剩余预算:
ErrorBudget_remaining = ErrorBudget_total - ErrorBudget_consumed
实战注意:在 GitOps 驱动的 SLO 复核中,错误预算的计算通常由监控系统(如 Prometheus + SLO 生成器)每 30-60 秒执行一次,并将结果写入 Git 仓库的 SLO 状态文件。ArgoCD 或 Flux 通过读取该文件决定是否允许自动同步。
2.3 预算消耗速率
消耗速率(Burn Rate)衡量错误预算被消耗的快慢程度。它是 SLO 告警和预算复核的关键指标。
| 消耗速率 | 含义 | 典型场景 | 建议动作 |
|---|---|---|---|
| < 1× | 慢速消耗,预算充足 | 正常运营,偶发小故障 | 正常发布,无需干预 |
| 1× ~ 2× | 中速消耗,需关注 | 局部故障或性能退化 | 启动复核,限制高风险变更 |
| 2× ~ 5× | 快速消耗,需响应 | 区域性故障或版本回退 | 暂停非紧急变更,启动应急 |
| > 5× | 急速消耗,预算即将耗尽 | 大规模中断或持续降级 | 冻结所有变更,全量回滚 |
消耗速率计算公式:
BurnRate = ErrorBudget_consumed / (ElapsedTime × (1 - SLO_target))
简化理解:
BurnRate = 实际消耗速度 / 允许消耗速度
当 BurnRate > 1 时,表示当前故障率已经超过 SLO 允许的长期平均值,预算正在加速消耗。
2.4 预算窗口期
窗口期(Window Period)是 SLO 评估的时间跨度,直接影响错误预算的敏感度和稳定性。
| 窗口类型 | 典型时长 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 滚动窗口 | 7天 / 30天 | 平滑波动,反映长期趋势 | 对突发故障响应迟钝 | 核心业务 SLO |
| 固定日历窗口 | 自然月 / 季度 | 与财务/业务周期对齐 | 窗口边界处预算重置突兀 | 合规报告、SLA 对账 |
| 复合窗口 | 多窗口并行 | 兼顾长期趋势与短期告警 | 复杂度高,需多指标联动 | GitOps 自动复核策略 |
窗口期选择陷阱:过短的窗口(如 1 小时)会导致错误预算频繁耗尽,引发不必要的变更冻结;过长的窗口(如 90 天)会掩盖短期故障,使预算复核失去时效性。推荐在 GitOps 实践中使用复合窗口策略:主窗口 30 天用于预算总量计算,辅窗口 1 小时用于快速告警。
2.5 复合窗口策略在 GitOps 中的应用
在 GitOps 驱动的 SLO 预算复核中,单一窗口无法同时满足“长期趋势稳定”和“短期故障敏感”的需求。推荐使用复合窗口策略:
- 长期窗口(30 天滚动):用于计算错误预算总量,决定是否允许重大版本发布。
- 短期窗口(1 小时滚动):用于快速检测突发故障,触发紧急复核和变更冻结。
- 中期窗口(7 天滚动):用于周度预算复核,评估本周变更对可靠性的影响。
GitOps 实践示例:在 ArgoCD 的 ApplicationSet 中,可以配置 PreSync 钩子读取 SLO 状态 ConfigMap。当短期窗口 BurnRate > 3 时,PreSync 返回失败,阻止自动同步;当长期窗口剩余预算 < 20% 时,仅允许 P0 级热修复通过。
2.6 错误预算与 GitOps 复核的联动机制
在 GitOps 工作流中,错误预算状态直接驱动复核决策:
- 监控层:Prometheus + SLO 生成器持续计算错误预算和消耗速率,写入指标存储。
- 状态同步层:Operator 定期将错误预算状态同步到 Git 仓库的
slo-status.yaml文件。 - 复核决策层:ArgoCD / Flux 的 PreSync 钩子读取该文件,判断是否允许当前变更。
- 通知层:当预算消耗速率超过阈值或剩余预算低于警戒线时,自动触发 Slack / PagerDuty 通知。
常见误区:错误预算不是“用完即止”的静态额度。在滚动窗口下,随着时间推移,旧的故障记录会移出窗口,预算会自动恢复。因此,即使预算耗尽,只要停止故障并等待窗口滚动,预算会逐步回升。GitOps 复核策略应区分“预算耗尽”和“持续高消耗速率”两种状态,前者可等待窗口重置,后者需要立即人工介入。