3. SLI 基础回顾：服务等级指标的定义与常见类型
在构建基于服务画像的 CI/CD 流水线 SLI 口径之前，必须回归 SLI 的本质。SLI（Service Level Indicator，服务等级指标）是衡量服务某个特定维度表现好坏的直接量化值。它不是目标，而是对服务行为“是什么”的客观描述。
核心定义：SLI = 服务质量的原始测量值。例如：“过去 5 分钟内，所有 HTTP GET 请求的 P99 延迟为 210ms”。
3.1 四大黄金信号：SLI 的分类框架
Google SRE 经典理论将 SLI 归纳为四个核心类别，称为“四大黄金信号”。这四类指标覆盖了用户可感知的绝大部分服务质量维度。
| SLI 类型 | 核心关注点 | 典型测量对象 | 常见口径示例 |
|---|---|---|---|
| 延迟 (Latency) | 请求处理的速度 | 响应时间、处理时长 | P50 / P95 / P99 延迟 ≤ 500ms |
| 错误率 (Error Rate) | 请求失败的占比 | HTTP 5xx、业务异常、超时 | 错误率 ≤ 0.1% |
| 吞吐量 (Throughput) | 系统处理请求的容量 | QPS、RPS、TPS、带宽 | 峰值吞吐量 ≥ 1000 QPS |
| 饱和度 (Saturation) | 资源被占用的程度 | CPU 使用率、内存占用、连接池水位 | CPU 饱和度 ≤ 80% |
3.2 四大 SLI 类型详解
3.2.1 延迟 (Latency)
延迟衡量的是服务“快不快”。在 CI/CD 流水线中，延迟 SLI 通常关注构建时间、部署时间和测试执行时间。需要特别注意的是，延迟的分布往往是非正态的，因此推荐使用百分位数（如 P95、P99）而非平均值。
- 常见误区：仅使用平均延迟。平均值会掩盖长尾慢请求，导致 SLI 失真。
- 流水线场景：“从代码提交到构建完成的时间 P95 ≤ 5 分钟”。
3.2.2 错误率 (Error Rate)
错误率衡量的是服务“稳不稳”。错误不仅包括 HTTP 5xx 服务器错误，还应包含业务逻辑错误（如返回了错误码但 HTTP 状态码为 200）和功能失效（如部署后核心接口返回空数据）。
- 计算方式：错误请求总数 / 总请求数 × 100%。
- 流水线场景：“部署后冒烟测试的错误率 = 0%”。
3.2.3 吞吐量 (Throughput)
吞吐量衡量的是服务“装不装得下”。在流水线上下文中，吞吐量通常指单位时间内完成的部署次数或处理的构建任务数。吞吐量 SLI 与系统容量规划直接相关。
- 关键点：吞吐量需要与延迟联合分析。当吞吐量接近系统上限时，延迟通常会急剧上升。
- 流水线场景：“CI 集群每分钟处理构建任务数 ≥ 50 个”。
3.2.4 饱和度 (Saturation)
饱和度衡量的是服务“还有多少余量”。它通常是最容易被忽视但最具预测性的 SLI。饱和度指标往往来自基础设施层，例如 CPU 使用率、内存占用、磁盘 I/O 等待时间、连接池使用率等。
- 高级用法：使用利用率 vs 延迟的拐点曲线来定义饱和度阈值。
- 流水线场景：“构建节点 CPU 饱和度 ≤ 70%，避免因资源争抢导致构建超时”。
实践建议：在定义 SLI 时，不要试图一次性覆盖所有指标。建议从“延迟”和“错误率”这两个用户最敏感的维度开始，逐步加入“吞吐量”和“饱和度”。
3.3 SLI 类型关系图：四大黄金信号与流水线映射
下图展示了四大 SLI 类型之间的关联关系，以及它们如何映射到 CI/CD 流水线的关键阶段。
3.4 SLI 选择原则：从“可测量”到“有意义”
并非所有指标都适合作为 SLI。在选择 SLI 时，应遵循以下优先级原则：
- 用户可见性优先：优先选择用户能直接感知的指标（如 API 延迟），而非内部实现细节（如 GC 暂停时间）。
- 可测量性：指标必须能够被稳定、持续地采集，且采集开销可接受。
- 可区分性：SLI 应能清晰区分“好”与“坏”的状态，避免模糊边界。
- 可行动性：当 SLI 恶化时，团队应能据此做出明确的运维或开发决策。