流水线执行跟踪的核心，是围绕一次交付流建立可核对的状态链：每次运行都能回答“跑到哪、卡在哪、谁接手、能否放行”。本文按记录口径、跟踪步骤、角色分工、完整示例和完成检查五部分展开，覆盖从触发到关闭的执行跟踪方法；流水线与研发平台的接口配置、发布准入规则设计不在本文范围内。
要点总览（TL;DR）
- 跟踪以“一次运行”为记录单位，必填字段覆盖运行标识、触发来源、关联需求、代码版本、节点状态、时间、失败原因、产物去向和处置结论，状态统一为排队、执行中、成功、失败、中止、待人工确认六种。
- 跟踪按触发登记、阶段推进、失败处置、产物与放行衔接、运行关闭五步推进，每步都有输入、动作、输出和完成标志，失败记录须同时具备接手人、原因分类和处置结论。
- 角色按提交者/开发、流水线维护者、测试与发布角色、交付负责人划分，交接物统一落在运行记录及关联工作项中，口头同步不作为状态依据。
- 完成检查从可追溯性、状态及时性、失败接手、产物对应、关闭结论和复盘可用性六个方面设置通过标准与证据，问题按字段缺失、状态滞后、责任空缺三类归集整改。
跟踪对象与状态字段怎么定
跟踪范围先按交付流划定，再落到具体流水线。建议以“一条能支撑某个环境发布的最小流水线集合”为跟踪单元，例如从代码合并到测试环境部署的构建、单元测试、镜像打包、部署四个节点。范围确定后，把纳入跟踪的分支和环境写清楚：主干分支与发布分支纳入，临时验证分支可按需登记；测试、预发、生产环境分别对应不同的流水线实例，避免用一条流水线的状态代表全部环境。
记录单位是“一次运行”，每次运行生成一条独立记录，字段分为必填与选填。必填字段保证任何一次运行都能被追溯和判断，选填字段用于补充分析。
| 字段名 | 含义 | 必填 | 维护角色 |
|---|---|---|---|
| 运行标识 | 本次运行的唯一编号，与流水线工具中的运行号对应 | 必填 | 流水线维护者（由工具自动生成，人工核对） |
| 流水线名称与环境 | 所属流水线及目标环境（测试/预发/生产） | 必填 | 流水线维护者 |
| 触发来源 | 人工触发、代码合并触发、定时触发或上游流水线触发 | 必填 | 提交者/开发 |
| 关联需求或变更 | 本次运行对应的需求单、缺陷单或变更单编号 | 必填 | 提交者/开发 |
| 代码版本 | 分支名与提交号，多仓库时逐一列出 | 必填 | 提交者/开发 |
| 阶段与节点状态 | 构建、测试、部署等各节点的当前状态 | 必填 | 流水线维护者（工具回写，异常时人工修正） |
| 开始与结束时间 | 运行开始、各阶段起止、整体结束时间 | 必填 | 流水线维护者 |
| 失败原因 | 失败节点、错误摘要、日志定位信息 | 失败时必填 | 提交者/开发填写，流水线维护者复核 |
| 产物与去向 | 产物名称、版本号、存放位置及部署目标 | 成功时必填 | 流水线维护者 |
| 处置结论 | 重跑、回滚、修复后重提或终止的原因说明 | 失败或中止时必填 | 提交者/开发 |
| 备注 | 环境异常、依赖变更等补充说明 | 选填 | 任一角色 |
状态取值统一为六种：排队、执行中、成功、失败、中止、待人工确认。“待人工确认”用于自动化节点通过但需要人工判断的环节，例如部署前的人工核验；把它单独列出，可以避免人工等待被误记为执行中。状态口径由流水线维护者统一发布，各团队按同一套取值填写，不再自造“基本通过”“部分成功”等中间状态。
从触发到放行的跟踪步骤
跟踪按时间顺序推进，每一步都有明确的输入、动作、输出和完成标志。以下五步适用于大多数交付流，节点数量可按流水线实际阶段增减。
第一步：触发登记
输入是待交付的需求或变更、待合并的代码版本。动作是提交者在触发流水线前确认关联工作项已就绪，触发后登记触发来源、关联需求编号和代码版本。输出是一条带有运行标识的初始记录，状态为排队或执行中。完成标志是运行记录中触发来源、关联需求、代码版本三项均已填写，且能在工作项中反查到这次运行。
第二步：阶段推进记录
输入是流水线各节点的执行结果。动作是构建、测试、部署节点每完成一个，就更新对应节点状态与起止时间；节点失败时立即置为失败并保留日志定位信息。输出是反映当前进度的阶段状态序列。完成标志是所有已执行节点的状态与时间均已更新，且与流水线工具中的运行详情一致。若工具已自动回写状态，人工只需核对异常节点，避免重复维护。
第三步：失败处置
输入是失败节点的错误摘要与日志。动作是提交者在约定时限内认领失败，判断属于代码问题、环境问题还是流水线配置问题，填写失败原因并指派处理人；修复后重跑或调整配置，把结论回填到处置结论字段。输出是带责任人和结论的失败记录。完成标志是失败记录有明确接手人、有原因分类、有最终处置结论，三者缺一不可。
第四步：产物与放行衔接
输入是成功运行产生的构建产物。动作是流水线维护者登记产物名称、版本号和存放位置，并把产物版本与运行标识绑定；需要进入下一环境的，在记录中标注目标环境和待确认状态。输出是可与运行记录互相追溯的产物清单。完成标志是每个进入待发布状态的产物都能通过版本号找到对应的运行记录，后续准入判断直接引用该记录，不再另行整理。
第五步：运行关闭
输入是本次运行的最终状态。动作按三类结束方式收尾：成功运行确认产物已归档、关联需求状态已更新；失败运行确认已修复重跑或已终止并说明原因；中止运行记录中止原因和后续安排。输出是关闭状态的运行记录。完成标志是记录中不再存在“执行中”或“待人工确认”的悬置状态，且关闭结论可供复盘引用。
角色分工与各环节交付物
状态无人更新通常源于职责边界不清。按四类角色划分，每个角色只维护自己负责的字段和交接物，可以减少重复填写。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 提交者/开发 | 触发前确认关联需求与代码版本；失败后第一时间认领，判断原因并回填处置结论 | 触发登记信息、失败原因与处置结论 |
| 流水线维护者 | 定义节点与状态口径；核对工具回写的状态；处理环境与配置类异常；异常超时升级 | 状态口径说明、节点定义、异常升级记录 |
| 测试与发布角色 | 在测试通过、部署完成等关键节点确认结果，回填确认结论 | 节点确认记录、测试结论 |
| 交付负责人 | 汇总当前批次运行状态，判断是否进入下一环节，关闭运行记录 | 批次状态汇总、放行判断结论 |
交接发生在三个时点：开发把失败记录交给处理人时，需附错误摘要和已排查范围；流水线维护者把异常升级给交付负责人时，需附影响范围和已尝试的处置；测试与发布角色确认节点后，把结论回填到运行记录，交付负责人据此判断放行。交接物统一落在运行记录及其关联工作项中，口头同步只作为提醒，不作为状态依据。
当团队使用 ONES 管理需求与流水线时，可以把运行记录与需求、任务等工作项关联：ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，并在项目、迭代、需求中可视化代码提交、流水线构建与产品发布过程。这样，触发登记中的关联需求、失败处置中的责任人指派、放行前的状态汇总可以在同一工作项上下文中完成，减少在工具之间来回核对。
一次完整跟踪的运行示例
以下为演示情景，用于说明字段与步骤如何配合，数据为示意。
背景：需求单 REQ-218 需要修改订单导出逻辑，开发在 feature/export 分支完成提交，准备进入测试环境验证。
触发登记。开发确认 REQ-218 已进入开发中状态，合并代码后触发测试环境流水线，登记：运行标识 RUN-1042，流水线“订单服务-测试环境”，触发来源为代码合并，关联需求 REQ-218，代码版本 feature/export @ a1b2c3d。状态置为执行中。
阶段推进。构建节点 10:02 开始、10:05 成功；单元测试节点 10:05 开始、10:09 失败，失败原因为导出用例断言不通过，日志定位到 ExportServiceTest 第 47 行。记录状态更新为失败，其余节点标记为未执行。
失败处置。开发在 10:15 认领，判断为代码问题，指派自己处理，补充说明“空数据场景未处理”。修复后提交新版本 a1b2c3e，重跑生成 RUN-1043，处置结论填写“修复后重跑”。RUN-1042 关闭为失败，保留原记录供复盘。
产物与放行衔接。RUN-1043 构建、测试、部署节点依次成功，产物 order-service:1.4.2-rc1 归档到制品库，记录中标注目标环境为预发、状态待人工确认。测试角色在预发验证通过后回填确认结论，交付负责人将状态更新为成功并注明“可进入发布评审”。
角色交接。开发把失败记录与修复说明交给测试角色；测试角色把预发验证结论回填运行记录；交付负责人依据 RUN-1043 的完整记录判断进入下一环节。整个过程通过运行标识与需求编号双向可查。
迁移到其他流水线时，需要调整的是节点划分和产物类型：例如前端流水线把单元测试替换为构建产物校验，部署节点改为静态资源发布；字段和步骤保持不变。若流水线包含多环境连续部署，可为每个环境各建一条运行记录，用上游运行标识串联。
跟踪是否到位的完成检查
以下清单可用于月度自查或交付评审，每项给出通过标准、证据来源和负责人。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 运行可追溯到触发来源与代码版本 | 抽查近两周运行，100% 记录含触发来源、关联需求、代码版本 | 运行记录与工作项关联截图 | 流水线维护者 |
| 阶段状态及时更新 | 节点结束后 30 分钟内状态更新，无长期停留在执行中的记录 | 运行记录时间戳对比 | 流水线维护者 |
| 失败有明确接手人 | 失败记录均有责任人和原因分类，无未指派失败 | 失败记录清单 | 提交者/开发 |
| 产物与运行记录可对应 | 进入待发布状态的产物均能通过版本号找到运行记录 | 产物清单与运行记录对照 | 流水线维护者 |
| 运行结束后有关闭结论 | 无悬置状态，成功、失败、中止均有收尾说明 | 关闭状态统计 | 交付负责人 |
| 记录可用于复盘与放行判断 | 随机抽取一次发布，能仅凭运行记录说明放行依据 | 发布评审记录 | 交付负责人 |
检查发现的问题按字段缺失、状态滞后、责任空缺三类归集，分别对应补充必填校验、调整状态更新时点、明确角色交接规则。连续两个检查周期通过标准全部满足，可认为跟踪机制进入稳定运行；若失败记录长期缺少原因分类，应优先检查失败处置环节的时限约定是否合理，而非增加更多字段。
常见问题
流水线运行失败后重跑，原记录应该保留还是覆盖？
保留原记录，重跑生成新的运行标识。原运行以失败状态关闭，并在处置结论中写明“修复后重跑”及对应新运行标识；新运行独立记录触发来源、代码版本和阶段状态。这样复盘时能看清失败原因与修复动作的对应关系，放行判断也只引用最终成功的那次运行。
一条流水线连续部署多个环境，需要为每个环境单独建运行记录吗？
建议为每个环境各建一条运行记录，用上游运行标识串联。原因是不同环境的触发条件、确认角色和产物去向不同，合并成一条记录会让状态口径混乱，例如测试环境已成功而预发仍在等待人工确认时，单一状态无法准确表达。若环境之间是自动连续推进且无需分别确认，也可以合并记录，在阶段状态中按环境分段标注。
工具已经自动回写状态，人工还需要维护哪些字段？
工具回写通常覆盖节点状态、起止时间和日志，人工重点维护三类内容：触发前的关联需求与变更编号、失败后的原因分类与处置结论、产物归档后的去向与放行确认。这些字段依赖人的判断，工具难以自动生成。人工核对时优先检查异常节点，正常节点以工具回写为准，避免重复维护。
团队规模较小，角色分工能否合并？
可以合并角色，但要保留职责边界。例如开发同时承担提交者和失败处置责任，交付负责人同时承担放行判断和运行关闭，此时需在记录中明确每个字段的维护人，避免出现“都以为对方会填”的空缺。合并后仍建议保留流水线维护者的独立职责，状态口径和节点定义的统一需要有人专门负责。
跟踪记录如何与发布准入衔接？
跟踪记录为发布准入提供输入，准入规则本身属于发布审批与质量门禁的设计范围。衔接点在产物与运行记录绑定：进入待发布状态的产物能通过版本号找到对应运行记录，记录中包含阶段状态、失败处置结论和确认人。准入评审直接引用该记录判断是否放行，不再另行整理材料。若准入要求补充安全扫描或人工审批结论，可在运行记录的备注或关联工作项中挂接，保持引用关系不变。
