SLO 与错误预算

「系统要可靠」需要 可量化目标。SLO（Service Level Objective） 定义「多可靠算够」；错误预算（Error Budget） 是允许失败的那部分配额——用完就应 停功能、修稳定性。

学习目标

• 区分 SLI、SLO、SLA
• 为 CodeRoadMap 定义 1～2 个 SLI
• 衔接 prom-promql 与 prom-alerts

术语

术语	含义	例子
SLI	可测量指标	成功请求比例、P99 延迟
SLO	对 SLI 的目标	99.9% 请求 < 500ms
SLA	对客户的合同承诺	违约赔偿（通常低于内部 SLO）

内部 SLO 应 严于 对外 SLA，留 buffer。

CodeRoadMap 示例 SLI

SLI-1 可用性 = 非 5xx 请求 / 总请求
SLI-2 延迟   = P99(latency) < 800ms（tracks 列表 API）

Prometheus 查询概念：

# 5xx 比例（5 分钟窗口）
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
/
sum(rate(http_server_requests_seconds_count[5m]))

指标采集见 prom-spring。

错误预算

SLO 99.9% 可用 → 每月约 43 分钟可「违约」
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
   预算充足                  预算耗尽
   可激进发版                冻结功能，修可靠性
   做实验                    加强 [rel-postmortem](/tracks/reliability-essentials/lessons/rel-postmortem)

宝塔单机 SLO 现实

• 无多 AZ 冗余时，宿主维护窗口 计入预算或单独公告
• 备份恢复 RTO/RPO 也是 可靠性目标，与可用性并列

监控栈：backend → Prometheus → Grafana → Alertmanager
                              │
                              └── SLO  burn rate 告警

与降级联动

错误预算快耗尽时，优先 降级非核心（rel-degrade），保住核心 SLI。

练习

• 为 tracks API 写一条 SLI + SLO（含数值）
• 计算 99.5% 月度错误预算分钟数
• 设计一条 burn rate 告警规则思路

小结

SLO 让可靠性可度量；错误预算平衡速度与稳定。 下一课：事后复盘。