流水线执行跟踪的依据，核心是让团队在事后能回答三个问题：这次执行由什么触发、按什么规则运行、结果是否可核验。围绕这三点，可以把依据归为触发与版本、配置、执行过程、质量与准入、变更与关联五类。下面按“记录什么—怎么采集—谁来归档—如何复盘—怎样验收”的顺序，给出一套可直接落地的依据清单与操作步骤，适用于使用持续集成与持续交付流水线的研发团队。
要点总览（TL;DR）
- 流水线执行跟踪的依据分为五类：触发与版本、配置、执行过程、质量与准入、变更与关联，每类对应一个复盘时必须回答的判断问题。
- 触发源、制品版本、阶段起止时间、失败与重试记录、门禁结论建议列为必须记录项；执行节点、人工干预说明、审批链可按团队规模与发布频率按需扩展。
- 依据采集嵌入流水线各阶段，随执行自动产生或由责任人在固定节点填写，并按“产出者即归档者”分工，避免事后补录。
- 验收标准是仅凭记录、不询问当事人即可独立还原一次执行；触发源缺失、门禁结论无证据、关联对象缺失应阻断归档并限期补齐。
- 当某类缺口反复出现时，优先把它改为流水线中的自动采集项，从源头减少人工补录。
先定跟踪对象：一次流水线执行要记录哪些依据
跟踪依据的设计起点是确定“一次执行”作为记录单元。每次流水线运行生成一条独立记录，所有依据挂在这条记录下，而不是散落在聊天记录或个人本地日志中。五类依据分别回答一个判断问题，缺哪一类，复盘时就会出现对应的盲区。
| 依据类别 | 回答的判断问题 | 典型字段 | 记录要求 |
|---|---|---|---|
| 触发与版本 | 这次执行是谁、以什么方式、基于哪份代码或制品发起的 | 提交号、分支或标签、制品版本号、触发方式（提交触发、定时触发、手动触发）、发起人、触发时间 | 必须记录 |
| 配置 | 这次执行按什么规则运行，环境与依赖是什么 | 流水线定义版本或配置文件版本、环境标识、环境参数、依赖组件版本、密钥与凭证的引用标识 | 必须记录 |
| 执行过程 | 各阶段实际发生了什么，是否出现过中断或人工介入 | 阶段名称、各阶段起止时间、执行节点、日志位置、失败原因、重试次数与重试原因、人工干预说明与操作人 | 阶段起止时间、失败与重试记录必须记录；执行节点、人工干预说明按需扩展 |
| 质量与准入 | 结果是否达到进入下一环节的标准 | 测试用例执行结果、扫描报告、门禁规则版本、门禁判定结论、判定时间 | 必须记录 |
| 变更与关联 | 这次执行服务于哪个需求、缺陷或变更，是否经过必要审批 | 关联需求或缺陷编号、变更单编号、审批记录、关联人 | 关联对象必须记录；审批记录按发布管理要求按需扩展 |
区分必须记录与按需记录，目的是控制采集成本。触发源、制品版本、阶段起止时间、失败与重试记录、门禁结论这五项，任何一次执行都应具备，否则无法独立还原过程。执行节点、人工干预的详细说明、关联变更单的完整审批链，可以按团队规模与发布频率决定是否纳入。小团队高频发布时，可先保证必须项齐全，再逐步补充扩展项。
字段定义完成后，建议形成一份团队共用的字段说明，写明每个字段的取值格式与填写位置，例如提交号采用完整哈希还是短哈希、制品版本采用构建号还是语义化版本。字段口径统一，后续的检索、比对和报表才有意义。
按阶段落地：从触发到归档的操作步骤
依据采集应嵌入流水线各阶段本身，随执行自动产生或由责任人在固定节点填写，避免事后补录。下表按阶段列出输入、动作、输出与完成标志。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 触发 | 代码提交、定时计划或手动发起请求 | 记录触发方式、提交号、分支或标签、发起人与触发时间，写入执行记录头部 | 执行记录已创建并带触发信息 | 执行记录中触发字段完整，可定位到具体提交 |
| 构建与配置 | 流水线定义文件、环境参数、依赖清单 | 固定本次使用的流水线定义版本，记录环境标识与关键参数，登记依赖与密钥的引用标识 | 配置快照与构建产物版本号 | 配置版本与制品版本已写入记录，二者可对应 |
| 执行 | 构建产物、部署目标环境 | 按阶段记录起止时间与日志位置；出现失败时记录失败阶段与原因；发生重试时记录重试次数与原因；有人工介入时记录操作人与操作内容 | 阶段级执行明细 | 每个阶段均有起止时间，失败与重试均有对应说明 |
| 质量门禁 | 测试结果、扫描报告、门禁规则 | 汇总测试与扫描结果，记录门禁规则版本与判定结论，注明判定时间 | 门禁判定记录及证据链接 | 判定结论明确为通过或不通过，且能追溯到具体报告 |
| 归档与关联 | 执行记录、关联需求或缺陷、变更单 | 将执行记录与需求、缺陷、变更单建立关联，补充审批记录，归档至团队约定的位置 | 完整执行档案 | 从需求或变更单可反查到本次执行，反之亦然 |
落地时有两个细节值得注意。其一，配置依据要记录“本次实际使用的版本”，而非“当前最新版本”，否则环境参数调整后无法还原当时的运行条件。其二，重试与人工干预是高频争议点，建议在流水线中设置强制填写项：一旦触发重试或人工操作，必须选择原因分类并留下说明，否则不进入下一阶段。
当团队使用 ONES 管理研发过程时，可以在执行记录与工作项关联这一环节衔接：ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并将流水线与项目关联；代码提交也可与业务工作项关联，便于从需求侧查看对应的构建与发布过程。这样，执行记录与需求、任务的关联不必依赖人工在多个系统间搬运。
角色与交付物：谁产出哪份依据
依据无人归档是跟踪体系失效的常见原因。分工原则是“产出者即归档者”：谁在流程中产生这份依据，谁负责把它写入约定位置。下表给出典型分工，团队可按实际岗位合并或拆分。
| 角色 | 主要职责 | 交付物 | 归档位置 |
|---|---|---|---|
| 流水线维护者 | 维护流水线定义与门禁规则，保证采集字段随执行自动生成 | 流水线定义版本记录、配置快照、门禁规则版本 | 流水线配置库与执行记录系统 |
| 开发提交人 | 发起执行，说明提交意图，处理失败与重试 | 提交号与分支信息、失败原因说明、重试原因说明 | 执行记录对应字段与提交说明 |
| 测试与质量负责人 | 提供测试与扫描结果，确认门禁判定 | 测试结果、扫描报告、门禁判定结论 | 质量报告库，并在执行记录中挂接证据 |
| 发布负责人 | 确认发布范围，关联需求与变更单，核对审批记录 | 关联关系、审批记录、发布结论 | 需求或变更单，以及执行记录的关联字段 |
交接点需要设置核对动作。触发到构建之间，由流水线维护者确认配置版本已固定；执行完成到门禁判定之间，由质量负责人确认报告齐全；门禁通过到归档之间，由发布负责人确认关联对象完整。每个交接点核对通过才进入下一环节。
依据缺失时的处理方式应事先约定：缺失必须项时，阻断进入下一阶段，由对应角色在约定时限内补齐；缺失按需项时，记录缺口并在复盘时评估是否升级为必须项。阻断规则要写进流水线或发布检查单，避免依赖口头提醒。
示例：一次失败执行的跟踪记录如何还原
以下为演示情景，用于说明依据如何支撑复盘，不指向具体团队的真实事件。
某次发布中，构建阶段通过，部署阶段失败。复盘时，团队按记录逐项还原：触发与版本依据显示，本次执行由开发提交人手动触发，基于分支 release-2.4 的提交 a1b2c3，制品版本为 build-1187。配置依据显示，流水线定义版本为 v12，部署环境为预发布环境，环境参数中数据库连接地址在本次执行前有过调整。执行过程依据显示，部署阶段在启动后约两分钟失败，日志指向连接超时，期间有一次重试，重试原因为网络抖动，操作人留下了说明。质量与准入依据显示，单元测试与扫描均通过，门禁判定为通过，说明问题不在代码质量。变更与关联依据显示，本次执行关联需求编号与一张配置变更单，变更单的审批记录完整。
把五类依据放在一起，结论就清晰了：失败原因指向部署环境的参数调整，而非代码或制品本身；重试记录排除了偶发网络问题的可能；门禁结论说明质量环节无需复查。团队据此回滚参数并重新执行，同时在配置变更流程中增加“变更后首次部署需由变更发起人确认环境参数”的核对动作。
从这个示例可以提炼几条可迁移的记录习惯：手动触发必须写明目的；环境参数调整要关联到变更单；重试必须填写原因；门禁结论要能链接到原始报告。这些习惯的共同点是让每条依据都能被独立核验，而不依赖当事人回忆。
完成检查：跟踪依据是否够用的核对项
判断依据是否够用，标准是：不询问当事人，仅凭记录能否独立还原一次执行。以下清单可按次核对，也可作为阶段门禁的检查项。
| 核对项 | 通过标准 | 不通过时的补齐条件 |
|---|---|---|
| 触发源可追溯 | 能定位到具体提交号、分支或标签、触发方式与发起人 | 由提交人补充触发信息，无法确认时标记为异常执行 |
| 制品版本可追溯 | 执行记录中的制品版本与实际部署产物一致 | 核对构建产物清单，补登版本号 |
| 配置可还原 | 流水线定义版本、环境标识与关键参数均有记录 | 由流水线维护者导出配置快照并归档 |
| 失败与重试有记录 | 每次失败有阶段与原因，每次重试有次数与原因 | 由操作人补填说明，缺失原因的重试计入复盘问题 |
| 人工干预有留痕 | 干预人、干预内容与时间可查 | 补充操作说明，并在后续执行中启用强制填写 |
| 门禁结论有证据 | 判定结论明确，且能链接到测试或扫描报告 | 由质量负责人补挂报告，无法补挂时判定为无效门禁 |
| 关联对象完整 | 需求、缺陷或变更单可从执行记录反查，审批记录齐全 | 由发布负责人补齐关联，缺失审批的发布需重新确认 |
阻断项建议设为三类：触发源缺失、门禁结论无证据、关联对象缺失。这三项直接影响执行结果的可信度，出现时应阻断归档并限期补齐。其余核对项不通过时，可先记录缺口，在复盘中评估影响。
清单之外，团队可以定期抽查一批执行记录，按上述标准逐项核对，统计缺口类型与分布。当某类缺口反复出现时，优先考虑把它改为流水线中的自动采集项，从源头减少人工补录。ONES 支持在项目、迭代、需求中查看代码提交、流水线构建与产品发布等过程，并提供数据报表用于追溯工具链操作，可作为抽查与改进的辅助手段；具体报表指标口径以实际配置为准。
常见问题
小团队发布频率高，五类依据能否先只做一部分？
可以，但必须项不能省。建议先保证触发源、制品版本、阶段起止时间、失败与重试记录、门禁结论这五项齐全，它们决定了一次执行能否被独立还原。执行节点、人工干预的详细说明、关联变更单的完整审批链，可以先按需记录，等发布节奏稳定后再逐步纳入必须项。压缩采集范围时，要同步更新字段说明和检查清单，避免不同成员按不同口径填写。
流水线执行记录和需求、变更单之间的关联，靠人工维护还是系统自动完成？
取决于团队使用的工具。若流水线平台与研发管理工具已经集成，关联可以由系统同步完成。以 ONES 为例，其 DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并将流水线与项目关联；代码提交也可与业务工作项关联。若尚未集成，则需要发布负责人在归档环节人工补齐关联，并把这一步写入交接核对动作。
重试和人工干预为什么容易成为跟踪缺口，怎么处理？
这两类动作通常发生在执行中途，操作人关注的是尽快恢复，容易忽略填写原因。处理方式是在流水线中设置强制填写项：一旦触发重试或人工操作，必须选择原因分类并留下说明，否则不进入下一阶段。原因分类可以按网络、环境、配置、代码等维度预设，减少填写负担。复盘时，缺失原因的重试应计入问题清单，推动后续执行规范填写。
依据缺失时，是阻断推进还是先记录缺口？
按缺失类型区分。触发源缺失、门禁结论无证据、关联对象缺失这三类直接影响执行结果的可信度，应阻断归档并限期补齐。其余核对项不通过时，可以先记录缺口，在复盘中评估影响。阻断规则要写进流水线或发布检查单，明确补齐责任人与时限，避免依赖口头提醒。
定期抽查执行记录时，重点看什么？
重点看缺口的类型与分布，而不是单次执行的对错。按完成检查清单逐项核对一批记录，统计哪类字段缺失最频繁、集中在哪些阶段或哪些角色。当某类缺口反复出现时，优先考虑把它改为流水线中的自动采集项。ONES 支持在项目、迭代、需求中查看代码提交、流水线构建与产品发布等过程，并提供数据报表用于追溯工具链操作，可作为抽查的辅助手段，具体报表指标口径以实际配置为准。
