流水线执行记录能算哪些交付效率与稳定性指标

流水线执行记录能直接支撑两类指标：交付效率看构建与部署是否顺畅、时间花在哪一段；稳定性看执行是否可靠、失败后恢复多快。真正影响结果的是口径——统计哪条流水线、哪些分支和环境，一次执行怎么算，分母取全部还是有效执行。口径不统一，同一份记录会算出不同数值。本文给出可复算的指标定义、计算步骤与解读限制，适用于交付效能复盘和看板设计。

要点总览（TL;DR）

• 流水线执行记录可派生两类指标：效率类包括构建频次、提交到构建成功时长、构建成功到部署间隔、部署频次和流水线段变更前置时间；稳定性类包括执行成功率、失败重跑率、平均恢复时长、失败按阶段分布和回滚占比。
• 计算前先固定统计对象（流水线、分支、环境）、时间窗、事件定义和分母，否则同一份记录会算出不同数值。
• 执行成功率的分母应使用剔除取消和跳过后的有效执行次数，分母为零时输出“无样本”而非0%。
• 时长类指标建议同时给出中位数和P90，并标注样本量与缺失值处理方式。
• 指标反映流程执行表现，不能单独作为质量或绩效结论；不同流水线、分支和环境的记录不宜直接横向比较。

复盘和看板要回答什么问题

指标选择应从复盘要做的判断出发，而不是先把能算的都算一遍。交付效能复盘通常围绕两类问题展开：效率类关注交付快不快、卡在哪一段，例如构建是否频繁、从提交到构建成功要等多久、构建成功后多久才部署；稳定性类关注交付稳不稳、失败后恢复多快，例如执行成功率高低、失败是否集中在某个阶段、回滚是否频繁。两类问题对应不同的指标族，混在一起看容易得出模糊结论。

复盘与看板是两种用途，取数粒度不同。复盘面向一次或一段时间的回顾，需要按流水线、分支、环境拆开看分布和趋势，样本量可以小但要标注清楚；看板面向持续监控，需要固定时间窗和统计对象，按天或按周滚动更新，重点是异常能否被及时发现。同一指标在两种场景下的时间窗、聚合方式和告警阈值应分别设定。

下表把常见评估问题与指标族、使用场景对应起来，可作为选指标的起点。

评估问题	对应指标族	典型使用场景
构建与部署是否足够频繁	效率类：构建频次、部署频次	看板监控交付节奏；复盘判断是否存在批量积压
从提交到可部署卡在哪一段	效率类：提交到构建成功时长、构建成功到部署间隔、流水线段变更前置时间	复盘定位等待环节；看板观察时长趋势
流水线执行是否可靠	稳定性类：执行成功率、失败重跑率	看板监控异常波动；复盘分析失败原因
失败后恢复是否及时	稳定性类：平均恢复时长、失败按阶段分布	复盘评估响应机制；看板设置恢复时长提醒
交付是否频繁回退	稳定性类：回滚占比	复盘评估变更风险；看板观察回滚趋势

本文只讨论流水线执行记录本身能派生的指标。发布审批规则、质量门禁配置以及流水线与外部平台的对接方式属于另外的话题，不在计算口径范围内。

从执行记录能派生的效率与稳定性指标

下面给出十个指标的定义、公式、分母、时间窗与单位。所有指标都按流水线、分支、环境三个维度切分统计，同一指标在不同维度下的数值不可混用。时间窗需在报表中明确写出，例如“最近 30 个自然日”或“最近 20 次执行”，二者结果不同。

效率类指标

指标	定义与公式	分子	分母	单位
构建频次	时间窗内有效执行次数 ÷ 时间窗天数	有效执行次数	统计天数	次/天
提交到构建成功时长	构建成功时间 − 关联提交时间，取中位数或 P90	每次成功执行的时长	纳入统计的成功执行次数	分钟或小时
构建成功到部署间隔	部署时间 − 对应构建成功时间，取中位数	每次部署的间隔时长	纳入统计的部署次数	分钟或小时
部署频次	时间窗内部署次数 ÷ 时间窗天数	部署次数	统计天数	次/天
流水线段变更前置时间	部署完成时间 − 首次关联提交时间，取中位数	每次变更的时长	纳入统计的变更数	小时或天

时长类指标建议同时给出中位数和 P90。中位数反映典型体验，P90 反映长尾等待，两者差距大说明存在少数特别慢的执行，值得单独排查。构建频次和部署频次的分母是统计天数，不是执行次数，这一点在跨周期比较时尤其要写清楚。

稳定性类指标

