质量 SLO 是什么
把质量目标写成服务级目标：先定义可测量的指标（SLI），再给出目标值（SLO），然后由目标反推出允许的失败额度，也就是错误预算。有了这三层，质量就进入可度量、可协商的工程语言——不是「要更稳」，而是「28 天窗口内成功率 99.9%，允许约 40 分钟不可用」。
基本信息
| 组成 | SLI（指标）→ SLO（目标）→ 错误预算 |
|---|---|
| 示例 | 月可用性 99.9%；P99 延迟 < 300ms |
| 联动 | 预算耗尽 → 冻结非紧急发布，优先修复 |
| 来源 | Google SRE 的 SLO 与错误预算实践、OpenSLO 规范 |
落地要点
- SLI 从用户视角选：成功率、延迟、关键流程完成率，而不是 CPU 使用率
- 窗口明确：28 天滑动窗口比自然月更稳定，不会被月末重置掩盖问题
- 目标值从现状出发：先统计当前实际水平，再选择略高的目标
- 预算与发布策略绑定：预算充足时鼓励发布，耗尽时先修稳定性
- 多分量服务按用户体验加权，避免个别慢接口被平均值掩盖
- 定期复核：目标过松则失去意义，过紧则频繁打断交付
SLO 声明示例
SLO 声明示例
service: checkout
sli: 成功率 = (2xx + 3xx) / 总请求
slo: 99.9% / 28 天滑动窗口
error_budget: 0.1% ≈ 约 40 分钟/28 天
policy: 预算耗尽 → 暂停非紧急发布，优先修复
# 另加一条延迟目标
sli: P99 延迟
slo: < 300ms / 28 天窗口三层关系
| 层 | 回答的问题 | 常见错误 |
|---|---|---|
| SLI | 量什么？ | 选了运维指标而非用户体验指标 |
| SLO | 要多好？ | 拍脑袋定成 99.99%，成本无人核算 |
| 错误预算 | 允许失败多少？ | 算出来却不与发布流程联动 |
| 策略 | 预算用完怎么办？ | 写进文档但没人执行 |
SLO 定得过高等于没有目标：99.99% 表示一年只有几十分钟不可用，任何一次抖动都会触发警报，团队会对告警脱敏，真实故障反而被忽略。
SLO 无人消费就是装饰：不接告警、不接发布流程、决策时没人引用，它很快会变成一份过期的文档。落地的标志是——发布评审里真的会问「预算还剩多少」。