发布内容核对表按“版本内容—配置与依赖—部署与验证—回滚与应急”四段设计检查项，每项写明通过标准、证据、负责人和检查时点，并把影响发布放行的项标为阻断项。核对表在发布评审前定稿、发布执行中逐项勾验、发布后归档留证。下文给出可直接套用的表结构、各段检查项与通过标准写法，并说明如何在ONES中承载检查项与证据。
要点总览（TL;DR）
- 核对表按“版本内容—配置与依赖—部署与验证—回滚与应急”四段分组，每行固定填写检查项、通过标准、证据、负责人、检查时点和是否阻断六个字段。
- 通过标准要写成可判断真假的完成条件，写明对象、动作和确认方，把“已确认”“正常”这类表述替换为带证据链接的具体条件。
- 阻断项依据失败后果判断：未通过会导致无法验证发布结果或无法安全回滚的项标为阻断，阻断项全部通过才可放行。
- 核对表在发布评审前定稿、发布执行中逐项勾验、发布后随发布单归档，出现回滚或例外放行时触发复盘并回写模板。
- 把检查项建成可指派、可挂证据、可联动状态的工作项，可让核对表在发布全过程中保持有效，ONES可承载这一方式。
谁在什么时点使用这张核对表
核对表的使用对象是参与本次发布的角色，使用阶段覆盖发布前、发布中、发布后三个时点。它约束的是某一次具体发布的内容与执行，产品版本规划、制品仓库中的版本号与存储管理由各自流程负责，核对表只引用其结果，不替代这些流程。
适用版本范围包括常规迭代版本、热修复版本和配置变更类发布。热修复版本可以精简检查项数量，但阻断项不能省略；配置变更类发布重点检查配置项与回滚方案两段。
| 角色 | 使用时点 | 职责 |
|---|---|---|
| 发布负责人 | 评审前定稿、执行中主持勾验、发布后归档 | 组织核对表填写，判断阻断项是否全部通过，决定是否放行 |
| 开发 | 评审前 | 提供变更范围、需求与缺陷清单、数据库脚本、回滚脚本 |
| 测试 | 评审前、执行中 | 提供冒烟与回归结果，执行发布后验证 |
| 运维 | 评审前、执行中 | 确认部署顺序、监控告警就绪、值班安排 |
| 产品/业务验收方 | 评审前、发布后 | 确认发布说明与对外公告口径，执行业务验收 |
检查项怎么分组：四段结构与字段设计
核对表按四段分组：版本内容、配置与依赖、部署与验证、回滚与应急。每行固定填写六个字段，缺任一字段的检查项视为未定义完整，不能进入评审。
| 字段 | 填写要求 |
|---|---|
| 检查项 | 一个可执行的动作或一个可核对的产物，一行只写一件事 |
| 通过标准 | 可判断真假的完成条件，写明对象、动作和确认方 |
| 证据 | 能证明通过的产物：报告链接、评审记录、脚本路径、截图或配置项编号 |
| 负责人 | 对该项结果负责的单一角色，不写“相关同学” |
| 检查时点 | 评审前、发布执行中或发布后，精确到环节而非日期 |
| 是否阻断 | 是/否，标“是”的项未通过则不得放行 |
通过标准的写法决定核对表是否可用。“已确认”“正常”“无问题”无法判断，应改写为带对象和确认方的条件。例如把“发布说明已确认”改为“发布说明已由产品负责人确认，文档中列明变更范围与影响用户，附确认记录链接”；把“监控正常”改为“核心接口错误率与耗时告警已配置并完成一次测试触发，附告警截图”。
阻断项与普通项的区分依据是失败后果：该项未通过会导致发布后无法验证、无法回滚或影响用户可用，就标为阻断；只影响记录完整性或后续优化的，标为普通项。阻断项数量控制在十项左右，过多会让放行判断失去重点。
版本内容与配置依赖的检查项及通过标准
这一段在发布评审前完成，检查对象是本次发布的内容本身、运行所需的配置以及对外部组件的依赖。
| 类别 | 检查项 | 通过标准 | 证据 | 阻断 |
|---|---|---|---|---|
| 版本内容 | 需求与缺陷清单完整 | 本次发布包含的需求与缺陷均有编号、状态为已完成，清单与制品内容一致 | 需求/缺陷清单链接 | 是 |
| 版本内容 | 变更范围已界定 | 列出受影响的模块、接口与用户范围，标注不在本次范围内的内容 | 变更范围说明 | 是 |
| 版本内容 | 发布说明已定稿 | 发布说明由产品负责人确认，含变更内容、影响范围与已知问题 | 发布说明文档及确认记录 | 是 |
| 版本内容 | 对外公告口径一致 | 公告内容与发布说明一致，涉及用户可见变化的部分已由业务方确认 | 公告稿及确认记录 | 否 |
| 配置项 | 环境配置核对 | 各环境配置项逐项比对，差异项已说明原因并确认 | 配置比对记录 | 是 |
| 配置项 | 开关与灰度参数确认 | 开关默认值、灰度比例与放量节奏已写明，并有对应操作人 | 参数清单 | 是 |
| 配置项 | 密钥与证书有效 | 本次涉及的密钥与证书在有效期内，更新方式与生效时点已确认 | 有效期核对记录 | 是 |
| 配置项 | 数据库变更脚本已评审 | 脚本经开发与运维双方评审，含执行顺序、影响表与回退语句 | 评审记录与脚本 | 是 |
| 依赖项 | 上下游服务版本确认 | 依赖的上下游服务版本已列出，接口兼容性已确认 | 依赖清单与确认记录 | 是 |
| 依赖项 | 第三方接口可用 | 本次调用的第三方接口已完成连通性验证，配额与限流满足发布后流量 | 验证记录 | 否 |
| 依赖项 | 基础组件与中间件版本匹配 | 组件与中间件版本在支持范围内，与本次制品要求一致 | 版本清单 | 否 |
部署验证与回滚应急的检查项及通过标准
这一段覆盖发布执行与异常处置。部署验证项在发布执行中逐项勾验，回滚与应急项在评审前确认就绪、执行中保持可用。
| 类别 | 检查项 | 通过标准 | 证据 | 阻断 |
|---|---|---|---|---|
| 部署验证 | 发布包与制品一致 | 待部署包的校验值与评审通过的制品一致，来源可追溯 | 校验值比对记录 | 是 |
| 部署验证 | 部署顺序明确 | 写明各服务部署先后、并行或串行关系及等待条件 | 部署步骤说明 | 是 |
| 部署验证 | 冒烟用例通过 | 冒烟用例全部执行，结果记录完整，失败项已处理或明确不影响放行 | 冒烟执行报告 | 是 |
| 部署验证 | 关键回归通过 | 与变更范围对应的回归用例通过，覆盖本次改动的主要路径 | 回归报告 | 是 |
| 部署验证 | 监控与告警就绪 | 核心接口的错误率、耗时与业务指标告警已配置，并完成一次测试触发 | 告警配置与触发截图 | 是 |
| 回滚 | 回滚包可用 | 上一稳定版本的回滚包已准备，校验值与记录一致 | 回滚包校验记录 | 是 |
| 回滚 | 回滚脚本可执行 | 回滚脚本在预发环境演练过一次，执行步骤与耗时已记录 | 演练记录 | 是 |
| 回滚 | 数据回退方案明确 | 涉及数据变更的，写明回退语句、执行人与数据一致性校验方式 | 回退方案文档 | 是 |
| 回滚 | 回滚触发条件与决策人确定 | 写明触发回滚的指标阈值与决策人，决策人知晓并在岗 | 回滚决策说明 | 是 |
| 应急 | 值班与联系人明确 | 发布窗口内各角色值班人与联系方式已列出，交接方式已确认 | 值班表 | 是 |
| 应急 | 故障升级路径清晰 | 写明从发现到升级的层级、时限与通知渠道 | 升级路径说明 | 否 |
| 应急 | 发布窗口与冻结期确认 | 发布窗口避开业务高峰与冻结期，冲突情况已获批准 | 发布日历记录 | 否 |
阻断项清单与发布放行条件
放行规则只有一条：阻断项全部通过才可发布。非阻断项允许遗留，但必须记录责任人与整改期限，并在发布记录中列明。
典型阻断项包括：制品与评审通过的版本不一致；关键回归未通过；回滚包或回滚脚本缺失、未演练；数据库变更脚本未评审；监控与告警未就绪；回滚触发条件与决策人未确定。这些项的共同点是失败后无法验证发布结果或无法安全退出。
例外放行需要由发布负责人之外的一名审批人书面同意，记录内容包括放行理由、未通过项、风险接受人和补偿措施。例外记录与核对表一并归档，作为下次评审的输入。
发布完成后触发归档与复盘的条件：出现回滚、出现阻断项例外放行、发布后两小时内出现与本次变更相关的告警。复盘结论回写到核对表模板，增删检查项或调整通过标准，使下一版本直接复用。
核对表落地：在协作工具中承载检查项与证据
核对表以文档形式存在时容易停留在评审前一次性填写，执行中的勾验和证据散落在聊天记录里。把每个检查项建成可指派、可挂证据、可联动状态的工作项，能让核对表在发布全过程中保持有效。
具体做法是：按四段建立检查项工作项，逐项填写通过标准、负责人与检查时点，负责人到期前完成并上传证据；测试报告、评审记录、回滚脚本等证据挂到对应工作项或关联文档，避免另存多处；阻断项状态与发布单关联，存在未通过的阻断项时发布单停留在待放行状态，不能进入发布环节；发布结束后，核对表与证据随发布单归档，形成可追溯记录。
ONES支持将检查项作为工作项指派给负责人并设置截止时点，证据以附件或关联文档形式挂在工作项上，工作项状态可汇总到发布单，便于发布负责人按阻断项判断是否放行。团队可据此把上述四段检查项直接建成模板，在每次发布时复制使用，发布后保留归档记录供复盘查阅。
常见问题
热修复或配置变更类发布，核对表可以精简到什么程度？
热修复版本可以压缩检查项数量，但阻断项不能省略，尤其是制品一致性、关键回归、回滚包与回滚脚本、监控告警就绪这几类。配置变更类发布的重点放在配置项与回滚方案两段：环境配置比对、开关与灰度参数、密钥证书有效期、数据库脚本评审，以及回滚触发条件与决策人。精简的做法是删减非阻断的记录类检查项，保留与本次变更直接相关的判断项。
通过标准写到什么颗粒度才算够用？
判断标准是换一个人拿着这一行也能得出通过或不通过的结论。写法上包含三个要素：检查对象（哪份文档、哪个接口、哪个脚本）、完成动作（已确认、已演练、已比对）、确认方或证据（谁确认、附什么记录）。例如“回滚脚本可执行”写成“回滚脚本在预发环境演练过一次，执行步骤与耗时已记录，附演练记录链接”。如果一行里出现两个以上动作，拆成两行。
非阻断项遗留到发布后，怎么保证不被遗忘？
非阻断项允许遗留，但要在核对表中记录责任人与整改期限，并在发布记录里单独列出遗留清单。发布负责人可以在发布后固定一个复查时点，逐项确认整改状态；到期未完成的，升级到下一次发布评审作为输入。遗留项如果后续被判断会影响发布结果，应重新评估是否升级为阻断项。
例外放行的审批记录需要包含哪些内容？
例外放行由发布负责人之外的一名审批人书面同意，记录至少包含：放行理由、未通过的具体检查项、风险接受人、补偿措施（如加强监控、缩短观察窗口、准备手工回退步骤）。例外记录与核对表一并归档，并作为下次评审的输入，用于判断该检查项是否需要调整通过标准或改为阻断项。
核对表用文档维护和用工作项维护，分别适合什么情况？
发布频率低、参与角色少的团队，用文档维护核对表成本更低，评审前集中填写即可。发布频繁、多角色并行、需要留证追溯的团队，把检查项建成工作项更合适：负责人可指派、截止时点可提醒、证据挂在对应工作项上、阻断项状态可汇总到发布单。ONES支持将检查项作为工作项指派并挂接附件或关联文档，工作项状态可汇总到发布单，便于按阻断项判断放行。
