1. SLI 基础概念
1.1 什么是 SLI（Service Level Indicator）
SLI（Service Level Indicator，服务等级指标） 是对服务性能或质量某一特定维度的量化度量。在 CI/CD 流水线语境下，SLI 是衡量流水线执行健康度的可观测数值，例如：流水线成功率、平均执行时长、部署频率等。
SLI 的核心特征：
- 可量化：必须能用数字表达，如 98.5%、120 秒
- 可观测：能从日志、监控、API 等数据源直接采集
- 可对比：能设定阈值或基线进行趋势分析
- 面向用户：反映最终用户或下游系统实际体验
💡 实践要点： 选择 SLI 时遵循 "少而精" 原则。CI 流水线通常选取 3~5 个核心 SLI，避免指标泛滥导致运维成本激增。
1.2 SLI 在 CI 流水线中的意义
将 SLI 引入 GitLab CI 流水线，实现了从 "黑盒运行" 到 "可量化治理" 的转变。具体价值体现在：
| 维度 | 无 SLI 的流水线 | 有 SLI 的流水线 |
|---|---|---|
| 可见性 | 仅知道 "通过/失败" | 知道成功率、耗时分布、失败模式 |
| 决策依据 | 凭经验判断是否稳定 | 基于数据驱动优化 |
| 告警精度 | 全量告警或静默 | 按 SLI 阈值分级告警 |
| 持续改进 | 难以定位瓶颈 | 可量化瓶颈并跟踪改善效果 |
在 GitLab CI 中，SLI 可直接嵌入 .gitlab-ci.yml 的 job 输出、制品报告或 API 回调中，形成闭环反馈。
1.3 SLI 与 SLO / SLA 的关系
三者的关系可以用 "度量 → 目标 → 承诺" 来概括：
- SLI（指标）：实际测量值，如 "本周流水线成功率为 97.2%"
- SLO（目标）：基于 SLI 设定的期望阈值，如 "流水线成功率 ≥ 99%"
- SLA（协议）：对外承诺的正式协议，通常附带惩罚条款，如 "若成功率低于 95%，赔偿 10% 服务费"
🔗 关键认知： SLO 是 SLI 的目标边界，SLA 是 SLO 的商业化契约。在 CI 流水线场景中，团队通常先定义 SLI，再设定内部 SLO，最后才考虑对外 SLA。
下表展示了一个 GitLab CI 流水线的 SLI / SLO / SLA 示例：
| 类型 | 指标名称 | 示例值 | 说明 |
|---|---|---|---|
| SLI | 流水线成功率 | 98.2% | 过去 7 天成功流水线 / 总流水线 |
| SLO | 流水线成功率目标 | ≥ 99% | 内部团队承诺的月度目标 |
| SLA | 流水线成功率承诺 | ≥ 95% | 对下游发布团队的正式协议 |
| SLI | 平均执行时长 | 8 分 30 秒 | 过去 24 小时所有流水线平均耗时 |
| SLO | 平均执行时长目标 | ≤ 10 分钟 | 开发团队反馈的体验基线 |
⚠️ 常见误区： 不要将 SLI 与 SLO 混为一谈。SLI 是 "实际是多少"，SLO 是 "希望是多少"。在 GitLab CI 中，如果只采集 SLI 而不设定 SLO，指标将失去改进方向；如果只设定 SLO 而不采集 SLI，目标将无法验证。
1.4 典型 CI 流水线 SLI 清单
以下是在 GitLab CI 实践中常用的 SLI 清单，可作为团队初始选型的参考：
| SLI 名称 | 定义 | 采集方式 | 推荐 SLO |
|---|---|---|---|
| 流水线成功率 | 成功流水线数 / 总触发流水线数 | GitLab API / Webhook | ≥ 99% |
| 流水线执行时长 | 从触发到完成的总耗时（P50/P95） | CI job 日志时间戳 | P95 ≤ 15min |
| 部署频率 | 单位时间内成功部署次数 | GitLab 部署事件 | ≥ 10 次/天 |
| 变更失败率 | 导致生产故障的部署数 / 总部署数 | 告警系统 + 部署记录 | ≤ 5% |
| 恢复时间 | 从故障告警到恢复的平均时长 | 事件管理系统 | ≤ 1 小时 |
1.5 选择 SLI 的黄金法则
- 用户视角优先：选择直接影响开发人员或下游系统体验的指标，而非内部技术细节。
- 可操作性：SLI 必须能直接关联到具体改进动作，如 "增加缓存" 可优化 "执行时长" SLI。
- 避免指标膨胀：初始阶段控制在 5 个以内，后续按需扩展。
- 定义清晰口径：明确统计窗口（如 7 天滚动）、排除条件（如手动取消的流水线不计入）。
- 自动化采集：优先使用 GitLab CI 内置的
artifacts:reports、metrics或 API 回调，避免人工录入。