发布检查清单用于判断某一次发布是否具备上线条件：把质量、变更、依赖、回滚、监控和审批证据落到可核验的检查项上，每项写明通过标准、证据、负责人和检查时点，并标出阻断项。本文给出一份可直接使用的分阶段清单，适用于常规版本发布与紧急修复发布；全部阻断项通过、非阻断项有明确处置结论后，才允许放行。
要点总览（TL;DR）
- 发布检查清单围绕单次发布是否允许上线组织，按发布前、发布执行与回滚、发布后观察三个阶段逐项核验，每项写明通过标准、证据、负责人和检查时点。
- 通过标准要写成可对照判断的表述，例如“本次发布范围内无未关闭的严重及以上缺陷”，并配套缺陷列表、回归记录、变更单等可独立支撑结论的证据。
- 阻断项未通过即不得发布，常见阻断项包括严重缺陷未关闭、变更清单与实际内容不一致、回滚方案未验证、数据备份未完成、监控未配置、放行审批未签署。
- 整体完成条件为三条同时满足：全部阻断项通过、非阻断项均有处置结论或已批准豁免、放行确认由指定签署人完成。
- 清单落地时把一次发布建成工作项，检查项、证据附件与审批记录挂在同一处，发布后复盘直接引用该工作项的历史记录。
谁在什么时点使用这份发布检查清单
这份清单服务于单次发布的放行判断，参与者在不同时点承担不同核验责任。发布负责人组织检查并汇总结论，研发负责人确认变更内容与影响范围，测试负责人提供质量证据，运维或值班人员确认环境、部署与监控就绪，审批人依据证据做出放行决定。清单在发布前启动，贯穿发布执行，延伸到发布后观察期结束。
| 角色 | 主要检查时点 | 核心职责 |
|---|---|---|
| 发布负责人 | 发布前T-1至发布前、发布执行中 | 组织清单填写、汇总阻断项状态、发起放行审批 |
| 研发负责人 | 发布前T-1至发布前 | 确认变更清单、影响范围、配置与数据变更 |
| 测试负责人 | 发布前T-1至发布前 | 提供缺陷收敛、回归范围与测试结论证据 |
| 运维/值班人员 | 发布前、发布执行中、发布后观察期 | 确认环境资源、执行发布步骤、监控指标与告警 |
| 审批人 | 发布前放行节点 | 审核证据完整性，签署放行或驳回结论 |
清单的边界是回答“这次发布能否上线”。组织级的阶段决策机制、测试是否完成的专业判断，分别属于其他管理环节，本文不展开。这样划分可以让清单保持可操作：每个检查项都指向本次发布的具体证据，而不是重复评审流程。
发布前检查项：质量、变更与依赖
发布前检查决定是否进入执行阶段，重点是把“感觉可以发”转成“证据显示可以发”。以下检查表按质量、变更、依赖三类组织，每项都给出可判断的通过标准和所需证据。
| 类别 | 检查项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|---|
| 质量 | 缺陷收敛 | 本次发布范围内无未关闭的严重及以上缺陷；一般缺陷均有明确处置结论 | 缺陷列表及状态截图 | 测试负责人 | 是 |
| 质量 | 回归范围 | 回归范围覆盖本次全部变更点及关联模块，回归结论为通过 | 回归范围说明与执行记录 | 测试负责人 | 是 |
| 质量 | 测试结论引用 | 测试结论已形成书面记录，注明版本号、测试环境和结论日期 | 测试报告或结论记录 | 测试负责人 | 是 |
| 变更 | 变更清单 | 变更清单与实际发布内容一致，无清单外变更 | 变更单或发布内容清单 | 研发负责人 | 是 |
| 变更 | 影响范围 | 已列明受影响的系统、接口和用户场景，并通知相关方 | 影响范围说明与通知记录 | 研发负责人 | 是 |
| 变更 | 配置与数据变更 | 配置项、数据库脚本已评审，执行顺序和数据兼容性已确认 | 配置变更单、脚本评审记录 | 研发负责人 | 是 |
| 依赖 | 上下游系统 | 上下游系统版本兼容，接口联调通过 | 联调记录或接口验证结果 | 研发负责人 | 是 |
| 依赖 | 第三方服务 | 第三方服务可用，配额与证书在有效期内 | 服务状态确认记录 | 运维/值班人员 | 是 |
| 依赖 | 环境与资源 | 目标环境部署完成，计算、存储、网络资源满足发布要求 | 环境检查记录 | 运维/值班人员 | 是 |
通过标准的写法要避免“已完成”“没问题”这类无法判断的表述。可操作的做法是写明对象、状态和证据形式，例如“本次发布范围内无未关闭的严重及以上缺陷”，检查人可以直接对照缺陷列表得出结论。证据则要能独立支撑结论，截图需包含时间与版本信息，记录需注明检查人。
发布执行与回滚准备检查项
执行阶段的检查目标是让发布步骤可复现、退路可用。发布前确认执行顺序和回滚条件，发布中按步骤执行并记录结果，任何偏离预案的操作都需要记录原因。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 发布步骤与执行顺序 | 发布步骤已书面化，含每步操作、预期结果和验证方式，执行顺序经复核 | 发布方案文档 | 发布负责人 | 是 |
| 回滚方案 | 回滚步骤与发布步骤对应，回滚后系统状态可恢复到发布前 | 回滚方案文档 | 研发负责人 | 是 |
| 回滚触发条件 | 明确写出触发回滚的指标阈值或异常现象，值班人员可据此判断 | 回滚触发条件说明 | 发布负责人 | 是 |
| 回滚演练证据 | 关键变更在预发或演练环境完成回滚验证，结果记录在案 | 回滚演练记录 | 运维/值班人员 | 是 |
| 发布窗口与值班安排 | 发布窗口已确认，值班人员与联系方式明确，避开业务高峰 | 发布排期与值班表 | 发布负责人 | 是 |
| 通知对象 | 受影响业务方、客服与相关团队已收到发布通知，含时间与影响说明 | 通知记录 | 发布负责人 | 否 |
| 数据备份与恢复 | 涉及数据变更的发布已完成备份，恢复流程可用并验证过 | 备份记录与恢复验证结果 | 运维/值班人员 | 是 |
回滚准备容易被写成“有回滚方案”就通过，实际判断要看三点：回滚步骤是否与本次变更对应、触发条件是否可被值班人员直接识别、是否做过验证。缺少验证记录的回滚方案，在真实故障中往往无法按预期执行，因此应作为阻断项处理。
发布后观察与放行确认检查项
发布完成不等于放行结束。观察期用于确认系统在真实流量下表现符合预期，并把最终结论固化下来，形成可追溯的闭环。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 监控指标与告警阈值 | 核心业务指标、错误率、响应时间、资源使用率已配置监控，告警阈值与基线明确 | 监控配置截图 | 运维/值班人员 | 是 |
| 观察期时长 | 观察期时长已事先约定，覆盖至少一个业务高峰或关键交易周期 | 观察期安排记录 | 发布负责人 | 是 |
| 观察结论记录 | 观察期结束时记录指标对比结果，明确正常或异常结论 | 观察期指标记录 | 运维/值班人员 | 是 |
| 异常上报与升级路径 | 异常上报渠道、升级对象和响应时限已明确，值班人员知晓 | 升级路径说明 | 发布负责人 | 是 |
| 放行确认签署 | 放行结论由指定签署人确认，注明签署时间与结论 | 审批或签署记录 | 审批人 | 是 |
观察结论应写成可比较的记录，例如发布前后同一指标的变化，而不是“运行正常”一句结论。放行确认的签署人应在发布前指定，避免发布后临时找人签字，导致责任不清。
阻断项与完成条件
清单能否发挥作用，取决于阻断规则是否被严格执行。阻断项是未通过即不得发布的项目，通常包括：严重及以上缺陷未关闭、变更清单与实际发布内容不一致、回滚方案未验证、数据备份未完成、监控未配置、放行审批未签署。这些项目直接关系发布失败后的可控性，不能以“先发布再补”的方式绕过。
非阻断项未通过时，需要有明确处置结论：立即修复、接受风险并记录、或调整发布范围。接受风险的决定应写明风险内容和承担人，不能只勾选“已知悉”。豁免适用于确有客观原因无法在本次发布前完成的项目，需要由申请人提出、说明原因和补偿措施，经审批人批准后留痕；豁免记录应随发布记录一并归档，供后续复盘引用。
整体完成条件可以归纳为三条：全部阻断项状态为通过；非阻断项均有处置结论或已批准的豁免；放行确认已由指定签署人完成。三条同时满足，本次发布才视为具备放行条件。
证据留存与负责人分工
证据是清单可追溯的基础。每类检查项对应固定的证据形式，统一存放位置和命名规则，才能在发布后快速回溯，也便于复盘时引用。
| 检查类别 | 证据形式 | 留存位置 | 负责人 | 复核人 |
|---|---|---|---|---|
| 质量 | 测试报告、缺陷列表、回归记录 | 测试管理空间，按版本号归档 | 测试负责人 | 发布负责人 |
| 变更 | 变更单、影响范围说明、脚本评审记录 | 变更管理记录，按发布批次归档 | 研发负责人 | 发布负责人 |
| 依赖 | 联调记录、环境检查记录 | 发布工作项附件 | 运维/值班人员 | 研发负责人 |
| 执行与回滚 | 发布方案、回滚演练记录、备份记录 | 发布工作项附件 | 运维/值班人员 | 发布负责人 |
| 观察与放行 | 监控截图、观察结论、审批记录 | 发布工作项附件 | 值班人员、审批人 | 发布负责人 |
命名规则建议包含发布日期、版本号和检查类别，例如“20250612-v3.2.1-回滚演练记录”，便于按批次检索。负责人负责提交证据，复核人负责确认证据与检查项对应，两者分离可以降低“自己检查自己”带来的遗漏。清单及全部证据在发布结束后归档，复盘时直接引用同一批记录，避免重新收集材料。
用工作项承载发布检查清单
清单落地时最常见的问题是检查项散落在文档、聊天记录和邮件里，状态和证据对不上。把一次发布建成一个工作项，检查项作为工作项下的子项或检查列表，负责人、状态和证据附件都挂在该工作项上，可以让放行判断有统一依据。
具体做法是：发布负责人创建发布工作项，按本文三个阶段录入检查项并指定负责人；各负责人完成检查后更新子项状态，上传对应证据附件；阻断项单独标记，未通过时工作项保持未完成状态；审批人在工作项中查看证据并记录放行结论。ONES 支持工作项、子项、状态流转、附件与审批记录的管理，可以把检查项状态、证据和放行结论放在同一处，发布后复盘时直接引用该工作项的历史记录。这样清单从一份静态表格变成可追踪的执行记录，检查项是否完成、由谁完成、依据什么证据，都能在发布结束后查证。
常见问题
紧急修复发布也要走完整的发布检查清单吗？
紧急修复发布同样需要清单，但可以按变更范围裁剪检查项，不能跳过阻断规则。裁剪时保留与本次修复直接相关的质量证据、变更清单、回滚方案和监控确认，把与本次无关的检查项标注为不适用并写明理由。回滚方案和监控确认在紧急场景下更关键，因为修复本身可能引入新问题，缺少退路会让故障处理更被动。裁剪结果由发布负责人记录，审批人按裁剪后的清单判断放行。
非阻断项没通过，但业务方要求按时上线，怎么处理？
非阻断项未通过时，需要给出明确处置结论：立即修复、接受风险并记录、或调整发布范围。业务方要求按时上线属于接受风险的场景，应由风险承担人书面写明风险内容、影响范围和补偿措施，经审批人确认后随发布记录归档。记录的作用是让后续复盘能追溯当时的判断依据，避免风险暴露后责任不清。阻断项不适用这一处理方式，未通过即不得发布。
回滚演练记录缺失，能否先用回滚方案文档代替？
回滚方案文档说明的是计划怎么做，回滚演练记录证明的是实际能做。两者不能互相替代。缺少演练记录时，回滚步骤是否与本次变更对应、恢复后系统状态是否可达预期都未经验证，真实故障中按方案执行可能失败。因此回滚演练证据应作为阻断项处理，在发布前补齐；确有客观原因无法完成的，按豁免流程申请、审批并留痕，同时说明补偿措施。
观察期多长合适，观察结论怎么写才算有效？
观察期时长应在发布前约定，覆盖至少一个业务高峰或关键交易周期，具体长度取决于业务流量特征和变更影响范围。观察结论要写成可比较的记录，例如发布前后同一指标的变化、错误率与响应时间的对比，而不是“运行正常”一句判断。结论由值班人员记录，发布负责人复核，作为放行确认签署的依据之一。
检查项和证据分散在文档、聊天记录里，怎么保证可追溯？
可追溯的关键是让检查项状态、证据和放行结论指向同一份记录。常见做法是把一次发布建成一个工作项，检查项作为子项或检查列表，负责人更新状态并上传证据附件，阻断项单独标记，审批人在同一工作项中记录放行结论。证据命名包含发布日期、版本号和检查类别，便于按批次检索。ONES 支持工作项、子项、状态流转、附件与审批记录的管理，可以把这些内容放在同一处，发布后复盘直接引用该工作项的历史记录。
