设想一个早晨，客户等着 AI 生成当天的销售简报，产品页面却一直显示“处理中”。原因不在自己的服务器，而是调用的模型服务暂时不可用。
“那就换另一家。”这个答案听着简单，实际可能没这么快。
备用服务有没有可用额度，能不能读同样的文件，结果格式是否兼容，都需要成立。两家服务甚至可能依赖同一处基础设施。接了第二个接口，只能说明多了一种选择，还不能证明故障时整条业务跑得通。
这就涉及两个概念：供应商锁定与降级。前者是产品对一家服务依赖太深，更换时成本很高；后者则是在部分能力出问题时，仍保住可以可靠交付的部分。
AWS 的可靠性文档强调，依赖失效时应尽量保留核心功能，而且异常路径要经过测试，通常应比主流程更简单。资料：AWS
继续用简报的假设例子。解释性文字暂时生成不了，但经过规则计算的销售数字还能提供。客户至少能先看到基础统计，文字部分清楚标注等待处理。这就是一种有意义的降级：缺了什么是明白的，保留下来的部分仍可信。
如果悄悄拿昨天的摘要冒充今天的结果，页面看起来完整，实际却把故障藏进了内容。这样的“不中断”，反而可能让客户做错判断。
等待或暂停也可能是合理结果。有些任务没有可靠替代办法，宁可让状态说清楚，也不能为保持按钮可用而输出低于底线的结果。人工接手同样有容量，一个人不可能在故障时无上限补齐所有请求。
供应商依赖还有较慢的一面：接口调整、服务停止、使用条件变化，都可能让产品需要迁移。如果特殊写法散在每个角落，更换就会牵动更多地方。把差异集中管理，可以减少代码修改，却不会自动消除模型行为与数据安排的差异。
我觉得，理解这种取舍，可以想想商店停电。有的店还能用手工方式记一笔订单，有的冷藏商品必须暂停出售。维持营业，也有能维持到哪里的边界。
一份可信的备用方案，最终要让客户知道：现在还能得到什么，哪些事情尚未完成，以及什么时候应该等。备用按钮本身，并不构成这份答案。