2 篇博文 含有标签「fallback」

你在九个月前编写的回退路径（fallback path）——那个用于捕获模型超时、切换到更便宜的供应商、并在两者都宕机时返回模板化消息的路径——实际上在过去的十二周里从未在生产环境中运行过。它仅在最初发布时被执行过一次，集成测试仍然能通过，操作指南（runbook）也仍在使用它。但这并不意味着它还能工作。第六周的一次重构改变了上游上下文对象的形状。第九周的一次依赖库升级悄悄移动了一个配置键。代码仍然可以编译。测试仍然能通过，因为它们是针对与代码相同的陈旧 Fixture 编写的。下次当你的主路径出现 504 错误时，你的“优雅降级”将会把一个 NullPointerException 甩在用户脸上，而复盘报告将会指出——这已经是今年第三次了——在上游契约变更后，回退路径从未被重新测试过。

这是 AI 系统韧性工程中一种隐性的失败模式。回退路径是你应用程序中专门为了被忽视而存在的部分。在一百天里，有九十九天生产流量都会绕过它。CI 从不执行它，因为没有任何测试与之关联。负责它的团队在两次事故之间会忘记它的存在。然后在第一百天，当主模型供应商出现区域性故障，你终于需要它时，这段代码却在付费客户面前发生了代码腐烂（bit-rots）。

我第一次看到备用路由引发的事故比它试图缓解的停机故障还要严重时，复盘文档的标题是这样写的：“主服务降级 11 分钟。备用服务导致我们的解析器降级了 6 天。” 没人写错代码。没人跳过 Schema 评审。18 个月前连接备用服务时的二级供应商集成测试还是通过的。其间发生的事情是，两个供应商之一悄悄收紧了其枚举强制转换（enum coercion）策略，而我们下游解析器所遵循的契约——我们认为“或多或少就是 JSON Schema”的契约——已经从共享标准漂移成了两个略微不兼容的方言。

这是我不断看到的失败模式，而且它总能让那些本该更明白的团队感到惊讶。“JSON 模式”听起来像是一个你开启的功能。其实不然。它是一个你需要维护的契约——针对你可能路由到的每一个供应商分别维护——而且随着供应商演进其结构化输出技术栈，这个契约每季度都会发生漂移。你签署合同时供应商文档中所暗示的“无缝替换”，在生产环境中其实是一个需要维护的转换层。如果没有这个层，你的备用路径就会变成一个纸面上的合规产物：存在于架构图中，但在你真正需要它的那天却是坏的。