2. SLI指标分类体系：详解延迟、流量、错误、饱和度（USE/RED方法论），以及业务自定义SLI的分类标准
构建精准的SLO数据底座，首先需要建立一套清晰、可复用的SLI指标分类体系。业界经过多年实践，沉淀出两大经典方法论——USE（资源视角）与RED（服务视角），并在此基础上衍生出业务自定义SLI的分类标准。本章将系统拆解这三大分类维度，帮助你在不同抽象层级上精准选型。
2.1 两大经典方法论：USE与RED
USE与RED分别从基础设施资源和用户服务两个互补视角定义SLI，是SRE可靠性运营的基石。
| 维度 | USE（资源视角） | RED（服务视角） |
|---|---|---|
| 适用对象 | 物理机、容器、数据库、网络设备等资源 | API、微服务、应用层接口 |
| 核心指标 | Utilization（利用率）、Saturation（饱和度）、Errors（错误） | Rate（流量）、Errors（错误）、Duration（延迟） |
| 关注点 | 资源是否够用、是否过载、是否出错 | 请求是否被处理、处理是否正确、处理是否够快 |
| 典型场景 | CPU/内存/磁盘/网络监控 | HTTP请求成功率、响应时间、QPS |
核心原则：USE用于回答“资源健康吗？”，RED用于回答“服务正常吗？”。两者结合，可覆盖从底层到上层的全栈可观测性。
2.2 详解四大黄金指标：延迟、流量、错误、饱和度
Google SRE在《SRE: 运维解密》中提出的“四大黄金信号”，是对USE/RED方法论的高度抽象。以下逐一拆解其定义、采集粒度与常见陷阱。
2.2.1 延迟（Latency / Duration）
- 定义：请求从发出到收到完整响应所消耗的时间。
- 关键区分：必须区分成功请求延迟与失败请求延迟。失败请求通常快速返回（如4xx/5xx），若混入统计，会拉低整体延迟，掩盖真实性能问题。
- 推荐分位数：p50（典型体验）、p95（长尾用户）、p99（极端情况）。避免仅使用平均值。
- 采集粒度：服务端侧（推荐） vs. 客户端侧（更真实，但受网络波动影响）。
2.2.2 流量（Traffic / Rate）
- 定义：系统当前承载的请求量级或数据吞吐量。
- 常见单位：QPS（每秒查询数）、RPS（每秒请求数）、TPS（每秒事务数）、带宽（bps）。
- 作用：用于容量规划、弹性伸缩触发、异常流量检测（如DDoS）。
- 注意：流量指标需与时间窗口绑定（如1分钟平均QPS vs. 瞬时峰值QPS），避免被毛刺误导。
2.2.3 错误（Errors）
- 定义：请求处理失败的比率或数量。
- 分类：
- 显式错误：HTTP 5xx、4xx、超时、连接拒绝。
- 隐式错误：返回200 OK但业务逻辑错误（如“查询成功”但返回空数据）、响应体不符合契约。
- 采集建议：必须同时采集错误率（百分比）和错误数（值），低流量服务下错误率可能被放大。
2.2.4 饱和度（Saturation）
- 定义：资源或服务接近其最大容量的程度。
- 典型指标：CPU使用率、内存使用率、磁盘I/O等待队列长度、线程池活跃线程数、数据库连接池使用率。
- 关键信号：饱和度通常先于延迟恶化出现，是预测性告警的最佳输入。
- 阈值设定：通常以80%为警告线，90%为危险线，但需结合业务特性调整。
实战避坑：不要将“饱和度”与“利用率”混为一谈。利用率是当前使用比例，饱和度是“还有多少余量”。例如：CPU利用率80%可能仍有余量，但若运行队列长度持续大于CPU核数×2，则已进入饱和状态。
2.3 业务自定义SLI的分类标准
通用指标无法覆盖所有业务场景。业务自定义SLI需要遵循统一的分类标准，确保可采集、可计算、可对比。以下为推荐的三级分类体系：
| 一级分类 | 二级分类 | 示例指标 | 采集方式 |
|---|---|---|---|
| 可用性 | 服务可达性 | 健康检查成功率、端口连通率 | 探针/心跳 |
| 功能可用性 | 登录成功率、下单成功率 | 业务日志/APM | |
| 性能 | 响应速度 | 首屏加载时间、API p99延迟 | RUM/APM |
| 吞吐能力 | 并发用户数、每秒事务数 | 负载均衡/中间件 | |
| 准确性 | 数据一致性 | 对账差异率、数据同步延迟 | 离线校验/CDC |
| 业务正确性 | 搜索结果相关性评分、推荐点击率 | A/B测试/埋点 | |
| 新鲜度 | 数据时效性 | 实时数据延迟秒数、缓存更新延迟 | 时间戳比对 |
重要：业务自定义SLI必须满足“可量化、可重复、可自动化采集”三原则。避免定义“用户体验好”这类无法直接测量的指标。应将其拆解为“页面加载时间 < 2秒的请求占比”等可采集的代理指标。
2.4 SLI分类体系全景图
以下SVG图展示了从基础设施到业务层的完整SLI分类体系，以及USE/RED方法论在其中的映射关系。
2.5 分类标准选择决策树
在实际工作中，面对一个系统或组件，如何快速确定应该采用哪类SLI？以下决策树可辅助判断：
- 这是基础设施资源吗？（如CPU、内存、磁盘、网络） → 使用USE方法论，优先采集利用率和饱和度。
- 这是用户可见的服务吗？（如API、Web应用、RPC服务） → 使用RED方法论，优先采集流量、错误、延迟。
- 这是业务功能或流程吗？（如登录、下单、搜索） → 使用业务自定义SLI，从可用性、准确性、新鲜度、性能四个维度定义。
- 需要预测性告警？ → 重点关注饱和度指标，它通常领先于错误和延迟恶化。
最佳实践：一个成熟的SRE团队，通常同时维护3~5个基础设施USE指标、5~10个核心服务RED指标、以及2~3个关键业务自定义SLI。指标数量并非越多越好，关键在于每个SLI都能直接关联到一个明确的SLO目标。