SLO（Service Level Objective）

解决什么问题：让"系统有多好"从模糊感觉变成可量化的承诺—— 没有 SLO = "系统还行" / "系统有点慢" 永远扯不清；有了 SLO = "可用率 99.95%"是可验证、可问责的。

它是什么

SLO（Service Level Objective，服务等级目标） 是对服务 可靠性 / 性能 / 质量的具体可量化目标—— 通常以"在 XX 时间窗口内，XX 比例的请求满足 XX 标准"的形式表达。

SLO = 目标值（如"可用率 99.95%"）
  │
  ├─ SLI（Service Level Indicator，指标）：
  │   可量化的实际值（如"实际可用率 = 99.92%"）
  │
  ├─ SLA（Service Level Agreement，协议）：
  │   商业承诺（未达标赔钱）
  │
  └─ Error Budget（错误预算）：
      1 - SLO = 允许的"失败额度"

SE@G Ch 23： "An SLO is a target for the reliability of your service. If your service meets its SLO, it is considered reliable enough. If it misses its SLO consistently, you have a problem worth fixing."

V2 视角（V2 B5 + B6）：SLO = 反馈环的"目标值 ref"—— 没有 SLO 的反馈环 = 不知道往哪儿调；有了 SLO = 控制律有了明确的 reference，控制论闭环才能工作。

关键属性

属性	值/含义
可量化	必须能用数字衡量（99.9% / 200ms / 5xx < 0.1%）
有时窗	必须明确时间窗口（30 天 / 1 季度 / 1 年）
有主体	明确是哪个服务 / BC / 系统的 SLO
有用户视角	站在用户角度，不是纯技术指标
可达成	太严 = 永远崩；太宽 = 没意义
有预算	错误预算 = 1 - SLO，可消费
可调整	SLO 不是永久的，随业务演化调整
可问责	责任人 / 团队 / 流程都明确

怎么用

场景 1：定义 SLO（4 步法）

1. 选用户感知最强的指标：
   - 可用率（请求成功率）
   - 延迟（响应时间）
   - 吞吐（QPS / TPS）
   - 正确性（数据准确率）

2. 给数字：
   - 可用率 99.95%（约每月允许 ~22 分钟停机）
   - P99 延迟 < 200ms
   - 错误率 < 0.1%

3. 给时间窗口：
   - 30 天滚动窗口
   - 季度评估是否调整

4. 给责任人：
   - 谁负责这个 SLO？
   - 谁有权调整？
   - 未达标的处理流程？

场景 2：SLO 与 Error Budget

SLO = 99.95% 可用率
Error Budget = 0.05% = 每月 22 分钟

月度预算使用：
  - 周一：故障 -5 分钟（剩余 17 分钟）
  - 周三：常规维护 -10 分钟（剩余 7 分钟）
  - 周四：又故障 -8 分钟（剩余 -1 分钟，超支！）

超支后果：
  - 冻结所有非紧急变更
  - 集中精力做可靠性改进
  - 直到预算回到正

关键：Error Budget 让"可靠性 vs 新功能"的权衡有数据可依—— 不是工程师说了算，也不是产品说了算，是预算说了算。

场景 3：SLO 在闭环中的角色

测量 y(t) ──→ SLI（实际可用率 99.92%）
              │
              ↓
       比较 vs SLO（99.95%）
              │
              ↓
       误差 e = -0.03%（未达标）
              │
              ↓
       调节 u（自动：扩容 / 限流；人工：Postmortem + 改进）
              │
              ↓
       y(t+1) 重新测量

控制论 Ch 4：SLO 就是 reference r(t)—— 没有 SLO，控制律无的放矢；有了 SLO，控制论闭环才完整。

场景 4：多级 SLO（系统级 + BC 级）

系统级 SLO：99.95%
  │
  ├─ 订单 BC SLO：99.99%（核心链路）
  ├─ 推荐 BC SLO：99.9%（允许稍低）
  ├─ 报表 BC SLO：99.5%（离线可降级）
  └─ 营销 BC SLO：99.0%（活动期可放宽）

IDDD Ch 12：每个 BC 有自己的 SLO = 自治边界—— 一个 BC 的故障不应当拖垮系统级 SLO，这要求 BC 间有故障隔离。

常见误区

"SLO 越高越好"——错。SLO = 99.999% 听起来好，成本是指数级上升，且用户感知不到
"SLO = SLA"——错。SLO 是内部目标，SLA 是对外承诺——SLO 要比 SLA 严
"SLO = 永不故障"——错。SLO 必然有错，错才有改进空间
"SLO 没达成 = 失败"——错。短期内不达成 = 正常的——长期不达成才是问题
"SLO 只看技术指标"——错。SLO 必须从用户视角出发——内部技术指标 OK 但用户体验差 = SLO 失效

关键洞察

SLO 是反馈环的"目标值"——没有 SLO，控制律无的放矢。
SLO 不只是技术指标，是业务承诺： 99.95% = 我们承诺用户"一年最多 4 小时不可用"。这是工程和业务的契约——说出口的话必须算话。

SLO（Service Level Objective） ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：定义 SLO（4 步法） ​

场景 2：SLO 与 Error Budget ​

场景 3：SLO 在闭环中的角色 ​

场景 4：多级 SLO（系统级 + BC 级） ​

常见误区 ​

关键洞察 ​

相关链接 ​