SLO 定义

定义把技术可靠性与用户幸福绑定的可测服务等级目标。

为什么

SLO 是使可靠性与速度权衡显式的数字。没有它，每队优化 100% 可用性，意味着无风险部署、无新功能、产品慢 — 或鲁莽部署而可靠性是感觉。有 99.9% over 28 天 SLO，团队得每月 43 分钟宕机错误预算：可花在部署、功能开关或实验上，只要未超预算产品速度不受限。预算烧完则部署冻结直到可靠性恢复。这把"该发布吗？"从政治争论变算术检查，这是 SRE 对组织最大贡献。

何时使用

当服务到生产且有用户时。每个面向用户服务从一个 SLO 开始；成熟后加更多。

如何做

1. 识别用户旅程及其 SLI
   - SLI = "好事件 / 总事件"（如成功结账 / 尝试结账）
   - 选失败 = "服务挂了"对用户而言的旅程

2. 设 SLO 目标和窗口
   - 目标：99.9%（从这里开始；99.99% 花约 10 倍更多）
   - 窗口：28 天（长到平滑噪声，短到可行动）
   - 错误预算 = (1 - 0.999) × 28 天 = 43.2 分钟允许宕机

3. 定义 SLI 测量
   - "成功" = HTTP 200 + 业务成功（订单真创建，非仅 200）
   - 从用户边缘测（RUM/合成），非服务器内部视图

4. 使预算可行动
   - 燃烧率 >2x → 冻结风险部署，专注可靠性
   - 燃烧率 <0.5x → 自由部署，有余量
   - 向全队发布预算使非秘密

5. 季度审查调整
   - 从不烧预算 → SLO 太松，收紧（或发布更多）
   - 总烧预算 → SLO 太紧，放松（或投资可靠性）

示例

# SLO：28 天 99.9% 结账尝试成功
slo:
  service: checkout
  sli: "successful_checkouts / attempted_checkouts"
  target: 0.999
  window: 28d
  error_budget: 43.2m  # (1 - 0.999) * 28d

# SLI 测量（Prometheus）：
#   successful = rate(http_requests_total{service="checkout",status="200",order_created="true"}[5m])
#   total      = rate(http_requests_total{service="checkout"}[5m])
#   sli        = successful / total

# 燃烧率告警：
#   burn = (1 - sli) / (1 - 0.999)
#   burn > 2 持续 1h → page（2x 快烧预算）
#   burn > 1 持续 6h → 工单（1x 烧，慢性）

# 策略：
#   若 burn > 2 → 部署冻结（仅修复，无功能）直到 burn < 1
#   若 burn < 0.5 → 自由部署（风险变更有余量）

常见问题

⚠SLO 设 100% — 零错误预算，每次部署是可靠性风险且速度归零；99.9% 是理智起点。
⚠从服务器内部视图（HTTP 200）测 SLI 而非用户边缘 — 200 但业务结果坏（订单未创建）算成功。
⚠SLO 无预算策略 — 数字存在但烧完无变化；价值在部署冻结策略非目标。
⚠每服务太多 SLO — 5 个 SLO 意味 5 个预算跟踪且无清晰信号；从一个开始，仅当第二旅程独立重要时加。

最佳实践

✓从 99.9% over 28 天开始 — 这给 43 分钟月错误预算平衡可靠性和速度；仅当用户要求时收紧。
✓从用户边缘（RUM 或合成）测 SLI，计业务成功非仅 HTTP 200 — 服务器视图藏用户可见失败。
✓使错误预算可行动：燃烧 >2x 冻结部署，<0.5x 允许风险变更 — 策略是价值非数字。
✓季度审查 SLO：从不烧预算则太松，总烧则太紧 — 从真实用户行为校准。