错误预算为何是SRE稳定性的核心度量体系
SRE稳定性工程体系的核心不是消除所有故障——这不现实也不经济——而是用错误预算（Error Budget）量化系统可接受的故障空间，在可靠性和迭代速度之间找到工程最优解。错误预算的本质是把可用性目标从模糊的“尽量稳定”转化为精确的数字：99.9%的SLO意味着每月43.8分钟的不可用预算，超过这个阈值新功能发布冻结，全部精力投入可靠性改善。
SLO/SLI/SLA三层指标体系设计
SRE实践中，三个概念必须严格区分：SLI（Service Level Indicator）是可度量的指标，如请求延迟P99、错误率、可用性；SLO（Service Level Objective）是SLI的目标值，如P99延迟小于500ms、错误率小于0.1%；SLA（Service Level Agreement）是面向客户的合同承诺，违约有经济赔偿。
SLI的选择遵循三个原则：直接反映用户体验、可精确度量、团队可控。常见SLI设计：
# Prometheus中定义SLI指标查询
# 请求可用性SLI
sum(rate(http_requests_total{code!~'5..'}[5m]))
/
sum(rate(http_requests_total[5m]))
# 延迟SLI - P99
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket[5m]))
by (le)
)
# 错误预算消耗速率SLI
(1 - (
sum(rate(http_requests_total{code!~'5..'}[5m]))
/ sum(rate(http_requests_total[5m]))
)) / (1 - 0.999) # 0.999是SLO目标
一个常见的设计错误是把过多SLI塞进一个SLO。经验法则是每个服务不超过3个SLI：可用性、延迟、吞吐量。多了度量成本飙升且告警疲劳。
错误预算计算与燃烧率模型
错误预算的核心公式：Error Budget = 1 - SLO。99.9%月度SLO的错误预算为0.1%，即43.8分钟/月。但关键不是静态计算，而是动态跟踪燃烧率（Burn Rate）——当前错误消耗速度是预算分配速度的几倍。
# 错误预算燃烧率计算
# burn_rate = 当前错误率 / SLO允许的错误率
# 例：SLO=99.9%，当前窗口(1h)错误率=1%
# burn_rate = 0.01 / 0.001 = 10x
# 意味着按当前速率，1个月的预算在3天(30/10)内耗尽
# Prometheus燃烧率查询
(
1 - sum(rate(http_requests_total{code!~'5..'}[1h]))
/ sum(rate(http_requests_total[1h]))
)
/
(1 - 0.999)
Google SRE推荐的燃烧率告警窗口组合：用1小时窗口检测快速恶化（6x燃烧率），用6小时窗口检测缓慢泄漏（3x燃烧率），用3天窗口检测长期趋势（1x燃烧率）。多窗口组合可兼顾灵敏度和噪声控制。
Prometheus + Sloth自动化SLO管理
Sloth是开源的SLO管理工具，基于Prometheus规则生成SLO告警和仪表盘，把SLO定义从手写PromQL变成声明式YAML配置：
# Sloth SLO定义文件 - sloth-slo.yaml
version: 'prometheus/v1'
service: 'api-gateway'
slos:
- id: 'availability'
name: 'API Gateway Availability'
sli:
events:
error_query: sum(rate(http_requests_total{code=~'5..'}[{{.window}}]))
total_query: sum(rate(http_requests_total[{{.window}}]))
alerting:
name: ApiGatewayAvailabilityBudgetBurn
labels:
team: sre
annotations:
summary: 'High error budget burn rate'
page_alert:
labels:
severity: critical
ticket_alert:
labels:
severity: warning
spec:
objective: 0.999
# 生成Prometheus规则
sloth generate -i sloth-slo.yaml -o prometheus_rules.yaml
# 生成的规则包含多窗口燃烧率告警
# 1h/5m窗口 - 6x燃烧率 - Page告警
# 6h/30m窗口 - 3x燃烧率 - Ticket告警
# 3d/6h窗口 - 1x燃烧率 - Ticket告警
这种声明式定义消除了手写多窗口告警规则的繁琐，也避免了低级错误。团队只需关注SLO目标值和SLI查询逻辑。
错误预算耗尽后的工程决策机制
错误预算耗尽不是单纯的告警事件，而是触发工程流程切换的信号。Google的实践经验是建立“错误预算策略”文档，明确预算耗尽后的行动规则：
1. 冻结发布：剩余预算低于10%时，非紧急变更冻结，所有Code Review重点转向可靠性评估。
2. 优先级重排：剩余预算低于0时，SRE团队的可靠性改进项（如增加限流、改进重试逻辑、补充混沌工程测试）优先级高于一切功能开发。
3. 事后复盘：预算耗尽事件必须在3个工作日内完成复盘，输出SLO是否合理、SLI是否准确、告警是否及时的结论。
# Grafana仪表盘错误预算可视化查询
# 剩余错误预算百分比
100 * (1 - (
sum(increase(http_requests_total{code=~'5..'}[30d]))
/ sum(increase(http_requests_total[30d]))
) / (1 - 0.999))
# 预算耗尽预计时间
# 如果当前燃烧率为B，月度预算为E分钟
# 预计耗尽时间 = 剩余预算(%) * 43200(月分钟数) / (B * 100)
错误预算机制的真正价值不在于告警本身，而在于用数据驱动可靠性投入的优先级决策。当“99.9%”不再是一句口号而是精确的数字仪表盘时，技术债和功能需求的博弈才有了客观的衡量标尺。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/sre-cuo-wu-yu-suan-ji-zhi-shi-zhan-slo-ding-yi-yu-cuo-wu-yu/
