错误预算是什么
错误预算是把 SLO 换算成允许失败的额度：可用性目标 99.9% 意味着 30 天里可以损失约 0.1% 的时间，也就是 43 分钟左右。它的作用是把稳定性争论变成可结算的数字：预算还有剩余就允许承担风险加快发布，预算耗尽就该停下来做可靠性工作。
30 天周期允许的不可用时长
| SLO | 预算比例 | 每月允许不可用 |
|---|---|---|
| 99% | 1% | 7 小时 12 分钟 |
| 99.9% | 0.1% | 43 分钟 12 秒 |
| 99.95% | 0.05% | 21 分钟 36 秒 |
| 99.99% | 0.01% | 4 分钟 19 秒 |
预算消耗进度
预算消耗进度
# 当前窗口不可用比例（30 天滚动）
1 - (sum(rate(http_requests_total{code!~"5.."}[30d]))
/ sum(rate(http_requests_total[30d])))
# 除以预算比例得到消耗进度，结果大于 1 表示已耗尽
# 0.1% 预算对应分母 0.001，按自己的 SLO 调整典型使用场景
- 发布决策：预算充足时加快迭代节奏，把风险留给可控的变更
- 故障复盘量化：用预算消耗量衡量一次故障的严重程度，替代主观判断
- 跨团队沟通：把可靠性讨论变成数字对账，减少能不能发的争论
- 投入排序：连续几个周期预算耗尽，说明稳定性欠债需要立项处理
- 灰度验收：观察灰度期间的预算消耗速率，判断是否继续放量
错误预算只有写进发布流程才有意义：常见做法是剩余低于 25% 时限制高风险变更，耗尽时冻结功能发布并优先修复。
统计口径要提前约定：哪些失败计入预算（服务端错误、超时、降级），哪些不计（计划内维护、客户端参数错误），否则每个周期都会重新争吵一次。
落地要点
- 与发布节奏绑定：把剩余额度写进发布检查清单，超支即触发评审
- 定期对账：每个周期复盘预算的消耗构成，区分计划内风险与意外故障
- 分级设定：核心链路与内部工具的 SLO 不同，预算不可一概而论
- 与链路联动：预算异常消耗时用 trace_id 定位到具体故障批次
预算要能被看见才有效：把消耗进度做成看板并放在值班最常看的位置，比写在文档里更容易被执行。