错误预算到底是什么？怎么用？

更新时间：2026-09-19。短答页。错误预算是 SRE 把「稳定」和「迭代」这对矛盾变成客观数字的核心机制。

一句话回答

错误预算 = 1 − SLO，即「在不违背目标的前提下，一段时间内允许出错的额度」。它把可靠性变成一种可消耗的预算：预算充足就能放心发版做实验，预算耗尽就冻结非紧急变更、集中修稳定性。

怎么算

SLO 99.9%（30 天） → 错误预算 = 0.1%
允许停机 ≈ 43200 × 0.1% ≈ 43 分钟
延迟型 SLO：允许 0.1% 的请求超过延迟阈值

99% 到 99.99% 的停机分钟对照见 SLO 与错误预算。

怎么用：一个共同货币

• 没有预算时：开发想多发、运维想稳，永远吵架。
• 有预算后：看还剩多少做决定——
  • 剩余充足：这个月没怎么出错，大胆上线新功能（稳定性是为业务服务的）。
  • 快速消耗（高燃烧率）：收紧灰度、提高发布审批。
  • 耗尽 = 0：冻结非紧急发布，全员先还「稳定性债」，直到预算恢复。

燃烧率 = 实际错误率 / 允许错误率
14.4 倍 → 约 2 天烧光月预算，要紧急处理

落地要点

1. 按服务/接口分账：下单核心链路单独算，别让边缘功能烧光全站预算。
2. 配多窗口燃烧率告警：短窗判突发、长窗确保持续，见 SLO recording rules。
3. 不是惩罚工具：频繁烧光说明 SLO 不合理或架构有问题，应改系统而非扣绩效。
4. 计划内消耗标注：压测、混沌演练会故意出错，单独窗口统计。

坑

• SLO 定 100%，预算恒为 0，机制失效。
• 所有服务共用一个池子，一个非核心故障冻结了核心发布。
• 只看预算余额不看燃烧速度，等耗尽才发现已经来不及。

总结

错误预算等于 1 减 SLO，代表一个月内被允许的失败请求或停机额度（99.9% 约 43 分钟），它让「要不要发版」从立场之争变成看余额决策：预算足就快速迭代、燃烧过快就收紧、耗尽就冻结发布转修稳定性；实践中按核心链路分账、用多窗口燃烧率监控、并把它当作工程信号而非惩罚，才能真正平衡速度与可靠。