4. 代码提交阶段 SLI：提交频率、提交大小、提交到构建的延迟、代码审查通过率
代码提交阶段是 CI/CD 流水线的起点，也是质量内建的第一道防线。本阶段 SLI 直接反映开发团队的提交习惯、代码集成效率以及审查流程的健康度。通过量化提交频率、提交大小、提交到构建的延迟以及代码审查通过率，团队可以精准定位流程瓶颈，优化从“编码完成”到“进入构建”的转化效率。
4.1 核心 SLI 定义与计算口径
下表列出了代码提交阶段四个核心 SLI 的标准化定义、计算方式及推荐采集点：
| SLI 名称 | 定义 | 计算口径 | 数据来源 |
|---|---|---|---|
| 提交频率 | 单位时间内（通常为工作日）推送到主仓库的提交次数 | 总提交数 ÷ 统计天数（排除非工作时段可做归一化） | Git 日志 / Webhook 事件 |
| 提交大小 | 单次提交包含的变更量，以变更文件数或代码行数（LOC）衡量 | 每次提交的 diff 文件数 / diff 行数（建议取 P50/P95） | Git diff 统计 / CI 触发载荷 |
| 提交到构建的延迟 | 从代码推送完成到 CI 流水线开始执行构建任务的时间间隔 | 构建开始时间戳 - 推送完成时间戳（秒级） | CI 系统 API / 事件时间线 |
| 代码审查通过率 | Pull Request / Merge Request 在首次审查后获得批准的比率 | 首次审查即通过的 PR 数 ÷ 总 PR 数 × 100% | 代码托管平台 API（GitHub/GitLab） |
实践建议：提交频率和提交大小应联合分析。高频 + 小提交通常代表良好的原子化提交习惯；低频 + 超大提交则暗示代码集成风险高，容易引发合并冲突和构建失败。
4.2 提交频率与提交大小的平衡模型
提交频率和提交大小之间存在典型的权衡关系。过高的提交频率若伴随过小的变更，可能导致 CI 资源浪费；而过低的频率伴随超大提交，则会使问题发现严重滞后。推荐使用“提交健康矩阵”进行可视化监控。
4.3 提交到构建的延迟：端到端时效分析
“提交到构建的延迟”是衡量 CI 基础设施响应能力的关键指标。延迟过高会直接拉长开发反馈循环，降低开发者的提交意愿。延迟通常由以下环节构成：
- Webhook 触发延迟：代码托管平台推送事件到 CI 系统的网络耗时。
- CI 调度排队延迟：构建任务在 CI 队列中等待可用执行器的时间。
- 环境准备延迟：拉取代码、安装依赖、缓存恢复等前置步骤耗时。
SLI 目标参考：提交到构建的延迟 P95 应控制在 30 秒以内。若超过 60 秒，需排查 CI 执行器资源是否充足、Webhook 通道是否拥塞、或是否存在不必要的预检查步骤。
4.4 代码审查通过率：质量内建的第一道门
代码审查通过率反映审查流程的严格程度与代码质量的基线水平。过高的通过率（接近 100%）可能意味着审查流于形式；过低的通过率则可能表明代码规范不明确或审查标准过于严苛。
建议将审查通过率与审查轮次结合分析：
- 首次审查通过率 > 80%：代码质量成熟，审查流程高效。
- 首次审查通过率 50% - 80%：存在一定改进空间，建议检查代码规范文档是否清晰。
- 首次审查通过率 < 50%：需立即介入，可能原因包括：缺乏编码规范、审查者标准不统一、或开发者未进行自测。
4.5 综合调优案例：从指标到行动
某中型互联网团队在实施 SLI 监控后，发现以下问题：
- 提交频率：平均每天仅 1.2 次提交/人，远低于行业基准（3-5 次）。
- 提交大小：P95 提交包含 25+ 个文件，属于超大提交。
- 提交到构建延迟：P95 达到 120 秒，主要卡在 CI 排队。
- 审查通过率：首次通过率仅 35%，平均需要 2.8 轮审查。
团队采取以下优化措施：
- 推行原子化提交规范：要求每次提交不超过 5 个文件，并配置 Git Hooks 进行前置检查。
- 扩容 CI 执行器：将并发执行器从 4 个增加到 12 个，并启用自动扩缩容策略。
- 建立审查标准清单：制定明确的审查 Checklist，减少审查者主观差异。
- 设置提交频率看板：在团队周会上展示提交频率趋势，鼓励高频小提交。
注意：优化提交频率时，切忌强制要求开发者“凑次数”。应通过降低提交门槛（如简化分支策略、提供本地验证工具）来自然引导行为改变。指标是结果，不是目标。
经过 4 周迭代，该团队的提交频率提升至 3.8 次/天，提交大小 P95 降至 6 个文件，提交到构建延迟降至 18 秒，首次审查通过率提升至 72%。四个 SLI 的联合改善直接缩短了功能交付周期 40%。