审批的对象是一次确定的变更

审批不是确认“这个项目可以上线”，而是允许特定版本在特定环境、约束和时间范围内执行。前几课已有镜像门禁、签名验证和流量回退，本课将这些证据组织成发布记录。

不引用没有可核实口径的“70% / 90% 故障来自变更”。团队可以从自身事故记录统计变更关联性，并说明时间窗口、样本量和归因方式。

按风险选择流程

类型	示例	处理方式
标准变更	已验证的低风险静态页面发布	预授权条件满足时自动执行并留痕
常规变更	应用升级、schema 扩展	就绪检查后由指定责任人审批
紧急变更	恢复业务所需的热修复	明确应急授权与恢复目标，事后补充记录

审批强度、记录保留期与事后补办期限按团队制度及适用要求确定，不在课程中虚构统一行业年限。快速通道也应记录谁授权、执行了哪个版本、影响与结果。

一份具体的变更单

以下为 delivery-demo 的填写示例。digest、时间和责任人字段必须替换为真实记录，不把示例当作批准凭据。

字段	示例填写方式
目标	prod，将页面 v1 更新到 v2，并新增数据库 description 列
制品	复制 CI 的完整镜像 digest；附 CI run、验签和扫描报告
配置	配置仓库 PR 与合并 commit；配置项变化清单
数据	V2__add_description.sql 的发布包摘要；staging 迁移记录
兼容性	旧查询仍可执行；新增列允许空值；本次不删旧列
窗口与责任	实际执行窗口、执行人、审批人、业务验收人
放行条件	无待处理门禁失败；容量满足滚动更新；备份可恢复
观察	首页面向正确版本；数据库列存在；错误率与延迟在约定阈值内
回退	恢复上一镜像与入口；保留兼容的新列；不自动删除数据
结束	实际版本、观察结果、失败与处置、记录归档位置

将人工判断和机器检查分开

机器适合核验 digest、签名、检查状态、字段存在性和发布窗口。兼容性判断、不可逆数据操作及故障影响需要有证据的人审。AI 可以辅助发现遗漏，但不能替代凭据校验和执行授权。

发布就绪检查：

• 镜像、迁移文件和配置已固定，审批后没有替换。
• 旧版与新版对当前 schema 的兼容性已在 staging 验证。
• 应用恢复、数据前向修复与备份恢复分别有步骤及耗时记录。
• 放量阈值、观察窗口、最小流量和指标缺失处理明确。
• 新副本容量、依赖可达性、相关人员通知已确认。

任何制品或配置发生变化都重新评估，不复用旧审批。数据库逆向 SQL 不是通用要求：删除数据、外部副作用等可能无法可靠逆转，应明确恢复方法与业务可接受损失。

审批流程也需要验收

用一个缺少回退版本的实验申请验证它不能放行；用一份审核通过后更换 digest 的申请验证原批准失效；模拟监控无数据，确认流程暂停而非默认成功。

下一课讨论 AI 的辅助审核价值，最后由结课项目把机器检查串成实际发布步骤。