指标	定义与公式	分子	分母	单位
执行成功率	成功执行次数 ÷ 有效执行次数	成功执行次数	有效执行次数（剔除取消、跳过）	百分比
失败重跑率	发生重跑的失败执行次数 ÷ 失败执行次数	重跑的失败执行次数	失败执行次数	百分比
平均恢复时长	恢复成功时间 − 首次失败时间，取平均值或中位数	每次失败到恢复的时长	纳入统计的失败事件数	分钟或小时
失败按阶段分布	各阶段失败次数 ÷ 失败总次数	某阶段失败次数	失败总次数	百分比
回滚占比	回滚部署次数 ÷ 部署总次数	回滚次数	部署总次数	百分比

执行成功率的分母用有效执行而非全部执行，是口径上的关键选择。若把取消和跳过计入分母，成功率会被系统性拉低，且不同团队的手动取消习惯不同，横向比较会失真。失败重跑率的分母是失败执行次数，用于观察失败后是否倾向重试而非修复；重跑本身既可能是偶发环境问题，也可能掩盖真实缺陷，需要结合失败阶段分布一起看。

数据口径与证据要求

指标可复算的前提是执行记录字段完整。取数前应确认流水线平台能提供以下字段：执行 ID、触发方式（自动、手动、定时）、触发人、开始时间与结束时间、各阶段与步骤的结果状态、关联的提交或变更标识、目标环境。缺少结束时间会导致时长类指标无法计算，缺少触发方式则无法区分手动触发对频次和成功率的影响。

事件定义需要在计算前写成文字规则，常见定义如下：

• 一次执行：流水线一次完整运行，以执行 ID 唯一标识。
• 一次有效执行：状态为成功或失败、且实际运行了构建或部署步骤的执行，剔除取消、跳过和重复触发。
• 一次部署：将构建产物发布到目标环境的动作，需与执行记录中的部署阶段或部署事件对应。
• 一次变更：从首次关联提交到部署完成的一组执行，用于计算变更前置时间。

证据留存方面，原始执行日志、状态流转记录、重跑与取消记录都应可回溯，至少保留一个统计周期以上，便于抽样核对。数据来源以流水线平台自身记录为准；当团队同时使用多个平台时，需先统一字段名称、时间格式和状态取值，再合并统计，否则同名指标在不同平台间含义可能不同。

计算与评估步骤

从原始记录到可用指标，建议按五步执行，每步留下可检查的中间结果。

1. 清洗：剔除取消、跳过和重复触发的执行，给重跑执行打标记并保留与原执行的关联关系。清洗规则要写成文档，避免不同人处理方式不一致。
2. 归类：按流水线、分支、环境、时间窗四个维度分组。分组粒度决定后续能否定位问题，建议至少保留到环境和分支两级。
3. 计算：按第二节公式求值，逐项记录分母。分母为零时输出“无样本”，不输出 0% 或 0 次，避免被误读为表现良好。
4. 校验：抽取若干执行，比对原始日志中的开始结束时间与计算结果，检查时长字段缺失、跨时区记录和时钟偏差。发现缺失值时说明处理方式，例如剔除或按同流水线中位数填补，并标注填补比例。
5. 输出：每个指标值同时给出样本量、统计窗口和统计对象。样本量过小时在报表中加注，不据此下结论。

校验环节容易被跳过，但它决定了指标能否被信任。一次抽样比对通常只需十几条记录，却能发现字段映射错误或状态定义不一致这类系统性问题。

一个可复算的例子

假设某流水线在最近 30 天内共有 120 次执行记录，其中成功 96 次、失败 18 次、取消 6 次；18 次失败中有 5 次在当天重跑并成功。按前述口径计算：

• 有效执行次数 = 120 − 6 = 114 次。
• 执行成功率 = 96 ÷ 114 ≈ 84.2%。若误用全部执行作分母，则为 96 ÷ 120 = 80.0%，两者相差 4.2 个百分点。
• 失败重跑率 = 5 ÷ 18 ≈ 27.8%，表示近三成失败通过重跑处理。
• 构建频次 = 114 ÷ 30 ≈ 3.8 次/天。

时长类指标以提交到构建成功时长为例。假设 96 次成功执行中有 90 次能匹配到关联提交时间，6 次因提交信息缺失无法计算。将这 90 个时长排序后取中位数，得到 42 分钟；P90 为 3 小时 10 分。报表中应写明“样本 90 次，缺失 6 次未纳入”，而不是直接给出一个没有样本说明的数值。若某分支在时间窗内只有 2 次成功执行，中位数意义有限，应标注“样本不足，仅供参考”，或改用更长的时间窗。

