三个概念的分工
SLI 是可观测、可计算的指标，例如过去五分钟的请求成功率；SLO 是团队为这个指标设定的内部目标与统计窗口，例如滚动 28 天可用性不低于 99.9%；SLA 是对外合同里的承诺，通常附带赔付或折扣条款。三者的关系是自上而下收紧：SLA 必须宽于 SLO，SLO 又必须建立在真实可测的 SLI 之上。
基本信息
| SLI | Service Level Indicator：可测量、可复现的服务质量指标 |
|---|---|
| SLO | Service Level Objective：内部目标值与统计窗口 |
| SLA | Service Level Agreement：对外承诺，含赔付或罚则 |
| 常见 SLI | 可用性、延迟、吞吐、正确性、数据新鲜度 |
| 统计窗口 | 滚动 28 天或自然月，按结算与复盘节奏选择 |
典型使用场景
- 定目标：把模糊的稳定性要求转成可度量、可结算的具体数值
- 发布决策：以错误预算的消耗速率决定能否继续放量
- 外包与采购：用 SLA 条款约束第三方依赖的可用性
- 架构论证：不同冗余方案能支撑的 SLO 不同，用于评估投入成本
- 故障复盘：用 SLI 还原故障期的真实影响范围与时长
- 跨团队对齐：统一 SLI 定义后，上下游对可用的判断不再各执一词
三者对照
| 概念 | 是什么 | 举例 | 违约后果 |
|---|---|---|---|
| SLI | 可观测可计算的指标 | 过去 5 分钟的请求成功率 | 无，只作为度量 |
| SLO | 内部目标与统计窗口 | 滚动 28 天可用性不低于 99.9% | 触发错误预算策略 |
| SLA | 对外承诺，常含赔付条款 | 可用性不低于 99.5%，未达按比例赔付 | 赔付、折扣或解约 |
常见 SLI 与取值方式
| SLI 类型 | 典型定义 | 数据来源 |
|---|---|---|
| 可用性 | 成功请求数除以总请求数 | 服务端埋点或网关访问日志 |
| 延迟 | 耗时落在阈值内的请求比例，如 300ms 内 | 直方图指标或链路数据 |
| 吞吐 | 单位时间成功处理的请求或数据量 | 服务端计数指标 |
| 正确性 | 业务语义成功的比例 | 业务埋点，需与接口契约一致 |
| 数据新鲜度 | 数据产出的延迟时间 | 离线任务调度与数据平台 |
可用性 SLI 的 PromQL 写法
可用性 SLI 的 PromQL 写法
# 成功率：非 5xx 占比
sum(rate(http_requests_total{code!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# 延迟 SLI：300ms 内完成的请求比例
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
/ sum(rate(http_request_duration_seconds_count[5m]))
# 任务型服务：成功完成任务数 / 应完成任务数
sum(rate(jobs_completed_total{result="success"}[1h]))
/ sum(rate(jobs_completed_total[1h]))SLI 要贴近用户视角：用户在意请求是否成功、耗时是否可接受，而不是内部线程池大小或垃圾回收次数。
目标值必须和统计窗口一起定义：同样写 99.9%，按自然月还是滚动 28 天结算，结果可能相差数倍，写进文档才能避免月底扯皮。
不要用单一内部指标冒充可用性：只统计网关状态码会漏掉后端静默失败与依赖超时，建议同时补充端到端拨测或业务成功率。
SLO 数量要克制
一个服务建议只保留两三条 SLO：通常是可用性加一条延迟，必要时再补数据新鲜度或正确性。SLO 越多，指标维护与预算统计的成本越高，复盘时也越容易陷入口径争论。先把真正会被用于发布决策的那一两条定下来，比一次铺开十几条更容易落地。
SLO 可以随业务阶段调整：新服务初期允许宽松并留出学习期，运行稳定后再逐步收紧，不要把一次性拍出的目标当成永久约束。
定目标时的三个提醒
- 目标越高边际成本越陡：从三个 9 提升到四个 9，往往需要成倍的冗余与自动化投入
- SLI 要能稳定测量：采集不稳定的指标不适合做 SLI，先把埋点补齐再定目标
- 目标要落到人：每条 SLO 指定负责人，否则预算耗尽时无人推动修复