三个词的精确含义

概念 全称 含义
SLI Service Level Indicator 一个可测量的服务质量数字（"过去 5 分钟成功请求占比"）
SLO Service Level Objective 你对内承诺的 SLI 目标（"成功率 ≥ 99.9% 滚动 30 天"）
SLA Service Level Agreement 你对客户的合同承诺，达不到通常有罚金

SLA ⊃ SLO ⊃ SLI 的常见说法：内部 SLO 通常严于 SLA（提前预警），SLI 是组成它们的原始数据。

不要照抄"99.9%"

互联网上充满了"99.9%/99.99% 是行业标准"的说法。别信——SLO 该多严只能由你的业务 + 用户期望 + 成本约束决定。

举例：

  • 个人博客 → 99% 都未必需要；停 1 天没人在意
  • 公司内部工具 → 99% 可能够；员工等几分钟能接受
  • B2B SaaS API → 99.9%–99.99%；客户合同里写了
  • 支付通道 → 99.99%+；每分钟 down 都是钱

多一个 9 的成本通常是上一个量级的几倍——要权衡，不要追求"看起来漂亮"。

怎么定义一个好的 SLI

经验法则（来自 Google SRE Workbook）：

  1. 从用户角度看——不是"CPU 是否健康"，是"用户请求是否成功"
  2. 比例形式而不是绝对数——"成功率"比"成功数"好（不受流量波动影响）
  3. 数据可获得——能从已有 metrics 算出来

常见 SLI 模板：

可用性 = 成功请求数 / 总请求数
延迟    = p95 / p99 请求耗时 < X ms 的比例
质量    = 返回正确结果的请求比例（业务定义）
新鲜度  = 数据延迟 < X 秒的时间比例

一个具体 SLO 的写法

服务：付款 API
SLI：HTTP 请求里 status < 500 的比例
SLO：滚动 30 天窗口内 ≥ 99.9%
窗口：30 天滚动

滚动窗口比"按月"清晰——任意 30 天都得满足，不会被月底刷分。

100% 是错误的目标

"为什么不追求 100%？"

  • 100% 意味着任何变更都不能上——你需要风险预算来发布、实验、改进
  • 用户的依赖链上有比你 SLO 低的环节（运营商网络、用户设备）——你做到 100% 用户也感知不到
  • 越接近 100%，边际成本指数级上升

承认这点就有了下一篇要讲的 Error Budget。

多窗口多燃烧率告警（进阶）

简单做法："SLO 燃烧 → 告警"——但 30 天窗口很慢才反应。

SRE Workbook 推荐多窗口多燃烧率（Multi-Window Multi-Burn-Rate）：

快窗口（如 1h）燃烧率 > 14.4 倍 → page（影响快）
中窗口（如 6h）燃烧率 > 6 倍   → page（影响中）
慢窗口（如 3d）燃烧率 > 1 倍   → ticket（缓慢恶化）

计算公式细节查 SRE Workbook 第 5 章——直接抄是最稳的。

SLO 的反模式

  • SLO 制定后不维护：业务变了 SLO 没改 → 数字没意义
  • SLO 成员一拍脑袋决定：要和 PM / 业务方对齐——他们对"什么算用户感知到的故障"有发言权
  • SLI 来自非用户视角："数据库 CPU 告警" 不是 SLI
  • 写了 SLO 但没人为它负责：SLO 必须有 owner（通常是 SRE / 服务团队 lead）

推荐阅读

下一篇：用 Error Budget 决定什么时候停发布。