发布冻结期间，什么改动仍然值得做？

发布冻结并不意味着所有改动风险相同。修复可公开利用的漏洞，和调整首页模型路由权重，都叫改动，但延后的代价、验证手段和撤回能力差别很大。小团队更需要一张能帮助判断的申请，而不是一句“谁也别动”。

冻结的是变更入口

Google SRE 的发布章节讨论检查清单和保护开关，提供的是长期方法，不是针对今年双十一的统一指令。结合十月模型接口与搜索费用持续变化的现实，我倾向于把冻结规则写成：所有变更都必须经过可追溯入口，例外也需要证据。

下面三项是构造的桌面评审案例，未在生产系统执行。

“合理处理方向”不是自动批准。安全漏洞也可能有兼容性风险，冻结期间的补丁仍要检查失败后的出路。

一张够用的申请

我会要求申请人写下：当前问题影响谁；不做的后果；最小改动是什么；隔离验证的命令和原始结果；哪个指标决定停止；谁有权限停止；数据已写入后如何处理。负责人姓名要对应实际值班表，不能写“后端组”。

例如模型路由修改，即使应用能一键回切，已经发出的供应商请求、已产生的费用和已返回给用户的答复都不能回滚。因此验证不应只看进程启动成功，还要看小流量请求的事实正确率、错误分类和费用上限。本文没有这些真实数据，就不预写百分比提升。

先走一遍撤回，再讨论上线

桌面演练可以让评审人扮演请求者：拿到故障信号后，他能否仅凭申请找到旧版本、执行人和观察窗口？若撤回文档引用的是过期配置，申请还没达到可执行状态。人工复核结果和未决项应留在记录里，不能把“大家群里说可以”当测试通过。

冻结期允许的改动，应有比平时更清楚的理由、较小的影响面和可验证的退出条件。这里没有虚构当晚的事故或战果；采用前还需由负责人确认实际窗口、补丁公告和依赖状态。