只统计流水线阻塞次数，容易把“偶发但每次拖很久”和“频繁但很快恢复”混为一谈。要判断治理投入是否值得、先治哪类阻塞，需要把阻塞拆成三层指标：发生频率、单次持续时长、对交付周期的影响。本文给出一套可复算的定义、口径、公式和算例，重点说明分母怎么取、时间戳怎么对齐，以及如何用同一批变更做对照，避免把次数当成唯一结论。
要点总览（TL;DR）
- 只统计阻塞次数会混淆“高频短阻塞”和“低频长阻塞”，度量应同时呈现频率、持续时长和交付周期影响三层指标。
- 频率用阻塞率表达，需注明分母是流水线运行次数还是变更数；时长取单次阻塞的中位数与P90，并折算阻塞工时占比。
- 交付周期影响建议用同一窗口内的变更做对照，比较含阻塞与无阻塞变更的周期中位数，或计算阻塞时长占交付周期的比例。
- 阻塞需要操作性定义和统一时间戳，阈值、分母、统计范围变化时记录口径版本，避免前后数据直接拼接比较。
- 指标用于定位问题和验证改进，样本过少时标注“样本不足”，不宜直接作为绩效排名依据。
度量目标：回答阻塞到底拖慢了什么
建立阻塞度量的第一步，是明确它要支撑哪些决策。常见的决策有三类：是否值得投入治理流水线稳定性；优先治理哪一类阻塞（环境不可用、等待人工审批、依赖服务超时等）；改进措施上线后效果是否真的出现。这三个问题分别对应不同的观察角度，单一的次数指标无法同时回答。
三层指标与决策问题的对应关系可以这样理解：频率回答“发生面有多广”，即单位时间窗内有多少次运行或多少变更被阻塞，用于判断问题是普遍现象还是个别现象；持续时长回答“单次代价有多大”，即每次阻塞从进入到恢复花了多久，用于识别少数长时间阻塞造成的集中损耗；交付周期影响回答“最终拖慢了交付多少”，即阻塞是否真实反映在变更从进入交付流到完成的时长上，用于验证治理是否带来交付结果改善。
| 指标层 | 回答的问题 | 典型输出 | 主要用途 |
|---|---|---|---|
| 频率 | 阻塞发生得有多普遍 | 阻塞次数、阻塞率 | 判断是否需要治理、比较不同流水线或分支 |
| 持续时长 | 每次阻塞的代价有多大 | 时长中位数、P90、阻塞工时占比 | 识别长尾阻塞、估算人力占用 |
| 交付周期影响 | 阻塞是否拖慢了交付结果 | 含阻塞与无阻塞变更的周期对比、阻塞时长占周期比例 | 验证改进效果、向业务方说明影响 |
需要提前说明的是，次数指标并非无用，它适合作为事件清单的入口，帮助定位具体案例。问题在于把次数当作结论：次数相同的两个团队，可能一个是高频短阻塞，一个是低频长阻塞，治理手段完全不同。因此本文的度量目标清单要求三层指标同时呈现，次数只作为第一层的原始计数。
阻塞的定义、指标与统计范围
阻塞需要一个可操作的判定规则，否则不同人统计出的事件数无法比较。建议把阻塞定义为：流水线运行中断、等待人工介入或资源不可用，且持续超过设定阈值。阈值的作用是过滤瞬时抖动，例如把阈值设为5分钟，短于5秒的重试失败不计入阻塞事件。阈值一旦确定，应在整个统计周期内保持一致，并在报表中注明。
判定阻塞时还要区分状态与原因。状态指流水线处于无法继续推进的情形，原因则记录为环境不可用、等待审批、依赖超时、凭证失效等分类。原因分类用于后续的优先级排序，状态判定用于计算时长，两者分开记录可以避免把“等待人工审批”这类流程性阻塞和技术性阻塞混在一起分析。
指标清单建议包含以下五项，每项都注明单位和分母：
- 阻塞次数：统计窗口内符合判定规则的阻塞事件数量，单位次。
- 阻塞率：阻塞运行次数除以总运行次数，或阻塞变更数除以总变更数，需注明所用分母。
- 阻塞时长中位数与P90：单次阻塞从进入阻塞到恢复的时长，单位分钟，中位数反映典型情况，P90反映长尾。
- 阻塞工时占比：阻塞时长合计除以统计窗口内的可用总工时，用于估算人力被占用的比例。
- 交付周期影响：含阻塞变更与无阻塞变更的交付周期对比，或阻塞时长占交付周期的比例。
统计范围需要事先划定：纳入哪些流水线（例如主干分支的构建与部署流水线）、哪些分支（是否包含特性分支）、时间窗（按自然周还是按迭代）、变更范围（是否包含热修复和配置变更）。范围划定后写入度量说明，后续调整需记录变更时间与原因。
排除项同样要明确：计划内维护导致的流水线暂停、团队主动取消的运行、与交付流无关的定时任务或文档构建流水线，都不计入阻塞事件。排除规则的作用是让分子分母对应同一类对象，避免把非交付流的中断算进交付阻塞率。
数据口径与证据：时间戳、分母和缺失值
指标能否复算，取决于时间戳是否统一。建议至少采集五个时间点：进入阻塞时间、恢复时间、变更提交时间、变更进入交付流时间、交付完成时间。进入阻塞时间取流水线状态首次变为不可推进的时刻，恢复时间取流水线重新可推进或该次运行被判定终止的时刻。变更提交时间与进入交付流时间用于计算交付周期，交付完成时间取变更部署完成或验收通过的时刻，具体取哪个点需在口径中固定。
分母口径有三种常见选择，差异明显，不能混用：按变更数计算，分母是统计窗口内进入交付流的变更总数，适合回答“多少比例的变更被阻塞过”；按流水线运行次数计算，分母是窗口内流水线运行总次数，适合回答“运行层面的阻塞面”；按时间窗计算，分母是窗口内的可用工时或自然时间，适合计算阻塞工时占比。同一张报表内应只使用一种分母，或在并列展示时明确标注。
| 字段 | 取值说明 | 用途 | 缺失时处理 |
|---|---|---|---|
| 进入阻塞时间 | 流水线状态首次不可推进的时刻 | 计算阻塞时长起点 | 标记为不可计算，不计入时长统计 |
| 恢复时间 | 重新可推进或运行终止的时刻 | 计算阻塞时长终点 | 跨窗口未恢复的按窗口截止时间截断并标注 |
| 变更提交时间 | 代码合并或提交的时刻 | 交付周期起点之一 | 缺失时改用进入交付流时间并注明 |
| 进入交付流时间 | 变更进入待发布队列的时刻 | 交付周期起点 | 缺失时该变更不进入周期对比样本 |
| 交付完成时间 | 部署完成或验收通过的时刻 | 交付周期终点 | 缺失时标记为未完成，不参与周期均值 |
缺失值与异常值需要规则化处理。时间戳缺失的事件保留在事件清单中，但不进入时长和周期计算，并在报表中单列“不可计算事件数”。重复事件按流水线运行标识去重，同一运行内多次状态抖动合并为一次阻塞，时长从首次进入阻塞算到最终恢复。跨天或跨窗口的阻塞，按统计窗口截止时间截断，截断部分在下一窗口继续记录，避免同一段时长被重复计入两个窗口。
数据来源方面，建议保留原始事件记录与计算脚本或查询语句，使任何一个汇总数字都能回溯到具体事件。证据留存还包括口径版本号：当阻塞阈值、分母或时间戳定义发生变化时，记录变更日期，旧数据按旧口径解释，新数据按新口径计算，不直接拼接比较。
计算步骤：从原始事件到三个指标
有了定义和口径，计算可以按固定步骤执行。以下公式中的时间单位统一为分钟，比率保留一位小数，样本量同时呈现。
第一步，计算阻塞率。阻塞率 = 阻塞运行次数 ÷ 总运行次数 × 100%，或阻塞率 = 阻塞变更数 ÷ 总变更数 × 100%。两个公式回答的问题不同，报表中必须写明使用哪一个分母。若同一窗口内两种口径都要看，分两列展示，不合并成一个数字。
第二步，计算单次阻塞时长。单次阻塞时长 = 恢复时间戳 − 进入阻塞时间戳，单位分钟。对窗口内所有可计算事件排序后取中位数与P90。中位数反映典型阻塞的代价，P90反映长尾阻塞，两者差距大说明阻塞时长分布不均，治理重点应放在长尾事件上。
第三步，计算阻塞工时占比。阻塞工时占比 = 阻塞时长合计 ÷ 统计窗口总工时 × 100%。总工时的口径需事先约定，例如按团队人数乘以窗口内工作小时数。该指标用于估算阻塞对人力占用的影响，适合与阻塞次数并列展示，避免只看次数低估长阻塞的代价。
第四步，计算交付周期影响。有两种做法。做法一，取同一窗口内的变更，分为含阻塞变更组与无阻塞变更组，分别计算交付周期中位数，比较两组差值，差值即阻塞关联的周期差异。做法二，对含阻塞变更计算阻塞时长占其交付周期的比例，观察阻塞在单个变更周期中的权重。两种做法都建议使用中位数而非均值，减少极端值干扰。
第五步，处理分母为零与样本过少。当总运行次数或总变更数为零时，不输出比率，只呈现事件清单和绝对时长。当样本量低于约定下限（例如少于20次运行或10个变更）时，比率标注“样本不足”，同时给出绝对数和事件明细，避免用一个小样本比率下结论。
算例：一个两周窗口的阻塞度量
以下为演示情景，数据为构造值，用于说明计算过程。某团队统计两周窗口内主干分支的构建与部署流水线，总运行次数200次，其中12次运行被判定为阻塞，阻塞原因包括环境不可用5次、等待审批4次、依赖超时3次。12次阻塞的时长分别为：8、12、15、20、25、30、35、40、55、70、95、180分钟。
阻塞率 = 12 ÷ 200 × 100% = 6.0%。将12个时长排序后，中位数为第6与第7个值的平均，即(30+35)÷2 = 32.5分钟。P90取第11个值附近，约95分钟。阻塞时长合计为585分钟，若窗口总工时为2人×10个工作日×8小时×60分钟 = 9600分钟，则阻塞工时占比 = 585 ÷ 9600 × 100% ≈ 6.1%。
交付周期影响方面，假设窗口内共有80个变更，其中10个变更在交付过程中遇到阻塞，70个未遇到阻塞。含阻塞变更的交付周期中位数为52小时，无阻塞变更为30小时，差值22小时。同时，含阻塞变更的阻塞时长中位数为35分钟，占其交付周期的比例约1.1%。这组数字说明：阻塞在单个变更周期中的直接时间占比不高，但含阻塞变更的整体周期明显更长，差异可能来自阻塞引发的排队、返工或等待审批，需要结合事件明细进一步定位。
| 指标 | 计算式 | 结果 | 解读 |
|---|---|---|---|
| 阻塞率 | 12 ÷ 200 | 6.0% | 发生面中等，需结合原因分类看集中度 |
| 阻塞时长中位数 | 排序后第6、7位平均 | 32.5分钟 | 典型阻塞约半小时 |
| 阻塞时长P90 | 排序后第11位附近 | 约95分钟 | 长尾明显，最长一次180分钟 |
| 阻塞工时占比 | 585 ÷ 9600 | 约6.1% | 人力占用不可忽略 |
| 交付周期差值 | 52 − 30 | 22小时 | 含阻塞变更周期更长，需查原因 |
这个算例体现了三层指标的价值：如果只看次数，12次在200次运行中似乎不算严重；但P90达到95分钟、最长一次180分钟，说明少数长阻塞贡献了大部分阻塞时长；交付周期差值22小时则提示阻塞可能与更长的等待和返工相关。三类信息合在一起，才能支撑“先治环境不可用还是先治审批等待”的判断。
解读与限制：避免把指标当因果结论
阻塞指标反映的是关联，不能直接证明因果。含阻塞变更的交付周期更长，可能因为阻塞本身拖慢了流程，也可能因为复杂变更更容易同时触发阻塞和长评审。解读时应回到事件明细，查看阻塞前后发生了什么：是否伴随返工、是否等待了额外审批、是否与其他变更争抢环境。只有把阻塞事件放回具体流程，才能判断改进措施应落在哪一环。
样本量与时间窗直接影响结论稳定性。两周窗口内十几起阻塞事件，比率的小幅波动可能只是随机变化；跨团队比较时，流水线数量、变更规模和发布节奏不同，阻塞率不宜直接排名。建议固定时间窗和统计范围，连续观察多个窗口的趋势，再判断改进是否有效。
指标适合用于定位问题和验证改进，不适合直接作为个人或团队的绩效排名依据。一旦指标与考核挂钩，容易出现缩短阻塞记录、拆分事件或调整阈值的行为，反而破坏数据可信度。更稳妥的做法是把阻塞指标作为流程改进的输入，配合事件复盘记录改进项和完成情况。
口径需要持续复核。阻塞阈值、分母选择、时间戳定义任何一项变化，都会让前后数据不可直接比较。建议维护一份口径说明，记录每次变更的日期、原因和影响范围，季度复核一次指标是否仍服务于最初的决策问题。
在度量落地环节，如果团队使用 ONES，可以把流水线执行状态与项目工作项关联起来。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并将流水线与项目关联，用于可视化 CI/CD 过程、识别阻塞。ONES 效能管理提供交付效率、交付质量、资源效率、完成情况四个维度的分析，并可自动收录系统内流转的研发数据形成分析指标。落地前需要确认的是：阻塞事件的判定阈值、起止时间戳字段，以及阻塞时长与变更交付周期的关联计算方式，是否能在现有报表配置中实现；若资料未覆盖这些字段，应先在试点流水线上验证取数口径，再推广到全量统计。
常见问题
阻塞阈值设多少分钟比较合适，阈值变了历史数据还能比吗？
阈值没有统一标准，取决于流水线的正常波动幅度。可以先统计一段时间的运行中断时长分布，把明显属于瞬时抖动的那部分排除，再确定一个能过滤噪声又不吞掉真实阻塞的值，例如5分钟或10分钟。阈值一旦确定，应在整个统计周期内保持一致。
阈值调整后，历史数据不能直接与新数据拼接比较。建议在口径说明中记录变更日期和原因，旧窗口按旧阈值解释，新窗口按新阈值计算；如果确实需要跨期对比，可以用新阈值重算历史原始事件，并标注为重算结果。
按变更数算阻塞率和按运行次数算阻塞率，报表里应该用哪个？
两个分母回答的问题不同。按运行次数算，分母是窗口内流水线运行总次数，适合看运行层面的阻塞面，判断流水线本身是否稳定；按变更数算，分母是进入交付流的变更总数，适合看有多少比例的变更在交付过程中被阻塞过，更贴近交付视角。
选择哪一个取决于度量要支撑的决策。如果目标是治理流水线稳定性，用运行次数作分母更直接；如果目标是向业务方说明交付受阻情况，用变更数作分母更容易理解。同一张报表内只使用一种分母，需要并列展示时分两列并明确标注，不合并成一个数字。
含阻塞变更的交付周期比无阻塞变更长，能直接说是阻塞造成的吗？
不能直接归因。含阻塞变更的周期更长，可能因为阻塞本身拖慢了流程，也可能因为复杂变更更容易同时触发阻塞和长评审、返工。两组变更在复杂度、变更规模上未必可比。
更稳妥的做法是回到事件明细，查看阻塞前后发生了什么：是否伴随返工、是否等待了额外审批、是否与其他变更争抢环境。如果条件允许，可以按变更规模或变更类型分层后再比较周期，减少混杂因素。指标的作用是提示哪里值得进一步查，因果判断需要结合流程复盘。
统计窗口内阻塞事件只有几次，比率还能用吗？
样本过少时，比率的小幅波动可能只是随机变化，不适合据此下结论。建议约定一个样本下限，例如少于20次运行或10个变更时，比率标注“样本不足”，同时给出绝对数和事件明细。
分母为零时不输出比率，只呈现事件清单和绝对时长。跨团队比较时也要注意流水线数量、变更规模和发布节奏的差异，阻塞率不宜直接排名，连续观察多个窗口的趋势更有参考价值。
用ONES落地这套阻塞度量，需要先确认哪些配置？
ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并将流水线与项目关联，用于可视化 CI/CD 过程、识别阻塞。ONES 效能管理提供交付效率、交付质量、资源效率、完成情况四个维度的分析，并可自动收录系统内流转的研发数据形成分析指标。
落地前需要确认三件事：阻塞事件的判定阈值能否在现有报表配置中体现；进入阻塞和恢复的时间戳字段是否可从同步数据中取得；阻塞时长与变更交付周期的关联计算方式是否支持。若现有资料未覆盖这些字段，建议先在试点流水线上验证取数口径，再推广到全量统计。
