Error Budget 与发布节奏

公式

Error Budget = (1 - SLO) × 时间窗口

例：SLO = 99.9% / 滚动 30 天 → Error Budget ≈ 每月 43 分钟不可用。

这 43 分钟可以是：

Error Budget 不是用来"算出能挂多少分钟"——是用来回答这个月还能发多少改动。

预算还多   → 团队可以激进发布、做实验、上风险高的功能
预算快用完 → 暂停非关键发布、加测试覆盖、修可靠性
预算用光   → 冻结发布，全力还稳定性债

"Error Budget 是用来花的，不是用来攒的。"

这句话的意思：没用完预算 = 你的目标定得太保守——可能因此错失了上线速度。SRE 的目标不是"零事故"，是"最大化用户价值"。

具体来说：

预算耗光 → 不是"再开个会决定要不要继续发"——按 SLO 政策自动冻结，恢复后自动解冻。

燃烧率 = 当前错误率 / SLO 允许的错误率

例：SLO = 99.9% → 允许错误率 0.1%。某窗口内实际错误率 2.4% → 燃烧率 = 2.4 / 0.1 = 24x。

按这个速率，30 天预算大约 30 / 24 ≈ 1.25 天就燃尽。

燃烧率告警通常分多档（见上一篇 SLO 文章末尾的多窗口告警表）：

按预设政策执行（写下来、不临时议）：

如果 Error Budget 在月窗口内剩余 < 0：
  1. 立即冻结所有非紧急生产发布
  2. 当前迭代切到可靠性主题
  3. 复盘：是 SLO 太严还是真的不稳定
  4. 预算在新窗口恢复后解冻

如果是真实坏事：
  - 升级故障复盘
  - 加监控、加测试、加冗余、加容量

Q：业务说"必须发"怎么办？ A：SLO/Error Budget 是 SRE 与业务事先约定的。事到临头要发 = 协议失效。要么调 SLO（公开讨论后），要么接受冻结。

Q：第三方依赖故障算谁的预算？ A：用户视角是"你的服务挂了"，所以算你的。这是为什么要选靠谱依赖、做 fallback。

Q：SLO 太严，预算永远是负的？ A：要么 SLO 定得不切实际（调），要么服务本身有重大问题（修）。不要装看不见。

Q：SLO 太松，预算永远花不完？ A：把 SLO 提一档；或者拆出更细的 SLI（如不同 endpoint）独立 SLO。

部分适用：