流水线执行跟踪要回答两个问题：每次运行走到了哪一步，以及每一步花了多久。前者靠状态指标记录触发、排队、执行、结束及失败原因，后者靠时效指标计算排队等待、执行时长、端到端时长和失败恢复间隔。两类指标都以运行ID为主键关联，并统一时间戳来源、时区和分母口径，才能判断跟踪是否及时、完整，并支撑异常协调。ONES DevOps 解决方案可集中呈现 CI/CD 过程并同步流水线执行状态与日志，适合作为运行记录与异常处置的承载位置。
要点总览（TL;DR）
- 状态指标覆盖触发来源、排队与执行状态、成功/失败/取消/跳过/超时终态、失败原因分类、重试次数和人工介入标记，以运行ID为主键关联阶段与作业。
- 时效指标给出可复算公式：排队等待=开始执行−触发，执行时长=结束−开始，端到端=结束−触发，另设阶段时长、作业时长、失败发现时长、失败恢复时长和重跑间隔。
- 判断跟踪是否及时看状态更新延迟分布和失败到认领的间隔；判断是否完整看必备字段缺失率与状态跳变连续性，两者结合恢复时长共同解读。
- 时间戳统一采用平台事件时间并注明时区与精度，缺失运行标记为不完整并从时效统计中排除，成功率分母需固定取消与跳过的处理规则。
- 指标用于发现异常、协调处置和验证改进，时长变化不能直接归因于流程改进，成功率也不能替代发布准入判断。
跟踪及时与完整要回答哪两个问题
评估流水线执行跟踪，先要把“跟踪得好不好”拆成两个可判断的问题。及时性问的是：状态变化发生后，多久被记录并暴露给需要知道的人。完整性问的是：一次运行从触发到结束，关键状态和时间点是否齐全，能否还原全过程。两个问题都针对流水线运行及其阶段、作业，评估对象是运行记录本身，与个人产出无关。
把指标用途限定在发现异常、协调处置和验证改进上，采集范围会更清晰。团队需要知道哪次运行卡在排队、哪次失败后长时间无人认领、哪个阶段耗时突然拉长，据此安排处置；改进措施上线后，再用同一口径对比前后变化。若把指标直接用于个人考核，采集动作容易变形，例如人为缩短记录间隔或回避标记失败，反而破坏数据可信度。
据此可以形成一份判断问题清单：最近一个时间窗内，有多少运行缺少开始或结束时间戳；状态更新从发生到可见的延迟分布如何；失败运行从失败到被认领、再到恢复成功的间隔有多长；阶段和作业级结果是否都能关联回同一次运行。这些问题分别对应完整性、及时性和恢复效率，后续章节的字段与公式都围绕它们展开。
状态指标：一次运行要记录哪些节点
状态指标的作用是还原一次运行的位置和结果。采集时应覆盖从触发到终态的完整链路，并为每个字段规定取值，避免同一状态在不同流水线里叫法不一。下表给出建议字段，字段名可按平台习惯调整，取值定义需要团队内统一。
| 字段名 | 取值 | 说明 |
|---|---|---|
| 运行ID | 平台生成的唯一标识 | 关联阶段、作业、代码提交的主键 |
| 触发来源 | 提交、合并请求、定时、手动、上游流水线 | 区分自动触发与人工触发，便于分析触发结构 |
| 触发时间 | 时间戳 | 以平台事件时间为准，记录到秒 |
| 排队状态 | 排队中、已开始 | 标记运行等待执行资源的区间 |
| 运行状态 | 排队、执行中、成功、失败、取消、跳过、超时 | 终态需区分成功、失败、取消、跳过、超时五类 |
| 阶段状态 | 未开始、执行中、成功、失败、取消、跳过 | 按阶段记录进入与结束状态 |
| 作业状态 | 未开始、执行中、成功、失败、取消、跳过、超时 | 作业是失败定位的最小单元 |
| 失败原因分类 | 环境、依赖、测试、配置、代码、其他 | 由处置人确认后填写，避免仅凭日志关键词自动归类 |
| 重试次数 | 整数 | 同一作业或同一运行的重试次数，需说明统计层级 |
| 人工介入标记 | 是、否 | 标记是否有人工重跑、手动放行或干预处置 |
终态的区分直接影响后续统计。取消通常来自主动中止或新提交顶替，跳过多由条件判断触发，超时说明执行超出预期上限，三者与失败的性质不同，混在一起会掩盖真实问题。失败原因分类建议保留“其他”并允许补充说明，因为环境抖动、依赖下载失败、测试用例不稳定、配置错误和代码缺陷的处置路径差异很大，分类准确才能支撑协调分工。
重试次数和人工介入标记容易被忽略，却对解读时效指标很关键。一次运行经历多次重试后成功，端到端时长会被拉长，若不做标记，容易被误读为流水线变慢。人工介入标记则能帮助区分自动恢复与人工处置，评估异常协调的实际工作量。
时效指标：各段耗时怎么定义和计算
时效指标需要给出公式、单位、时间窗和分母，保证任何人拿到原始记录都能复算。建议统一以秒或分钟为单位，同一张报表内不混用；时间窗按周或按迭代固定，跨窗口比较时说明起止边界。
| 指标 | 计算公式 | 单位 | 分母口径 |
|---|---|---|---|
| 排队等待时长 | 开始执行时间 − 触发时间 | 秒 | 按运行次数统计，排除未进入排队的运行 |
| 执行时长 | 结束时间 − 开始执行时间 | 秒 | 按运行次数统计，取消与跳过单独列出 |
| 端到端时长 | 结束时间 − 触发时间 | 秒 | 按运行次数统计，需说明是否含排队 |
| 阶段时长 | 阶段结束时间 − 阶段开始时间 | 秒 | 按阶段次数统计，同一运行ID内聚合 |
| 作业时长 | 作业结束时间 − 作业开始时间 | 秒 | 按作业次数统计 |
| 失败发现时长 | 失败被认领时间 − 运行失败时间 | 分钟或小时 | 按失败运行次数统计 |
| 失败恢复时长 | 修复后首次成功时间 − 首次失败时间 | 小时 | 按失败事件统计，需固定同一代码分支范围 |
| 重跑间隔 | 下一次运行触发时间 − 上一次运行结束时间 | 分钟 | 按相邻运行对统计 |
阶段与作业时长要区分串行和并行。串行阶段的时长可以直接相加，并行阶段相加会超过端到端时长，此时应分别报告“阶段时长之和”和“端到端时长”，并注明并行度。按运行ID聚合时，同一运行内多个作业的时长可以求和用于分析资源消耗，但判断用户感知的等待时间应以端到端时长为准。
失败发现时长和失败恢复时长需要明确时间窗。失败发现时长衡量从运行失败到有人认领的间隔，认领动作可以是更新工作项状态、在协作渠道响应或指派处理人，团队需事先约定哪种动作算认领。失败恢复时长衡量从首次失败到修复后首次成功，统计时应限定同一分支或同一合并请求范围，避免把无关的成功运行算作恢复。分母为零的情况要单独处理：时间窗内没有失败运行时，失败恢复时长记为“无样本”，不写为零，也不参与均值计算。
分母口径需要在报表上显式标注。按运行次数统计时，取消和跳过是否计入要固定规则，建议成功率的分母排除取消与跳过，另设一列展示其数量；按阶段次数或作业次数统计时，分母是阶段或作业的出现次数，同一运行可能贡献多个样本，均值含义与按运行统计不同，不能直接比较。
数据口径与证据：时间戳、缺失值和可比性
时效指标可复算的前提是时间戳来源统一。建议全部采用流水线平台的事件时间，而不是日志打印时间或采集端接收时间，因为日志时间受缓冲和时钟偏差影响，采集端时间会引入传输延迟。时区统一为团队约定的标准时区并在报表中注明，精度至少到秒；跨时区团队尤其要避免本地时间直接入库。
运行ID是关联的主键。阶段、作业、代码提交、触发人、关联工作项都应挂到同一个运行ID下，这样既能从一次失败运行追溯到具体提交，也能从需求或工作项反查相关运行。若平台提供上游流水线触发关系，还应记录父运行ID，便于分析跨流水线的等待。
数据质量问题需要明确处理规则，而不是事后凭感觉剔除。常见情况包括：时间戳缺失，标记为“不完整运行”并从时效统计中排除，同时计入完整性指标；事件乱序到达，按事件时间排序后重新计算，不按接收顺序；重复上报，以运行ID加事件类型加时间戳去重，保留最早一条。每条剔除规则都应记录剔除数量，避免统计口径悄悄变化。
跨项目、跨流水线比较前要对齐变量。环境差异（开发、测试、生产）、并行度、作业规模、依赖下载缓存策略都会影响时长，直接比较绝对值容易得出错误结论。可行做法是先在同一环境、相似作业规模的分组内比较，或改用同组内的分位数变化来观察趋势。
采集与评估步骤：从字段到判断结论
采集工作从字段定义开始。先按前两节的字段表和公式表确定事件清单，再在流水线平台侧通过事件回调、接口导出或日志解析落表，所有记录以运行ID为主键写入同一张运行事实表，阶段和作业作为明细表关联。字段定义确定后不宜频繁变更，变更时保留版本号，避免历史数据口径断裂。
完整性校验可以按以下顺序执行：
- 统计每次运行的必备字段缺失率，必备字段至少包括触发时间、开始执行时间、结束时间、终态；
- 检查状态跳变是否连续，例如出现“结束”却没有“开始”，或阶段状态跳过执行中直接到成功；
- 核对阶段与作业数量是否与平台配置一致，识别漏采；
- 将不完整运行单独列出，分析集中在哪类触发方式或哪条流水线。
及时性校验关注延迟分布而非单一均值。可以统计状态更新延迟的中位数和尾部值，即状态实际发生到在跟踪界面可见的间隔；再统计失败运行从失败到被认领的间隔分布。尾部值偏大往往说明通知链路或值班安排存在问题，比均值更能暴露协调缺口。
汇总节奏建议按周或按迭代固定，输出一页包含运行总数、终态构成、各段时长分位数、完整性缺失率和恢复时长的简报。解读时结合异常协调记录：如果某周恢复时长下降，同时协作记录显示认领和处置更及时，才能说明改进起了作用；若指标变化而处置记录没有对应变化，需要先排查数据口径或作业规模变化。
在工具承载上，ONES 可集成 Jenkins、GitLab CI 等第三方流水线工具，同步流水线数据并更新执行状态和日志，并把流水线与项目关联，在项目、迭代、需求中呈现构建与发布过程。团队可以把运行记录关联到对应工作项，让失败运行有明确的责任上下文，处置动作和状态更新留在同一处，便于后续核对失败发现与恢复的实际情况。报表能提供到什么粒度，以实际集成的字段范围为准。
一个计算示例：单条流水线与一周汇总
以下为演示情景，数字用于说明计算过程。
单次运行示例：某次运行由合并请求触发，触发时间为 10:00:00，10:00:40 开始执行，10:06:10 结束，终态成功。则排队等待时长为 40 秒，执行时长为 5 分 30 秒即 330 秒，端到端时长为 6 分 10 秒即 370 秒。该运行包含构建、单元测试、集成测试三个阶段，时长分别为 90 秒、120 秒、120 秒，串行执行，阶段时长之和为 330 秒，与执行时长一致。
一周汇总示例：某流水线一周内共触发 50 次运行，其中成功 40 次、失败 6 次、取消 3 次、跳过 1 次。若成功率分母排除取消与跳过，则成功率为 40 ÷ 46 ≈ 87.0%；若分母计入全部运行，则为 40 ÷ 50 = 80.0%。两种口径都可用，但必须在报表中注明，且前后周保持一致。端到端时长取这 50 次运行的中位数和 90 分位，分别反映典型体验和尾部等待。
失败恢复示例：6 次失败运行中，有 4 次在同一分支上修复后重新运行成功。第一次失败发生在周一 14:00，修复后成功在周一 16:30，恢复时长为 2.5 小时；其余三次按同样方法计算后取中位数。另外 2 次失败属于环境问题，重跑即通过，可按规则单独归类，不与代码修复混算。若某一周没有失败运行，恢复时长记为“无样本”，报表显示横线而非 0。
缺失值处理示例：一周内有 2 次运行缺少开始执行时间，无法计算排队等待时长和执行时长。这 2 次运行标记为不完整，从时效统计的分母中排除，同时计入完整性指标，即缺失率为 2 ÷ 50 = 4%。若缺失集中在定时触发场景，应优先排查该触发方式的时间戳采集。
解读与限制：指标能说明什么、不能说明什么
时长变化需要谨慎归因。端到端时长上升，可能来自作业规模增加、并行度调整、依赖下载变慢或执行环境波动，也可能确实来自流程改进的反向效果。没有同步记录作业规模和环境信息时，单看时长曲线无法区分这些原因。可行做法是把时长与作业数量、并行度、缓存命中情况放在一起看，必要时抽取具体运行对照日志。
成功率对分母口径敏感。取消和跳过是否计入，会让同一批数据得出不同数值，因此规则一旦确定就应固定并在报表中展示分母构成。成功率反映的是运行结果分布，不能替代发布准入判断；一次运行成功不代表产物可以发布，发布还需要质量门禁、审批和变更范围等条件，这些属于发布审批与质量门禁的范围。
指标组合使用比单指标更可靠。完整性缺失率说明数据是否可信，状态更新延迟说明跟踪是否及时，失败恢复时长说明协调是否有效，三者结合才能判断跟踪体系的整体状况。任何单一指标都不足以支撑因果结论，也不适合直接作为个人绩效依据。指标的价值在于让异常更早被看见、让处置有据可查、让改进可被验证，超出这个范围的使用需要额外的证据和方法。
常见问题
流水线运行被取消或跳过时，时效指标应该怎么统计？
取消和跳过与失败性质不同，建议在状态指标中单独记录终态，在时效统计中分开处理。执行时长和端到端时长可以照常计算并单独列出，但成功率的分母需要固定规则：常见做法是排除取消与跳过，另设一列展示其数量，并在报表中注明分母构成。规则一旦确定，前后周和跨流水线比较都应保持一致，否则同一批数据会得出不同数值。
失败恢复时长按什么范围统计才不会被无关运行干扰？
失败恢复时长衡量从首次失败到修复后首次成功，统计时应限定在同一分支或同一合并请求范围内，避免把其他分支的成功运行算作恢复。若失败由环境问题导致、重跑即通过，建议单独归类，不与代码修复混算。时间窗内没有失败运行时，记为“无样本”，报表显示横线而非 0，也不参与均值计算。
状态更新延迟这类及时性指标，采集端能直接算出来吗？
可以，但需要两个时间点：状态实际发生的时间和状态在跟踪界面可见的时间。前者取自流水线平台的事件时间，后者取自跟踪系统的入库或展示时间，两者相减得到延迟。建议统计中位数和尾部值，尾部偏大往往说明通知链路或值班安排存在缺口。若平台只提供日志时间，需先确认时钟同步情况，否则延迟会被日志缓冲和时钟偏差污染。
跨项目比较流水线时长时，需要先对齐哪些变量？
环境（开发、测试、生产）、并行度、作业规模、依赖下载缓存策略都会影响时长，直接比较绝对值容易得出错误结论。可行做法是先在同一环境、相似作业规模的分组内比较，或改用同组内的分位数变化观察趋势。跨流水线比较时还应确认时间窗起止边界和分母口径一致，否则差异可能来自统计规则而非执行状况。
这些指标能否直接用于评估团队或个人的交付表现？
不建议。指标反映的是流水线运行及其阶段、作业的状况，时长变化可能来自作业规模、并行度或环境波动，成功率受分母口径影响，单指标不足以支撑因果结论。更合适的用法是组合完整性缺失率、状态更新延迟和失败恢复时长，用于发现异常、协调处置和验证改进效果。若确需用于绩效场景，需要额外的证据和方法支撑。
