3. SLI 定义与选择：如何定义好的 SLI
SLI（Service Level Indicator，服务等级指标）是 SLO 落地的基石。一个错误的 SLI 会导致 SLO 失去衡量意义，甚至引导团队优化错误的方向。本章将系统讲解如何定义高质量的 SLI、常见的 SLI 类型以及选择原则。
3.1 什么是好的 SLI
好的 SLI 必须同时满足以下四个特征：
| 特征 | 说明 | 反例 |
|---|---|---|
| 可测量 | 能从监控系统或日志中直接获取数值 | "用户体验良好"（无法量化） |
| 可对比 | 不同时间窗口、不同版本之间能公平比较 | 采样率不固定的请求延迟 |
| 面向用户 | 反映用户真实感知的服务质量 | CPU 使用率（用户不关心） |
| 可行动 | SLI 恶化时团队能明确知道如何改进 | "网络抖动次数"（无法直接定位根因） |
实战建议： 在定义 SLI 时，先问自己三个问题：这个指标用户能感受到吗？我们能持续采集吗？指标变差时团队知道该修什么吗？如果任一答案为"否"，则需要重新设计 SLI。
3.2 四大核心 SLI 类型
业界公认的四大黄金信号（Google SRE 经典理论）构成了 SLI 的核心分类体系。以下逐一说明每种类型的定义、典型指标和适用场景。
3.2.1 延迟（Latency）
衡量服务响应请求所花费的时间。延迟 SLI 通常关注特定百分位（如 p50、p95、p99）的响应时间，而非平均值。
- 典型指标： p99 延迟 ≤ 200ms、p95 延迟 ≤ 100ms
- 适用场景： API 服务、数据库查询、页面加载
- 常见陷阱： 只关注平均延迟，忽略长尾请求
3.2.2 错误率（Error Rate）
衡量请求失败的比率。错误不仅包括 HTTP 5xx，还应涵盖业务逻辑错误（如"购物车结算失败"返回 200 但实际失败）。
- 典型指标： HTTP 5xx 占比 ≤ 0.1%、业务错误率 ≤ 0.5%
- 适用场景： 所有在线服务、支付、订单系统
- 常见陷阱： 只统计显式错误，忽略隐式错误（如返回空数据）
3.2.3 吞吐量（Throughput）
衡量系统在单位时间内处理的请求量或数据量。吞吐量下降往往预示着系统容量瓶颈或部分功能降级。
- 典型指标： QPS（每秒查询数）、RPS（每秒请求数）、TPS（每秒事务数）
- 适用场景： 高并发系统、流处理管道、CDN 带宽
- 常见陷阱： 将吞吐量与并发数混淆
3.2.4 饱和度（Saturation）
衡量系统资源被消耗的程度。饱和度接近 100% 通常意味着即将发生性能退化或错误率飙升。
- 典型指标： CPU 使用率、内存使用率、连接池占用率、磁盘 IO 等待时间
- 适用场景： 基础设施层、中间件、数据库
- 常见陷阱： 只关注资源使用率，忽略排队深度
关键认知： 饱和度 SLI 通常不作为用户可见的 SLO 目标，而是作为预警指标（Burn Rate 告警的早期信号）。在定义 SLO 时，优先选择延迟和错误率作为核心 SLI。
3.3 选择 SLI 的五大原则
在实际项目中，面对海量可观测指标，如何筛选出真正有效的 SLI？以下五大原则来自 Google SRE 及多家头部互联网公司的实战经验。
- 原则一：用户视角优先
- 选择用户直接感知的指标，而非内部组件指标
- 示例：选择"首页加载时间"而非"CDN 回源率"
- 原则二：简单可理解
- SLI 定义应让非技术同事（产品、运营）也能理解
- 避免复合指标或需要多步计算的衍生指标
- 原则三：覆盖关键路径
- 优先覆盖用户请求的主链路，而非边缘功能
- 示例：支付成功率比"用户头像上传成功率"更重要
- 原则四：可采集且稳定
- 确保指标能被持续、稳定地采集，不存在采样盲区
- 避免依赖第三方不稳定数据源
- 原则五：与业务目标对齐
- SLI 应直接关联业务 KPI（如转化率、留存率）
- 示例：电商系统的"结算成功率"直接决定 GMV
常见误区： 不要试图为每个组件都定义 SLI。一个微服务系统可能有上百个指标，但真正需要纳入 SLO 管理的 SLI 通常不超过 5 个。过多的 SLI 会导致监控疲劳和告警风暴。
3.4 SLI 定义实战模板
以下是一个标准化的 SLI 定义模板，可直接用于团队内部评审：
| 字段 | 示例值 |
|---|---|
| SLI 名称 | API 响应延迟（p99） |
| SLI 类型 | 延迟 |
| 数据来源 | API 网关访问日志 → Prometheus Histogram |
| 计算方式 | 过去 5 分钟内，所有请求的 p99 响应时间 |
| 排除条件 | 排除健康检查请求、排除压测流量 |
| 用户影响 | 高延迟导致页面加载超时，用户流失 |
| 关联 SLO | 99.9% 的请求 p99 延迟 ≤ 200ms |
3.5 不同服务类型的 SLI 推荐
根据服务类型的不同，SLI 的侧重点也有所差异。以下表格可作为快速参考：
| 服务类型 | 首选 SLI | 辅助 SLI | 典型 SLO 目标 |
|---|---|---|---|
| Web API | p99 延迟、错误率 | QPS、CPU 饱和度 | p99 ≤ 200ms，错误率 ≤ 0.1% |
| 数据库 | 查询延迟、慢查询占比 | 连接池饱和度、磁盘 IO | p95 查询延迟 ≤ 50ms |
| 消息队列 | 消息投递延迟、消费延迟 | 队列深度、吞吐量 | 投递延迟 ≤ 1s，消费延迟 ≤ 5s |
| CDN / 静态资源 | 首字节时间、缓存命中率 | 带宽使用率、错误率 | 首字节时间 ≤ 100ms，命中率 ≥ 95% |
| 批处理 / 离线任务 | 任务完成率、处理延迟 | 资源饱和度、数据新鲜度 | 任务成功率 ≥ 99.9%，延迟 ≤ 4h |
落地检查清单： 每次定义完 SLI 后，对照以下问题做最终确认：
✅ 这个 SLI 是否来自用户请求的端到端数据？
✅ 是否排除了内部重试、健康检查等非用户流量？
✅ 团队是否能在 5 分钟内解释清楚这个 SLI 的含义？
✅ 如果这个 SLI 变差，是否知道该优化哪个组件？
✅ 这个 SLI 是否来自用户请求的端到端数据？
✅ 是否排除了内部重试、健康检查等非用户流量？
✅ 团队是否能在 5 分钟内解释清楚这个 SLI 的含义？
✅ 如果这个 SLI 变差，是否知道该优化哪个组件？
3.6 本章小结
- 好的 SLI 必须满足：可测量、可对比、面向用户、可行动
- 四大黄金信号：延迟、错误率、吞吐量、饱和度，其中延迟和错误率是 SLO 首选
- 选择 SLI 的五大原则：用户视角、简单可理解、覆盖关键路径、可采集稳定、与业务对齐
- 不同服务类型有差异化的 SLI 推荐组合，避免一刀切
- 使用标准化模板定义 SLI，确保团队理解一致