开发、测试、运维之间的责任衔接不清，常见表现是提测时才发现材料不全、发布时没人敢拍板回滚、故障发生后定位与修复互相等待。本文给出一套可直接套用的方法：用责任矩阵固定各阶段的主责、协作与知会角色，用五类交接卡定义每个衔接点的输入、动作、输出与完成标志，再以准入准出条件和证据留痕让责任可追溯。文中也说明如何借助 ONES 这类工作项与交付记录工具承载矩阵与交接记录，适用于正在梳理发布链路、希望先把一条链路跑通的研发与交付团队。
要点总览（TL;DR）
- 用一张“阶段×角色”责任矩阵固定需求、开发、测试、发布、运行五个阶段的主责、协作与知会角色，每个格子只设一个主责，先消除共同负责导致的推诿。
- 把构建、提测、发布、变更与配置、故障响应五类交接点写成交接卡，每张卡明确输入、动作、输出、完成标志与负责人，让“交接完成”有可判断的依据。
- 准入准出条件按风险分级设置，核心服务从严、低风险变更从简，条件少而硬并优先自动判断，配套测试报告、发布记录、变更单、故障复盘等证据留痕，使责任可追溯。
- 先选一条发布链路试点，用检查清单核对矩阵无空白格、交接卡可执行、证据可回查，跑通后再扩展到其他服务。
先定责任边界：一张矩阵说清谁主责、谁协作
责任衔接的第一步是把“谁负责”从口头共识变成书面结构。推荐用一张“阶段×角色”的责任矩阵：行是交付阶段，列是参与角色，格内填写该阶段该角色承担的交付物与决策权。矩阵的价值在于让每个格子都有明确归属，避免出现“共同负责”却无人推进的情况。
阶段划分建议覆盖五个环节：需求、开发、测试、发布、运行。角色至少包含开发、测试、运维三方，并按需要加入产品、架构或安全角色。每个格子标注角色类型：主责（对结果负责、做最终决定）、协作（提供输入、参与执行）、知会（接收结果、知情即可）。一个格子只设一个主责，协作可以有多个。
| 阶段 | 开发 | 测试 | 运维 |
|---|---|---|---|
| 需求 | 协作：评估技术可行性 | 协作：提出可测性要求 | 知会：了解容量与部署影响 |
| 开发 | 主责：代码、单元测试、构建产物 | 协作：提前介入用例设计 | 协作：提供环境与部署规范 |
| 测试 | 协作：修复缺陷、提供构建说明 | 主责：测试执行与质量结论 | 协作：保障测试环境稳定 |
| 发布 | 协作：发布待命、问题定位 | 协作：发布前回归确认 | 主责：发布执行与回滚操作 |
| 运行 | 协作：缺陷修复与根因分析 | 知会：参与质量复盘 | 主责：监控、告警与故障响应 |
边界划分有三条原则。质量上，测试对“是否达到发布标准”给出结论，开发对缺陷修复质量负责，运维对线上运行质量负责，三者不互相替代。环境上，测试环境由测试提出需求、运维保障可用，开发不得随意改动共享环境配置。变更上，任何进入生产环境的变更都需要运维确认执行窗口，开发提供变更内容与影响范围。
矩阵填完后要做一次空白格检查：每个阶段是否都有主责角色，是否存在两个主责冲突，知会角色是否被遗漏。矩阵不是一次定稿的文件，服务类型、团队规模变化时应同步修订，并在版本发布前确认当前有效版本。
五类交接点的输入、动作、输出与完成标志
责任矩阵解决“谁负责”，交接卡解决“怎么交”。每个交接点写清五项内容：输入（交接前必须具备的材料）、动作（交接双方做什么）、输出（交接产生的记录或产物）、完成标志（可判断交接结束的条件）、负责人（谁发起、谁确认）。以下五类交接点覆盖了从代码到线上运行的主要衔接。
构建交付
输入是已合并的代码、通过的单元测试与构建配置；动作是开发触发构建并确认产物可部署，运维核对构建环境与依赖版本；输出是可部署产物及其版本号、构建日志；完成标志是产物在目标环境可启动且版本号可追溯；负责人是开发发起、运维确认。
提测交接
输入是开发交付清单（变更说明、影响范围、自测记录、已知问题）与可访问的测试环境；动作是开发提交提测申请，测试核对材料完整性后决定是否接收；输出是提测单与准入判断结论；完成标志是测试确认材料齐全并开始执行用例；负责人是开发发起、测试确认。
发布交接
输入是发布单、变更说明、回滚预案与测试通过结论；动作是开发说明变更内容与风险点，测试确认回归范围，运维审核发布窗口与回滚方案；输出是经三方确认的发布单；完成标志是发布单获批且回滚预案可执行；负责人是运维主责、开发与测试会签。
变更与配置交接
输入是配置项清单、变更申请与影响评估；动作是变更提出方说明改动内容，运维评估对现有环境的影响并安排执行；输出是变更单与配置项更新记录；完成标志是变更执行完成且配置基线同步更新；负责人是变更提出方发起、运维确认。
故障响应交接
输入是告警信息与初步影响范围；动作是运维先做发现与止损，判断为应用缺陷后移交开发定位，修复方案涉及配置或环境时再由运维执行；输出是故障记录、根因说明与复盘报告；完成标志是故障恢复且复盘结论归档；负责人按阶段切换：发现与止损由运维主责，根因定位与修复由开发主责，复盘由运维牵头、开发与测试参与。
五类交接卡建议统一模板存放，随发布流程一起流转。交接卡的作用是让“交接完成”有明确判断依据，而不是靠口头通知或群消息确认。
用准入准出条件与证据留痕让责任可追溯
交接卡定义了动作，准入准出条件定义了门槛。设置方法上，条件应按风险分级：核心服务或涉及数据变更的发布，准出条件更严格，例如要求完整回归与回滚演练；内部工具或低风险变更可简化条件。一刀切的门禁要么拖慢低风险交付，要么对高风险变更约束不足。
条件要少而硬，优先选择可自动判断的项，例如构建是否成功、单元测试是否通过、关键用例是否全部执行。需要人工判断的项，如变更影响评估、回滚预案审核，应明确判断人和判断标准，避免写成“视情况而定”。
| 证据类型 | 产生环节 | 留存要求 |
|---|---|---|
| 测试报告 | 提测与发布前 | 关联版本号，记录用例执行与缺陷情况 |
| 评审记录 | 需求与方案阶段 | 记录参与人与结论 |
| 发布记录 | 发布阶段 | 记录发布单、执行人、时间与结果 |
| 变更单 | 变更与配置交接 | 记录变更内容、影响评估与执行确认 |
| 故障复盘 | 故障响应后 | 记录时间线、根因与改进项责任人 |
责任追溯依赖证据与交接点的对应关系。出现问题时可沿链路回查：发布单是否记录了变更范围，测试报告是否覆盖了受影响功能，提测材料是否说明了已知风险。能定位到具体交接点，就能定位到该点的主责角色，追溯才有依据。门禁流于形式通常源于条件过多或无法判断，精简条件并尽量自动校验是更实际的做法。
这些矩阵、交接卡与证据记录需要落在团队日常使用的协作工具中才能持续运转。ONES 支持通过业务需求、研发任务等工作项关联代码提交，可视化代码研发过程；测试管理支持用例与需求、任务关联，未通过用例可快速创建缺陷任务并在测试与研发团队间流转，并可自动生成测试报告反馈版本质量。将责任矩阵与交接卡作为工作项字段或关联文档维护，发布与变更记录随工作项留存，追溯时可按工作项回看整条链路。具体承载方式需结合团队实际配置确定。
角色与交付物对照：每个角色要交出什么
从角色视角汇总交付物，便于分工落地与考核对齐。下表按角色列出各阶段的核心交付物，团队可在此基础上增补。
| 角色 | 核心交付物 |
|---|---|
| 开发 | 技术方案与影响评估、代码与单元测试、构建产物与版本号、提测清单、缺陷修复记录、根因分析 |
| 测试 | 测试用例与可测性建议、提测准入判断、测试报告与质量结论、回归范围确认、缺陷跟踪记录 |
| 运维 | 环境与部署规范、发布单执行记录、回滚预案、变更单与配置基线、监控告警记录、故障复盘报告 |
| 跨角色共同 | 发布说明（运维牵头、开发与测试会签）、故障复盘报告（运维牵头、开发与测试参与）、责任矩阵修订记录（交付负责人牵头） |
共同交付物最容易出现牵头人不明的问题，应在责任矩阵中明确牵头角色与参与角色。交付物清单确定后，可与工作项类型对应，让每类交付物在流程中有固定归属，减少临时补材料的情况。
示例：一条发布链路的责任衔接怎么走
以下为演示情景，用于说明责任流转方式，不代表特定团队的真实案例。设定：某服务计划发布一个包含接口变更的版本，涉及开发、测试、运维三方。
提测阶段：开发提交提测单，附变更说明、影响范围、自测记录与已知问题，并确认测试环境可用。测试核对材料后决定接收，按影响范围执行用例，未通过用例创建缺陷任务并指派开发。测试完成回归后出具测试报告，给出是否达到发布标准的结论，由测试负责人确认放行。
发布阶段：运维根据测试结论与发布单安排发布窗口，开发提供变更内容与风险点并在发布期间待命，测试确认回归范围。发布单需明确回滚预案与回滚决策人，通常由运维负责人拍板是否回滚，开发提供技术判断支持。发布执行与结果记录在发布单中。
上线后故障：监控告警由运维首先响应，完成初步止损与影响范围判断；确认为应用缺陷后移交开发定位根因，修复方案涉及配置或环境调整时由运维执行；故障恢复后由运维牵头组织复盘，开发提供根因分析，测试评估是否需要补充用例。每个环节对应责任矩阵中的阶段行与交接卡条目，复盘时可逐项核对交接是否按约定完成。
完成检查：责任衔接机制是否真的落地
机制建立后需要逐项核对是否真正运转。以下清单可用于验收，建议在试点结束后执行一次，之后按发布周期定期复查。
- 责任矩阵是否覆盖需求、开发、测试、发布、运行全部阶段，每个阶段是否都有唯一主责角色，是否存在空白格或主责冲突。
- 五类交接点是否都有对应的交接卡，每张卡是否写清输入、动作、输出、完成标志与负责人。
- 准入准出条件是否按风险分级设置，是否可判断，是否有对应证据留存，是否存在长期无人核对的僵尸条件。
- 最近一次发布能否按交接点回查发布单、测试报告与变更记录；最近一次故障能否定位到具体交接环节与主责角色。
- 试点范围是否明确，试点链路的交接卡是否经过实际发布验证，扩展计划是否列出下一批服务与时间安排。
检查中发现的问题应回到责任矩阵或交接卡修订，而不是停留在会议结论。先跑通一条发布链路，确认交接卡可用、证据可查、追溯可行，再逐步扩展到其他服务，是较为稳妥的落地路径。
常见问题
团队规模较小、开发测试运维由同一批人兼任时，责任矩阵还有必要做吗？
有必要，但可以简化。人员兼任时，风险不在于没人干活，而在于同一人在不同阶段切换角色后，交接动作被省略。建议保留矩阵的阶段行与主责标注，把协作与知会列合并，重点写清每个阶段结束时需要留下什么记录。例如同一个人既写代码又做发布，仍应在提测和发布两个节点分别留下提测清单与发布记录，便于事后回查。团队扩大或引入专职角色时，再按原结构补充列即可。
交接卡和现有的发布流程文档是什么关系，需要两套都维护吗？
两者可以合并维护。交接卡关注的是单个衔接点的输入、动作、输出、完成标志与负责人，发布流程文档描述的是整体步骤顺序。实践中可以把交接卡作为发布流程文档的附件或章节，每个流程节点引用对应的交接卡，避免同一份要求写两遍、改一处漏一处。流程调整时先改交接卡，再同步流程文档中的节点说明，保持两者一致。
准入准出条件设置后经常被绕过，怎么处理？
先排查绕过原因。常见情况是条件过多、判断标准模糊，或缺少可自动校验的手段，导致执行者只能靠人工确认而选择跳过。处理方式包括：把条件数量压缩到关键几项，优先保留构建成功、单元测试通过、关键用例执行完毕这类可自动判断的项；对必须人工判断的条件写明判断人和判断依据；对高风险变更保留强制门禁，对低风险变更简化流程。条件被绕过时记录具体环节，作为下一轮修订矩阵与交接卡的输入。
故障发生后开发和运维对根因判断不一致，责任怎么界定？
按故障响应交接卡的分段职责处理：运维负责发现、止损与影响范围判断，确认为应用缺陷后移交开发定位根因，涉及配置或环境调整的修复由运维执行。根因判断不一致时，以复盘环节的事实记录为准，包括时间线、监控数据、变更记录与日志。复盘由运维牵头、开发与测试参与，结论写入复盘报告并明确改进项责任人。若分歧源于交接卡本身描述不清，应在复盘后修订对应条目，而不是在单次故障中临时裁定。
责任矩阵和交接卡放在哪里维护，才能保证大家用的是最新版本？
关键是让矩阵与交接卡跟随实际交付流程存放，而不是单独放在个人文档里。可以将其作为工作项字段或关联文档维护在团队日常使用的协作工具中，发布与变更记录随工作项留存，追溯时按工作项回看整条链路。ONES 支持通过业务需求、研发任务等工作项关联代码提交，测试管理支持用例与需求、任务关联并自动生成测试报告，可作为承载交接记录的选项之一，具体配置需结合团队实际情况确定。无论使用何种工具，都应指定矩阵的维护责任人，并在每次发布前确认当前有效版本。