分母为零的情形同样需要明确标注。例如某环境在统计期内没有部署记录，回滚占比的分母为零，此时输出“无部署样本”，而不是 0%。

解读指标时的口径限制

指标数值受统计规则影响很大，解读时需逐项核对口径。取消和跳过会改变成功率的分母；手动触发会抬高执行次数但不一定代表交付节奏；重跑会同时影响成功率和恢复时长，若把重跑后的成功直接计入成功率，会高估流水线的首次通过能力。这些处理方式没有绝对对错，但必须在报表中写明，且同一指标在不同周期保持同一规则。

不同流水线、分支和环境之间的记录不宜直接横向比较。主干分支的构建频次天然高于特性分支，生产环境部署次数远少于测试环境，直接对比会得出误导性结论。需要比较时，应先确认统计对象、时间窗和事件定义一致，再讨论差异。

样本量小和时间窗过短会导致指标剧烈波动。一周内只有几次执行的流水线，成功率在 50% 与 100% 之间跳变属于正常现象，不宜据此判断改进或退步。建议为每个指标设定最小样本量，低于阈值时只展示原始记录，不展示比率。

这些指标反映的是流程执行表现，不能单独作为质量结论或绩效结论。成功率高不代表缺陷少，部署频次高也不代表价值交付多。跨平台合并统计时，字段定义和状态取值的差异会进一步削弱可比性，合并前应做字段映射说明。

把指标落到复盘与看板

看板建议按效率与稳定性两组分区展示，每个指标卡片标注统计窗口、统计对象和样本量。效率区放构建频次、部署频次和两个时长指标，稳定性区放执行成功率、失败重跑率、平均恢复时长和回滚占比。失败按阶段分布适合用堆叠图呈现，便于一眼看出失败集中在哪个环节。

复盘时先看趋势和分布，再定位具体阶段。例如发现某分支执行成功率连续两周下降，先看失败按阶段分布是否集中在测试阶段，再抽取该阶段的失败日志确认原因。异常指标应转为改进事项，写明责任人、预期动作和验证时间，下次复盘时回看是否改善。

指标口径说明、复盘记录和改进跟踪需要有承载的地方，否则口径容易在人员变动后丢失。ONES 可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，并将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程；ONES Performance 提供交付效率、交付质量等维度的效能度量体系与仪表盘模板。团队可以把指标口径文档、复盘结论和改进工作项放在同一处，让口径与结论可追溯。具体可同步的字段范围和预置指标模板，以实际集成配置和官方说明为准。

常见问题

取消和跳过的执行记录应该计入成功率的分母吗？

建议不计入。执行成功率的分母使用有效执行次数，即状态为成功或失败、且实际运行了构建或部署步骤的执行，剔除取消、跳过和重复触发。若把取消和跳过计入分母，成功率会被系统性拉低，而不同团队的手动取消习惯不同，横向比较会失真。具体剔除规则应写成文档，并在同一指标的各个统计周期保持一致。

重跑后的成功应该算作首次成功吗？

这取决于你要回答的问题。如果关注流水线的首次通过能力，重跑后的成功不应直接计入成功率，否则会高估稳定性；如果关注最终交付是否完成，可以把重跑结果纳入。无论采用哪种口径，都应在报表中写明，并配合失败重跑率一起看。重跑率偏高既可能是偶发环境问题，也可能掩盖真实缺陷，需要结合失败按阶段分布进一步定位。

统计窗口选多长比较合适？

没有统一标准，取决于执行频率和复盘目的。看板监控通常按天或按周滚动更新，复盘可以按一个迭代或最近30个自然日统计。关键是每个指标都标注统计窗口和样本量，并设定最小样本量阈值。一周内只有几次执行的流水线，成功率在50%与100%之间跳变属于正常波动，低于阈值时建议只展示原始记录，不展示比率。

多个流水线平台的数据可以合并统计吗？

可以合并，但需要先做字段映射。不同平台对状态取值、时间格式、触发方式的定义可能不同，直接合并会让同名指标含义不一致。合并前应统一字段名称和状态取值，写清映射规则，并保留原始记录以便回溯。跨平台合并后的指标可比性会进一步削弱，解读时应说明数据来源和映射方式。

这些指标能直接用于团队绩效评估吗？

不建议单独使用。执行成功率、部署频次等指标反映的是流程执行表现，成功率高不代表缺陷少，部署频次高也不代表价值交付多。用于绩效评估容易诱导团队调整触发方式或规避记录，反而损害数据质量。更合适的做法是把指标作为复盘和改进的输入，异常指标转为改进事项，记录责任人和验证时间，关注趋势是否改善。