发布内容核对清单要能直接用于发布评审和发布执行，围绕四条主线设计：版本内容、配置、依赖、回滚。每条检查项都写明通过标准、证据、负责人和检查时点，并标出阻断项；阻断项全部通过并留存证据，才允许发布。下面按使用角色与时点、四类检查表、字段填写规范、阻断与放行规则依次展开。
要点总览（TL;DR）
- 发布内容核对清单按四条主线组织：版本内容、配置、依赖、回滚；每条检查项写明通过标准、证据、负责人和检查时点。
- 版本内容核对重点是对照需求与缺陷清单确认范围、变更项关联编号、待发布包与评审通过的制品一致。
- 配置核对覆盖环境差异、功能开关与灰度、关键参数、密钥证书和配置回退值；依赖核对覆盖上下游接口、数据库脚本、第三方组件和依赖方发布窗口。
- 回滚核对要写明可量化的触发条件与决策人，确认回滚包与生产版本匹配、数据备份与回退脚本就绪，并安排回滚后验证。
- 阻断项全部通过并留存证据才允许发布；豁免需说明补偿措施与风险接受人，涉及数据安全与回滚能力的阻断项不建议豁免。
谁在什么时点使用这份核对清单
这份清单服务于发布门禁，执行主体需要覆盖发布全流程的相关角色。发布负责人对整份清单的完整性和放行结论负责；开发负责版本内容、变更项与配置项的确认；测试负责验证结果与回归证据；运维负责环境、部署执行与回滚包准备；DBA负责数据库变更脚本、备份与数据回退。角色可以兼任，但每项检查必须落到具体角色或人名，避免出现无人认领的空白项。
清单在四个时点使用，每个时点的检查重点不同：
| 时点 | 主要动作 | 参与角色 | 产出 |
|---|---|---|---|
| 发布前准备 | 填写版本内容、配置、依赖、回滚各项，收集证据 | 开发、测试、运维、DBA | 已填写的核对表与证据附件 |
| 发布评审 | 逐项判断通过与否，确认阻断项状态 | 发布负责人主持，各角色确认 | 评审结论与待办项 |
| 发布执行 | 按清单核对执行顺序、配置生效、依赖就绪 | 运维、DBA、开发值守 | 执行记录与异常记录 |
| 发布后验证 | 验证功能、监控指标与回滚预案可用性 | 测试、运维、开发 | 验证结论与观察期记录 |
清单在门禁中的作用是放行依据：评审时阻断项未全部通过，发布不进入执行；执行中出现新的阻断问题，按回滚触发条件处理。清单不是评审会议的参考材料，而是签字确认的放行凭证。
版本内容核对：范围、变更与制品一致性
版本内容核对解决“发的是不是计划要发的东西”。检查项要能对照需求或缺陷清单逐条判断，避免范围蔓延或漏发。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 | 阻断 |
|---|---|---|---|---|---|
| 版本号与发布范围 | 版本号与发布计划一致，范围清单与需求/缺陷清单逐条对应，无计划外条目 | 发布计划、需求清单比对记录 | 发布负责人 | 发布前准备 | 是 |
| 变更项关联 | 每个变更项都关联到需求或缺陷编号，无孤立变更 | 变更清单与编号对照表 | 开发 | 发布前准备 | 是 |
| 制品一致性 | 待发布包的版本号、构建号与构建记录一致，包内制品与评审通过的制品相同 | 构建记录、制品校验值 | 开发、运维 | 发布评审 | 是 |
| 文档同步 | 发布说明、用户文档、接口文档已按本版本变更更新 | 文档评审记录或版本链接 | 开发、产品 | 发布评审 | 否 |
| 排除项明确 | 未纳入本版本的需求或缺陷已列明并通知相关方 | 排除清单与通知记录 | 发布负责人 | 发布评审 | 否 |
制品一致性是容易被忽略的阻断项：评审通过的包与最终上线的包必须是同一个构建产物，重新打包需要重新核对。文档同步列为一般项，但涉及对外接口变更时应升级为阻断项。
配置核对：环境、开关与参数
配置核对的目标是消除环境差异带来的发布失败。检查重点是各环境配置的差异是否被评审、开关与参数是否有明确取值、敏感信息是否脱离代码库。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 | 阻断 |
|---|---|---|---|---|---|
| 环境配置差异 | 测试、预发、生产配置差异逐项列出并评审通过，差异项有说明 | 配置差异对比记录、评审记录 | 运维、开发 | 发布评审 | 是 |
| 功能开关与灰度 | 开关名称、默认值、灰度比例、生效范围已确认，与发布策略一致 | 开关配置清单 | 开发 | 发布评审 | 是 |
| 关键参数 | 数据库连接、超时、限流、线程池等关键参数取值已核对，与容量评估匹配 | 参数核对表 | 开发、运维 | 发布评审 | 是 |
| 密钥与证书 | 密钥、证书已更新且在有效期内，未进入代码库，权限配置正确 | 密钥管理记录、有效期截图 | 运维 | 发布执行前 | 是 |
| 配置回退值 | 每项变更配置都记录原值，可一键或按步骤恢复 | 配置变更记录含原值 | 运维 | 发布前准备 | 是 |
配置项的共同要求是“变更前有原值、变更后有验证”。灰度比例和开关默认值需要与发布方案对齐，例如灰度从1%起步还是直接全量，应在评审时确定并写入清单，执行时照单核对。
依赖核对：上下游、数据脚本与第三方组件
依赖核对覆盖三类对象：上下游服务、数据库变更脚本、第三方组件与中间件。依赖问题的特点是发布当时不暴露、运行一段时间才出现，因此检查要前移到评审阶段。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 | 阻断 |
|---|---|---|---|---|---|
| 上下游接口兼容 | 上下游服务版本与接口契约已确认，新增或变更字段兼容旧版本调用方 | 接口契约文档、联调记录 | 开发 | 发布评审 | 是 |
| 数据库变更脚本 | 脚本已评审，执行顺序明确，可重复执行或具备幂等保护 | 脚本评审记录、执行顺序说明 | DBA、开发 | 发布评审 | 是 |
| 第三方组件版本 | 组件与中间件版本在官方支持范围内，无已知高危漏洞 | 版本清单、漏洞扫描结果 | 开发、运维 | 发布评审 | 是 |
| 依赖方发布窗口 | 依赖方的发布窗口与本版本对齐，先后顺序已约定 | 发布日历、协同记录 | 发布负责人 | 发布评审 | 是 |
| 降级方案 | 依赖不可用时的降级或熔断策略已配置并验证 | 降级配置、演练记录 | 开发、运维 | 发布执行前 | 否 |
数据库脚本要特别关注执行顺序和回退能力：新增字段、数据订正、索引变更混在一个脚本里时，回退难度会显著上升，评审时应要求拆分并标注每步的回退方式。降级方案列为一般项，但核心链路依赖不可降级时，应升级为阻断项。
回滚项核对：触发条件、回滚包与数据回退
回滚核对的判断标准是：发布失败时，团队能在约定时间内按预案恢复到已知可用状态。回滚项必须在发布前完成核对，发布中才准备回滚往往来不及。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 | 阻断 |
|---|---|---|---|---|---|
| 回滚触发条件 | 明确错误率、延迟、核心功能失败等量化阈值，指定决策人 | 回滚预案文档 | 发布负责人 | 发布评审 | 是 |
| 回滚包匹配 | 回滚包与当前生产版本一致，已校验可用 | 回滚包版本记录、校验值 | 运维 | 发布执行前 | 是 |
| 数据回退 | 数据库回退脚本与备份就绪，备份时间点明确，恢复步骤可执行 | 备份记录、回退脚本评审记录 | DBA | 发布执行前 | 是 |
| 回滚后验证 | 回滚后的功能验证步骤、监控观察项、通知对象已列明 | 验证清单、通知名单 | 测试、运维 | 发布评审 | 是 |
| 回滚演练 | 关键版本完成回滚演练或预演，记录耗时与问题 | 演练记录 | 运维、DBA | 发布前准备 | 否 |
回滚触发条件要写成可判定的阈值，例如“核心接口错误率连续5分钟超过1%”或“支付成功率低于基线10%”，并写明谁有权决定回滚。数据回退是最容易缺失的一环：只回滚应用不回退数据，可能造成新旧版本数据不一致，因此备份时间点和回退脚本必须同时就绪。
通过标准、证据与负责人怎么填
清单能否逐项判断通过，取决于字段写法。填写规范如下：
- 通过标准：写成可观察、可判定的事实，避免“已确认”“没问题”这类无法验证的表述。推荐结构是“对象＋状态＋判定方式”，例如“待发布包构建号与评审记录一致，校验值相同”。
- 证据：写明证据类型和存放位置，常用类型包括配置截图、构建日志、评审记录、执行记录、演练记录、监控截图。证据要能在评审时当场调取。
- 负责人：填写到具体角色或人名，同一项涉及多个角色时指定第一责任人，其余为会签人。
- 检查时点：从发布前准备、发布评审、发布执行、发布后验证四个时点中选择，一项检查只对应一个主时点。
- 签字确认：评审时由负责人逐项确认，发布负责人汇总签字；电子流程中以状态流转和审批记录代替手写签字。
一份可用的清单还应包含“不适用”选项及理由栏。某些检查项对特定版本确实不涉及，例如无数据库变更时数据回退项不适用，但需要填写理由并由发布负责人确认，不能直接留空。
阻断项与发布完成条件
阻断项的判定原则是：该项不通过会导致发布失败、数据错误、无法回滚或核心功能不可用。按此原则，版本范围与制品一致性、环境配置差异、密钥证书、数据库脚本、上下游兼容、回滚包与数据回退、回滚触发条件应列为阻断项。文档同步、排除项通知、降级方案、回滚演练通常列为一般项，涉及对外接口或核心链路时升级为阻断项。
阻断项未通过时的处理流程：由负责人记录未通过原因和影响，发布负责人决定延期发布或走豁免流程。豁免需要说明补偿措施、风险接受人和观察期安排，并由发布负责人及以上层级审批；涉及数据安全与回滚能力的阻断项不建议豁免。
发布完成条件包括三条：全部阻断项通过并留存证据；发布后验证按清单完成，核心功能与监控指标正常；观察期内出现的问题已记录并指定跟踪人。观察期长度按版本影响面确定，观察期内的遗留项进入跟踪列表，明确责任人和关闭时间，不能随发布结束而消失。
用ONES承载核对过程与证据留存
清单落地后，常见问题是检查项散落在文档和聊天记录里，评审时找不到证据，放行结论无法追溯。可以把核对过程放到工作项管理中承载：将四类检查项建成版本工作项下的子工作项或检查项模板，每个检查项对应一条记录，字段包含通过标准、证据、负责人、检查时点和是否阻断。
执行时，各角色在对应检查项上更新状态并附上证据，证据与版本工作项关联，评审时按版本汇总查看。发布门禁通过状态流转实现：阻断项全部进入通过状态后，版本工作项才能流转到待发布或已发布状态，审批记录随工作项留存。发布后如发生回滚，回滚记录同样关联到该版本工作项，形成从检查、放行到回滚的完整追溯链。这样清单不只是评审当天的表格，而是版本历史的一部分，后续复盘和审计可以直接调取。
常见问题
版本内容核对中，制品一致性为什么建议列为阻断项？
评审通过的包与最终上线的包必须是同一个构建产物。如果发布前重新打包，包内代码可能与评审版本不同，测试结论就不再适用于上线内容。因此制品一致性通常列为阻断项：核对版本号、构建号与构建记录一致，包内制品校验值与评审记录相同；一旦重新打包，需要重新走核对与评审。
没有数据库变更的版本，回滚项还需要核对哪些内容？
数据回退项可以标注为不适用，但需要填写理由并由发布负责人确认，不能直接留空。其余回滚项仍需核对：回滚触发条件与决策人、回滚包与当前生产版本是否匹配、回滚后的验证步骤与通知对象。如果版本涉及配置变更，配置回退值也应一并确认，保证应用回滚后配置同步恢复。
灰度发布时，配置核对和回滚核对的侧重点有什么不同？
配置核对侧重开关名称、默认值、灰度比例和生效范围是否与发布方案一致，执行时照单核对。回滚核对侧重灰度期间的判定标准：错误率、延迟或核心功能失败的量化阈值，谁有权决定扩大灰度、暂停或整体回滚，以及回滚后如何验证。灰度比例调整本身也应记录原值，便于恢复。
阻断项未通过时，什么情况下可以走豁免流程？
豁免适用于影响可控、有补偿措施且风险可被接受的情况，例如一般项升级为阻断项但已有替代验证手段。流程上由负责人记录未通过原因和影响，说明补偿措施、风险接受人和观察期安排，由发布负责人及以上层级审批。涉及数据安全与回滚能力的阻断项不建议豁免，应延期发布或修复后重新评审。
清单里的证据怎样留存，才能在复盘和审计时调取？
证据要写明类型和存放位置，评审时能当场调取。常见做法是把检查项建成版本工作项下的子工作项，各角色更新状态时附上截图、日志、评审记录或演练记录，证据与版本工作项关联。发布门禁通过状态流转实现，审批记录随工作项留存；发生回滚时回滚记录同样关联到该版本，形成从检查、放行到回滚的追溯链。
