流水线执行记录能支撑两类指标：效率类看排队与执行时长、从提交到可部署产物的周期、部署频率；稳定性类看执行成功率、失败恢复时长、重跑与回滚比例、变更失败率。这些指标的计算前提是先固定统计对象、时间窗、分母和失败判定规则，否则同一份记录会得出不同结论。下面按复盘和看板设计的使用顺序，给出字段来源、计算公式、口径陷阱和一个可复算的示例。
要点总览（TL;DR）
- 流水线执行记录可派生两类指标：效率类包括构建排队时长、执行时长、端到端交付周期、部署频率与部署间隔；稳定性类包括执行成功率、失败恢复时长、重跑率、回滚率与变更失败率。
- 计算前先固定统计对象（流水线、分支、环境）、时间窗、分母和失败判定规则，同一份记录在不同口径下会得出不同结论。
- 成功率的分母要明确是否包含取消、跳过和手动触发；重跑率按执行次数与按提交去重回答的是不同问题，需选定一种并保持一致。
- 样本过少或分母为零时标注“样本不足”，改用绝对次数或延长观察窗口，不输出比率结论；跨流水线、分支、环境的数据分组呈现后再比较。
- 指标用于趋势观察与流程改进，效率与稳定性应成对解读，复盘结论转成可跟踪的工作项，下一轮用同一口径复算验证。
复盘和看板要回答哪几个问题
指标选择应先从问题出发。交付效能复盘通常要回答“这段时间交付节奏有没有变化、变化发生在哪一环”，看板则要回答“当前哪些流水线在拖慢或阻断交付”。两类场景对粒度的要求不同：复盘可以按周或按迭代聚合，允许较粗的分组；看板需要按流水线、分支、环境细分，并能下钻到单次执行。
把问题、指标方向和使用场景对应起来，可以避免堆指标：
| 要回答的问题 | 指标方向 | 主要使用场景 | 建议粒度 |
|---|---|---|---|
| 交付节奏是否加快或变慢 | 部署频率、部署间隔、端到端交付周期 | 迭代或月度复盘 | 按周/迭代聚合，按流水线分组 |
| 时间花在等待还是执行 | 构建排队时长、执行时长 | 复盘定位瓶颈、看板监控 | 按流水线与阶段拆分 |
| 流水线是否可靠 | 执行成功率、重跑率 | 看板日常监控 | 按流水线、分支、环境分组 |
| 失败后恢复是否及时 | 失败恢复时长、回滚率 | 复盘评估改进效果 | 按失败事件聚合 |
| 变更是否带来额外风险 | 变更失败率 | 复盘与发布节奏评估 | 按部署批次或环境统计 |
这些指标用于观察趋势、定位流程问题和支持改进决策。把它们直接当作个人或团队的排名依据，会诱导规避记录（例如减少手动触发、拆分流水线），使数据失真。复盘结论应落到具体环节的改进动作上，而不是停留在数值高低。
从执行记录能取到哪些字段
流水线执行记录一般以“一次执行”为一条记录，常见字段包括：触发方式（提交触发、定时触发、手动触发）、关联的提交标识与分支、开始与结束时间、执行状态（成功、失败、取消、跳过）、阶段与步骤明细、目标环境、是否为重跑。这些字段多数属于原始记录，可以直接用于计数和计时。
另一些指标需要跨系统关联：端到端交付周期需要把代码提交时间与产出可部署产物的时间对齐，提交时间通常来自代码库，产物时间来自流水线或制品库；变更失败率需要把部署记录与后续的故障或回滚事件关联；部署频率需要发布系统提供部署完成时间。关联键一般是提交标识、构建号或发布单号，关联质量直接决定指标可信度。
| 字段 | 来源 | 可派生指标 |
|---|---|---|
| 触发方式 | 执行记录原始字段 | 成功率分母界定、手动触发占比 |
| 提交标识、分支 | 执行记录，必要时关联代码库 | 按分支分组、重跑去重、交付周期起点 |
| 开始/结束时间 | 执行记录原始字段 | 排队时长、执行时长、失败恢复时长 |
| 状态 | 执行记录原始字段 | 成功率、失败次数、取消与跳过统计 |
| 阶段与步骤 | 执行记录原始字段 | 阶段耗时分布、瓶颈定位 |
| 目标环境 | 执行记录，必要时关联发布系统 | 按环境分组、部署频率、变更失败率 |
| 重跑标记 | 执行记录，或按提交标识推断 | 重跑率、成功率去重口径 |
| 部署完成时间 | 发布系统或制品库 | 部署频率、端到端交付周期终点 |
字段缺失时指标可以降级为近似口径，但要在看板上标注。例如没有独立的排队开始时间，只能用“触发时间到执行开始时间”近似排队时长；没有重跑标记，只能按同一提交标识的多次执行推断重跑；没有发布系统时间，端到端周期只能截到“产出制品”而非“部署完成”。降级口径适合趋势观察，不适合与其他口径的数据直接比较。
效率与稳定性指标的计算口径
下表给出每个指标的定义、公式、分母、时间窗与单位。统计对象默认是“某条流水线在某分支上、面向某环境的执行”，实际使用时按复盘范围替换，并在报表上写明。
| 指标 | 定义与公式 | 分母/样本 | 时间窗与单位 |
|---|---|---|---|
| 构建排队时长 | 执行开始时间 − 触发时间，取均值或中位数 | 时间窗内全部有效执行 | 按周或迭代，分钟 |
| 执行时长 | 执行结束时间 − 执行开始时间，取均值或中位数 | 时间窗内全部有效执行，可按阶段拆分 | 按周或迭代，分钟 |
| 端到端交付周期 | 可部署产物产出时间 − 对应提交时间，取中位数 | 时间窗内进入部署的提交 | 按周或迭代，小时或天 |
| 部署频率 | 时间窗内部署成功次数 ÷ 时间窗天数 | 按环境统计的部署成功记录 | 每日或每周，次/天 |
| 部署间隔 | 相邻两次部署成功时间差的均值或中位数 | 时间窗内相邻部署对 | 按周或迭代，小时 |
| 执行成功率 | 成功执行次数 ÷ 有效执行次数 × 100% | 有效执行次数，需明确是否含取消、跳过、手动触发 | 按周或迭代，百分比 |
| 失败恢复时长 | 恢复成功的执行结束时间 − 首次失败执行结束时间，取中位数 | 时间窗内已恢复的失败事件 | 按周或迭代，小时 |
| 重跑率 | 重跑执行次数 ÷ 总执行次数 × 100%，或按提交去重后统计 | 总执行次数或去重提交数 | 按周或迭代，百分比 |
| 回滚率 | 回滚次数 ÷ 部署成功次数 × 100% | 部署成功次数 | 按周或迭代，百分比 |
| 变更失败率 | 导致失败或回滚的部署次数 ÷ 部署总次数 × 100% | 部署总次数，需定义“导致失败”的判定窗口 | 按周或迭代，百分比 |
几个口径细节需要提前写进报表说明。成功率的分母要明确是否包含取消和跳过的执行：取消多为人为中断，跳过多为条件不满足，二者与真实失败性质不同，混入分母会压低成功率。重跑率按执行次数统计会放大频繁重跑流水线的影响，按提交去重则更接近“一次变更需要跑几次才能通过”的含义，两种口径回答的问题不同，选一种并保持一致。失败恢复时长是 MTTR 的近似口径，只覆盖“流水线层面恢复”，不覆盖线上故障的完整修复过程。变更失败率的判定窗口要事先约定，例如部署后 24 小时内出现回滚或关联故障即计入，窗口不同结果不可比。
口径限制：哪些地方最容易算错
分母为零和样本过少是最常见的失真来源。某个环境一周只部署两次，成功率可能是 100% 或 50%，波动完全由单次事件决定。处理方式是标注“样本不足”，改用绝对次数呈现，或延长观察窗口到样本足够；比率类指标在样本低于约定阈值时不出结论。
不同流水线、分支、环境之间不能直接横向比较。主干分支的流水线执行频繁、失败容忍度低，特性分支的流水线可能只跑部分阶段；预发环境与生产环境的部署频率天然不同。比较前应统一统计对象和失败判定规则，或分组呈现，避免把“环境差异”读成“团队差异”。
重跑、取消、跳过和手动触发会显著改变成功率。失败后重跑成功，如果按执行次数统计，成功率被抬高；如果按提交去重统计，则反映首次通过情况。手动触发往往用于补救，计入常规执行会拉低或拉高成功率。建议在报表中同时给出“含重跑”和“去重”两个口径，或至少注明采用哪一种。
时间对齐也容易出错。跨系统关联时，代码库、流水线、发布系统的时钟和时区可能不一致，跨天统计会出现记录落到错误日期的情况。统一使用同一时区并校验关键时间戳的先后关系（提交时间应早于执行开始时间），可以提前发现异常记录。
最后，单个指标不能直接推出因果或绩效结论。执行时长下降可能来自缓存命中，也可能来自跳过了测试阶段；成功率上升可能来自减少了覆盖范围。指标应成对观察，并结合阶段耗时、测试覆盖等过程数据解释，再决定改进动作。
一个可复算的计算示例
以下为演示情景，数据仅用于说明计算过程，不代表任何团队的真实水平或达标线。假设统计某流水线在某一周（7 天）内面向预发环境的执行记录，共 20 次执行：成功 14 次，失败 4 次，取消 1 次，跳过 1 次；其中失败后有 3 次通过重跑成功，重跑执行共 5 次；该周部署成功 6 次，发生回滚 1 次。
执行成功率（含取消与跳过）：14 ÷ 20 × 100% = 70%。若分母只计有效执行（排除取消和跳过）：14 ÷ 18 × 100% ≈ 77.8%。两个口径差异明显，报表需注明采用哪一个。
重跑率：按执行次数为 5 ÷ 20 × 100% = 25%；若按提交去重，假设这 5 次重跑对应 3 个提交，则去重口径为 3 ÷ 18 × 100% ≈ 16.7%。
平均执行时长：假设 20 次执行总时长为 640 分钟，均值为 32 分钟；其中 4 次失败执行平均 12 分钟，成功执行平均约 37.7 分钟。只看总均值会低估成功路径的实际耗时，按状态分组更有解释力。
失败恢复时长：3 次失败事件从首次失败结束到重跑成功结束分别间隔 2 小时、5 小时、11 小时，中位数为 5 小时。第 4 次失败未恢复，不计入该指标，但应在报表中单独列出未恢复次数。
回滚率：1 ÷ 6 × 100% ≈ 16.7%。若该周部署总次数为 7 次（含 1 次失败部署），变更失败率则为 (1 次回滚 + 1 次失败部署) ÷ 7 × 100% ≈ 28.6%，具体是否把失败部署计入取决于事先约定的判定规则。
样本不足的处理示例：若把统计范围缩小到某个特性分支，该周只有 2 次执行、1 次失败，成功率为 50%。此时应标注“样本不足（n=2）”，只报告“2 次执行中 1 次失败”，不输出比率结论。
结果怎么解读、怎么落到看板
解读时以趋势为主。单周的部署频率或成功率受发布计划、节假日和偶发故障影响，连续四周以上的走向更能说明流程是否改善。效率与稳定性要成对看：部署频率上升同时变更失败率上升，说明节奏加快可能以质量为代价；执行时长下降同时重跑率上升，说明节省的时间可能被反复重跑抵消。
看板建议分三层呈现：第一层是趋势概览，按周展示部署频率、成功率、端到端交付周期中位数；第二层按流水线、分支、环境分组，标出偏离自身历史区间的项；第三层下钻到单次执行，查看阶段耗时、失败步骤和重跑记录。每层都标注统计口径、时间窗和样本量，样本不足的项显示绝对次数。
复盘结论需要转成可跟踪的工作项，否则指标只停留在报表上。常见做法是把“某阶段排队时长偏高”“某流水线重跑率连续上升”写成改进任务，指定负责人和验证时间，下一轮复盘时用同一口径复算验证效果。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志；在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程，便于把执行记录与需求、迭代关联起来查看。ONES 效能管理提供交付效率、交付质量等维度的度量分析能力，可将复盘结论落到工作项跟踪，形成从度量到改进的闭环。具体可用的预置指标和报表模板，以实际配置为准。
常见问题
成功率的分母到底该不该包含取消和跳过的执行？
取决于你想回答的问题，但必须在报表上写明并长期保持一致。取消多为人为中断，跳过多为条件不满足，二者与真实失败性质不同。若目标是衡量流水线本身的可靠性，建议分母只计有效执行，排除取消和跳过；若目标是观察整体执行负担和人工干预频率，可以把它们计入，但应同时单独列出取消与跳过的次数，避免读者误读。
两种口径的数值差异可能很大。演示情景中 20 次执行含 1 次取消、1 次跳过，含取消跳过的成功率为 70%，只计有效执行约为 77.8%。切换口径时应在看板上标注变更时间，避免前后趋势被口径变化污染。
重跑率按执行次数算还是按提交去重算，哪个更适合复盘？
两者回答的问题不同。按执行次数统计反映流水线的总执行负担，频繁重跑的流水线会被放大；按提交去重统计更接近“一次变更需要跑几次才能通过”，适合评估变更本身的通过质量。复盘时如果关注资源消耗和排队压力，用执行次数口径；如果关注代码变更质量与测试稳定性，用去重口径。
实际操作中可以两个都算，但要在报表中并列呈现并注明定义。只保留一个口径时，需保证历史数据用同一规则重算，否则趋势对比会失真。
某个环境一周只部署两三次，指标波动很大，怎么处理？
先设定样本阈值，例如比率类指标在样本低于约定数量时不出结论。低于阈值时改用绝对次数呈现，如“本周 3 次部署中 1 次回滚”，并标注样本量；也可以延长观察窗口到月度或季度，让样本积累到可比较的量级。
不要用低样本的比率做跨团队或跨环境比较。预发环境与生产环境的部署频率天然不同，分组呈现比强行拉平更可靠。
执行记录里缺少排队开始时间或重跑标记，指标还能算吗？
可以降级为近似口径，但要在看板上标注。没有独立排队开始时间时，用触发时间到执行开始时间近似排队时长；没有重跑标记时，按同一提交标识的多次执行推断重跑；没有发布系统时间时，端到端周期只能截到产出制品，无法覆盖部署完成环节。
降级口径适合观察自身趋势，不适合与其他口径的数据直接比较。若需要跨团队对比，应先补齐关联字段或统一采用同一种降级规则。
复盘得出的指标异常，怎么保证改进真的落地？
把结论转成可跟踪的工作项是关键一步。常见做法是把“某阶段排队时长偏高”“某流水线重跑率连续上升”写成改进任务，指定负责人和验证时间，下一轮复盘用同一口径复算，对比改进前后的数值。
ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，可在项目、迭代、需求中查看代码提交、流水线构建和产品发布过程；ONES 效能管理提供交付效率、交付质量等维度的度量分析能力，便于把复盘结论落到工作项跟踪。具体可用的预置指标和报表模板以实际配置为准。
