2. SLI 基础概念：服务等级指标与四大黄金信号
SLI（Service Level Indicator，服务等级指标）是衡量系统或流水线某一维度服务质量的核心量化指标。在跨团队 CI/CD 流水线中，SLI 必须从“最终用户”视角（即开发人员提交代码到部署生效的完整体验）进行定义，而非仅关注基础设施层面的原始数据。
2.1 SLI 定义三要素
一个合格的 SLI 必须同时明确以下三个要素，否则无法在跨团队间形成统一口径：
| 要素 | 说明 | 流水线示例 |
|---|---|---|
| 测量窗口 | SLI 数据聚合的时间范围 | 过去 5 分钟 / 过去 1 小时 / 最近 100 次构建 |
| 聚合方法 | 原始数据如何汇总为单一数值 | 平均值 / P50 / P95 / P99 / 成功率百分比 |
| 计数条件 | 哪些事件计入分母，哪些计入分子 | 仅统计“触发 CI 的 PR 构建”，排除手动重试 |
口径对齐关键： 不同团队对“构建失败”的定义可能不同——是“编译报错”算失败，还是“单元测试未通过”也算失败？SLI 定义阶段必须书面化这些计数条件，否则后续质量门禁将产生争议。
2.2 四大黄金信号在流水线中的映射
Google SRE 提出的四大黄金信号（延迟、流量、错误、饱和度）不仅适用于生产服务，同样可以系统化地映射到 CI/CD 流水线的各个阶段。以下表格展示了每个信号在流水线中的具体 SLI 定义：
| 黄金信号 | 流水线 SLI 名称 | 典型测量方式 | 数据来源 |
|---|---|---|---|
| 延迟 (Latency) | 流水线端到端耗时 | 从代码提交到部署完成的 P95 耗时 | CI/CD 平台 API + 时间戳埋点 |
| 流量 (Traffic) | 构建并发量与吞吐量 | 每分钟启动的构建任务数 / 排队任务数 | 构建队列监控 + Runner 日志 |
| 错误 (Errors) | 流水线失败率 | 失败构建数 / 总构建数（排除手动取消） | CI/CD 平台 Webhook 事件 |
| 饱和度 (Saturation) | 构建资源利用率 | Runner CPU 使用率 / 并发槽位占用率 | Kubernetes / 虚拟机监控 |
实践建议： 初期每个信号只选 1 个最核心的 SLI 进行采集，避免过度埋点。例如先聚焦“流水线失败率”和“端到端 P95 耗时”，待数据稳定后再扩展其他维度。
2.3 四大黄金信号映射关系图
下图展示了四大黄金信号如何从生产服务监控模型映射到 CI/CD 流水线的不同阶段，以及各信号之间的关联关系：
2.4 各信号详细定义与流水线示例
2.4.1 延迟（Latency）
- SLI 名称：流水线端到端耗时（Pipeline Lead Time）
- 测量方式：从开发者触发构建（git push / PR merge）到流水线最终状态（成功/失败）的时间差，取 P95 或 P99 分位数。
- 流水线示例：“过去 1 小时内，所有 PR 构建的 P95 耗时不超过 15 分钟。”
- 常见陷阱：排队等待时间是否计入？建议明确区分“排队延迟”和“执行延迟”，分别定义 SLI。
2.4.2 流量（Traffic）
- SLI 名称：构建并发数与吞吐量
- 测量方式：每分钟/每小时启动的构建任务数，以及同时运行的构建任务峰值。
- 流水线示例：“高峰期并发构建数不超过 Runner 池容量的 80%。”
- 常见陷阱：流量激增可能导致 Runner 资源争抢，进而影响延迟 SLI。流量 SLI 通常用于容量规划而非质量门禁。
2.4.3 错误（Errors）
- SLI 名称：流水线失败率（Pipeline Failure Rate）
- 测量方式：失败构建数 / 总构建数 × 100%。需排除手动取消、超时自动取消等非故障场景。
- 流水线示例：“最近 100 次构建中，失败率低于 5%。”
- 常见陷阱：基础设施故障（如 Runner 宕机）导致的失败应与代码质量失败分开统计，否则会掩盖真实问题。
2.4.4 饱和度（Saturation）
- SLI 名称：Runner 资源利用率
- 测量方式：CPU 使用率、内存使用率、并发槽位占用率、磁盘 I/O 等待时间。
- 流水线示例：“Runner 节点 CPU 平均利用率超过 85% 时触发扩容告警。”
- 常见陷阱：饱和度 SLI 通常不直接用于质量门禁阻断，而是作为容量规划的输入。但极端饱和度（如 100%）会间接导致延迟和错误 SLI 劣化。
⚠️ 跨团队口径对齐警告： 不同团队可能对“错误”的定义不一致——A 团队将“单元测试失败”视为错误，B 团队仅将“编译失败”视为错误。在制定 SLI 口径时，必须使用统一的计数条件文档，并在流水线配置中通过标签（tag）或分类字段进行标记，否则质量门禁将产生误判。
2.5 SLI 采集与存储建议
为支撑后续的质量门禁计算，SLI 数据需要以结构化方式存储。推荐使用以下数据模型：
{
"pipeline_id": "build-20250321-001",
"team": "payment-team",
"stage": "test",
"sli_type": "latency",
"value_ms": 34200,
"p50_ms": 28500,
"p95_ms": 62000,
"timestamp": "2025-03-21T10:30:00Z",
"tags": {
"branch": "feature/payment-v2",
"trigger": "pr_merge"
}
}每个 SLI 事件应包含团队标签、流水线阶段、信号类型和分位数数据，以便后续按团队、按阶段进行聚合分析。