本文给出一份可直接对照填写的流水线阶段责任示例，以“提交代码—构建—自动化测试—预发布验证—生产发布”五阶段为假设情景，逐阶段写清负责人、执行人、评审/准入人、输入、产出、完成标准和异常升级路径。示例为演示情景，不指向真实客户或实测结果；文中也会说明如何改造成自己团队的版本，以及哪些条件下不宜照搬。ONES 可在工作项与文档状态中承载责任分工与交接记录，后文按已有依据简述衔接方式。
要点总览（TL;DR）
- 阶段责任表按八列组织：阶段、负责人、执行人、评审/准入人、输入、产出、完成标准、异常升级，覆盖一个阶段从进入到离开的完整责任链。
- 负责人与执行人分开设置，让计划与验收责任独立于具体操作；完成标准写成可判断的通过条件，例如“构建成功且产物可下载、版本号可追溯”。
- 异常升级按阶段风险设定，越靠近生产发布，升级层级越高、响应要求越紧；交接物落到工作项状态、构建记录或评审文档上，交接才可追踪。
- 迁移到其他团队时，先按实际交付形态定阶段，再把角色映射到岗位，逐阶段写完成标准与升级路径，并约定随组织与流水线变化定期维护。
- 示例基于约二十人团队、每周两次发布的假设情景，团队规模、发布频率或交付形态差异较大时需调整阶段划分与角色设置，强监管场景还需额外准入设计。
示例目标：这份阶段责任表要解决什么问题
这份示例要交付的成果是一张“阶段责任表”，它回答一个具体问题：流水线跑起来之后，每个阶段由谁计划、谁操作、谁放行、出了问题找谁。责任表把口头约定变成可对照检查的条目，让交接有物可交、有据可查。
示例采用八列结构，覆盖一个阶段从进入到离开的完整责任链：
- 阶段：流水线中的一个环节，按交付顺序排列。
- 负责人：对该阶段的计划、资源与最终结果负责的人。
- 执行人：实际动手操作或触发该阶段的人。
- 评审/准入人：判断该阶段能否通过、能否进入下一阶段的人。
- 输入：进入该阶段前必须具备的物料或状态。
- 产出：该阶段结束时留下的可检查结果。
- 完成标准：判断该阶段“做完了”的可验证条件。
- 异常升级：失败、超时或争议时向谁报告、按什么顺序升级。
示例情景设定为：一个约二十人的产品研发团队，采用主干开发、每日多次提交、每周两次常规发布的节奏，流水线由代码平台与构建工具串联，团队岗位包括开发、测试、运维和发布经理。以上团队规模、发布频率与工具形态均为假设，用于演示填写方法，不代表任何真实组织。
完整示例：五阶段流水线责任表
下表是完整的五阶段责任示例。角色一律使用岗位名，实际使用时替换为具体人员或值班组即可。表中“交接物”一列说明阶段之间传递什么，便于在工具中落到具体工作项或文档状态。
| 阶段 | 负责人 | 执行人 | 评审/准入人 | 输入 | 产出 | 完成标准 | 异常升级 |
|---|---|---|---|---|---|---|---|
| 提交代码 | 开发负责人 | 提交代码的开发人员 | 代码评审人（同模块资深开发） | 已拆分的研发任务、本地自测通过的改动 | 合并请求、关联任务的工作项、评审记录 | 合并请求通过至少一名评审人批准，关联任务状态更新为“待构建” | 评审超 1 个工作日未响应，升级至开发负责人；合并冲突由提交人自行解决 |
| 构建 | 构建值班人（运维轮值） | 流水线自动触发，值班人负责处置失败 | 开发负责人确认构建产物可用 | 已合并的代码、构建配置 | 构建产物、构建日志、版本号 | 构建成功且产物可下载、版本号可追溯至对应提交 | 连续两次构建失败，升级至运维负责人；构建时长超过阈值升级至构建值班人上级 |
| 自动化测试 | 测试负责人 | 测试执行人（测试工程师） | 测试负责人判定是否放行 | 构建产物、测试用例集、测试环境 | 测试报告、缺陷工作项、用例执行记录 | 冒烟用例全部通过，回归用例通过率达到约定阈值，未通过项均已建缺陷并分级 | 阻塞级缺陷出现，立即升级至测试负责人与开发负责人；环境不可用升级至运维 |
| 预发布验证 | 发布经理 | 运维执行部署，测试执行验证 | 发布经理与产品负责人共同确认 | 通过测试的构建产物、预发布环境、验证清单 | 预发布验证记录、发布评审结论 | 验证清单逐项勾选完成，关键业务路径走通，遗留问题已记录并确认可接受 | 验证发现阻断问题，升级至发布经理决定延期；环境差异问题升级至运维负责人 |
| 生产发布 | 发布经理 | 运维执行发布操作 | 发布经理批准，必要时由技术负责人复核 | 预发布验证结论、发布方案、回滚预案 | 发布记录、监控观察结论、发布后确认单 | 发布完成且观察期内关键指标正常，回滚预案确认可执行 | 发布后指标异常，立即升级至发布经理并启动回滚；重大故障升级至技术负责人 |
阶段之间的交接动作同样要写清。示例中，提交代码到构建的交接物是“已合并的代码与关联任务状态”；构建到自动化测试的交接物是“带版本号的构建产物”；测试到预发布验证的交接物是“测试报告与遗留缺陷清单”；预发布到生产发布的交接物是“验证记录与发布评审结论”。每个交接物都应能在工具中找到对应的工作项、构建记录或文档，避免只靠口头通知。
逐项解释：每个字段为什么这样填
表格填得出来不等于填得对。下面解释几个关键字段的填写依据，并给出常见填法对照。
阶段负责人与执行人为什么要分开
负责人对结果负责，执行人完成具体操作，两者分开可以让计划与验收责任独立于操作本身。以构建阶段为例，流水线自动触发，执行人实际上是系统，但构建失败时需要有人处置、有人对构建质量负责，因此设置构建值班人作为负责人。若负责人与执行人是同一人，容易出现“自己触发、自己宣布通过”的情况，问题被推迟到下游才暴露。
完成标准要写成可判断的通过条件
“构建完成”不是完成标准，因为它无法判断是否可进入下一阶段；“构建成功且产物可下载、版本号可追溯至对应提交”才是。可判断的标准通常包含三个要素：一个可观察的结果、一个判定方式、必要时一个阈值。测试阶段的“回归用例通过率达到约定阈值”就属于带阈值的写法，阈值本身由团队按业务风险确定，示例不预设具体数字。
异常升级按阶段风险设定
越靠近生产发布，升级层级越高、响应要求越紧。提交代码阶段的问题通常可在开发组内解决，升级到开发负责人即可；自动化测试出现阻塞级缺陷，需要测试与开发负责人同时知情；生产发布后指标异常，则直接升级至发布经理并启动回滚，重大故障上报技术负责人。升级路径写清“向谁、什么条件下、多久内”，比只写“及时上报”更有可执行性。
交接物要落到具体工作项或文档状态
交接如果只靠群消息，事后无法回溯是谁在什么状态下放行的。把交接物落到工作项状态、构建记录或评审文档上，交接就有了可查证的载体。示例中每个阶段的产出都对应一类可追踪对象，这也是责任表能与实际执行对上的关键。
评审/准入人与发布审批的边界
评审/准入人判断的是“本阶段能否通过”，例如测试负责人判断测试是否达到放行条件；发布审批判断的是“这次发布是否允许执行”，属于发布管理范畴。两者可以由同一人承担，但判断对象不同，填写时应分开表述，避免把阶段准入写成发布审批。发布审批与质量门禁的规则设计不在本文展开。
常见填法对照如下：
| 字段 | 常见但不足的填法 | 更可用的填法 |
|---|---|---|
| 完成标准 | 测试完成 | 冒烟用例全部通过，未通过项已建缺陷并分级 |
| 异常升级 | 有问题找负责人 | 阻塞级缺陷 30 分钟内升级至测试负责人与开发负责人 |
| 交接物 | 通知下游 | 测试报告文档状态更新为“已提交评审”，关联缺陷清单 |
| 评审/准入人 | 大家确认 | 测试负责人签字放行，记录放行时间 |
可迁移规律：换一条流水线怎么改这张表
示例的价值在于方法可迁移。换一条流水线时，按以下步骤改写，通常能在一到两次评审内得到可用版本。
- 先定阶段，再定角色。按实际交付形态列出阶段，移动应用可能增加打包签名与商店提审，数据类交付可能增加数据校验。阶段数量不必凑成五个，命名用团队日常说法即可。
- 把角色映射到岗位。小团队可由一人兼多个负责人角色，但要在表中注明兼任关系；跨团队协作时，明确每个角色归属哪个团队，避免出现无人认领的阶段。
- 逐阶段写完成标准。从“进入下一阶段前必须看到什么”倒推，优先写可自动检查的条件，人工判断的条件注明判断人。
- 按风险排升级路径。列出每个阶段最可能失败的两种情形，分别写清升级对象与响应要求。
- 把交接物挂到工具对象上。每个交接物对应一个工作项状态、一次构建记录或一份评审文档，确保交接可追踪。
- 约定维护节奏。组织调整、流水线增删阶段或发布频率明显变化时，同步更新责任表。
责任表要真正起作用，需要与日常协作载体衔接。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并把流水线与项目关联，便于在项目、迭代、需求中查看代码提交、构建和发布过程。这意味着示例中的“构建产物版本号”“测试报告状态”等交接物，可以在工作项和流水线记录中找到对应位置；通过代码提交与业务工作项关联，也能让提交代码阶段的交接有据可查。测试环节若使用 ONES TestCase，用例可分配执行人，未通过用例可快速创建缺陷任务，与示例中测试阶段的执行人和缺陷流转相对应。需要说明的是，上述能力依赖相应集成配置，具体支持范围以实际集成为准。
适用边界：示例不能直接照搬的情形
示例建立在若干前提之上：团队规模约二十人、每日多次提交、每周两次常规发布、具备独立的测试与运维岗位、流水线以自动化构建和测试为主。团队规模明显更小、发布频率更低或采用完全不同的交付形态时，阶段划分和角色设置都需要调整，直接照搬会出现角色空缺或职责重叠。
以下情形超出本文范围，需要另行设计：流水线与代码平台、构建工具的具体对接配置；发布审批流程与质量门禁的规则设计；具体工具的价格、版本与认证信息。这些内容涉及平台配置与组织制度，不能从本示例推导。
强监管或高风险发布场景，例如涉及资金交易、医疗数据或安全合规要求的系统，通常需要额外的准入设计，包括独立复核、变更窗口和审计留痕。示例中的评审/准入设置可以作为起点，但不足以覆盖这类场景的合规要求。
最后，责任表是活文档。组织调整、人员变动、流水线增删阶段后若不更新，表上的负责人会与实际执行脱节，交接记录也会失去参照。建议把责任表的维护纳入发布流程变更的常规动作，在每次流水线调整时同步复核一遍。
常见问题
小团队人少，负责人和执行人必须分开吗？
可以兼任，但建议在表中注明兼任关系。分开设置的目的，是让计划与验收责任独立于具体操作，避免出现自己触发、自己宣布通过的情况。小团队由一人兼多个角色时，至少在完成标准上保留可检查的客观条件，例如构建产物可下载、用例通过率达到约定阈值，让兼任不削弱验收的独立性。
完成标准里的阈值怎么定，示例为什么不给具体数字？
阈值取决于业务风险和发布节奏，同一套数字放到不同团队未必合适。示例只给出写法结构：一个可观察的结果、一个判定方式、必要时一个阈值。团队可以先用历史数据或试运行几轮确定初值，再随缺陷逃逸情况调整。关键是阈值写在责任表里、有人对判定负责，而不是停留在口头约定。
阶段责任表和发布审批是什么关系，会不会重复？
两者判断对象不同。评审/准入人判断的是本阶段能否通过，例如测试负责人判断测试是否达到放行条件；发布审批判断的是这次发布是否允许执行，属于发布管理范畴。两者可以由同一人承担，但填写时应分开表述。发布审批流程与质量门禁的规则设计不在本文范围，需要另行设计。
责任表填好后，怎么保证实际执行时不走样？
把交接物挂到工具对象上是关键一步。每个阶段的产出对应一个工作项状态、一次构建记录或一份评审文档，交接就有可查证的载体，事后能回溯是谁在什么状态下放行的。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并把流水线与项目关联，便于在项目、迭代、需求中查看代码提交、构建和发布过程；通过代码提交与业务工作项关联，提交代码阶段的交接也有据可查。上述能力依赖相应集成配置，具体支持范围以实际集成为准。
流水线增删阶段或组织调整后，责任表要怎么维护？
建议把责任表维护纳入发布流程变更的常规动作：流水线增删阶段、发布频率明显变化、团队拆分合并或关键岗位人员变动时，同步复核一遍责任表。复核重点看三处：是否有阶段无人认领、完成标准是否仍可判断、升级路径上的联系人是否在职。责任表长期不更新，表上的负责人会与实际执行脱节，交接记录也会失去参照。
