那个在你的代码冻结期间送达的模型弃用通知

邮件是在周二发出的。你那两个最重要的功能所依赖的 Checkpoint 进入了 90 天的下线期。你的工程团队正处于为了另一个发布而进行的协同代码冻结（Freeze）的第二周。等到冻结解除时，你将只有不到三十天的时间来针对新模型重新验证两个生产环境的功能——这里的“重新验证”意味着重建评估集、运行影子流量、获得产品负责人签字，并在一个没人关注的 Feature Flag 之后发布，因为发布团队还在忙着处理代码冻结原本针对的那个项目。

这种冲突并不少见。主要供应商发布废弃周期的频率是以月为单位的，每个在托管模型上运行的团队现在都经历过至少一个周期。团队尚未吸收的教训是，供应商的废弃并不是像库升级那样的工程事件——它是一个运行在你无法控制的时钟上的排程事件，任何没有预留预算的路线图都会将这笔成本视为一场意外。

接收端的本能反应是争论时间节点。“我们正在冻结期。”“我们三周后有个发布。”“我们能申请延期吗？”有时确实可以——供应商的客户团队会悄悄地为一级客户延长权限，而对于主动提出要求的账号，公布的日期很少是真正的截止日期。但谈判本身并不是教训。教训在于，你的路线图假设供应商的生命周期是像天气一样的外部因素，而实际上它们是预定的、可预测的，并且是可以提前规划的。

冻结政策是为不同的威胁模型而写的

大多数工程冻结旨在高风险窗口期（如黑色星期五、监管截止日期、营销驱动的发布）稳定代码。其机制是“停止更改，以免破坏任何东西”。该政策假设威胁来自内部：疏忽的合并、配置漂移、或是在一年中最繁忙的周末导致结账系统崩溃的未经测试的优化。

这种思维模型能很好地处理内部发起的风险。但它处理外部发起的风险的效果很差，因为冻结只能抑制团队自身控制的更改。模型下线是你系统中由供应商发起的更改，并会在他们设定的日期到达那一刻传播。冻结无法抑制它。冻结只能抑制你的应对措施。

更糟糕的是，冻结在技术工作之上增加了协调成本。本应进行模型迁移的团队，同时也同意了不触动生产环境。获得例外情况需要与冻结所保护的发布项目的负责人进行沟通，而这些沟通恰恰发生在那个团队最无法分心的时候。阻力最小的路径是“我们等冻结结束后再处理”。阻力最小的路径也是你如何陷入 30 天期限悬崖的原因。

如果一个冻结政策没有将外部废弃列为许可的例外，那么这个政策就是在假装供应商的时间表不存在。它们确实存在。它们会提前发布。政策是可以更新的。

废弃周期是路线图的输入，而非意外

最快的修复方式也是成本最低的：将供应商公布的废弃模式视为每个季度规划中的输入。数据是公开的。每个主要的托管模型供应商都有一个废弃页面，列出了历史下线窗口、当前的通知期以及正在进行的废弃集合。每季度阅读这些页面可以让你相当准确地了解未来一年的迁移时间表。

阅读后可以产生三个类别：

• 你所依赖的、已经废弃的模型——这些模型有明确的日期。将它们视为预定在那个日期发布的项目，并进行相应的规划。
• 你所依赖的、仍被标记为旧版但尚未废弃的模型——这些模型距离明确的日期还有 60 到 180 天。在下一个规划周期中为它们预留容量。
• 你所依赖的、仍处于活跃状态的模型——这些是下一次会让你感到意外的模型。根据供应商的发布节奏选择最可能的候选对象，并假设每个主要模型每年会有一次废弃事件作为规划基准。

做这种练习的团队很少。但每个在生产环境流量中使用托管模型的团队都应该这样做。这个练习只需要一个下午的时间，就能产生一整年的日历事项，否则这些事项就会在代码冻结期间以邮件的形式突然降临。

加载中…