错误预算的计算、消费与发布门禁
错误预算是 1 减去 SLO 后允许的失败量，单位可以是分钟、请求数或事件数。它的用途不是“把预算花完”，而是给发布和故障提供一个可量化的风险额度。预算耗尽时，先冻结功能发布，只做可靠性改进。
预算按 SLO 分别计算：可用性、延迟、数据新鲜度各有各的预算，不能合并成一个数字。
28 天窗口的预算换算：
# 99.9% SLO：允许失败比例 0.1%
awk 'BEGIN {printf "可用性预算: %.2f 分钟\n", 28*24*60*(1-0.999)}'
# 请求数预算：800 万请求
awk 'BEGIN {printf "允许失败请求: %.0f\n", 8000000*(1-0.999)}'
按剩余预算决定发布策略：
| 剩余预算 | 发布策略 | 审批 |
|---|---|---|
| > 50% | 正常发布 | 无需额外审批 |
| 25%–50% | 暂停高风险变更，缩小批次 | 团队负责人 |
| 1%–25% | 只允许小流量金丝雀 | SRE + 负责人 |
| 0 | 功能冻结，只修可靠性 | 事故复盘后解冻 |
计算剩余预算的 PromQL：
1 - (
sum(rate(http_requests_total{job="api",code=~"5.."}[28d]))
/
sum(rate(http_requests_total{job="api"}[28d]))
) / (1 - 0.999)
长期窗口查询代价高，用 recording rule 预聚合：
groups:
- name: error-budget
interval: 1m
rules:
- record: job:slo_error_ratio:rate5m
expr: |
sum by (job) (rate(http_requests_total{code=~"5.."}[5m]))
/ sum by (job) (rate(http_requests_total[5m]))
按燃烧率触发冻结，而不是等预算归零；job:error_budget_remaining:ratio 由 28 天预算公式预聚合：
groups:
- name: budget-freeze
rules:
- alert: ErrorBudgetExhausted
expr: job:error_budget_remaining:ratio < 0.05
for: 10m
labels:
severity: critical
annotations:
summary: "错误预算不足 5%，冻结功能发布"
- alert: ErrorBudgetBurnRateHigh
expr: job:slo_error_ratio:rate1h > 6 * 0.001
for: 5m
labels:
severity: page
合上页面，先回答，再展开对照。