错误预算与燃烧率：把可靠性变成发布决策
更新时间：2026-09-19。前置：SLI 与 SLO 怎么定义。错误预算是 SRE 最核心也最容易被讲虚的概念。它的本质是一句话：SLO 没要求 100%，那允许失败的额度就是一种可以花的预算，而花这笔预算的规则，决定了团队该拼命发版还是停手稳一稳。
一、预算怎么算：1 − SLO，再换算成分钟
错误预算（比例） = 1 - SLO
30 天总分钟数 = 30 × 24 × 60 = 43200 分钟
允许不可用时长 = 43200 × (1 - SLO)| SLO | 错误预算 | 30 天允许停机 | 适用 |
|---|---|---|---|
| 99.0% | 1.0% | 432 分钟（7.2h） | 内测/非核心 |
| 99.5% | 0.5% | 216 分钟（3.6h） | 一般业务 |
| 99.9% | 0.1% | 43.2 分钟 | 主流在线服务 |
| 99.95% | 0.05% | 21.6 分钟 | 核心交易 |
| 99.99% | 0.01% | 4.3 分钟 | 极高可用，成本陡增 |
延迟型 SLO 同理：若 SLO 是「99% 请求 < 500ms」，那 30 天内允许 1% 的请求（按总量计）超过 500ms，这 1% 就是错误预算。几个九与停机时间的完整换算见高可用几个九。
二、预算是「开发」和「稳定」的共同货币
没有错误预算时，开发想多发、运维想少发，永远在吵架。有了预算，争论变成一个客观数字：
- 预算充足（这个月还没怎么出错）：放心发布、做实验、上线新功能——可靠性为业务服务，不是越稳越好。
- 预算快耗尽：触发策略，发布需要更高审批、灰度比例收窄、非必要变更暂停。
- 预算耗尽（burned out）：冻结非紧急发布，精力转去修稳定性（加限流、补缓存、修根因），直到预算在新窗口恢复。
这样「要不要发版」不再看谁嗓门大，而看还剩多少预算。配套稳定性手段见优雅降级、舱壁隔离。
三、燃烧率 burn rate：预算花得多快
burn rate = 实际错误率 / 允许错误率 = 实际错误率 / (1 - SLO)- burn rate = 1：匀速花预算，30 天恰好用完，贴着 SLO 走。
- burn rate = 14.4：按此速度，预算在 30/14.4 ≈ 2 天内烧光——快速燃烧，紧急介入。
- burn rate = 6：约 5 天烧光——中速。
- burn rate < 1：花得比计划慢，预算有结余。
只看「当前错误率」无法判断严重度：对 99.9% 的 SLO，0.5% 错误率是 5 倍燃烧；对 99.0% 的 SLO，同样 0.5% 却只有 0.5 倍、毫无问题。燃烧率把不同 SLO 的严重度归一化，这是它比裸错误率好用的地方。
四、多窗口多燃烧率告警
只在长窗口（30 天）看反应太慢，只在短窗口（5 分钟）看会被瞬时抖动刷屏。生产做法是短窗口判严重度 + 长窗口确认可持续，两个窗口同时超阈值才告警：
| 级别 | 短窗口 | 燃烧率 | 长窗口 | 燃烧率 | 响应 |
|---|---|---|---|---|---|
| 紧急 Page | 5m | 14.4 | 1h | 14.4 | 立刻 on-call（2 天烧光） |
| 紧急 Page | 30m | 6 | 6h | 6 | 当班处理（5 天烧光） |
| 工单/预警 | 2h | 3 | 1d | 3 | 工作时间跟进（10 天） |
| 趋势 | 6h | 1 | 3d | 1 | 记录，预算匀速耗尽 |
双窗口同时满足才触发，既抓住突发（5m 立刻发现）、又过滤毛刺（必须持续 1h 才 page），这是治理告警风暴的关键技巧。Prometheus 规则写法见 SLO recording rules。
五、预算策略要事先写好
- 消耗与发布挂钩：定义明确门槛，如剩余 < 25% 时非核心变更需审批，= 0 时冻结。
- 按服务/接口分账：下单链路和静态资源不该共用一个池子，核心链路单独算。
- 计划内消耗：压测、混沌演练、已知迁移会故意消耗预算，应在独立窗口或显式标注，避免污染考核。
- 预算不是惩罚工具：频繁烧光说明 SLO 不合理或系统有结构性问题，应改架构/调目标，而不是追责个人——与无指责复盘一脉相承。
坑
- 把错误预算当财务惩罚：它是工程决策信号，烧光该改架构而非扣绩效，否则团队会把 SLO 注水。
- 只设单窗口告警：短窗误报多、长窗反应慢，必须双窗口 AND。
- 所有服务共用一个池子：一个边缘功能烧光全站预算，核心链路反被冻结。
- SLO 定成 100%：预算恒为 0，整套机制失效。
- 燃烧率不乘窗口看：14.4 倍只持续 1 分钟无伤大雅，持续 1 小时才是事故。
总结
错误预算等于 1 减 SLO 并可换算成每月允许出错的请求数或停机分钟（99.9% 约 43 分钟），它把「能不能发版」从主观争论变成客观规则——预算足就大胆迭代、耗尽就冻结非紧急发布转修稳定性；燃烧率用实际错误率除以允许错误率把不同 SLO 的严重度归一（14.4 倍约 2 天烧光），并以短窗口判烈度、长窗口确保持续的双阈值告警兼顾灵敏度与抗噪，让可靠性目标真正驱动发布节奏。