3. 常见SLI类型
在可靠性评审中，SLI（Service Level Indicator）是衡量服务质量的量化指标。不同的 SLI 类型对应不同的服务特征和故障模式。校准阈值前，必须准确理解每种 SLI 的定义及其适用场景。本节将逐一解析五种核心 SLI 类型。
3.1 延迟 SLI（Latency SLI）
定义：延迟 SLI 衡量服务响应请求所花费的时间，通常以毫秒（ms）或秒（s）为单位。常见的统计口径包括平均延迟、P50（中位数）、P95、P99 延迟。
适用场景：
- 用户交互型服务：如 Web 页面加载、API 接口调用、数据库查询。用户对响应时间敏感，高延迟直接影响用户体验。
- 实时系统：如在线游戏、视频直播、金融交易系统，要求毫秒级响应。
- 微服务调用链：用于识别上游服务或下游依赖的瓶颈。
校准要点：延迟 SLI 的阈值通常按百分位设定。例如，P99 延迟 < 200ms 表示 99% 的请求在 200ms 内完成。校准时应关注长尾延迟，而非平均值。
常见误区：仅使用平均延迟作为 SLI，会掩盖高百分位的性能劣化。建议至少同时监控 P50 和 P99。
3.2 错误率 SLI（Error Rate SLI）
定义：错误率 SLI 衡量请求处理失败的比率，通常以百分比（%）表示。错误可细分为 HTTP 5xx（服务端错误）、4xx（客户端错误）、业务逻辑错误、超时错误等。
适用场景：
- 所有在线服务：任何对外提供 API 或页面的系统，都需要监控错误率。
- 数据处理管道：如消息队列消费、ETL 任务，错误率反映数据完整性。
- 第三方依赖集成：用于衡量上游依赖的稳定性。
| 错误类型 | 典型阈值参考 | 说明 |
|---|---|---|
| HTTP 5xx | < 0.1% | 服务端内部错误，需立即响应 |
| HTTP 4xx | < 1% 或按业务定义 | 客户端错误，需区分正常业务拒绝 |
| 业务逻辑错误 | < 0.5% | 如订单创建失败、支付失败 |
| 超时错误 | < 0.01% | 通常与延迟 SLI 联动 |
3.3 吞吐量 SLI（Throughput SLI）
定义：吞吐量 SLI 衡量系统在单位时间内处理的请求量或数据量，常见单位有 QPS（每秒查询数）、RPS（每秒请求数）、TPS（每秒事务数）、BPS（每秒字节数）。
适用场景：
- 容量规划：评估系统能否承载预期流量峰值。
- 限流与降级：当吞吐量接近系统上限时触发保护机制。
- 批处理系统：如日志处理、数据同步，关注每小时处理记录数。
注意：吞吐量 SLI 通常与延迟 SLI 呈负相关。当吞吐量接近瓶颈时，延迟会急剧上升。校准阈值时需结合两者进行联合分析。
3.4 饱和度 SLI（Saturation SLI）
定义：饱和度 SLI 衡量资源被使用的程度，反映系统距离容量极限的接近程度。常见指标包括 CPU 使用率、内存使用率、磁盘 I/O 等待时间、网络带宽利用率、连接池使用率、队列深度等。
适用场景：
- 基础设施监控：服务器、数据库、中间件的资源使用情况。
- 弹性伸缩：当饱和度超过阈值时触发自动扩容。
- 故障预测：饱和度持续上升往往是性能劣化的前兆。
校准要点：饱和度阈值不应设置为 100%。例如，CPU 使用率建议阈值设为 80%，预留缓冲空间应对突发流量。队列深度建议阈值设为最大容量的 70%。
3.5 可用性 SLI（Availability SLI）
定义：可用性 SLI 衡量服务在给定时间窗口内正常运行的比率，通常以百分比（%）表示。计算公式为：可用性 = (总时间 - 不可用时间) / 总时间 × 100%。常见的可用性标准有 99.9%（三个九）、99.99%（四个九）、99.999%（五个九）。
适用场景：
- SLA 承诺：对外向客户承诺的服务可用性等级。
- 核心业务系统：如支付、登录、搜索等关键链路。
- 基础设施服务：如 DNS、负载均衡、数据库主从切换。
| 可用性等级 | 年不可用时间 | 月不可用时间 | 典型场景 |
|---|---|---|---|
| 99.9% | 8.76 小时 | 43.8 分钟 | 非关键内部系统 |
| 99.99% | 52.56 分钟 | 4.38 分钟 | 面向用户的 Web 服务 |
| 99.999% | 5.26 分钟 | 26.3 秒 | 金融交易、电信核心网 |
3.6 五种 SLI 的关系与选择
在实际可靠性评审中，这五种 SLI 并非孤立存在，而是相互关联、共同构成服务的健康画像。下图展示了它们之间的典型关系：
3.7 场景化选择指南
在可靠性评审中，应根据服务类型和业务目标选择合适的 SLI 组合。下表总结了不同场景下的推荐 SLI 类型：
| 服务类型 | 推荐 SLI 组合 | 优先级 | 典型阈值示例 |
|---|---|---|---|
| 用户前端 API | 延迟 + 错误率 + 可用性 | 延迟 > 错误率 > 可用性 | P99 延迟 < 200ms, 错误率 < 0.1% |
| 后台批处理 | 吞吐量 + 错误率 + 饱和度 | 吞吐量 > 错误率 > 饱和度 | 每小时处理 > 100 万条, 错误率 < 0.5% |
| 数据库服务 | 延迟 + 饱和度 + 可用性 | 延迟 > 饱和度 > 可用性 | P99 查询延迟 < 50ms, CPU < 80% |
| 消息队列 | 吞吐量 + 饱和度 + 错误率 | 饱和度 > 吞吐量 > 错误率 | 队列深度 < 最大容量 70%, 消费延迟 < 1s |
| CDN / 静态资源 | 可用性 + 延迟 + 吞吐量 | 可用性 > 延迟 > 吞吐量 | 可用性 > 99.99%, P95 延迟 < 100ms |
最佳实践：每个服务至少选择 2-3 个 SLI 类型，避免单一指标带来的盲区。例如，仅监控延迟可能忽略错误率飙升，仅监控可用性可能掩盖性能劣化。