发布审批要回答的问题只有一个：这一次发布是否允许上线。可执行的做法是把发布拆成申请、门禁核验、评审决策、放行与留档四个动作，每一步都留下可核对的输入和输出。前提是门禁条件、证据来源和决策权限在发布前已经写清楚，审批才能重复执行、事后可追溯。发布申请、门禁证据与审批结论通常需要在工作项和文档中流转留痕，ONES 可以作为承载这类记录的工具之一。
要点总览（TL;DR）
- 发布审批只回答一个问题：这一次发布是否允许上线。按申请、门禁核验、评审决策、放行与留档四步推进，每步都要有明确输入、输出和完成标志。
- 申请单需写清发布范围、变更清单、验证证据、回退方案和发布窗口；核验人对照门禁表逐项核对证据，口头确认不计入核验结果。
- 门禁表固定门禁项、判定标准、证据来源、责任人四个字段，并区分阻断项与可豁免项；豁免须记录理由、批准人和补做期限，不能用于功能验证、回退方案等核心项。
- 决策结论限定为通过、有条件通过、驳回三种；有条件通过必须写明附加条件、责任人和跟踪方式，决策人权限按发布风险分级事先约定。
- 审批完成的最低标准是审批记录、证据与发布结果能互相对应；紧急发布通道需限定场景，发布后补做完整审批和证据归档。
发布审批的核心动作与操作步骤
发布审批按四个动作推进：申请人提交发布申请，核验人按质量门禁逐项核对证据，决策人给出结论，放行后记录实际结果并归档。四个动作首尾相接，前一步的输出就是后一步的输入，任何一步缺少明确产物，审批就容易退化成签字。
第一步：提交发布申请
输入是本次发布的变更内容和验证材料。申请人需要写清发布范围（涉及哪些系统、模块、环境）、变更清单（新增、修改、删除的具体内容）、验证证据（测试结果、回归范围、验证环境）、回退方案（回退步骤、回退触发条件、数据兼容处理）、发布时间窗口和影响范围。输出是一份信息完整的发布申请单。完成标志是申请单字段齐全，核验人无需再向申请人追问基本信息即可开始核验。
第二步：按质量门禁逐项核验
输入是发布申请单和门禁表。核验人对照门禁表逐项检查，每一项都要指向具体证据，例如测试报告编号、验证环境截图、变更评审记录，而不是凭印象判断“应该没问题”。核验结果分三种：满足、不满足、满足但需附条件。输出是一份带证据指向的核验记录。完成标志是所有阻断项都有明确结论，可豁免项记录了理由、批准人和补做期限。
第三步：评审决策
输入是核验记录和发布申请单。决策人依据门禁结论给出三种结论之一：通过，表示所有阻断项满足、无遗留风险；有条件通过，表示阻断项满足但存在需要跟踪的事项，必须写明附加条件、责任人和完成时限；驳回，表示存在未满足的阻断项或回退方案不可行。输出是带结论、决策人和时间的审批记录。完成标志是结论明确、附加条件可执行、决策人对结论负责。
第四步：放行与留档
输入是审批结论。通过或有条件通过后，发布负责人按计划执行发布，并在发布完成后记录实际发布时间、执行结果、是否触发回退、遗留问题。输出是发布记录与审批记录的合并归档。完成标志是审批记录、证据、发布结果三者能互相对应，事后任何人可以据此还原这次发布为什么被放行。
发布审批的角色分工与交付物
发布审批涉及四类角色：申请人、核验人、决策人、留档与复盘责任人。角色可以一人多岗，但职责边界要写清楚，尤其是决策权限，避免出现“谁都能批、谁都不负责”的情况。
| 角色 | 主要职责 | 交付物 | 权限边界 |
|---|---|---|---|
| 发布申请人（通常是发布负责人或开发负责人） | 整理发布范围、变更清单、验证证据和回退方案，发起申请 | 发布申请单 | 对申请信息真实性负责，无权自行决定放行 |
| 质量门禁核验人（测试、运维、安全等按门禁项分工） | 对照门禁表逐项核验证据，标注满足、不满足或需附条件 | 核验记录及证据指向 | 只对核验项给出结论，不代替决策人放行 |
| 审批决策人（发布负责人上级或变更审批负责人） | 依据核验结论给出通过、有条件通过或驳回 | 审批结论及附加条件 | 权限应事先约定，例如高风险发布需更高级别决策人 |
| 留档与复盘责任人（通常是发布负责人或项目经理） | 归档审批记录与发布结果，组织复盘 | 归档记录、复盘结论 | 对记录完整性负责，不修改已归档的审批结论 |
证据来源要固定下来：测试证据来自测试报告或验证记录，安全证据来自安全扫描或评审结论，运维证据来自变更窗口确认和回退演练记录。核验人只采信有出处的证据，口头确认不计入核验结果。决策人的权限边界建议按发布风险分级设定，例如涉及核心交易链路的发布由更高层级决策人审批，普通配置变更可授权到团队负责人。留档与复盘由发布负责人牵头，复盘结论回写到门禁表或流程中，形成下一轮改进的输入。
质量门禁条件怎么写：一张可填写的门禁表
门禁表的作用是让每次审批用同一把尺子。建议固定四个字段：门禁项、判定标准、证据来源、责任人。判定标准要写成可核验的条件，例如“核心用例通过率 100%，且无未关闭的严重缺陷”，而不是“测试充分”。
| 门禁项 | 判定标准 | 证据来源 | 责任人 | 类型 |
|---|---|---|---|---|
| 功能验证 | 本次变更相关用例全部通过，无未关闭的严重缺陷 | 测试报告、缺陷列表 | 测试负责人 | 阻断项 |
| 回归范围 | 受影响模块完成回归，回归清单与变更清单对应 | 回归记录 | 测试负责人 | 阻断项 |
| 回退方案 | 回退步骤可执行，回退触发条件明确，数据兼容已确认 | 回退方案文档、演练记录 | 发布负责人 | 阻断项 |
| 变更窗口 | 发布时间在约定窗口内，相关方已收到通知 | 发布计划、通知记录 | 运维负责人 | 阻断项 |
| 监控告警 | 关键指标监控已配置，告警接收人明确 | 监控配置记录 | 运维负责人 | 可豁免项（可发布后 24 小时内补齐） |
阻断项不满足时不能放行；可豁免项允许在记录理由、批准人和补做期限后先行发布，但豁免不能用于功能验证、回退方案这类核心项。门禁条件应随发布类型调整：常规迭代可以精简为功能验证、回归、回退三项；涉及数据库结构变更或核心链路的发布，应增加数据兼容、安全评审、灰度与回滚演练等门禁项。调整后的门禁表要在发布前确认，避免审批当天临时加项或减项。
一次发布审批的完整示例
以下为演示情景，用于说明判断依据，不代表真实项目数据。某团队计划在周四晚发布订单模块的一次迭代，涉及优惠券计算逻辑调整和两个接口字段变更，影响下单与支付前置校验。
申请人提交的发布申请包含：变更清单（优惠券规则调整、接口字段新增）、验证证据（相关用例 46 条全部通过，回归覆盖下单与支付前置校验）、回退方案（关闭新规则开关并回退接口版本，触发条件为下单失败率超过阈值）、发布窗口（周四 22:00–23:00）。
核验人逐项核对：功能验证满足，回归范围满足，回退方案满足；监控告警项中，优惠券核销失败率的告警尚未配置，属于可豁免项。核验结论为“阻断项全部满足，监控告警项需附条件”。
决策人给出“有条件通过”：附加条件是在发布后 24 小时内补齐优惠券核销失败率告警，责任人为运维负责人，跟踪方式是在发布记录中登记待办并在次日站会确认。发布执行后记录：22:10 完成发布，22:30 观察期内下单失败率正常，未触发回退，遗留待办一项。审批记录、核验证据和发布结果一并归档。
发布审批的完成检查与常见缺口
判断一次发布审批是否做到位，可以按下面的清单逐项核对。清单全部满足，才说明审批有实际约束力。
- 发布申请单字段齐全，变更清单与验证证据一一对应。
- 每个阻断项都有明确结论和证据指向，没有“口头确认”代替证据。
- 审批结论为三种之一，有条件通过的附加条件写明了责任人、时限和跟踪方式。
- 决策人符合事先约定的权限级别。
- 发布结果已回填，审批记录、证据、发布结果可互相对应。
- 豁免项已登记理由、批准人和补做期限，并在期限内关闭。
常见缺口有几类。一是证据缺失或过期，例如引用上一版本的测试报告，处理方式是退回补充，不能用“上次也是这样”替代；证据确实无法在窗口内补齐时，按可豁免项流程处理，并明确补做期限。二是紧急发布通道被滥用，紧急通道应限定在故障修复等明确场景，边界由决策人书面确认，发布后须在规定时间内补做完整审批和证据归档，补审不能省略门禁核验。三是审批记录不可追溯，表现为结论没有决策人、时间或证据指向，检查方法是随机抽取一次历史发布，看能否仅凭归档记录还原放行理由。
用工作项与文档承载发布审批记录
审批记录要能追溯，靠的是把申请、证据和结论落到有状态、有归属的载体上。常见做法是用一个发布工作项承载申请与审批，用关联文档承载证据和结论。
发布申请作为工作项，字段可包括发布范围、变更清单、回退方案、发布窗口、风险等级、申请人和决策人；状态按“待提交—待核验—待决策—已放行—已发布—已归档”流转，每次流转记录操作人和时间。门禁证据以文档或附件形式关联到工作项，核验结论写在核验记录中并回链到对应门禁项。审批通过后，发布记录作为同一工作项的后续状态更新，把实际发布时间、执行结果、遗留待办回填进去，形成从申请到结果的完整链条。这样归档后的记录可以直接用于复盘：回看某次发布的门禁结论与实际结果是否一致，进而调整门禁表或流程。ONES 的工作项与文档可以承载这类字段、状态流转和关联关系，具体配置按团队现有流程设定。
常见问题
发布审批和研发阶段评审有什么区别，边界怎么划？
发布审批针对的是一次具体发布，判断这一次是否允许上线，输入是本次发布的变更清单、验证证据和回退方案，输出是放行结论。研发阶段评审关注的是阶段目标是否达成、是否进入下一阶段，属于组织级决策。两者可以共用部分证据，但结论对象不同：阶段评审通过不自动等于某次发布可以放行，发布审批也不能替代阶段决策。测试是否完成、质量是否达标属于测试报告与质量评估的结论，发布审批引用这些结论作为门禁证据，不重复做测试完成判断。
门禁项在审批当天发现不适用，可以临时删掉吗？
不建议在审批当天临时增删门禁项。门禁表应在发布前按发布类型确认，审批时按已确认的版本执行。如果确实发现某项门禁不适用于本次发布，处理方式是由决策人书面确认该项不适用并记录理由，而不是直接从门禁表中删除。若属于可豁免项，按豁免流程登记理由、批准人和补做期限。审批结束后，把不适用或调整的情况回写到门禁表，作为下一轮调整的依据，避免同类发布反复出现临时判断。
有条件通过之后，附加条件没人跟踪怎么办？
有条件通过的风险在于附加条件被遗忘。做法是把每个附加条件转成一条有责任人、有完成时限的待办，登记在发布记录中，并在发布后的固定节点（例如次日站会或发布复盘）逐项确认关闭情况。跟踪人建议由留档与复盘责任人担任，而不是由提出条件的决策人自己跟。附加条件到期未关闭时，应升级到决策人处理，必要时暂停后续相关发布，直到条件关闭。
紧急发布可以跳过门禁核验吗？
紧急通道压缩的是审批等待时间，门禁核验本身仍要执行。可行的做法是事先约定紧急发布的适用场景（例如线上故障修复），由决策人书面确认进入紧急通道，核验人只核对与本次修复直接相关的核心门禁项，例如回退方案和验证证据。发布完成后须在规定时间内补做完整审批和证据归档，补审时逐项补齐当时未核验的门禁项。紧急通道的使用记录应定期回看，如果频繁触发，说明常规发布流程或门禁设置需要调整。
审批记录要留到什么程度，才算可追溯？
可追溯的最低要求是：仅凭归档记录就能还原这次发布为什么被放行。记录中应包含发布范围与变更清单、每项门禁的结论及证据指向、决策人、决策时间和结论类型、有条件通过时的附加条件与关闭情况，以及发布后的实际执行结果。检查方法是随机抽取一次历史发布，看能否在不询问当事人的情况下还原上述信息。如果结论只有签字没有证据指向，或者发布结果没有回填，就属于记录缺口，需要在流程中补上对应字段和状态流转。
