3. 流水线成功率 SLI：定义、计算口径、常见误区和修正方法
流水线成功率（Pipeline Success Rate）是衡量 CI/CD 交付质量最直观的 SLI。它直接反映代码从提交到产出制品的稳定性，也是团队交付效率的“晴雨表”。然而，不同团队对“成功”的定义、统计窗口和排除条件差异巨大，导致该指标在跨团队对标时经常失真。本节从定义出发，逐步拆解计算口径、常见陷阱及修正策略。
3.1 定义与核心语义
流水线成功率定义为：在给定时间窗口内，最终状态为“成功”的流水线执行次数，占所有“有明确结果”的执行次数的比例。
Pipeline Success Rate = (Successful Runs) / (Successful Runs + Failed Runs) × 100%
其中：
- Successful Runs：流水线所有阶段（构建、测试、扫描、部署等）均通过，且产出预期制品或完成预期动作。
- Failed Runs：流水线因编译错误、测试失败、安全漏洞阻断、超时或基础设施异常等原因终止。
- 排除项：手动取消、触发后因上游依赖缺失而自动跳过、仍在运行中的执行。
3.2 计算口径的三大维度
不同团队对“一次执行”的粒度定义不同，直接影响 SLI 数值。下表列出三种常见口径及其适用场景：
| 口径类型 | 统计单元 | 典型场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 按提交（Commit） | 每次 git push 触发的完整流水线 | 主干开发、特性分支验证 | 直接反映代码质量，与开发行为强关联 | 重试或快速修复会导致分母膨胀 |
| 按流水线实例（Run） | 每次手动或自动触发的执行记录 | 多分支、多环境并行部署 | 统计简单，工具原生支持 | 无法区分“同一代码多次重试”与“不同代码提交” |
| 按制品版本（Artifact） | 最终产出可部署制品的流水线执行 | 发布审批、生产部署前检查 | 聚焦交付质量，排除中间调试 | 忽略非制品类流水线（如清理、迁移） |
3.3 常见误区与修正方法
在实际工程中，以下四个误区最容易导致流水线成功率 SLI 失真：
误区一：将“手动取消”计入失败
开发者在发现早期阶段失败后手动取消流水线，这类执行不应计入失败。修正方法：在统计时过滤掉状态为 cancelled 或 aborted 的记录，仅保留 success 和 failure 状态。
误区二：忽略基础设施故障导致的失败
因 Agent 离线、磁盘空间不足、网络抖动等基础设施原因导致的失败，与代码质量无关。修正方法：在流水线中增加“基础设施异常”标签，统计时单独标记，并在 SLI 中提供“排除基础设施故障后的修正成功率”。
误区三：重试机制导致分母膨胀
部分 CI 系统在失败后自动重试，导致同一提交产生多次执行记录。修正方法：对同一 commit SHA 的多次执行，只保留最后一次结果作为该提交的最终状态。
误区四：时间窗口选择不当
使用自然周/月作为窗口，容易因节假日或发布冻结期导致数据波动。修正方法：采用滚动窗口（如最近 7 天、最近 30 天），并配合“执行次数”作为辅助指标，避免低样本量下的比率失真。
3.4 修正后的计算流程
下图展示从原始流水线日志到最终 SLI 的完整处理链路：
3.5 工程案例：多团队口径对齐实践
某中型互联网公司有三个业务团队，各自使用不同的 CI 工具（Jenkins、GitLab CI、GitHub Actions）。初期各团队上报的流水线成功率分别为 92%、87%、95%，但经过口径对齐后，实际差异远小于表面数据。
对齐步骤：
- 统一统计单元：全部切换为“按提交”口径，对同一 commit 的多次执行只保留最终结果。
- 统一排除规则：所有团队过滤
cancelled状态，并标记基础设施失败原因。 - 统一时间窗口：采用滚动 7 天窗口，每日凌晨计算一次。
- 建立校准表：各团队每月交叉验证 50 条原始记录，确保标签一致性。
对齐前后对比：
| 团队 | 对齐前（原始口径） | 对齐后（统一口径） | 偏差原因 |
|---|---|---|---|
| A 团队（Jenkins） | 92% | 89% | 原口径未排除基础设施失败 |
| B 团队（GitLab CI） | 87% | 90% | 原口径将手动取消计入失败 |
| C 团队（GitHub Actions） | 95% | 91% | 原口径未对重试执行去重 |
3.6 修正后的 SLI 仪表盘设计
推荐在监控仪表盘中同时展示以下三个视图，以提供完整的成功率画像：
- 主 SLI：修正后的流水线成功率（排除取消、去重、标记基础设施失败）。
- 辅助指标：总执行次数、重试率、基础设施失败占比。
- 趋势线：滚动 7 天和 30 天的成功率变化曲线，附带每日执行次数柱状图。
通过这种分层展示，团队既能快速定位成功率下降是否由代码质量引起，也能识别基础设施层面的系统性问题，从而做出更精准的改进决策。