发布检查清单要回答的问题很具体：这次发布是否允许放行。一份可用的清单通常包含七类信息：发布范围与版本标识、变更与依赖核对、质量门禁结果、环境与配置确认、数据与回滚准备、审批与责任人、上线后观察项。每项都应写明通过标准、证据、负责人和检查时点，并把不可放行的阻断项单独标出，避免把口头确认当成通过。
要点总览（TL;DR）
- 发布检查清单只回答一个问题：本次发布是否允许放行；组织级阶段决策和测试完成度评估作为输入引用，不在清单内重新讨论。
- 清单应覆盖七类信息：发布范围与版本标识、变更与依赖核对、质量门禁结果、环境与配置确认、数据与回滚准备、审批与责任人、上线后观察项。
- 每项检查固定四个字段：通过标准、证据、负责人、检查时点；证据缺失视为该项未确认，不能用口头确认替代。
- 阻断项与普通检查项分开标记：关键缺陷未关闭、回滚方案缺失、审批未完成等阻断项未清零不得放行，普通项可带条件通过但需记录。
- 整体放行需同时满足：阻断项清零、必填项均有可核对证据、豁免项已记录审批人与理由；上线后观察期结束并确认无异常后清单归档。
谁在什么时点使用这份清单
发布检查清单服务于单次发布的放行判断，使用对象覆盖发布负责人、研发、测试、运维和审批人。不同角色在清单上承担的动作不同：研发确认变更内容与依赖，测试提供质量门禁结论，运维确认环境、监控与回滚准备，发布负责人汇总证据并组织评审，审批人依据清单结果作出放行决定。清单本身不替代组织级的阶段评审，也不重新评估测试完成度，它引用这些结论作为输入。
检查时点分为三段：发布前评审、发布执行、上线后观察。发布前评审完成全部前置项的核验与审批；发布执行阶段核对步骤、数据变更与回滚条件是否按计划落实；上线后观察阶段确认监控指标与业务表现，满足关闭条件后清单归档。把时点写进清单，可以避免执行阶段才发现前置项缺失。
| 角色 | 主要动作 | 对应时点 |
|---|---|---|
| 发布负责人 | 汇总检查结果、组织评审、发起放行判定 | 发布前评审、发布执行 |
| 研发 | 确认变更清单、关联需求与缺陷状态、依赖项 | 发布前评审 |
| 测试 | 提供测试结论、缺陷遗留与豁免记录 | 发布前评审 |
| 运维 | 核对环境配置、监控告警、回滚方案 | 发布前评审、发布执行 |
| 审批人 | 审阅证据、批准放行或要求整改 | 发布前评审 |
| 值班与业务方 | 观察上线后指标、反馈异常 | 上线后观察 |
发布前检查项：范围、变更与质量门禁
发布前检查项决定这次发布“发什么、影响谁、质量是否达标”。每一项都要有明确的通过标准，标准写成可判断真假的条件，避免“已确认”“基本完成”这类无法复核的表述。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 版本号与发布范围 | 版本号唯一且与发布单一致；列明涉及服务、模块与影响面 | 发布单、版本标签记录 | 发布负责人 |
| 变更清单 | 每项变更关联需求或缺陷编号，状态为已完成或已关闭 | 变更单、工作项列表 | 研发 |
| 依赖项核对 | 上下游系统版本、接口契约、第三方服务可用性均已确认 | 依赖确认记录、接口文档版本 | 研发、运维 |
| 测试结论 | 约定范围的测试已执行完毕，结论为通过 | 测试报告链接 | 测试 |
| 缺陷遗留与豁免 | 遗留缺陷已评估影响并记录豁免人、理由与有效期 | 缺陷列表、豁免审批记录 | 测试、审批人 |
| 环境与配置 | 目标环境版本正确；配置项、功能开关、证书与密钥已核对且在有效期内 | 配置截图、证书有效期记录 | 运维 |
质量门禁结果要作为独立检查项引用，而不是在清单里重新讨论测试是否充分。测试结论、缺陷遗留和豁免记录三者齐全，才能说明质量门禁已闭环。环境与配置核对容易被压缩成一句“环境已就绪”，实际应拆到配置项、开关状态、证书与密钥有效期这些可验证的对象上。
发布执行与回滚准备检查项
执行阶段的检查项围绕“按计划做、出问题能退”展开。发布步骤要写明执行顺序和每步的验证动作，数据变更要单独列出脚本、执行人和执行结果核对方式。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 发布步骤与顺序 | 步骤清单经评审，执行顺序与依赖关系一致，每步有验证动作 | 发布方案、评审记录 | 发布负责人 |
| 数据变更与脚本 | 脚本经审核，执行前已备份，执行结果与预期一致 | 脚本评审记录、执行日志 | 研发、运维 |
| 回滚方案 | 回滚步骤可执行，回滚触发条件明确，回滚责任人已指定 | 回滚预案、演练或评审记录 | 运维 |
| 监控与告警 | 关键指标监控已覆盖本次变更，告警规则生效且通知对象正确 | 监控配置截图、告警测试记录 | 运维 |
| 发布窗口与通知 | 发布时间避开业务高峰，相关方已收到通知 | 发布通知记录 | 发布负责人 |
回滚检查项要写到可操作的程度：回滚触发条件是什么指标、达到什么阈值、由谁决定执行、回滚后如何验证数据一致性。只有“有回滚方案”这一句，无法在故障时支撑决策。数据变更类发布还应确认回滚是否涉及数据恢复，以及恢复的时间窗口。
审批、证据与责任人如何落表
清单能否被复核，取决于每项是否留下可追溯的证据和明确的责任人。建议为每个检查项固定四个字段：通过标准、证据、负责人、检查时点。缺少任一字段，复核时就容易退化为口头确认。
| 字段 | 填写要求 | 常见形式 |
|---|---|---|
| 证据 | 可打开、可核对，能直接证明该项已通过 | 评审记录、测试报告链接、变更单、配置截图、日志片段 |
| 执行人 | 实际完成检查动作的人 | 姓名或账号 |
| 复核人 | 对证据进行二次确认的人，与执行人分离 | 姓名或账号 |
| 审批人 | 对放行结果负责的人 | 姓名或角色 |
| 检查时点 | 标明发布前、执行中或上线后 | 时点标签加时间 |
| 未通过记录 | 写明未通过原因、整改动作与复检结果 | 问题记录、复检结论 |
证据缺失应视为该项未确认，不能用“已沟通”“已知悉”替代。豁免项要单独记录豁免人、理由和有效期，豁免不等于默认放行，仍需审批人确认。把执行人与复核人分开，可以减少同一人自检自签带来的遗漏。
当发布单、检查项和审批记录分散在文档、聊天和邮件中时，证据链容易断裂。ONES 可以把发布相关的工作项、检查项状态和审批记录放在同一处承载：研发在需求与缺陷工作项上更新状态，测试附上报告链接，发布负责人按清单逐项确认并提交审批，审批结果与豁免记录随发布单留存。这样复核时能沿同一条记录追溯每项检查的执行人、证据和时点。具体字段与审批流配置需按实际使用版本确认。
阻断项与放行完成条件
阻断项是清单中不可协商的部分：只要有一项未清零，本次发布就不得放行。普通检查项可以在记录条件与风险后带条件通过，阻断项不适用这种处理方式。
| 阻断项 | 判定说明 |
|---|---|
| 关键缺陷未关闭 | 影响核心流程的缺陷仍处于打开状态，且无经审批的豁免记录 |
| 回滚方案缺失或不可执行 | 没有回滚步骤、触发条件或责任人，或回滚未经验证 |
| 审批未完成 | 规定审批人未签署放行意见 |
| 质量门禁结论缺失 | 约定范围的测试未执行或测试报告无法提供 |
| 环境或配置未确认 | 目标环境版本不符，证书、密钥或关键开关状态未核对 |
整体放行条件可以归纳为三条：全部阻断项清零；必填检查项均有证据且证据可核对；豁免项均已记录审批人与理由。三条同时满足，发布负责人才提交放行审批。上线后观察项要写明观察时长、观察指标和关闭条件，观察期结束并确认无异常后，清单才归档关闭。清单模板可以按发布类型裁剪普通检查项，阻断项集合与放行判定规则应保持稳定，避免因发布类型不同而放松放行标准。
常见问题
发布检查清单和测试报告、阶段评审是什么关系？
三者回答的问题不同。测试报告回答约定范围的测试是否执行完毕、结论如何；阶段评审回答项目是否进入下一阶段；发布检查清单只回答本次发布是否允许放行。清单把测试结论和评审结论作为输入引用，不在清单里重新评估测试是否充分，也不替代阶段决策。实际操作中，清单上对应位置填写测试报告链接和评审记录编号即可，复核人沿链接核对原始结论。
普通检查项没通过，能不能先发布再补？
要看该项是否属于阻断项。阻断项未清零不得放行，不适用带条件通过。普通检查项在记录未通过原因、影响评估、整改动作和责任人后，可由审批人确认带条件通过，并在上线后观察期内完成整改与复检。带条件通过必须留下审批记录，复检结果回填到同一检查项，避免整改事项在发布后失去跟踪。
豁免记录应该写哪些内容，谁来批？
豁免记录至少包含四项：豁免对象（哪条缺陷或哪个检查项）、豁免理由与影响评估、豁免有效期、审批人。豁免由对放行结果负责的审批人签署，测试和研发提供评估依据。豁免不等于默认放行，有效期到期后需重新评估；涉及关键缺陷的豁免，还应在清单上标注为需重点观察项，纳入上线后观察指标。
上线后观察项要观察到什么程度才算关闭？
观察项在发布前就要写明观察时长、观察指标和关闭条件，例如核心接口错误率、关键业务转化指标、告警数量在观察期内处于约定范围。观察期结束，由值班或业务方确认指标无异常、遗留问题已处理或已转入后续迭代，发布负责人据此关闭清单并归档。观察期内出现异常时，按回滚触发条件判断是否执行回滚，处理结果补记到清单。
不同发布类型可以用同一份清单吗？
可以共用一份模板，按发布类型裁剪普通检查项，例如纯配置变更可简化数据脚本相关项，涉及数据库变更则必须保留备份与回滚验证项。裁剪时阻断项集合与放行判定规则保持稳定，避免因发布类型不同而放松放行标准。裁剪结果应在发布前评审中确认，并随发布单留存，便于后续复盘时对照。
