评估流水线阶段划分是否合理，可以从阶段等待时间、重复执行和跨阶段返工三类指标入手交叉判断：等待时间占比反映交接与排队是否过长，重复执行率反映同一阶段是否被反复触发，跨阶段返工率反映缺陷或变更是否在阶段之间来回流动。三类指标需要统一时间窗、分母和流水线范围后再比较，单看某一项不能证明划分优劣。
要点总览（TL;DR）
- 评估阶段划分是否合理，可用阶段等待时间占比、重复执行率、跨阶段返工率三类指标交叉判断，单看一项不能证明优劣。
- 阶段等待时间占比＝阶段间等待总时长÷流水线端到端总时长；重复执行率＝同一提交在同一阶段的重复触发次数÷该阶段总触发次数；跨阶段返工率＝发生跨阶段回流的缺陷或变更数÷同期进入该范围的缺陷或变更总数。
- 计算前统一时间窗、分母和流水线范围，主动取消与基础设施故障记录单列，不混入分母。
- 等待时间长先区分人工等待与资源排队，重复执行高先排查环境与测试数据，跨阶段返工需区分需求变更与质量缺陷。
- 不设通用达标线，阈值结合团队历史基线与业务节奏确定，指标用于定位问题与验证调整效果。
评估目标：阶段划分要回答哪三个问题
阶段划分评估的判断对象是阶段边界与交接点，包括每个阶段负责什么、在哪个节点把产物交给下一阶段、交接前需要满足什么条件。流水线工具本身的性能、界面和插件生态属于另一类问题，不纳入本次评估。把“划分是否合理”落到可回答的问题上，可以拆成三个方向。
第一个问题是阶段间等待是否过长。一个提交从进入流水线到完成部署，中间有多少时间花在阶段之间的排队和交接上，而不是花在实际执行上。第二个问题是阶段内是否反复重跑。同一份提交在同一阶段被多次触发，说明该阶段的输入、环境或脚本存在不稳定因素，阶段边界没有起到稳定过滤的作用。第三个问题是缺陷是否在阶段之间来回返工。测试阶段发现的问题回流到构建或开发阶段，修复后再次进入测试，这类跨阶段流动的次数和路径，直接反映阶段职责划分与准入条件是否清晰。
三个问题对应三类调整动作：等待时间集中在某两个阶段之间，考虑合并阶段或减少人工审批节点；重复执行集中在某一阶段，考虑拆分该阶段的职责或先稳定其运行环境；跨阶段返工集中在某条路径上，考虑把部分检查前移，或在交接点补充准入条件。评估结论的用途是调整阶段粒度、合并或拆分阶段、优化交接与准入，而不是给团队排绩效名次。
指标与范围：三类指标的定义与统计边界
三类指标各自回答一个独立问题，定义时需要把统计对象、计量单位和边界条件写清楚，否则不同流水线、不同时间段的数值无法放在一起比较。下表给出定义框架。
| 指标 | 统计对象 | 计量方式 | 边界说明 |
|---|---|---|---|
| 阶段等待时间 | 相邻两个阶段之间的排队与交接时长 | 时长，汇总后以占比呈现 | 需区分人工等待（审批、确认）与资源排队（执行机不足、并发受限） |
| 重复执行 | 同一提交在同一阶段被多次触发的次数 | 次数，按原因分类 | 区分自动重试与人工重跑，记录触发来源 |
| 跨阶段返工 | 缺陷或变更在阶段之间回流的次数与路径 | 次数与路径，汇总为比率 | 需关联缺陷单或变更单与阶段流转记录 |
统计范围需要事先固定：纳入哪些流水线、哪些分支、哪个时间窗、以提交还是以流水线运行次数为口径。建议以提交为口径统计重复执行与返工，以流水线运行记录为口径统计等待时间，并在报告中写明口径，避免同一份数据被两种方式重复计数。
排除项要单列。主动取消的运行、因基础设施故障中断的执行、因发布计划变更而撤回的提交，都不应混入重复执行或返工的分母，否则偶发事件会扭曲指标。这些记录可以单独统计为“异常执行”，作为环境稳定性的参考，但不参与阶段划分的判断。
数据口径与证据：从流水线记录中取哪些字段
指标要可复算，前提是流水线记录中保留了足够的字段。评估前先核对数据是否齐全，缺什么字段就调整口径，而不是用估算值填充。
- 阶段开始时间与结束时间：用于计算各阶段执行时长和阶段间间隔。
- 阶段间交接时间戳：上一个阶段结束到下一个阶段开始之间的时间点，用于拆分等待时间。缺少该字段时，可以用相邻阶段的时间差近似，但需在报告中注明替代口径。
- 触发原因与触发来源：区分代码提交触发、定时触发、人工重跑、自动重试，这是重复执行分类的基础。
- 执行结果：成功、失败、取消、超时，用于确定哪些运行进入分母。
- 关联提交标识：把同一提交的多次运行归并到一起。
- 关联缺陷单或变更单：用于识别跨阶段返工，并记录回流路径。
数据缺失时的处理方式要写进评估说明：字段缺失的阶段不参与该指标计算，或改用可获得的替代字段并标注；不同流水线字段粒度不一致时，先统一到可比的粒度再汇总，无法统一的单独列出，不强行合并。评估报告应保留原始记录的可追溯入口，便于他人复核计算结果。
当流水线数据与需求、缺陷、变更记录分散在不同系统时，关联字段的完整性决定了跨阶段返工能否被识别。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步编排的流水线数据、执行状态和日志，并在项目、迭代、需求中呈现代码提交、流水线构建与产品发布过程。这类关联数据为按提交归并运行记录、按需求追溯返工路径提供了基础；阶段级时间戳与触发原因字段的粒度，需要在集成配置时确认。
计算与评估步骤：公式、分母与时间窗
三类指标的计算规则如下表。所有比率均以百分比表示，计算前先确定时间窗和分母范围，同一份报告内保持一致。
| 指标 | 公式 | 分母说明 |
|---|---|---|
| 阶段等待时间占比 | 阶段间等待总时长 ÷ 流水线端到端总时长 × 100% | 端到端总时长取同一批提交从首次触发到最终阶段完成的时长 |
| 重复执行率 | 同一提交在同一阶段的重复触发次数 ÷ 该阶段总触发次数 × 100% | 总触发次数按阶段汇总，排除主动取消与基础设施故障记录 |
| 跨阶段返工率 | 发生跨阶段回流的缺陷或变更数 ÷ 同期进入该范围的缺陷或变更总数 × 100% | 分母为时间窗内进入统计范围的缺陷或变更总数 |
计算步骤建议按以下顺序执行。第一步，固定时间窗，例如选取连续四周的流水线运行记录，并写明起止日期。第二步，按流水线分别汇总，得到每条流水线的阶段等待总时长、各阶段触发次数、缺陷与变更总数。第三步，按阶段拆分，计算每个阶段的重复执行率和每对相邻阶段之间的等待占比。第四步，按路径拆分跨阶段返工，统计每条回流路径的次数。第五步，与历史基线对比，观察调整前后的变化。
分母为零时需要单独处理：某阶段在时间窗内没有触发记录，该阶段不计算重复执行率，标注为“无数据”；某时间窗内没有缺陷或变更进入统计范围，返工率不计算，不用零代替。跨流水线比较时，先确认各流水线的阶段数量和职责相近，阶段数量差异大的流水线不宜直接比较等待占比。
例子：一条流水线的三类指标演算
以下为演示情景，数据为便于说明计算过程而设定，不代表任何真实团队的表现。某流水线包含构建、单元测试、集成测试、预发布验证四个阶段，统计时间窗为四周，期间共有 200 次提交进入流水线。
等待时间方面，四周内流水线端到端总时长为 2000 小时，其中阶段间等待合计 500 小时，等待时间占比为 500 ÷ 2000 = 25%。进一步拆分，构建到单元测试之间等待 60 小时，单元测试到集成测试之间等待 120 小时，集成测试到预发布验证之间等待 320 小时。等待主要集中在集成测试之后，查看记录发现该环节需要人工确认才能进入预发布，属于人工等待而非资源排队。
重复执行方面，集成测试阶段四周内总触发 260 次，其中同一提交在该阶段被重复触发的次数为 52 次，重复执行率为 52 ÷ 260 = 20%。按原因分类，30 次为环境准备失败后的自动重试，15 次为测试数据不一致导致的人工重跑，7 次为脚本超时重跑。重复主要集中在环境与测试数据问题，而非阶段边界本身。
跨阶段返工方面，同期进入统计范围的缺陷与变更共 100 项，其中 18 项在预发布验证阶段发现问题后回流到集成测试或构建阶段，跨阶段返工率为 18 ÷ 100 = 18%。回流路径中，12 项从预发布验证回到集成测试，6 项从集成测试回到构建。
三类指标联合解读：等待占比 25% 且集中在集成测试到预发布之间，说明该交接点的人工确认是主要瓶颈，可以考虑把部分确认条件前移到集成测试的准入规则中，或合并这两个阶段的审批动作。重复执行率 20% 且原因集中在环境与测试数据，说明集成测试阶段的运行条件需要先稳定，此时拆分该阶段不会降低重复执行。返工率 18% 且回流集中在预发布到集成测试，说明预发布阶段暴露的问题本可以在集成测试阶段被拦截，适合在集成测试阶段补充检查项。三项指标指向的调整方向不同，需要分别处理，不能用一个动作同时解决。
解读与限制：指标能说明什么、不能说明什么
等待时间长，可能来自资源不足，也可能来自审批排队，两者对应的调整方式不同。资源排队需要增加执行资源或调整并发策略，审批排队需要审视审批节点是否必要、能否并行。看到等待占比高，先拆分人工等待与资源排队，再判断是否与阶段划分有关。
重复执行高，可能源于环境不稳定、测试数据不可靠或脚本缺陷，这些因素与阶段边界的关系较弱。此时优化阶段划分的收益有限，应先稳定运行条件。只有当重复执行集中在阶段交接处的准入检查反复触发时，才说明阶段职责或准入条件需要调整。
跨阶段返工需要区分需求变更与质量缺陷。需求变更引起的回流属于正常业务流动，不应计入质量问题的判断；质量缺陷引起的回流才反映阶段拦截能力。统计时按原因分类，分别计算比率。
三类指标不设通用达标线。不同业务节奏、不同发布频率的团队，合理区间差异很大。阈值应结合团队自身历史基线确定，例如以调整前四周的均值为参照，观察调整后是否改善。指标用于定位问题、验证调整效果，不直接等同于绩效评价，也不应作为个人考核依据。单指标的变化不能证明阶段划分变好或变坏，需要三类指标结合阶段数量、阶段职责与人工介入点一起解读。
评估结果要落到具体动作上：哪两个阶段之间等待最长、哪个阶段重复执行最多、哪条回流路径次数最高，分别对应合并、拆分或补充准入条件的建议。调整后重新采集同一口径的数据，与基线对比，形成闭环。ONES 效能管理提供交付效率、交付质量、资源效率、完成情况四个维度的度量实践体系，支持对系统中产生的数据进行多维度、精细化、自定义的分析，可作为按阶段、按流水线汇总上述指标的承载方式；具体指标是否预置，需在选型时结合集成配置核验。
常见问题
阶段等待时间占比高，应该先合并阶段还是先增加执行资源？
先拆分等待时间的构成再决定。把阶段间等待分为人工等待（审批、确认）与资源排队（执行机不足、并发受限）两类，分别统计时长。人工等待占比高，优先审视审批节点是否必要、能否并行或前移条件；资源排队占比高，优先调整执行资源或并发策略。两类原因对应不同动作，合并阶段只适用于交接本身冗余、职责重叠的情况。
同一提交在某一阶段被自动重试多次，是否全部计入重复执行率？
计入，但需要按原因分类后再解读。自动重试与人工重跑都属于同一提交在同一阶段的重复触发，应纳入分子；主动取消和基础设施故障中断的记录单列，不进入分母。分类统计后，如果重复集中在环境准备失败后的自动重试，说明该阶段运行条件不稳定，优先稳定环境；如果集中在人工重跑，则检查触发来源与准入条件。
跨阶段返工率计算时，需求变更引起的回流要不要排除？
不排除，但要与质量缺陷分开统计。需求变更引起的回流属于正常业务流动，质量缺陷引起的回流才反映阶段拦截能力。建议在分子中按原因分类，分别计算需求变更回流率与质量缺陷回流率，再结合阶段职责解读。混在一起计算会掩盖阶段拦截能力的真实变化。
流水线记录缺少阶段间交接时间戳，等待时间还能算吗？
可以用相邻阶段的时间差近似，但需在报告中注明替代口径，并说明该口径可能高估或低估等待时长。如果连阶段开始与结束时间都不完整，该阶段不参与等待时间计算，标注为“无数据”，不用估算值填充。数据缺失的阶段单独列出，不强行与其他流水线合并比较。
三类指标算出结果后，如何判断调整是否有效？
以调整前同一口径的历史数据为基线，调整后重新采集同一时间窗、同一分母范围的数据进行对比。观察指标变化的同时，确认阶段数量、阶段职责和人工介入点是否按预期改变。如果指标改善但阶段职责变得更模糊，需要重新审视调整动作。指标用于定位问题和验证效果，不直接作为绩效评价依据。
