从等待时间、重复执行与跨阶段返工评估流水线阶段划分

判断流水线阶段划分是否合理，可以围绕阶段边界与交接点，用阶段等待时间、重复执行、跨阶段返工三类指标交叉评估。三类指标需要固定时间窗、分母和统计口径，再结合变更规模分层解读；单看某一项下降不足以说明划分变好，还要观察交付周期、失败率和返工结构是否同步改善。

要点总览（TL;DR）

• 评估流水线阶段划分，重点看阶段边界与交接点是否造成额外消耗，用阶段等待时间、重复执行、跨阶段返工三类指标交叉判断。
• 阶段等待时间要区分排队、审批、资源争抢三类等待，重复执行要区分同阶段重跑与跨阶段重复构建，跨阶段返工按阶段对统计回退次数与返工工时。
• 三类指标需固定时间窗、分母与变更范围，按变更规模分层并剔除环境故障等异常样本，调整前后同口径复测才有可比性。
• 等待高且返工集中在同一阶段对，说明该边界既慢又不稳；等待低但返工高，可能是校验被后移；重跑高但返工低，可能是阶段职责重叠。
• 指标反映相关性而非因果，不设通用达标线，结论应落到具体阶段对并配合变更复盘确认。

评估目标：阶段划分要回答的三个问题

阶段划分的评估对象是阶段边界和交接点，关注变更在阶段之间流转时是否产生额外消耗。评估要回答三个问题：等待是否集中在某个交接点、重复执行中有多少可以避免、返工是否指向某条边界的位置不合适。结论用于决定合并相邻阶段、拆分过粗阶段，或把门禁前移、后移。

三个问题对应不同的决策用途。等待集中说明交接或资源安排需要调整；可避免的重复说明阶段职责或触发条件存在重叠；跨阶段返工集中说明前序阶段的产出标准与后序阶段的输入要求不匹配。评估前先把这三个问题写成待验证假设，后续取数和计算才有明确指向。

待验证问题	观察信号	可能的决策
等待是否集中在某处	某阶段排队或审批等待占比明显高于其他阶段	调整资源、合并审批节点或改变门禁位置
重复是否可避免	同一变更在同阶段反复重跑，原因集中在配置或触发条件	合并职责重叠的阶段，修正触发规则
返工是否指向边界错位	回退集中发生在特定阶段对，返工工时高	前移校验、拆分阶段或补充交接标准

指标与范围：三类指标的定义与统计边界

三类指标分别刻画时间损耗、执行损耗和质量损耗，定义时要写清分子、分母、单位和统计范围，避免不同团队各用一套口径。以下定义以单个统计时间窗内的变更集合为总体。

阶段等待时间

阶段等待时间指变更在某阶段处于等待状态、尚未开始执行的时长。需要区分三类：排队等待是等待可用执行资源的时间；审批等待是等待人工审批或门禁确认的时间；资源争抢等待是并发任务竞争同一环境或资源池的时间。常用指标是等待占比：

阶段等待占比 = 该阶段等待总时长 ÷ 该阶段从进入到离开的总时长 × 100%。

分母是该阶段内所有变更的阶段停留总时长，单位为人时或自然小时，需在口径中固定一种。三类等待分别计算占比，便于判断调整方向。

重复执行

重复执行分两种口径。同阶段重跑率 = 同一变更在同一阶段的重跑次数 ÷ 该阶段首次执行次数，反映单阶段内的反复。跨阶段重复构建率 = 同一变更在多个阶段重复执行同类构建或测试的次数 ÷ 该变更涉及的阶段数，反映阶段间职责重叠。重跑次数按变更累计，分母按阶段或变更计，统计时注明。

跨阶段返工

跨阶段返工指因前序阶段产出不合格而回退到上游重新处理。核心指标有两个：回退率 = 发生回退的变更数 ÷ 统计窗内变更总数；返工工时占比 = 返工处理工时 ÷ 该变更总交付工时。同时按“阶段对”记录回退次数，例如测试阶段回退到构建阶段、构建阶段回退到代码提交阶段，用于定位具体边界。

指标	公式	单位	分母	统计范围
阶段等待占比	阶段等待总时长 ÷ 阶段停留总时长	百分比	该阶段全部变更的停留时长	按阶段分别统计
同阶段重跑率	同变更同阶段重跑次数 ÷ 首次执行次数	次/次	该阶段首次执行次数	按阶段、按变更累计
跨阶段重复构建率	重复同类执行次数 ÷ 变更涉及阶段数	次/阶段	变更涉及的阶段数	按变更统计
回退率	发生回退的变更数 ÷ 变更总数	百分比	统计窗内变更总数	按阶段对统计
返工工时占比	返工工时 ÷ 变更总交付工时	百分比	该变更总交付工时	按变更、按阶段对

