DevOps协作中的扯皮，往往源于两件事没写清楚：某个环节到底谁拍板，以及“做完了”按什么标准算完成。本文给出一套可直接落地的方法：先按交付流拆出环节和交接点，用责任矩阵为每个环节指定唯一负责人，再把交付物、完成标准、验证方式和交接时点写成可验收的交付标准，最后固化到工作项与例行复盘中。文中提供责任矩阵、角色分工表、发布示例和完成检查清单，供研发、测试、运维、产品等角色对照使用。
要点总览（TL;DR）
- 责任划分按“需求到上线”的交付流拆环节，每个环节只设一个负责人，协作方和决策人分别写明，避免共同负责导致扯皮。
- 交付要求写到可验收的程度：每个交接点包含交付物、完成标准、验证方式、交接时点四要素，并区分必须满足的准入条件与可协商项。
- 发布与回滚的责任要在发布前指定，回滚决策人和执行人写进预案，事发时按预案执行。
- 把责任矩阵和交付标准固化到工作项字段与评审节点，通过例行复盘核对责任缺口和标准偏差，约定调整保留版本记录。
- 用完成检查清单逐项核对：唯一负责人、可验收标准、进入工作项、复盘修正，判断机制是否真正落地。
先拆交付流：责任从哪些环节开始划分
责任划分的第一步是确定划分的粒度。按“需求到上线”的完整交付流拆环节，比按部门拆更有效，因为扯皮通常发生在部门之间的交接处，而非部门内部。建议先画出一条从需求提出到线上反馈的主干流程，再在每个环节标注输入、输出和下游接收方。
一条典型的DevOps交付流可以拆为以下环节，团队可根据自身发布节奏增删：
| 环节 | 主要输入 | 主要输出 | 常见交接点 |
|---|---|---|---|
| 需求澄清 | 业务诉求、用户反馈 | 需求说明、验收口径 | 产品交开发 |
| 方案设计 | 需求说明、技术约束 | 设计文档、接口约定 | 开发交测试 |
| 开发实现 | 设计文档、任务拆分 | 代码、自测记录 | 开发交测试 |
| 测试验证 | 提测版本、测试用例 | 测试报告、缺陷清单 | 测试交发布 |
| 发布上线 | 发布计划、变更清单 | 发布记录、回滚预案 | 发布交运维 |
| 运维反馈 | 监控数据、用户反馈 | 问题单、改进建议 | 运维交产品与开发 |
识别交接点时，重点看三类容易扯皮的位置：一是提测，开发认为“代码写完”，测试认为“环境没准备好”；二是发布，发布负责人认为“变更已合入”，运维认为“回滚方案没确认”；三是线上问题处置，开发和运维对“谁先定位”各执一词。把这些位置单独列出来，后续每个交接点都要配一条交付标准。
拆分时还要区分两种角色：环节负责人对该环节的结果负责，环节内执行角色按任务分工完成具体工作。例如测试环节的负责人是测试负责人，执行角色可能包括功能测试、性能测试和自动化测试人员。负责人只有一个，执行角色可以多个，这一区分是下一步填写责任矩阵的基础。
本步的产出是一张交付流环节与交接点清单，完成标志是：每个环节都有明确的输入、输出和下游接收方，每个交接点都被标注出来并说明容易出问题的原因。
用责任矩阵写清每个环节的负责人和协作方
责任矩阵的作用是把“大家配合”变成“谁在什么位置承担什么”。推荐使用RACI思路，但字段要按DevOps场景具体化，避免只写字母不写含义。建议的字段如下：
| 字段 | 填写要求 | 示例（测试验证环节） |
|---|---|---|
| 环节 | 与交付流清单一致 | 测试验证 |
| 负责人 | 唯一，对该环节结果负责 | 测试负责人 |
| 协作方 | 参与执行、提供输入的角色 | 开发、产品 |
| 知会方 | 需要了解进展但不必参与执行 | 项目经理 |
| 决策人 | 对争议和例外做最终判断 | 技术负责人 |
填写时最容易犯的错误是“共同负责”。两个角色共同负责一个环节，等于没人负责，出问题时双方都能找到理由。正确做法是每个环节只设一个负责人，其他角色写入协作方或决策人。协作方的义务也要写具体，例如“开发在提测前完成自测并提交自测记录”，而不是笼统写“配合测试”。
发布与回滚是责任最容易模糊的场景，需要单独划清。可以参考以下划分：开发负责变更内容的正确性和回滚脚本的准备；测试负责发布前的回归结论；发布负责人负责发布窗口、发布顺序和发布过程记录；运维负责发布后的监控观察和异常上报；产品负责确认业务影响范围并在需要回滚时做出业务判断。回滚决策人应事先指定，通常由技术负责人或发布负责人担任，避免事发时临时找人拍板。
责任矩阵写完后需要评审确认，而不是由一个人填完就生效。建议组织一次跨角色评审，逐行确认负责人是否认可自己的职责、协作方是否清楚自己的输入义务、决策人是否具备相应权限。评审后的矩阵标注版本和生效日期，后续调整走变更记录，避免出现多个版本并存、各角色按不同版本执行的情况。
把交付要求写成可验收的交付标准
“做完了”之所以引发争议，是因为完成标准停留在个人理解里。交付标准要写到可验收的程度，每个交接点至少包含四个要素：交付物是什么、完成标准是什么、用什么方式验证、在什么时点交接。
以几个关键节点为例，判定条件可以这样设定：
- 代码提交：交付物为合入主干的代码和自测记录；完成标准为代码评审通过、持续集成构建成功、自测用例执行完毕；验证方式为流水线构建结果和评审记录；交接时点为提测日前一个工作日。
- 测试通过：交付物为测试报告和缺陷清单；完成标准为约定级别的用例全部执行、阻塞级和严重级缺陷清零、遗留缺陷有明确处理结论；验证方式为测试报告评审；交接时点为发布评审前。
- 发布就绪：交付物为发布计划、变更清单、回滚预案和监控配置；完成标准为变更已评审、回滚步骤经过演练或确认、关键指标告警已配置；验证方式为发布评审会签；交接时点为发布窗口开始前。
标准要区分必须满足的准入条件和可协商项。准入条件是硬门槛，例如严重缺陷未清零不得发布；可协商项是可以在评审中讨论调整的内容，例如非核心功能的测试覆盖范围。把两者混在一起，会导致要么所有条件都被当成硬性要求而拖慢交付，要么所有条件都可以商量而失去约束力。建议在交付标准表中用“必须/可协商”一列明确标注。
交付标准由谁确认也需要写清楚。通常由该交接点的下游接收方确认标准是否可验收，环节负责人确认标准是否可达成，决策人对争议条款做裁定。标准发生变更时，记录变更内容、原因、确认人和生效时间，并同步给所有相关角色。标准变更本身也应进入评审，避免下游在不知情的情况下按旧标准接收。
角色与交付物分工表
责任矩阵按环节组织，角色分工表按角色组织，两者互为补充。前者回答“这个环节谁负责”，后者回答“这个角色要交出什么”。下表可作为填写模板，团队按实际角色名称调整。
| 角色 | 核心职责 | 主要交付物 | 在评审与异常处置中的动作 |
|---|---|---|---|
| 产品 | 需求价值判断与验收口径定义 | 需求说明、验收标准、发布范围确认 | 参加发布评审，确认业务影响，决定是否接受带条件发布 |
| 开发 | 方案实现与代码质量 | 设计文档、代码、自测记录、回滚脚本 | 参加设计评审和代码评审，异常时负责定位变更引入的问题 |
| 测试 | 质量验证与风险暴露 | 测试用例、测试报告、缺陷清单 | 在发布评审中给出质量结论，对未达标项提出阻断意见 |
| 运维 | 环境稳定与线上可观测 | 环境配置、监控告警配置、线上问题单 | 发布后观察关键指标，异常时按预案执行回滚或升级 |
| 发布负责人 | 发布过程组织与节奏控制 | 发布计划、发布记录、回滚决策记录 | 主持发布评审，按准入条件判断是否放行，协调回滚执行 |
填写这张表时，重点核对责任与交付物是否一一对应。如果某个角色承担了职责却没有对应交付物，说明这项职责无法被验证；如果某个交付物没有明确责任人，说明它很可能在交接时被遗漏。评审、发布、异常处置三类动作要单独列出，因为这些场景下角色行为与日常开发差异较大，最容易出现“平时分工清楚、出事时找不到人”的情况。
示例：一次版本发布的责任与交付约定
以下为演示情景，用于说明责任矩阵和交付标准如何落到一次具体发布上，不代表任何真实项目数据。
示例背景：某团队计划在周四晚发布一个包含三个需求和一个数据库变更的版本，发布范围为生产环境全量，发布窗口两小时，要求具备一小时内回滚能力。
| 环节 | 负责人 | 交付物 | 完成标准 | 交接时点 |
|---|---|---|---|---|
| 需求澄清 | 产品负责人 | 需求说明与验收标准 | 三个需求的验收口径经开发与测试确认 | 周一上午 |
| 开发实现 | 开发负责人 | 代码、自测记录、数据库变更脚本与回滚脚本 | 代码评审通过，构建成功，回滚脚本在预发环境验证 | 周二下班前 |
| 测试验证 | 测试负责人 | 测试报告、缺陷清单 | 严重级缺陷清零，遗留缺陷有处理结论 | 周三下午 |
| 发布就绪 | 发布负责人 | 发布计划、变更清单、回滚预案、监控配置 | 发布评审会签通过，告警规则已生效 | 周四中午 |
| 发布执行 | 发布负责人 | 发布记录 | 按计划顺序执行，每步有结果记录 | 发布窗口内 |
| 发布后观察 | 运维负责人 | 监控观察记录、问题单 | 关键指标在观察期内无异常，或异常已按预案处置 | 发布后二十四小时 |
发布评审由发布负责人主持，产品、开发、测试、运维分别确认各自交付物是否达标。若测试报告显示存在未清零的严重缺陷，测试负责人提出阻断意见，发布负责人据此决定延期，而不是由开发或产品单方面推动放行。若发布后监控发现错误率上升，运维负责人按预案上报，回滚决策人依据回滚预案在约定时限内做出决定，开发负责执行回滚脚本并确认回滚结果，发布负责人记录决策过程和结果。
这个示例体现的判定依据是：每个环节的放行都依赖上游交付物是否满足完成标准，而不是依赖口头确认；回滚责任在发布前就已指定，事发时按预案执行，减少临时协调成本。
让约定持续生效：固化到工作项与例行复盘
责任矩阵和交付标准如果只存在于文档里，几周后就会与实际执行脱节。有效的做法是把约定嵌入团队每天使用的协作载体，让责任随工作项流转。
具体可以从三个动作入手。第一，在工作项中设置负责人、交付标准、验收状态等字段，让每个需求或任务在创建时就带上责任人和验收口径，而不是等到交接时再补。第二，在评审与交接节点设置检查动作，例如提测前核对自测记录是否附上、发布评审前核对回滚预案是否确认，检查不通过则工作项不能进入下一状态。第三，在例行复盘中核对两类偏差：一是责任缺口，即某个环节出现了无人负责或多人争抢的情况；二是标准偏差，即交付物满足了书面标准但下游仍然返工，说明标准需要修订。
ONES在这类场景中可以作为承载责任与交付约定的协作平台。通过业务需求、研发任务等工作项拉取代码分支，并将代码提交与工作项关联，团队可以在工作项上看到需求对应的代码进展，责任人和交付状态随工作项一起流转；集成Jenkins、GitLab CI等流水线工具后，构建与发布状态会同步到项目视图中，发布评审时可以直接对照流水线结果判断准入条件是否满足。这些能力的前提是完成相应的工作项与代码仓库关联配置及流水线集成，具体字段配置需以实际环境为准。
约定本身也需要版本管理。责任矩阵和交付标准每次调整都记录变更内容、原因和生效日期，并在复盘会上同步。建议每季度或每次重大流程变化后做一次整体复核，确认矩阵中的角色名称、环节划分和标准条目仍与团队实际一致。
完成检查：责任与交付要求是否真正明确
以下清单可用于自查或评审，逐项核对并记录结论。全部通过，说明责任与交付要求已经具备可执行的基础；存在未通过项，按对应章节的方法补齐。
| 检查项 | 核对方法 | 通过标志 |
|---|---|---|
| 每个环节是否有唯一负责人 | 逐行检查责任矩阵，确认负责人列只有一个角色 | 不存在“共同负责”的环节 |
| 每个交接点是否有可验收的交付标准 | 对照交付流清单，检查每个交接点是否具备交付物、完成标准、验证方式、交接时点四要素 | 四要素齐全，且标注了必须满足与可协商项 |
| 责任与标准是否已进入工作项和评审 | 抽查若干进行中的工作项，查看负责人、交付标准、验收状态字段是否填写 | 工作项携带责任与验收信息，评审节点有检查动作 |
| 回滚与异常处置责任是否事先指定 | 查看发布预案中是否写明回滚决策人和执行人 | 事发时可直接按预案执行，无需临时找人 |
| 复盘是否发现并修正责任缺口 | 查看最近几次复盘记录，是否有责任缺口或标准偏差的整改项 | 整改项有责任人和完成时间，并在后续复盘中验证关闭 |
| 约定是否有版本记录 | 检查责任矩阵和交付标准的变更记录 | 每次调整有变更内容、原因、确认人和生效日期 |
检查的频率建议与发布节奏匹配：每次发布评审时顺带核对当次涉及的交接点，每季度做一次完整核对。检查结果不必追求一次全部通过，重点是让未通过项进入整改清单，并在下一次核对时确认是否关闭。
常见问题
团队规模小、角色一人身兼多职时，责任矩阵还有必要做吗？
有必要，但可以简化。小团队中同一个人可能同时承担开发和发布负责人，责任矩阵的价值在于把“这个环节谁拍板”写下来，而不是增加角色数量。做法是保留环节和负责人两列，协作方和知会方可以合并或省略，决策人一栏写清当出现争议时由谁裁定。需要留意的是，一人兼任多个角色时，发布评审中的质量结论和放行判断最好由不同的人给出，避免自己评审自己。
交付标准定得太严会拖慢发布，怎么把握尺度？
关键是把标准分成准入条件和可协商项两类。准入条件对应不可接受的风险，例如严重缺陷未清零、回滚方案未确认，这类条件不因进度压力放宽；可协商项对应覆盖范围和验证深度，可以在发布评审中根据变更影响面调整。建议每次发布评审记录放宽了哪些可协商项、由谁确认，积累几次后就能看出哪些标准定得过高、哪些放宽后确实带来了返工，据此修订标准本身。
责任矩阵和交付标准应该由谁发起制定？
通常由研发负责人或项目经理发起，但内容必须经过跨角色评审确认。发起人的作用是组织拆解交付流、提供矩阵模板、推动各角色认领职责；负责人是否认可自己的职责、协作方是否清楚自己的输入义务，需要本人确认，不能由发起人代为填写。评审后的矩阵标注版本和生效日期，后续调整走变更记录。
线上突发故障时，责任矩阵还适用吗？
适用，但需要提前补充异常处置条款。日常环节的责任划分解决的是计划内交付，故障场景下还要明确三件事：谁负责第一时间响应和上报、谁有权决定回滚或降级、谁负责对外同步影响范围。这些内容写进发布预案或故障响应约定，并在复盘中检查实际处置是否与约定一致。若多次故障中出现同一环节无人响应，说明该环节的责任人设置需要调整。
责任和交付标准落到工具里，需要配置哪些内容？
至少包括三类配置：工作项上的负责人、交付标准、验收状态字段；评审与交接节点的状态流转检查，例如提测前必须附上自测记录才能进入下一状态；以及发布相关的工作项与代码提交、流水线构建结果的关联，便于评审时对照实际进展判断准入条件。以 ONES 为例，可通过业务需求、研发任务等工作项拉取代码分支并关联代码提交，集成 Jenkins、GitLab CI 等流水线工具后同步构建与发布状态，具体字段配置需以实际环境为准。
