错误预算是什么
错误预算是 1 减去 SLO 得到的允许失败额度：SLO 99.9% 对应 30 天约 43 分 12 秒不可用。它把“可靠性与交付速度如何取舍”从争论变成算术：预算有富余就多发布、多做实验，预算告急就收紧高风险变更、把资源投向可靠性。预算是给服务的共享额度，不按人或团队分摊。它本身只是数字，配套政策（谁决定冻结、冻结哪类变更、何时恢复发布）才是它能起作用的关键。
基本信息
| 公式 | 错误预算 = 100% - SLO |
|---|---|
| 示例 | SLO 99.9% → 30 天约 43 分 12 秒 |
| 示例 | SLO 99.99% → 30 天约 4 分 19 秒 |
| 用途 | 决定发布节奏、变更冻结与可靠性投入 |
| 配套 | 燃烧率告警 + 明确的冻结与恢复政策 |
| 注意 | 按 SLO 窗口滚动计算，不按自然月清零 |
典型使用场景
- 发布节奏决策：预算充足时提高发布频率，让改动更快得到真实流量验证
- 冻结判定：预算消耗超过阈值时自动冻结高风险变更，优先修可靠性
- 告警配置：多窗口多燃烧率组合，兼顾快速发现与抗抖动
- 业务沟通：用“本月还剩多少分钟”取代“系统稳不稳定”的定性争论
- 季度复盘：分析预算消耗来源，决定补架构、补测试还是补容量
燃烧率示例
燃烧率示例
1 小时烧掉月度预算的 2% → 燃烧率约 14.4
6 小时烧掉 5% → 约 6.0
3 天烧掉 10% → 约 1.0
常见做法：短窗口高燃烧率立即告警，长窗口低燃烧率开工单
口径提醒：预算按 SLO 窗口滚动计算，跨月不清零燃烧率与处置对照
| 燃烧率 | 消耗速度 | 典型处置 |
|---|---|---|
| 14.4 | 1 小时消耗 2% 月度预算 | 立即呼叫值班，按重大风险处理 |
| 6.0 | 6 小时消耗 5% 月度预算 | 通知服务负责人，暂停高风险变更 |
| 1.0 | 3 天消耗 10% 月度预算 | 开改进工单，排查持续性劣化 |
| 小于 1 | 慢于预算线消耗 | 正常发布，继续观察趋势 |
预算是给服务的共享额度，不按个人或团队分摊；一旦变成考核指标，团队会倾向少发布来保预算，量化权衡就失效了。
燃烧率告警要同时配短窗口与长窗口：只看短窗口会被瞬时抖动反复触发，只看长窗口则发现太慢，预算已经烧掉大半。
参考口径来自 Google SRE 系列公开资料：SLO 99.9% 的 30 天窗口约等于 43 分 12 秒，99.99% 约 4 分 19 秒，可用于快速估算预算额度。
与相邻指标的关系
错误预算的数值由 SLO 推导，SLO 又建立在 SLI 口径之上，因此改动 SLI 定义等于改动预算额度，必须走评审。它与 DORA 的变更失败率、故障恢复时长互为解释：预算烧得快，通常意味着变更失败率高或恢复偏慢，可以顺着这两条线找根因，而不是只盯预算数字本身。
预算告急时处置顺序
- 先确认口径：核对 SLI 采集是否正常，排除误报造成的假性消耗
- 立即止血：把资源集中到造成消耗的故障或劣化路径上
- 暂停高风险变更：只保留修复类与安全类改动，发布窗口顺延
- 开改进工单：把消耗来源转成可跟踪的工程任务并指定负责人
- 设恢复条件：明确预算回升或根因消除后，如何逐步恢复发布节奏
预算额度只与服务承诺有关，与团队规模无关：小服务照搬大服务的预算线，必然长期告急，目标要按服务单独设定。