统计范围要明确流水线范围（哪些流水线纳入）、变更类型（功能、修复、配置变更是否分开）、时间窗（如连续四周）和排除项（环境故障、外部依赖中断等非划分因素导致的异常样本）。范围一旦确定，调整前后复测沿用同一范围。

数据口径与证据：从哪里取数、如何保证可比

取数来源包括流水线运行记录、各阶段起止时间戳、重跑记录、回退操作记录，以及缺陷或工作项与变更的关联记录。必要字段至少包括：变更标识、阶段标识、阶段开始与结束时间、触发原因、执行结果状态、重跑序号、回退目标阶段、返工处理工时。

可比性处理有三个动作。第一，按变更规模与类型分层，小改动和大改动的等待与返工分布差异明显，混在一起会掩盖真实问题。第二，统一时间窗，调整前后使用相同长度和相同业务节奏的窗口，避开大促或版本冻结期。第三，剔除异常样本，环境故障、第三方服务中断导致的失败和重跑单独标记，不计入可避免重复。

分母为零和数据缺失要有明确规则。某阶段在时间窗内没有变更时，该阶段指标记为“无样本”，不按零处理，也不参与横向排名。时间戳缺失的变更从对应指标中剔除，并记录剔除数量；剔除比例过高时，该指标只作参考，不作为调整依据。

在工具层面，ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，同步流水线数据、执行状态和日志，并把流水线与项目关联，便于在项目、迭代、需求中查看构建与发布过程。阶段级时间戳和重跑记录是否可直接取用，需结合实际集成配置核验；缺失字段可从同步的执行状态与日志中加工。返工侧可借助测试管理中未通过用例创建缺陷任务、缺陷在测试与研发间流转的记录，关联回退与返工工时。

计算与评估步骤：从原始记录到判断结论

计算按五个步骤推进，每一步都产出可复核的中间结果。

1. 按变更维度还原阶段时间线。以变更标识为主键，把各阶段的开始、结束、等待、重跑、回退事件按时间排序，形成单变更的阶段轨迹。完成标志是每条变更都能画出从首次进入到最终通过的完整路径。
2. 计算三类指标及各自分母。按前述公式逐变更计算，再按阶段和阶段对聚合。等待时长区分排队、审批、资源争抢；重跑按原因分类；返工记录回退目标阶段和工时。
3. 按阶段与阶段对聚合，定位集中点。找出等待占比最高的阶段、重跑率最高的阶段、回退次数最多的阶段对。集中点比总量更有决策价值。
4. 三类指标交叉比对，形成划分调整假设。等待高且返工也集中在同一阶段对，说明该边界既慢又不稳；等待低但返工高，可能是校验被后移；重跑高但返工低，可能是阶段职责重叠而非质量问题。
5. 调整后同口径复测。合并、拆分或移动门禁后，用相同时间窗、相同分层和相同排除规则重算，对比三类指标与交付周期、失败率的变化。

交叉比对时可用一张矩阵辅助判断：把每个阶段对的等待占比、重跑率、回退率放在同一行，标记同时偏高的组合。矩阵只用于排序和提出假设，最终结论要回到具体变更复盘确认。

示例：一次阶段划分调整的评估过程

以下为演示情景，数值用于说明计算方法，不代表任何真实团队。某团队流水线分为构建、集成测试、验收测试、发布四个阶段，统计窗为连续四周，纳入 200 个变更，排除环境故障样本 12 个。

等待时间方面，集成测试阶段平均停留 6 小时，其中排队等待 2.4 小时、审批等待 1.2 小时，等待占比 60%；构建阶段等待占比 15%，验收测试 25%。重跑方面，集成测试同阶段重跑 80 次，首次执行 200 次，重跑率 40%，原因分布为环境准备失败 30 次、代码修复后重跑 35 次、配置调整 15 次。返工方面，验收测试回退到集成测试 28 次，回退率 14%，返工工时合计 140 人时，占这 28 个变更总交付工时的 18%。

阶段/阶段对	等待占比	重跑率或回退率	观察
构建	15%	重跑率 8%	正常
集成测试	60%	重跑率 40%	等待与重复同时偏高
验收测试→集成测试	—	回退率 14%	返工集中在一条边界

交叉后指向的问题是：集成测试阶段承担了环境准备、基础校验和部分验收职责，职责过粗导致排队和重跑集中；验收测试发现的问题大量回退到集成测试，说明两者的校验标准没有对齐。调整方案是把环境准备拆为独立前置阶段并预置资源，把基础校验前移到构建后，验收测试的准入标准与集成测试的通过标准对齐。

