4. SLI 指标类型与选择:延迟、吞吐量、错误率、饱和度、可用性
SLI(Service Level Indicator,服务等级指标)是 SLO 工程的量化基石。选择错误的 SLI 会导致 SLO 无法反映真实用户体验,甚至误导容量规划与故障定位。本章系统梳理五大经典 SLI 类型,并给出平台服务的选型决策框架。
4.1 五大 SLI 指标类型定义
Google SRE 经典著作将 SLI 归纳为以下五类,每一类对应不同的服务质量维度:
| 指标类型 | 核心含义 | 典型测量方式 | 平台服务示例 |
|---|---|---|---|
| 延迟 (Latency) | 请求从发出到收到完整响应的时间 | P50 / P95 / P99 分位延迟 | API 网关请求延迟 < 200ms (P99) |
| 吞吐量 (Throughput) | 单位时间内成功处理的请求数或数据量 | RPS (Requests Per Second) / TPS | CI/CD 流水线每分钟构建数 |
| 错误率 (Error Rate) | 失败请求占总请求的比例 | HTTP 5xx 占比 / 业务错误码占比 | 容器编排 API 错误率 < 0.1% |
| 饱和度 (Saturation) | 资源被使用的程度,接近瓶颈的程度 | CPU 使用率 / 内存使用率 / 连接池占用 | 集群节点 CPU 饱和度 < 80% |
| 可用性 (Availability) | 服务处于正常工作状态的时间比例 | Uptime / 成功请求占比 | 控制面 API 可用性 ≥ 99.99% |
关键认知: 可用性本质上是错误率在时间窗口上的聚合。实践中,平台团队通常将可用性 SLI 定义为“成功响应数 / 总请求数”,而非简单的机器存活检测。
4.2 指标选择决策树
为平台服务选择 SLI 时,应遵循“用户视角优先”原则。以下决策树帮助团队快速锁定核心指标:
4.3 平台服务 SLI 选型对照表
不同平台服务类型对 SLI 的敏感度差异显著。下表给出常见平台组件的推荐 SLI 组合:
| 平台服务类型 | 首选 SLI | 次选 SLI | 选型理由 |
|---|---|---|---|
| API 网关 / 控制面 | 延迟 (P99) | 错误率、可用性 | 网关是流量入口,延迟直接影响所有下游服务 |
| CI/CD 流水线 | 吞吐量 (构建数/小时) | 错误率、饱和度 | 开发效率取决于流水线吞吐,而非单次构建速度 |
| 容器编排集群 | 饱和度 (CPU/内存) | 延迟、吞吐量 | 集群过载是平台故障的首要原因,饱和度是早期预警 |
| 日志 / 监控管道 | 吞吐量 (事件数/秒) | 延迟、错误率 | 数据丢失比延迟更严重,吞吐量保障数据完整性 |
| 身份认证服务 | 延迟 (P50) | 可用性、错误率 | 认证是高频同步调用,低延迟是刚需 |
| 对象存储 / 持久化层 | 可用性 | 延迟、吞吐量 | 存储层故障会导致数据丢失,可用性优先级最高 |
4.4 指标组合与反模式
选择 SLI 时,平台团队常犯以下错误,需特别注意规避:
- 单一指标陷阱: 仅用可用性衡量服务质量。可用性 99.99% 的服务可能 P99 延迟高达 5 秒,用户感知极差。
- 平均延迟误区: 使用平均延迟而非分位延迟。平均延迟会掩盖长尾请求,P99 延迟才是真实体验的边界。
- 饱和度指标缺失: 只关注延迟和错误率,忽略饱和度。延迟升高往往是饱和度接近 100% 的结果,而非根因。
- 吞吐量定义模糊: 未区分“成功吞吐量”与“总吞吐量”。错误请求不应计入吞吐量 SLI。
平台工程实践提示: 在 CI/CD 流水线中集成 SLI 采集时,建议为每个微服务至少配置 2 个核心 SLI + 1 个饱和度 SLI。例如:P99 延迟 + 错误率 + CPU 饱和度。这组“黄金三角”能覆盖绝大多数故障场景。
4.5 从 SLI 到 SLO 的映射规则
选定 SLI 后,需要将其转化为可量化的 SLO 目标。以下映射规则帮助团队建立一致性:
4.6 平台服务 SLI 选型检查清单
在最终确定 SLI 之前,建议团队逐项核对以下清单:
- 用户视角验证: 所选 SLI 是否直接反映用户或下游服务的真实体验?
- 可测量性验证: 该指标是否能在生产环境中持续、低成本地采集?
- 可区分性验证: 指标是否能区分“正常”与“异常”状态?
- 正交性验证: 多个 SLI 之间是否存在强相关性?避免冗余指标。
- 可行动性验证: 当 SLI 恶化时,团队是否有明确的响应动作?
- 饱和度前置验证: 是否已包含至少一个饱和度指标作为早期预警?
平台工程最佳实践: 建议将 SLI 选型结果记录在平台服务目录中,并与 CI/CD 流水线的质量门禁绑定。例如:当 P99 延迟超过 SLO 阈值时,自动阻止该服务的生产发布。这种“代码即 SLO”的实践能有效防止服务质量退化。