SLI 与 SLO 怎么定义：从性能指标到可承诺的目标

更新时间：2026-09-19。前置阅读：黄金信号/RED/USE 怎么选、分位数为什么用直方图算。本篇解决一个最常见的误区：把「CPU 使用率」「QPS」这类资源/流量指标误当成对用户的承诺。SRE 度量的起点是先定义「用户在意什么」，再倒推该测哪些指标。

一、SLI / SLO / SLA 是三层，别混

概念	是什么	谁来定	例子
SLI	实际测量的指标，最好是 0~1 的比例	工程	成功请求数 / 总请求数 = 99.95%
SLO	团队内部承诺的目标值	工程+产品	30 天内成功率 ≥ 99.9%
SLA	对客户的合同，违约要赔	商务/法务	月可用性 < 99.5% 赔 10% 费用

关键关系：SLA 是 SLO 兜不住之后的赔付底线，所以 SLO 必须比 SLA 更严。SLA 写 99.5%，内部 SLO 就定 99.9%，中间留 0.4 个百分点缓冲，否则每次贴着合同线跑迟早赔钱。

二、好 SLI 是「比例」，对应用户能感知的结果

SLI 最推荐写成「好事件 / 总事件」的比例，因为它直接对应用户有多大概率得到好体验：

• 可用性 SLI：成功请求数 / 有效请求总数（HTTP 5xx、超时、连接拒绝算坏；4xx 客户端错误通常不算可用性事故，但要单独看）。
• 延迟 SLI：延迟 ≤ 阈值的请求数 / 总请求数，例如「P99 ≤ 300ms」等价于「至少 99% 的请求在 300ms 内返回」。
• 质量 SLI：完整返回/正确结果的请求比例（用空结果率、错误码细化，适合搜索、推荐类）。

不要把 CPU 使用率 80%、内存 12GB、QPS 5000 直接当 SLI——它们是原因/资源指标，用户不感知；它们用来解释「为什么 SLO 破了」，而不是承诺本身。这与 USE 在资源维度查瓶颈、RED 在请求维度看服务的分工一致，见三类指标体系。

三、两类 SLO 的落地写法

1）可用性 SLO（滚动 30 天）

过去 30 天，所有 /api/order 请求中 HTTP 状态码 < 500 且未超时(<2s) 的比例 ≥ 99.9%
数据源：网关访问日志 / Prometheus http_requests_total（按 code、route 标签）

2）延迟 SLO（分档，别只写均值）

过去 30 天：
  P50 ≤ 80ms   （多数用户的典型体验）
  P95 ≤ 200ms  （长尾开始有感）
  P99 ≤ 500ms  （最差的 1%，对应移动端弱网）

为什么用 P99 而非平均值见分位数直方图；直方图在 Prometheus 怎么落地见 SLO recording rules。

四、窗口、聚合粒度与「哪些请求算数」

1. 窗口：常用滚动 28/30 天，比自然月平滑；不要用 5 分钟窗口定 SLO（抖动会让目标忽好忽坏），短窗口只用于告警。
2. 聚合：SLO 必须先汇总原始事件再算比例，不能把各实例成功率平均——10 个实例里 1 个全挂，平均成功率会被稀释成 90%，掩盖单点故障。
3. 排除项要写明：计划内发布窗口、客户自身故障、灰度 1% 流量是否计入，定义里说清，否则复盘各执一词。
4. 数据来源要可信：优先用边缘/网关侧（最接近用户），服务端埋点会漏掉「请求根本没到」的故障。

五、好 SLO vs 坏 SLO

维度	坏的写法	好的写法
指标	「系统稳定」「CPU 不高」	成功率、达标延迟比例（可测）
阈值	「尽量快」	P99 ≤ 500ms（明确数值）
窗口	「平时」	滚动 30 天
松紧	100%（做不到，反而失信）	99.9%（留错误预算）

不要追求 100%：用户感知不到 99.9% 与 100% 的差别，但为那 0.1% 付出的冗余成本极高。SLO 的价值恰恰是承认允许少量失败，把省下的预算用于迭代，见错误预算。

坑

• 拿资源指标当 SLO：CPU 正常不代表用户能下单，承诺必须落在请求结果上。
• 平均各实例成功率：会掩盖单实例/单可用区故障，必须用事件总和计算。
• 阈值定 100%：没有错误预算，团队被零失败目标绑架、不敢发布。
• 窗口太短：用 5 分钟粒度定月度目标，抖动期被误判成 SLO 已破。
• 只写均值延迟：平均 50ms 可能是一半 5ms、一半 95ms，长尾用户全在受苦。

总结

SLI 是实测的「好事件/总事件」比例、SLO 是团队内部承诺且必须严于对外 SLA，好的 SLO 只用用户可感知的成功率与分档延迟（P50/P95/P99），写清阈值、滚动窗口、数据源与排除项，并坚持先汇总原始事件再算比例、目标留余量（99.9% 而非 100%），从而把可观测三支柱里的性能指标真正变成可承诺、可告警、可复盘的服务质量目标。