评估交付流水线的阶段划分是否合理，可以从三个可观测问题入手：阶段边界是否对应可独立验证的交付物，阶段之间的等待与交接是否造成明显停滞，跨阶段返工是否集中在少数边界上。本文给出一套可复算的方法，覆盖指标定义、取数口径、计算步骤与示例演算，评估范围限于交付流执行本身，不涉及平台对接配置与发布审批规则设计。
要点总览（TL;DR）
- 评估阶段划分是否合理，先看三个可观测问题：边界是否对应可独立验证的交付物、阶段间等待是否造成明显停滞、跨阶段返工是否集中在少数边界。
- 核心指标包括阶段等待时间与执行时长、重复执行率、跨阶段返工率，需先固定公式、单位、分母口径与统计范围，结果才能复算和比较。
- 计算按四步推进：汇总等待与执行时长算等待占比、算重复执行率定位高重复阶段、按边界配对统计返工率、组合三项结果判断合并、拆分或调整门禁位置。
- 等待占比高可能来自资源排队而非阶段划分，重复执行率高需区分环境不稳定与职责重叠，返工率受记录质量影响，结论应与阶段负责人核对后再落地。
- 不设通用达标线，以团队三到六个月历史数据为基线，指标连续两个以上窗口同向变化才适合作为调整依据。
评估目标：阶段划分要回答哪几个问题
阶段划分的“合理”需要落到可采集、可判断的问题上，否则讨论容易停留在流程图上。评估对象是阶段边界，即每个阶段从哪里开始、到哪里结束、向下游交付什么，流水线工具本身不在评估范围内。
建议把评估拆成以下问题清单，逐条给出证据：
- 边界问题：每个阶段结束时，是否产出一个可以独立验证的交付物，例如可部署的构建产物、通过测试的代码版本、可发布的镜像？如果某阶段结束时没有可验证产物，这个边界就值得怀疑。
- 等待问题：阶段之间的等待时间占整个交付周期的比例是多少？等待集中在哪些边界？
- 返工问题：缺陷或变更回溯到上游阶段的次数，是否集中在少数几个边界上？
- 职责问题：相邻两个阶段是否存在职责重叠，导致同一类检查被重复执行？
评估结论通常有三种输出：合并阶段，适用于边界两侧职责重叠、等待占比高且返工不集中在边界的情况；拆分阶段，适用于单个阶段内部混杂了不同验证目标、失败原因难以定位的情况；调整门禁或交接位置，适用于返工集中出现在某个边界、需要把检查前移或后移的情况。三种结论都应以数据为依据，并与阶段负责人确认后再实施。
指标与范围：等待时间、重复执行与跨阶段返工怎么定义
三类核心指标需要先固定公式、单位与分母，后续计算才能复算和横向比较。下表给出建议定义，团队可根据自身记录能力调整，但调整后应在同一时间窗内保持一致。
| 指标 | 定义与公式 | 单位 | 统计对象 |
|---|---|---|---|
| 阶段执行时长 | 阶段开始到阶段结束的时间差，按阶段分别汇总，可取平均值或中位数 | 分钟或小时 | 每次有效的阶段运行 |
| 阶段等待时间 | 上游阶段结束到下游阶段开始之间的间隔 | 分钟或小时 | 每次阶段交接 |
| 阶段等待占比 | 阶段等待时间 ÷（该阶段等待时间 + 执行时长），或按整条流水线计算总等待 ÷ 总周期 | 百分比 | 同一时间窗内的阶段运行 |
| 重复执行次数 | 同一交付单元在同一阶段被再次执行的次数，不含首次执行 | 次 | 按交付单元计数 |
| 重复执行率 | 重复执行次数 ÷ 该阶段执行总次数 | 百分比 | 需明确分母按运行次数还是按交付单元 |
| 跨阶段返工次数 | 缺陷或变更被回溯到上游阶段处理的次数，按“来源阶段—目标阶段”配对记录 | 次 | 同一时间窗内纳入的交付单元 |
| 跨阶段返工率 | 某边界的返工次数 ÷ 该边界通过的交付单元数或运行次数 | 百分比 | 与重复执行率保持同一分母口径 |
统计范围需要同时固定四项：流水线范围（评估哪几条流水线）、分支范围（主干、发布分支或全部）、时间窗（例如连续四周）、纳入的交付单元（需求、提交或构建产物）。范围不一致时，不同阶段的数据不具备可比性，结论也容易失真。等待时间与执行时长应分开统计，混在一起会掩盖停滞的真实位置。
数据口径与证据：从流水线记录里取哪些字段
取数的目标是让每个阶段都能算出等待、执行、重复执行和返工四类数据。建议从流水线运行记录中提取以下字段：阶段名称、阶段开始时间、阶段结束时间、执行结果（成功、失败、中断）、触发方式（提交触发、定时触发、手动触发）、关联的工作项编号或提交号。关联字段是把流水线运行与交付单元对应起来的关键，缺少它就无法按交付单元计算重复执行率和返工率。
分母口径需要在取数前确定。按流水线运行次数计数适合观察整体稳定性，按交付单元计数适合观察单个需求的交付体验。两种口径可以并存，但同一张报表内应只使用一种，并在报表中注明。缺失值与中断运行的处理规则建议如下：
- 阶段结束时间缺失的运行，标记为数据不完整，不计入等待时间与执行时长的有效分母。
- 因人工取消或环境故障中断的运行，单独归类，不并入失败次数，避免拉高重复执行率。
- 同一交付单元在时间窗内跨窗口完成的情况，按首次进入该阶段的时间归属窗口，避免重复计数。
定量数据之外，还需要补充定性证据：阶段交接记录、返工原因备注、与阶段负责人的简短访谈。返工原因备注尤其重要，它能区分“环境不稳定导致的重复执行”和“阶段职责重叠导致的重复检查”，这两类问题的处理方向完全不同。
在记录环节，如果团队使用 ONES，流水线数据可以与项目工作项关联。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步编排的流水线数据、执行状态和日志，并在项目、迭代、需求中可视化代码提交、流水线构建与产品发布过程。这为按阶段取数和按交付单元关联提供了记录基础；阶段级时间戳与返工次数的具体字段范围，需要结合团队实际集成配置确认后再确定口径。
计算与评估步骤：从取数到判断的完整流程
拿到数据后，按以下四步计算，每步都产出可对照的结果，最后组合判断。
步骤一：汇总等待与执行时长，计算阶段等待占比。按阶段分别统计执行时长的平均值或中位数，再统计每个边界的等待时间，计算等待占比。等待占比明显高于团队历史基线的边界，列为候选问题边界。
步骤二：计算重复执行率，定位高重复阶段。按交付单元统计每个阶段的重复执行次数，除以该阶段执行总次数。重复执行率高的阶段，进一步查看重复原因：是环境不稳定、用例不稳定，还是阶段内包含了两类本应分开的验证目标。
步骤三：统计跨阶段返工率，识别返工集中的边界。按“来源阶段—目标阶段”配对统计返工次数，计算每个边界的返工率，形成边界返工分布。返工集中在少数边界时，说明这些边界的门禁位置或检查内容需要调整。
步骤四：组合三项结果做判断。可参考以下判定规则：
- 等待占比高，且返工集中在同一边界：优先考虑合并阶段或调整交接位置，减少不必要的排队。
- 重复执行率高，且集中在单一阶段：优先排查环境稳定性与阶段职责重叠，再决定是否拆分该阶段。
- 返工集中在某边界，但等待占比不高：优先调整门禁位置，把检查前移到更早的阶段。
- 三项指标均接近历史基线：维持现有划分，转入定期复评。
分母为零或样本过少时，不计算比率，改为列出原始次数并注明样本不足。例如某阶段在时间窗内只运行了三次，重复执行率即使为 33%，也不足以支撑拆分结论，应延长观察窗口或扩大流水线范围后重新计算。
示例：一条流水线的阶段评估演算
以下为演示情景，数据为虚构，仅用于说明公式代入与结论推导过程。
某流水线包含构建、集成测试、验收测试三个阶段，统计窗口为四周，共纳入 100 个交付单元。示例数据如下：
| 阶段 | 执行次数 | 重复执行次数 | 平均等待时间 | 平均执行时长 |
|---|---|---|---|---|
| 构建 | 100 | 20 | 5 分钟 | 10 分钟 |
| 集成测试 | 100 | 35 | 40 分钟 | 25 分钟 |
| 验收测试 | 100 | 10 | 120 分钟 | 30 分钟 |
返工记录显示：集成测试阶段发现的问题回溯到构建阶段 12 次，验收测试阶段发现的问题回溯到集成测试阶段 8 次、回溯到构建阶段 2 次。
逐项计算：
- 构建阶段等待占比：5 ÷（5 + 10）≈ 33%；集成测试阶段：40 ÷（40 + 25）≈ 62%；验收测试阶段：120 ÷（120 + 30）= 80%。
- 重复执行率：构建 20 ÷ 100 = 20%；集成测试 35 ÷ 100 = 35%；验收测试 10 ÷ 100 = 10%。
- 跨阶段返工率：构建—集成测试边界 12 ÷ 100 = 12%；集成测试—验收测试边界 8 ÷ 100 = 8%；构建—验收测试边界 2 ÷ 100 = 2%。
推导结论：验收测试阶段等待占比最高，达到 80%，说明交付单元在该阶段前排队明显；集成测试阶段重复执行率最高，为 35%，需要先排查环境与用例稳定性；返工主要集中在构建到集成测试的边界，占 12%。组合来看，验收测试前的等待更可能来自测试资源排队，而非阶段划分本身，建议先确认资源与排期；集成测试阶段职责偏重，可评估把部分快速检查前移到构建阶段，同时把验收测试的部分门禁前移，减少末端排队。以上结论需与阶段负责人核对返工原因备注后再实施。
解读与限制：结果怎么用、哪里不能过度推断
三项指标提供的是定位线索，不能直接当作因果结论。等待占比高，可能来自测试环境数量不足、审批排队或人员排期，也可能来自阶段边界设置过多；需要结合资源记录和交接记录区分。重复执行率高，需要区分环境不稳定与阶段职责重叠：前者表现为同一检查反复失败重跑，后者表现为不同阶段执行了内容相近的检查。跨阶段返工率受缺陷记录质量影响，如果返工原因备注缺失或归类随意，返工分布就会失真，此时应先改善记录习惯再计算。
阈值设定方面，不建议采用通用达标线。合理做法是以团队过去三到六个月的历史数据为基线，结合业务节奏确定观察区间，例如发布频繁的团队可以缩短时间窗，发布周期长的团队应延长窗口以保证样本量。指标变化需要连续两个以上窗口同向变化，才适合作为调整阶段划分的依据。
评估结论落地前，应与阶段负责人和相关角色确认，重点核对三类信息：等待是否由外部依赖造成、返工记录是否完整、重复执行是否属于有意设计的重试策略。确认后再决定合并、拆分或调整门禁位置，并在调整后保留同一套指标继续观察，验证改动是否达到预期。ONES 效能管理提供交付效率、交付质量、资源效率、完成情况等维度的度量分析，并支持对研发数据做自定义分析，可作为持续跟踪阶段指标、对比调整前后变化的记录载体；具体指标口径仍需按本文定义在团队内统一。
常见问题
阶段等待占比很高，是否就说明阶段划分不合理？
不一定。等待占比高说明交付单元在某个边界前排队明显，但排队的原因可能是测试环境数量不足、审批排队或人员排期，也可能是阶段边界设置过多。判断时要把等待数据与资源记录、交接记录放在一起看：如果等待集中在资源紧张的环节，优先解决资源问题；如果相邻阶段职责重叠、交接本身没有产生新的验证价值，才考虑合并阶段或调整交接位置。
重复执行率应该按流水线运行次数还是按交付单元计数？
两种口径回答的问题不同。按运行次数计数适合观察整体稳定性，按交付单元计数适合观察单个需求的交付体验。同一张报表内应只使用一种口径并注明，否则不同阶段的数据不可比。如果团队同时关注两类问题，可以分别出两张报表，但不要在同一张表里混用分母。
时间窗内样本太少，指标还能用吗？
样本过少时不建议直接计算比率下结论。例如某阶段在窗口内只运行了三次，即使重复执行率达到 33%，也不足以支撑拆分阶段的判断。此时可以列出原始次数并注明样本不足，延长观察窗口或扩大流水线范围后重新计算。发布周期长的团队本身就需要更长的窗口来积累样本。
评估结论落地后，怎么验证调整是否有效？
调整前后使用同一套指标定义、同一统计范围和同一分母口径继续观察，对比等待占比、重复执行率与跨阶段返工率的变化。指标需要连续两个以上窗口同向变化，才适合作为改动有效的依据。如果团队使用 ONES，效能管理提供交付效率、交付质量、资源效率、完成情况等维度的度量分析，并支持对研发数据做自定义分析，可作为持续跟踪阶段指标、对比调整前后变化的记录载体；具体指标口径仍需在团队内统一。
返工记录不完整时，跨阶段返工率还能算吗？
可以算，但结论要谨慎。返工原因备注缺失或归类随意时，返工分布会失真，此时算出的返工率只能作为粗略参考。更稳妥的做法是先改善记录习惯，要求返工处理时标注来源阶段与原因，积累一到两个窗口后再计算。记录质量提升后，返工率与边界分布才适合作为调整门禁位置的依据。
