发布审批流程示例的核心是一张“发布放行单”：把本次发布的版本范围、质量门禁结果、风险与回退方案、审批角色和放行结论写在同一份记录上，让审批人依据证据判断这一次发布是否允许。下面给出一份填写完整的演示示例，并逐项说明每个字段的判断依据、退回情形，以及换到不同团队时如何裁剪套用。
要点总览（TL;DR）
- 发布审批示例的核心是一张放行单，只回答一个问题：本次发布是否允许上线。
- 放行单最小字段集为发布标识、版本范围、质量门禁证据、风险与回退方案、审批角色与结论，缺一项审批人就难以有依据地判断。
- 质量门禁证据要引用报告名称、关键指标和缺陷单号，只写“测试通过”应退回补充。
- 审批顺序一般先技术后业务，结论分放行、有条件放行、退回三类，有条件放行必须写清可核验的条件。
- 组织级阶段决策、测试完成判断和产品能力核实不属于这张放行单的范围。
示例目标：这张发布放行单要回答什么
这张放行单只回答一个问题：本次发布是否允许上线。它针对的是一次具体的版本发布，判断对象是这一次的版本范围、证据和风险，结论只有放行、有条件放行、退回补充三类。示例中的团队、版本号、指标数值均为演示情景，用于展示填写方式，不代表真实客户案例或实测结果。
把边界划清楚，可以避免放行单被当成万能评审表。它与另外两类决策分工如下：
- 组织级阶段决策：决定一个产品阶段是否进入下一阶段、资源是否继续投入，关注的是方向和投入，通常由产品与技术负责人共同做出。放行单不承担这个职责。
- 测试完成判断：由测试负责人依据测试范围、用例执行和缺陷收敛情况判断测试工作是否结束。放行单引用这个判断的结论和证据，不重新做一遍测试评估。
- 单次发布审批：在测试完成、阶段决策已定的前提下，判断这一次发布能否按计划上线，以及需要哪些附加条件。
因此，放行单上的每个字段都应服务于“这一次能不能发”这个判断。与本次发布无关的长期规划、人员绩效、季度目标等内容，不放进这张单。
完整示例：一次版本发布的放行单
示例背景：某业务系统的订单模块计划发布 3.8.0 版本，包含两项功能改动和一项接口调整，计划在周四晚 22:00 上线。以下为填写完成的放行单，字段与内容一一对应。
| 字段 | 已填内容（示例） |
|---|---|
| 发布标识 | 订单模块 3.8.0，计划上线时间 周四 22:00，发布窗口 2 小时 |
| 版本范围 | 功能 A：订单批量导出；功能 B：优惠券叠加规则调整；接口 C：订单查询接口字段新增（向后兼容） |
| 变更清单 | 代码合并请求 14 个，数据库变更 1 项（新增索引，无数据迁移），配置变更 2 项（导出条数上限、超时时间） |
| 质量门禁证据 | 回归用例执行率 100%，通过率 98.6%，2 个未通过用例均为已知低优先级问题并附缺陷单号；性能测试报告显示导出接口 P95 响应 1.2 秒，低于 2 秒阈值；安全扫描无高危项，中危 1 项已记录整改计划 |
| 风险等级 | 中。理由：涉及数据库索引变更，回滚需额外脚本；接口字段新增对下游系统兼容，但需通知两个调用方 |
| 回退方案 | 应用回滚至 3.7.2 镜像，预计 15 分钟；索引变更保留不回退（对旧版本无影响）；配置项随应用回滚自动恢复；回退触发条件：上线后 30 分钟内错误率超过 1% 或核心下单链路不可用 |
| 审批角色与意见 | 测试负责人：测试结论已出，同意放行；开发负责人：变更清单确认无误，同意；运维负责人：发布窗口与回退脚本已就绪，同意；业务负责人：同意按计划上线，要求上线后 1 小时内同步监控数据 |
| 放行结论 | 有条件放行。条件：上线后 1 小时内由值班人员同步错误率与下单成功率；下游两个调用方已在发布前完成通知确认 |
| 流转记录 | 提交 周三 16:00 → 测试负责人审批 周三 16:40 → 开发负责人审批 周三 17:10 → 运维负责人审批 周三 17:30 → 业务负责人审批 周四 10:00 → 结论生效 |
这份放行单的特点是：每个结论都能追溯到具体证据或具体人。质量门禁部分给出的是报告名称和关键数值，风险部分说明了风险来源，回退方案写清了回退对象、耗时和触发条件，审批意见按角色分别记录，最终结论带有明确的附加条件。
逐项解释：每个字段为什么这样填
版本范围与变更清单
版本范围写“发了什么”，变更清单写“改了什么”。前者面向业务和审批人，用功能名称和影响面描述；后者面向执行人员，用合并请求数量、数据库变更、配置变更等可核对的对象描述。填写口径是：范围以本次实际合入的内容为准，超出已评估范围的内容要么拆到下一次发布，要么重新走评估。示例中接口 C 标注“向后兼容”，就是为了让审批人快速判断下游影响。
质量门禁证据如何引用
门禁证据要引用可查的记录，避免只写“测试通过”“没问题”。可用的写法包括：报告名称加关键指标、缺陷单号、扫描报告编号。示例中写“回归用例执行率 100%，通过率 98.6%，2 个未通过用例附缺陷单号”，审批人可以据此判断未通过项是否可接受。只写“测试已完成”属于口头描述，证据不足，应退回补充。
风险等级与回退方案的对应关系
风险等级决定回退方案的详细程度，两者必须匹配。低风险发布可以只写回滚镜像和时间；涉及数据库、配置、下游依赖的中高风险发布，回退方案要写清回退对象、回退顺序、预计耗时和触发条件。示例中风险定为“中”，原因是索引变更和下游通知，回退方案相应写明了“索引保留不回退”的处理，避免回退时误操作。风险等级写“低”却附带了复杂的数据迁移，或者风险写“高”却没有回退触发条件，都属于不匹配，应退回。
审批角色与放行结论的写法
审批角色按职责设置，常见为测试、开发、运维、业务四类，各自对自己掌握的证据负责。审批意见要写成“结论加依据”，例如“测试结论已出，同意放行”，而不是只签一个名字。放行结论分三种写法：放行、有条件放行、退回。有条件放行必须把条件写具体，示例中的条件是“上线后 1 小时内同步监控数据”，可执行、可核验。结论由具备放行权限的角色给出，其他角色的意见作为依据记录在案。
退回与补充证据的典型情形
- 门禁证据缺失，或只有口头描述、没有可查记录。
- 风险等级与回退方案不匹配，例如高风险发布没有回退触发条件。
- 变更范围超出已评估范围，出现未走评估的改动。
- 审批角色缺位，关键角色未给出意见。
- 放行结论含糊，例如只写“同意”而未说明是否有附加条件。
退回时应在放行单上写明退回原因和需要补充的材料，补充完成后重新提交，保留原有的流转记录，便于追溯。
可迁移规律：换一个团队怎么套用
这套字段结构可以拆成最小集和可裁剪项。最小集包括：发布标识、版本范围、质量门禁证据、风险与回退方案、审批角色与结论。这五项缺任何一项，审批人都难以做出有依据的判断。可裁剪项包括变更清单的颗粒度、流转记录的详细程度、附加监控要求的写法，团队可按发布规模和工具条件调整。
审批顺序的一般规律是先技术后业务：测试、开发、运维先确认证据和执行准备，业务角色最后确认上线时机和影响面。角色设置上，每个角色对应一类证据的负责人，避免同一人既提供证据又做最终放行。证据留痕要求是每个结论都能指向具体记录，发布结束后放行单与相关报告一并归档，作为后续复盘和审计的依据。
发布频率不同，放行单的用法也要调整：
| 发布类型 | 调整方式 |
|---|---|
| 高频小版本 | 保留最小字段集，变更清单按合并请求汇总，审批可并行进行，回退方案以自动回滚为主，结论以放行或有条件放行居多 |
| 低频大版本 | 增加变更清单颗粒度、下游影响分析和分阶段上线计划，回退方案写明分步回退顺序，审批串行进行并保留完整流转记录 |
当发布审批需要在系统中留痕时，可以把放行单作为一份文档或工作项挂在对应版本下，审批意见随状态流转记录，质量门禁证据以报告附件或链接形式关联。ONES 可以承载这类工作项状态流转、审批记录与文档留痕的管理动作，让放行单与版本、缺陷、测试报告保持在同一处可查。具体承载方式按团队现有工具配置确定，本文不展开产品功能细节。
适用边界：哪些情况不适用这张放行单
这张放行单只针对单次发布是否允许上线。以下情形不在本文范围内，需要另行处理：
- 组织级阶段决策：是否进入下一研发阶段、是否追加投入，属于阶段评审与决策机制的范畴，放行单不替代这类决策。
- 测试完成判断：测试工作是否结束、测试报告质量如何评估，由测试负责人和相关方法负责，放行单只引用其结论。
- 产品能力核实：示例中的字段和写法是流程设计示例，不构成对任何具体产品功能、版本、价格或认证的判断。
特殊发布情形需要调整处理原则：紧急修复可以缩小放行范围、由值班负责人加签后先上线，事后补齐完整放行单和复盘记录；灰度发布可以把放行单的结论限定在灰度批次，写明灰度比例、观察指标和扩大范围的条件，全量前再走一次放行确认。这些做法属于一般建议，团队应结合自身风险承受能力和审批权限设定具体规则。
常见问题
放行单上的质量门禁证据，引用到什么程度才算够？
判断标准是审批人能否只凭这条记录做出取舍。可用的写法包括报告名称加关键指标、缺陷单号、扫描报告编号，例如“回归用例执行率 100%，通过率 98.6%，2 个未通过用例附缺陷单号”。如果只写“测试已完成”“没问题”，审批人无法判断未通过项是否可接受，应退回补充。证据颗粒度可以随发布风险调整：低风险小版本引用汇总指标即可，涉及数据库或下游依赖的发布，建议把相关报告作为附件或链接一并关联。
紧急修复来不及走完整审批，放行单怎么处理？
常见做法是缩小放行范围、由值班负责人加签后先上线，事后补齐完整放行单和复盘记录。缩小范围指只放行修复本身涉及的改动，其他待发内容拆到下一次；加签指在原有审批角色之外，由具备应急权限的负责人确认风险与回退方案。事后补齐时保留原有点和实际处理过程，便于复盘。具体权限和时限由团队按自身风险承受能力设定，本文示例不构成统一规则。
灰度发布时，放行单的结论应该怎么写？
把结论限定在灰度批次，写明灰度比例、观察指标和扩大范围的条件，全量前再走一次放行确认。例如结论写“有条件放行：先放量 10%，观察 2 小时错误率与下单成功率，达标后扩大至全量”。这样放行单对应的是本次灰度动作，全量属于另一次判断，避免一次审批覆盖未经观察的全量上线。
审批角色可以由同一人兼任吗？
小团队里兼任常见，但要注意证据提供与最终放行尽量分开。如果测试、开发、运维由同一人承担，建议至少把质量门禁证据的出具和放行结论的签署在记录上分开写，保留可追溯的意见。发布规模较大或涉及下游系统时，业务角色的确认不宜省略，因为上线时机和影响面通常需要业务侧判断。
放行单和阶段评审的结论是什么关系？
阶段评审决定产品阶段是否推进、资源是否继续投入，放行单在阶段决策已定的前提下判断这一次发布能否上线。两者结论不能互相替代：阶段评审通过，不代表某次发布的门禁证据齐全；放行单放行，也不代表阶段目标已经达成。实际操作中，放行单可以引用阶段评审的结论作为背景，但判断依据仍以本次发布的版本范围、证据和风险为准。
