构建重跑率=统计周期内重跑次数÷统计周期内构建总次数×100%，分母按“构建次数”计，不按流水线数量计。重跑指同一提交、同一流水线配置下因失败或中断而再次触发的构建。这个指标要和构建失败率、失败类型分布、重跑原因分布一起看，才能判断“构建频繁失败”是否已经需要专项治理。下面给出完整口径、取数字段、计算步骤和一个可复算的算例。
要点总览（TL;DR）
- 构建重跑率=统计周期内重跑次数÷统计周期内构建总次数×100%，分母按构建次数计，不按流水线数量计。
- 重跑指同一提交哈希、同一流水线配置下因失败或中断而再次触发的构建；定时构建与手动构建是否计入需在统计前固定并保持稳定。
- 取数至少需要构建ID、提交哈希、流水线配置版本、触发方式、起止时间、构建结果、重跑标记和失败原因，缺失记录先列入待核对清单。
- 重跑率要与构建失败率、失败类型分布、重跑原因分布同窗口对照，连续两到三个周期上升或失败类型集中、影响主干合并时再考虑专项治理。
- 分母为零时不输出比率，样本过少时同时给出绝对次数并标注仅供参考，口径变更的周期不做直接环比。
评估目标：重跑率要回答什么问题
重跑率衡量的是构建稳定性，以及失败后恢复所付出的重复执行成本。它回答的问题是：在一个统计周期内，团队有多少比例的构建是“本来不该再跑一次”的重复执行。重跑次数越多，说明首次构建的成功率越低，或者失败后的恢复路径越长，流水线占用的机器时间和等待时间也越多。
这个指标适合作为构建质量的观察入口，不适合单独作为团队或个人绩效指标。原因在于重跑次数受提交频率、分支策略、流水线触发规则影响，单看一个比率容易把“提交多、构建多”误读为“质量差”。更稳妥的做法是把重跑率与构建失败率、失败类型分布放在同一统计窗口内对照：重跑率上升而失败率同步上升，通常指向构建本身不稳定；重跑率上升而失败率平稳，则要检查重跑触发规则是否被放宽。
是否触发专项治理，建议按团队自身历史基线设定初步阈值，例如连续两到三个统计周期重跑率持续上升，或某一失败类型在重跑原因中占比明显集中。这里不设通用达标线，因为不同团队的分支模型、构建时长和测试规模差异很大，套用外部数字容易产生误判。
指标与范围：重跑、构建次数和统计口径
重跑率、构建失败率和失败类型分布需要共用一套统计范围，否则三个数字放在一起没有可比性。下表给出各指标的定义、分子分母和单位。
| 指标 | 计算方式 | 分子 | 分母 | 单位 |
|---|---|---|---|---|
| 构建重跑率 | 重跑次数÷构建总次数×100% | 统计周期内被标记为重跑的构建次数 | 统计周期内全部构建次数 | 百分比，附绝对次数 |
| 构建失败率 | 失败构建次数÷构建总次数×100% | 结果为失败的构建次数 | 统计周期内全部构建次数 | 百分比，附绝对次数 |
| 失败类型分布 | 某类失败次数÷失败构建总次数×100% | 按编译、测试、环境、依赖、配置等类别计数的失败次数 | 失败构建总次数 | 各类别次数与占比 |
统计范围需要在计算前固定下来，并在报表中注明。需要明确的维度包括：纳入哪些流水线（全部还是主干相关流水线）、纳入哪些分支（主干、发布分支、特性分支是否都算）、时间窗的起止边界（按构建开始时间还是结束时间归属周期）、是否包含定时构建与手动构建。定时构建通常用于夜间全量验证，手动构建多用于临时排查，两者与代码提交触发的构建性质不同，建议在报表中单列或明确排除，并在多个周期之间保持一致。
重跑的识别口径也要统一：同一提交哈希、同一流水线配置下，因失败或中断而再次触发的构建计为一次重跑。同一提交因代码未变而重复触发但首次构建成功的，不计入重跑；不同提交之间的连续构建也不计入重跑。
数据口径与证据：从流水线记录里取哪些字段
重跑率能否复算，取决于原始记录是否保留了足够的字段。建议从流水线执行记录中取以下字段，形成一张构建明细表。
| 字段 | 用途 | 清洗要求 |
|---|---|---|
| 构建ID | 唯一标识一次构建，用于计数 | 去重，排除重复导入 |
| 提交哈希 | 识别同一提交的多次构建 | 统一长度与大小写 |
| 流水线名称与配置版本 | 限定统计范围，判断是否同一配置 | 配置变更需记录生效时间 |
| 触发方式 | 区分提交触发、定时触发、手动触发 | 缺失时标注为未知，不默认归入某一类 |
| 触发人 | 辅助判断手动重跑场景 | 系统账号单独标记 |
| 开始时间、结束时间 | 确定构建归属的统计周期 | 统一时区，明确按开始时间归属 |
| 构建结果 | 计算失败率，识别重跑前置条件 | 成功、失败、中断、取消分别保留 |
| 重跑标记 | 直接标记重跑构建 | 无现成标记时按提交哈希与配置推导 |
| 失败原因 | 归类失败类型 | 按固定分类映射，保留原始日志摘要 |
同一提交多次构建的识别方法是：以“提交哈希+流水线配置”为分组键，按开始时间排序，首次构建之后的同组构建若由失败或中断引发，标记为重跑。若流水线配置在周期内发生过变更，应以配置版本作为分组键的一部分，避免把配置调整前后的构建误判为重跑。
缺失值与异常记录需要单独处理：结果字段为空、开始时间缺失、构建时长为零的记录，建议先列入待核对清单，不直接计入分母；确认属于系统同步延迟的，可在下一周期补录并注明。数据可比性的前提是两个周期使用相同的统计窗口长度、相同的流水线范围和相同的触发方式口径，任一项变化都要在报表中标注。
计算步骤：从原始记录到重跑率
按以下五步执行，每一步都产出可核对的中间结果，便于他人复算。
- 确定统计窗口与流水线范围。写明起止日期、纳入的流水线与分支、触发方式口径，形成一份口径说明，与报表一同归档。
- 标记重跑构建。按“提交哈希+流水线配置”分组排序，对首次构建之后由失败或中断引发的同组构建打上重跑标记；已有重跑标记的，与推导结果交叉核对，差异记录原因。
- 计算分子分母并处理分母为零。分子为重跑构建次数，分母为窗口内全部构建次数，相除后乘以100%。分母为零时不输出比率，标注“本周期无构建”，改用绝对次数描述。
- 按失败类型分组统计。对失败构建按编译、测试、环境、依赖、配置等类别计数，计算各类别占失败总数的比例，并单独统计重跑构建的失败原因分布。
- 与上一周期对比形成趋势。用相同口径计算上一周期的重跑率与失败率，计算差值或环比，连续多个周期的变化方向比单点数值更有参考价值。
当团队已经把流水线接入研发管理平台，构建记录与需求、迭代的关联可以让取数更顺畅。以 ONES DevOps 解决方案为例，集成 Jenkins、GitLab CI 等第三方流水线工具后，平台会同步流水线数据、执行状态和日志，并在项目、迭代、需求中展示代码提交、流水线构建和产品发布过程。这样在按流水线范围取数时，可以直接以项目或迭代为边界筛选构建记录，减少手工对齐口径的工作；报表能力的具体指标项和字段口径仍需按团队实际配置确认。
例子：一个两周窗口的完整算例
以下为演示情景，数字用于说明计算过程，不代表任何团队的实际水平。某团队统计两周窗口内主干分支的提交触发构建，共记录构建总次数 480 次，其中失败构建 96 次，被标记为重跑的构建 60 次。
- 构建重跑率 = 60 ÷ 480 × 100% = 12.5%
- 构建失败率 = 96 ÷ 480 × 100% = 20.0%
对 96 次失败构建按类型归类：编译失败 18 次，测试失败 42 次，环境问题 21 次，依赖拉取失败 9 次，配置错误 6 次。对应占比分别为 18.8%、43.8%、21.9%、9.4%、6.3%。进一步看 60 次重跑的失败原因，若其中 30 次集中在测试失败，说明重跑主要发生在测试环节，可以优先检查用例稳定性和测试环境隔离，而不是全面改造流水线。
分母为零或样本过少时，处理方式要写进口径说明。若某周窗口内构建次数为 0，重跑率一栏留空并标注“无构建”；若构建次数少于 30 次，比率波动大，建议同时给出绝对次数，并在报表中标注“样本不足，仅供参考”，避免用一个小样本比率下结论。
解读与限制：怎么判断是否要专项治理
重跑率高而失败率低，常见原因包括环境抖动、缓存未命中、偶发失败的测试用例，以及重跑规则被放宽到“只要不是一次通过就重跑”。这类情况下，重跑次数上升并不完全对应代码质量问题，需要结合重跑原因分布定位。反过来，失败率高但重跑率低，可能说明团队在失败后直接排查修复，或者重跑需要人工审批，恢复成本体现在等待时间而非重跑次数上。
单指标不能作为因果保证。重跑率反映的是重复执行的比例，不能直接推出“构建质量差”或“流程有问题”，也不能单独用来评价某个团队。判断是否启动专项治理，建议同时满足以下条件中的两项以上：重跑率连续两到三个统计周期上升；失败类型集中在少数类别且占比明显偏高；重跑已经影响主干合并或发布节奏，例如主干构建排队时间明显拉长。触发治理后，先按失败类型分布确定优先处理的环节，再设定下一周期的观察目标。
指标口径变更时，例如新增纳入的流水线、调整触发方式范围或修改重跑识别规则，应在报表中标注变更时间点，跨口径的两个周期不做直接环比，可以分别计算后再说明差异来源。这样既保留了历史数据的参考价值，也避免把口径变化误读为质量变化。
常见问题
同一提交因为流水线配置调整又跑了一次，算重跑吗？
建议不算。重跑的识别口径是“同一提交哈希、同一流水线配置下，因失败或中断而再次触发的构建”。配置调整后，构建的输入条件已经变化，把它计入重跑会高估重跑率。实际操作中可以把配置版本作为分组键的一部分，配置变更前后的构建分属不同组，并在口径说明里记录配置生效时间。
定时构建和手动构建要不要计入重跑率的分母？
两种做法都可以，关键是固定下来并在报表中注明。定时构建多用于夜间全量验证，手动构建多用于临时排查，它们与代码提交触发的构建性质不同。如果混在一起统计，提交频率低但定时任务多的团队重跑率会被稀释。更清晰的做法是单列这两类构建，或者明确排除，并保证多个统计周期使用同一口径。
重跑率高但失败率不高，需要马上治理吗？
先定位原因再决定。重跑率高而失败率平稳，常见原因是环境抖动、缓存未命中、偶发失败的测试用例，或者重跑规则被放宽到“只要不是一次通过就重跑”。这时可以看重跑构建的失败原因分布，如果集中在少数类别，先处理对应环节；如果分散且没有明显集中，优先检查重跑触发规则是否过宽，暂不启动全面治理。
统计窗口内构建次数很少，重跑率还能用吗？
可以用，但要谨慎解读。构建次数少于 30 次时，比率受单次构建影响很大，一周多跑两次就可能让重跑率跳好几个百分点。建议同时给出重跑次数和构建总次数的绝对数字，并在报表中标注“样本不足，仅供参考”。判断趋势时，可以拉长窗口或合并多个周期，让样本量达到可比较的水平。
用ONES管理流水线数据，能直接拿到重跑率吗？
ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、执行状态和日志，并在项目、迭代、需求中展示代码提交、流水线构建和产品发布过程。平台支持多种数据报表，可用于集中度量和分析研发过程。至于是否内置重跑率、失败率、失败类型分布等具体指标及其字段口径，需要按团队实际配置确认，取数前建议先核对同步字段是否覆盖提交哈希、触发方式、构建结果和失败原因。