复测四周后，同口径下集成测试等待占比降至 35%，重跑率降至 22%，验收测试到集成测试的回退率降至 7%，返工工时占比降至 9%，交付周期中位数同步下降。该示例适用于变更规模相近、流水线结构类似的团队；变更类型差异大的团队需要先分层再比较。

解读与限制：指标能说明什么、不能说明什么

三类指标反映的是阶段划分与交付表现之间的相关性，不能直接当作因果结论。解读时要逐项排除替代解释。

• 等待时间下降可能来自增加执行资源或放宽审批，而非阶段边界变合理。要同时看资源投入和审批规则是否变化。
• 重跑减少可能源于跳过了某些校验。要核对失败率和缺陷发现阶段，确认质量没有转移到下游。
• 返工率受缺陷发现位置影响。发现越晚，返工工时越高；返工率下降也可能是问题被更早拦截，需结合发现阶段分布看。
• 不设通用达标线。基线应来自团队自身历史数据，调整前后同口径对比才有意义。
• 指标变化与阶段划分之间是相关性判断，需配合变更复盘确认具体原因，再决定是否固化调整。

常见误读包括：只看总等待时长不看结构，忽略审批等待与资源争抢等待对应不同动作；把全部重跑都算作划分问题，实际上代码修复后的正常重跑不可避免；只比较返工总量而不看阶段对，无法定位边界。评估结论宜写成“某阶段对的等待与返工同时偏高，建议调整该边界并复测”，而非“划分不合理”的笼统判断。ONES 支持多种数据报表，可追溯 DevOps 工具链中的操作并集中度量研发绩效，为这类复测提供数据基础；具体指标与报表范围以实际配置为准。

常见问题

统计阶段等待时间时，排队、审批和资源争抢三类等待需要分开算吗？

建议分开计算。三类等待对应的调整动作不同：排队等待偏高通常指向执行资源不足或调度策略，审批等待偏高指向门禁节点位置或审批规则，资源争抢等待偏高指向并发任务对同一环境或资源池的竞争。合并成一个总等待时长，只能看到慢，看不出该动哪里。

实操上可以在同一阶段内分别记录三类等待时长，再各自除以该阶段停留总时长得到占比。如果原始记录无法直接区分，可先按触发原因和状态字段做近似归类，并在口径说明中注明归类规则。

代码修复后的重跑算不算可避免的重复执行？

不算。代码修复后重新执行构建或测试是交付流程的正常环节，属于不可避免的重复。评估阶段划分时，应把重跑按原因分类，例如环境准备失败、配置调整、人为重试、代码变更后重跑，只把与阶段职责重叠或触发条件设置不当相关的部分计入可避免重复。

如果可避免部分占比很低，重跑率高更可能来自环境稳定性或执行资源问题，此时调整阶段划分的收益有限，应先处理环境与资源侧的原因。

某阶段在统计时间窗内没有变更，指标应该记为零吗？

不建议记为零。没有变更意味着该阶段没有样本，记为零会拉低整体均值，也会让该阶段在横向排名中显得异常优秀。更稳妥的做法是标记为“无样本”，不参与阶段间排名，并在汇总时说明该阶段的样本缺失情况。

同理，时间戳缺失的变更应从对应指标中剔除并记录剔除数量。剔除比例过高时，该指标只作参考，不宜作为合并、拆分或移动门禁的直接依据。

调整阶段划分后，多久复测比较合适？

复测窗口应与评估窗口保持相同长度，并尽量避开大促、版本冻结等业务节奏差异明显的时段，否则指标变化可能来自业务波动而非划分调整。调整刚落地时，团队需要一段适应期，可先观察一个窗口确认数据采集正常，再用完整窗口做正式对比。

复测时沿用相同的变更分层、排除规则和分母口径，同时观察交付周期中位数与失败率，确认等待、重跑、返工的改善没有以质量下降为代价。

用 ONES 做这类评估，数据从哪里来？

ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并把流水线与项目关联，可在项目、迭代、需求中查看构建与发布过程。返工侧可借助测试管理中未通过用例创建缺陷任务、缺陷在测试与研发间流转的记录，关联回退与返工工时。

阶段级起止时间戳和重跑记录能否直接取用，取决于实际集成配置；缺失字段可从同步的执行状态与日志中加工。ONES 支持多种数据报表，可追溯 DevOps 工具链中的操作并集中度量研发绩效，具体指标与报表范围以实际配置为准。