📚 课程目录第4章代码提交阶段SLI

4. 代码提交阶段 SLI：口径与测试验证流程

代码提交阶段是 CI/CD 流水线的起点，也是质量左移的关键环节。本阶段 SLI 聚焦于开发者的提交行为、代码审查效率以及静态分析质量，旨在量化“提交是否健康、审查是否充分、代码是否合规”。

下表汇总了代码提交阶段的 5 个核心 SLI 及其标准口径：

SLI 名称	口径定义	计算方式	数据来源
提交频率	单位时间内（通常为工作日）合并到主分支的提交次数	count(commits) / 工作日天数	Git 仓库日志
提交大小	单次提交涉及的文件变更数量或代码行数（LOC）	sum(changed files) 或 sum(LOC) / commit	Git diff 统计
提交到构建的延迟	从提交推送到远程仓库到 CI 触发构建任务开始的时间间隔	avg(构建开始时间 - 提交时间)	CI 系统事件 + Git Webhook
代码审查覆盖率	经过至少一次 Code Review 的提交占总提交的比例	count(有 review 的 commits) / count(total commits)	PR/MR 系统 API
静态代码分析通过率	通过静态分析（无阻断性缺陷）的提交占总提交的比例	count(通过的 commits) / count(执行分析的 commits)	静态分析工具报告

口径对齐要点： 提交频率建议按“工作日”而非“自然日”计算，避免周末低活跃度拉低均值；提交大小推荐使用“变更文件数”作为主要口径，因为 LOC 受语言和注释影响较大，跨团队可比性差。

每个 SLI 在上线前必须通过“数据准确性验证”和“阈值合理性验证”两个阶段。以下为标准化验证步骤：

数据源接入验证： 确认 Git 仓库 Webhook 能正确推送事件到 CI 系统，且 CI 系统能解析提交元数据（作者、时间戳、变更文件列表）。
口径计算验证： 选取 10 个已知提交样本，手动计算 SLI 值并与系统输出对比，误差应 < 1%。
边界条件测试： 测试空提交、超大提交（如 1000+ 文件）、并发提交等极端场景，确保 SLI 不崩溃、不产生负值或 NaN。
阈值合理性验证： 收集过去 30 天历史数据，绘制 SLI 分布图，确保初始阈值（如提交频率 > 1 次/天、提交大小 < 200 文件）覆盖 80% 的正常提交。
告警链路验证： 构造一个超出阈值的提交，确认告警能正确触发并发送到指定渠道（如钉钉、Slack）。

  验证案例： 某团队发现“提交到构建的延迟”SLI 长期偏高（平均 5 分钟）。排查后发现 CI 系统使用轮询而非 Webhook 触发，导致延迟。将触发方式改为 Webhook 后，延迟降至 15 秒以内。验证流程帮助快速定位了基础设施层面的瓶颈。

下图展示了从代码提交到 SLI 计算的整体数据流与组件关系：

提交频率： 避免将“合并提交（Merge Commit）”计入频率，应只统计功能提交或 squash 后的提交。建议使用 git log --no-merges 过滤。
提交大小： 自动生成的代码（如 protobuf、OpenAPI 客户端）会显著放大提交大小。建议在统计时排除 generated/ 或 vendor/ 目录。
提交到构建的延迟： 如果 CI 使用定时轮询（如每 5 分钟扫描一次），延迟会引入固定偏差。应在 SLI 看板上标注“轮询周期”，避免误判为性能问题。
代码审查覆盖率： 仅统计“有评论”的审查可能漏掉“LGTM 无评论”的通过场景。建议使用 PR/MR 的 approved 状态作为审查完成的标志。
静态代码分析通过率： 不同语言的分析工具阈值不同（如 Go 的 vet 与 Java 的 SpotBugs）。建议按语言/项目维度拆分 SLI，避免混合计算导致失真。

重要提醒： 静态代码分析通过率不应直接用于“卡点阻断”，而应作为“质量趋势指标”。如果通过率长期低于 90%，应优先修复工具配置（如误报规则）而非强制要求 100% 通过，否则会导致开发者绕过分析工具。

以下为代码提交阶段 SLI 上线前的最终验证清单，建议在预发环境逐项确认：

完成上述验证后，代码提交阶段的 SLI 即可正式接入生产流水线，并纳入日常 SRE 巡检范围。