1. SLI 基础概念：定义、关系与 CI/CD 价值
1.1 SLI 定义：可量化的服务质量指标
SLI（Service Level Indicator，服务等级指标） 是对服务质量的某个维度进行定量测量的原始指标。在 CI/CD 流水线语境下，SLI 是衡量流水线健康度的“仪表盘读数”，例如构建成功率、部署频率、流水线平均耗时等。
核心公式： SLI = 符合预期行为的样本数 / 总样本数 × 100%
SLI 必须满足 SMART 原则：
- Specific（具体）：明确定义测量对象，如“构建阶段通过率”而非“构建质量”。
- Measurable（可测量）：数据可被工具自动采集，如 Jenkins API、GitLab CI 日志。
- Achievable（可实现）：指标值在现有工程能力下可被观测。
- Relevant（相关）：指标与流水线稳定性、交付效率直接关联。
- Time-bound（有时限）：在固定时间窗口（如 1 小时、1 天）内计算。
1.2 SLI 与 SLO / SLA 的关系
SLI、SLO、SLA 构成服务质量管理体系的三个层次。下表清晰展示三者的区别与联系：
| 维度 | SLI（指标） | SLO（目标） | SLA（协议） |
|---|---|---|---|
| 定义 | 实际测量的服务质量数值 | SLI 应达到的目标阈值 | 服务提供商与用户之间的正式承诺 |
| 示例 | 构建成功率 = 98.5% | 构建成功率 ≥ 99% | 若低于 99%，提供 5% 服务抵扣 |
| 约束力 | 无约束，仅观测 | 内部团队承诺 | 法律/合同约束 |
| 时间粒度 | 实时/近实时 | 月度/季度滚动 | 按合同周期 |
| CI/CD 场景 | 流水线单步耗时 | P95 耗时 ≤ 5 分钟 | 客户交付 SLA 中定义 |
工程经验： 在 CI/CD 实践中，SLO 是 SLI 的“护栏”，SLA 是 SLO 的“商业延伸”。团队应优先定义 SLI，再设定 SLO，最后根据业务需求决定是否需要 SLA。
三者之间的依赖关系可通过以下结构图直观理解：
1.3 SLI 在 CI/CD 中的核心价值
在 CI/CD 流水线中引入 SLI 体系，能够带来以下四个维度的工程价值：
- 可观测性增强： 将流水线从“黑盒”变为“白盒”，每个阶段（代码检查、构建、测试、部署）都有量化指标。
- 故障快速定位： 当 SLI 偏离基线时，自动触发告警，帮助 SRE 团队在 5 分钟内定位瓶颈阶段。
- 容量规划依据： 基于 SLI 历史趋势（如构建队列积压时长），合理扩缩 CI 集群资源。
- 持续改进闭环： SLI 数据驱动 SLO 调整，形成“测量 → 分析 → 优化 → 再测量”的飞轮效应。
常见误区： 不要试图监控所有指标。选择 3~5 个与交付效率、稳定性强相关的 SLI 作为“黄金信号”，避免指标爆炸导致运维成本失控。
以下流程图展示 SLI 在 CI/CD 流水线中的典型采集与反馈路径：
1.4 典型 CI/CD SLI 示例清单
下表列出流水线中最常用的 6 个 SLI，涵盖效率与稳定性两个维度：
| SLI 名称 | 测量方式 | 典型阈值（SLO） | 采集工具 |
|---|---|---|---|
| 构建成功率 | 成功构建数 / 总构建数 | ≥ 99% | Jenkins / GitLab CI |
| 流水线总耗时 P95 | 95% 分位流水线完成时间 | ≤ 10 分钟 | Prometheus + Grafana |
| 部署频率 | 每日生产部署次数 | ≥ 5 次/天 | Spinnaker / ArgoCD |
| 变更失败率 | 导致故障的变更数 / 总变更数 | ≤ 5% | PagerDuty + 变更管理系统 |
| 测试通过率 | 通过测试用例数 / 总用例数 | ≥ 98% | JUnit / pytest 报告 |
| 队列等待时间 | 任务进入队列到开始执行的时间 | P90 ≤ 30 秒 | CI 引擎 API + 自定义 Exporter |
选型建议： 对于初创团队，优先采集“构建成功率”和“流水线总耗时”两个 SLI；随着流水线成熟度提升，逐步加入“变更失败率”和“部署频率”以覆盖 DORA 四指标。