软件上线发布审批清单用于回答一个具体问题：本次发布是否允许上线。它由发布负责人牵头，研发、测试、运维、安全合规和业务验收角色共同填写，在发布评审会前自检、会中逐项确认、发布窗口开启前完成签署。清单按六个阶段组织，每项写明通过标准、证据位置、负责人和检查时点；变更未冻结、关键缺陷未关闭、回滚方案缺失、监控未就绪、审批人未签署等阻断项任一不通过，本次发布即不放行。
要点总览（TL;DR）
- 清单按发布范围与变更冻结、质量与测试证据、安全与合规、部署与回滚、监控与值守、审批签署六个阶段组织，每项写明通过标准、证据、负责人和检查时点。
- 使用节奏分三段：评审会前各角色自检补证据，会中逐项确认并标记阻断项，发布窗口开启前完成最终签署。
- 变更未冻结、阻断级缺陷未关闭、回滚方案缺失、监控未就绪、关键审批人未签署属于阻断项，任一项不通过即不放行本次发布。
- 放行完成条件是全部阻断项通过、各角色签署齐全、证据清单完整可查；未通过时可选补齐重审、缩小发布范围或推迟窗口。
- 把检查项转为可指派的工作项并与证据文档关联，能让评审会前直接看到未完成项，发布结论与记录形成可追溯链路。
谁在什么时点使用这份发布审批清单
这份清单服务于一次具体的发布决策，使用对象是承担发布责任和提供放行证据的角色。发布负责人负责组织填写与汇总结论；研发负责人确认变更范围与技术准备；测试负责人提供测试与缺陷证据；运维负责人确认部署、回滚与监控就绪；安全与合规负责人给出安全扫描和数据处理的处置结论；业务验收人确认业务侧验证结果。角色可以兼任，但每项检查都要落到一个具名负责人。
使用时点分为三段，三段承担不同动作：
| 时点 | 主要动作 | 产出 |
|---|---|---|
| 发布评审会前 | 各负责人按分工自检，补齐证据并填写结论 | 预填完成的清单与证据索引 |
| 评审会中 | 逐项确认通过标准，标记阻断项，记录争议与例外申请 | 会议确认结论与待办 |
| 发布窗口开启前 | 核对阻断项全部关闭，完成最终签署 | 签署齐全的放行记录 |
需要区分判定范围：清单只回答“本次发布是否允许上线”。研发阶段的方案评审、代码评审属于阶段质量活动，测试报告及其结论属于测试完成判断，二者是清单的输入证据，清单本身不重新判定它们的技术结论，只核验证据是否齐备、结论是否支持放行。清单填写采用统一格式：每项记录“通过/不通过/不适用”、证据位置（文档编号或系统记录）、负责人和确认时间，避免只写“已完成”而无法追溯。
第一阶段：发布范围与变更冻结检查项
范围与冻结阶段解决“发布什么、冻结在哪个版本”的问题。范围不清或冻结失效，后续测试与安全证据都可能对应错误的制品，因此这一阶段的检查要在评审会最早完成。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 发布清单与版本号、制品标识一致 | 发布清单中的每个制品均有唯一版本号或哈希，与制品库记录一致 | 发布清单、制品库记录截图 | 发布负责人 | 评审会前 |
| 变更内容已登记并完成评审 | 每项变更关联需求或缺陷编号，且已完成相应评审 | 变更登记表、评审记录 | 研发负责人 | 评审会前 |
| 变更冻结已生效 | 冻结时间点已通告，冻结后新增变更走例外审批并留记录 | 冻结通告、例外审批单 | 发布负责人 | 冻结时点 |
| 依赖方与上下游已确认窗口 | 上下游系统、接口提供方书面确认发布窗口无冲突 | 确认邮件或协作记录 | 发布负责人 | 评审会前 |
| 发布范围与灰度或全量策略明确 | 明确本次为灰度还是全量，灰度批次、比例与放量条件已写明 | 发布方案 | 发布负责人与运维负责人 | 评审会中 |
冻结后出现紧急变更时，不能直接并入本次发布，应提交例外审批，说明变更内容、影响范围和补充验证方式，经授权人批准后更新发布清单并重新核验受影响检查项。依赖方确认要具体到接口和时间窗口，口头同意不计为通过。
第二阶段：质量与测试证据检查项
质量阶段核验的是证据是否覆盖本次变更、缺陷是否处于可接受状态。判断依据是测试报告和缺陷记录本身，清单负责确认这些材料齐备且结论明确。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 测试报告覆盖本次变更范围 | 报告列明测试范围与变更清单逐项对应，无遗漏模块 | 测试报告 | 测试负责人 | 评审会前 |
| 阻断级与严重级缺陷关闭 | 阻断级缺陷为零；严重级缺陷全部关闭或有经批准的处置结论 | 缺陷列表与状态记录 | 测试负责人 | 评审会中 |
| 遗留缺陷风险确认 | 每条遗留缺陷标注影响范围、规避方式，并有书面接受记录 | 遗留缺陷清单、接受记录 | 测试负责人与业务验收人 | 评审会中 |
| 回归范围与自动化执行结果 | 回归范围覆盖受影响功能，自动化用例执行结果可查，失败项已分析 | 回归清单、执行报告 | 测试负责人 | 评审会前 |
| 性能与容量结论 | 结论明确说明是否满足本次发布预期负载，不满足时有应对措施 | 性能测试报告 | 测试负责人 | 评审会前 |
遗留缺陷的书面接受要由有权承担业务风险的角色签署，接受记录写明缺陷编号、影响场景和观察措施。自动化执行结果中出现失败用例时，需给出失败原因分析，区分环境问题与真实缺陷，不能以“重跑通过”替代分析记录。
第三阶段：安全、合规与数据检查项
安全与数据检查关注本次变更是否引入新的暴露面、权限扩大或数据处理风险。检查结论要能回答“高危问题是否已处置、数据变更是否可回退”。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 安全扫描结果与高危处置 | 扫描覆盖本次制品，高危问题已修复或有经批准的风险接受 | 扫描报告、处置记录 | 安全负责人 | 评审会前 |
| 权限变更复核 | 新增或变更的权限逐条列出，符合最小权限要求，无越权配置 | 权限变更清单、复核记录 | 安全负责人与研发负责人 | 评审会中 |
| 数据库变更脚本评审与回退 | 脚本已评审，配套回退脚本可执行并经过验证 | 脚本评审记录、回退脚本 | 研发负责人与运维负责人 | 评审会前 |
| 敏感数据与个人信息处理 | 涉及的个人信息字段、用途、存储期限符合内部要求，脱敏措施明确 | 数据影响说明 | 安全与合规负责人 | 评审会中 |
| 第三方组件与许可证 | 新增组件清单完整，许可证类型已确认，无禁止使用的许可证 | 组件清单、许可证记录 | 研发负责人 | 评审会前 |
数据库变更的回退脚本要区分“结构回退”和“数据回退”，涉及数据删除或格式转换的变更，需说明回退后数据是否可恢复。风险接受记录应写明接受人、接受范围和有效期，超过范围的问题仍需修复。
第四阶段：部署、回滚与监控值守检查项
执行侧准备决定发布能否按计划推进、异常时能否快速止损。这一阶段的检查以“有人做、有依据做、出问题知道找谁”为标准。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 部署步骤与执行人 | 步骤按顺序编号，每步标注执行人与预计耗时，含灰度与分批策略 | 部署方案 | 运维负责人 | 评审会前 |
| 回滚方案与触发条件 | 回滚步骤可执行，触发条件量化（如错误率、时延阈值），决策人明确 | 回滚方案 | 运维负责人与发布负责人 | 评审会中 |
| 回滚演练或验证结果 | 在预发或灰度环境完成回滚验证，记录耗时与结果 | 演练记录 | 运维负责人 | 评审会前 |
| 监控指标、告警阈值与值班表 | 核心指标已配置，阈值与基线明确，发布窗口内值班人到岗 | 监控配置、值班表 | 运维负责人 | 发布窗口前 |
| 发布后验证用例与观察窗口 | 验证用例覆盖核心链路，观察窗口时长与判定标准已约定 | 验证清单 | 测试负责人与业务验收人 | 评审会中 |
回滚触发条件要写成可判断的数值或现象，例如“核心接口错误率连续五分钟超过设定阈值”，并指定谁有权下达回滚指令。观察窗口内由值班人按验证清单逐项确认，结果回填到发布记录，作为复盘依据。
第五阶段：审批签署与证据归档
签署环节把前面的检查结论转化为可追溯的放行决定。签署顺序建议按证据依赖排列：研发负责人确认范围与技术准备，测试负责人确认质量证据，安全与合规负责人确认风险处置，运维负责人确认执行准备，业务验收人确认业务可用，最后由发布负责人汇总并签署放行结论。
| 签署角色 | 授权范围 | 签署内容 | 记录载体 |
|---|---|---|---|
| 研发负责人 | 变更范围、技术方案、组件与脚本 | 范围与变更冻结、数据库脚本结论 | 发布单签署栏 |
| 测试负责人 | 测试结论与缺陷状态 | 测试证据与遗留缺陷接受 | 发布单签署栏 |
| 安全与合规负责人 | 安全扫描与数据处理结论 | 高危处置与合规确认 | 发布单签署栏 |
| 运维负责人 | 部署、回滚与监控准备 | 执行侧就绪确认 | 发布单签署栏 |
| 业务验收人 | 业务验证结果 | 业务可用确认 | 发布单签署栏 |
| 发布负责人 | 整体放行决定 | 放行结论与例外记录 | 发布单签署栏 |
证据清单应随发布单集中存放，包括发布清单、测试报告、缺陷记录、安全扫描报告、回滚方案与演练记录、监控配置、值班表。例外放行要单独记录：例外事项、批准人、风险说明、补偿措施和跟踪责任人，并在发布后按约定时点复核关闭情况。发布后复盘材料在复盘会结束后归档到同一发布记录下，保证一次发布从申请到复盘形成完整链路。
阻断项与放行完成条件
阻断项是评审会直接判定不放行的条件，任一项不通过，本次发布即停止或推迟。以下清单为通用建议，组织可按发布类型和风险等级调整范围，但调整结果应在发布前明确告知所有签署角色。
| 阻断项 | 判定依据 | 解除方式 | 授权层级 |
|---|---|---|---|
| 变更未冻结 | 冻结通告未发布或冻结后存在未审批变更 | 完成冻结并补办例外审批 | 发布负责人 |
| 阻断级缺陷未关闭 | 缺陷列表中存在阻断级未关闭项 | 修复并验证关闭 | 测试负责人确认 |
| 回滚方案缺失 | 无回滚步骤、无触发条件或无决策人 | 补齐方案并完成验证 | 运维负责人与发布负责人 |
| 监控未就绪 | 核心指标未配置、告警未生效或值班未落实 | 完成配置并确认告警可达 | 运维负责人 |
| 关键审批人未签署 | 签署栏存在空缺且无授权代签记录 | 取得签署或按授权规则代签 | 发布负责人上级 |
非阻断项包括一般级缺陷、文档待补充、非核心指标优化等，记录后纳入跟踪清单，明确责任人和完成时点，不因非阻断项阻塞本次发布，但要在下次发布前复核关闭情况。放行完成条件为：全部阻断项通过，各角色签署齐全，证据清单完整可查。未通过时的处置路径有三条：补齐证据后重新评审；缩小发布范围，将未就绪部分移出本次发布；推迟发布窗口并通知依赖方。三条路径的选择由发布负责人提出、评审会确认，并记录在发布单中。
把清单落到发布流程中的协作方式
清单要真正起作用，需要从文档变成可跟踪的执行记录。常见做法是把每个检查项转为可指派的工作项，设置负责人和截止时点，检查结论作为工作项状态更新，证据文档与发布单关联存放。这样评审会前可以直接查看未完成项，而不必逐份翻找材料。
在工具承载上，ONES 可用于把发布审批过程组织为一条可追溯的记录：检查项作为工作项指派到人并跟踪状态，测试报告、安全扫描报告等证据文档与发布单关联，阻断项状态变化触发通知和升级，审批结论与发布记录一并留存。对于多角色签署的发布，集中留存的价值在于复盘时能还原每个结论的依据和确认时间。团队可按自身流程裁剪清单项和阻断项范围，把调整后的版本固化为发布模板，减少每次发布重复沟通。
常见问题
发布评审会前证据还没补齐，可以先开会后补签吗？
可以开会，但结论要区分清楚。评审会中可以逐项确认并记录“证据待补”，把相关项标记为未通过；在发布窗口开启前，待补证据必须补齐并由对应负责人确认，签署才能完成。若到窗口开启时阻断项仍未关闭，本次发布按未通过处理，走补齐重审、缩小范围或推迟窗口的路径，不能用会后代签替代证据核验。
紧急修复发布也要走完整清单吗？
建议保留清单结构，按风险裁剪检查深度。紧急修复通常范围小、时间紧，可以合并部分检查项、简化证据形式，但变更冻结、缺陷关闭、回滚方案、监控值守和关键签署这几类阻断项仍应保留。裁剪结果要在发布前告知所有签署角色，并在发布记录中写明本次采用了简化版清单及理由，便于复盘时还原判断依据。
灰度发布只放量一部分，阻断项判定可以放宽吗？
灰度不改变阻断项的性质，但会影响判定范围。灰度阶段可以把观察窗口内的指标表现作为放量条件，把未覆盖的验证项留到下一批次；阻断项仍按本次实际发布范围判定，例如本次只放量一个批次，就核验该批次涉及的变更、缺陷和回滚路径。全量放量前需重新确认阻断项状态，避免灰度期间新增变更绕过冻结。
遗留缺陷由谁签字接受才算有效？
接受人应是有权承担该业务风险的角色，通常是业务验收人，涉及安全或数据影响时还需安全与合规负责人共同确认。接受记录写明缺陷编号、影响场景、规避措施和观察期限，仅写“已知悉”不构成有效接受。超出接受范围或影响核心链路的缺陷，仍按阻断项处理。
清单项和阶段评审、测试报告是什么关系？
阶段评审和测试报告是清单的输入证据，清单负责核验这些证据是否齐备、结论是否支持本次放行。清单不重新判定技术方案优劣，也不替代测试报告给出测试完成结论；它只回答本次发布是否允许上线。因此评审记录和测试报告要作为证据随发布单存放，清单中记录其位置和确认时间即可。
