三家都挂了，备份为什么没接上

一、三家一起挂的那天

2026 年 9 月 3 日早上九点半，美国东部的开发者发现一件事：Claude、ChatGPT、Grok 三家服务同时不可用，恢复用了 3 小时 40 分。

很多团队接了两家甚至三家，正是为了这一刻。但那天，换服务的按钮没有用。Cursor 同时集成了三家模型，来自 OpenAI 的约 5% 流量完全中断，部分功能停了 3 小时 40 分。

这不是某一家没做好。这是三家同时出问题。

二、多接一家，不等于多一个故障域

买三家，看起来是三条路。实际可能是一条路上的三个出口。

2025 年 11 月 18 日，Cloudflare 圣地亚哥数据中心一次维护失误，让 ChatGPT、Claude 和用来查故障的 DownDetector 一起瘫痪。三家服务看起来互相独立，底层共用同一段网络。

2026 年 8 月 16 日，Claude 的一次故障同时影响网页、控制台、API、Claude Code 和 Cowork。9 月 29 日，API 和网页又一起报错。网页能打开、API 能用，这两条路在关键时刻并不独立。

判断冗余，不看供应商名字，看故障域：是不是同一朵云、同一段网络、同一个身份服务、同一个地理区域。名字换三家，底座还是那一个，就只买到了一张合同。

把三家供应商的接口地址、云厂商、区域、身份服务列在一张表里。三行如果指向同一朵云、同一个区域，就先当一行看。

三、备用模型能调用，不等于能接住

换过去只是第一步。接下来要问：提示词能不能直接用、工具调用的格式一不一样、上下文长度够不够、输出结构会不会变。

一个客服助手在主模型上返回固定字段，转到另一家后返回了另一种结构，前端解析失败，用户看到空白。这比直接报错更难查，因为接口是通的。

备用模型上线前，要拿同一批真实请求跑一遍：同样的输入，输出字段、语气、长度、拒答边界是否可接受。把最近一百条真实请求存成一组样例，每次换模型都跑同一组。

跑不通的备用，只会在事故里多花时间。

四、切换要有触发条件，不能靠人发现

最慢的一次切换，往往是「等有人发现」。

把条件写进系统：连续 5 分钟错误率超过多少、首字延迟超过多少、超时比例超过多少，自动换；同时留一个手动开关，值班的人可以立刻按下。

条件要按业务分。客服能忍 3 秒，后台批处理能忍 30 秒，不能用一个阈值套所有场景。

值班的人要知道开关在哪。只有架构师知道的开关，凌晨两点等于没有。

五、换过去，还要能换回来

只写换过去，不写换回来，会出现另一种事故：主模型恢复后，流量还在备用模型上跑，账单和质量都没人管。

换回来要有冷却时间，避免主备来回抖。每次切换记一条：什么时候、因为什么、转到哪、谁确认的。

如果备用模型按次计费更贵，停在备用上的时间越长，账单越高。这个成本要提前算。

六、长任务断在半路，比整站挂更麻烦

一个自动任务跑到一半，模型接口断了，状态停在中间。重试一次，可能重复下单、重复发消息。

要做的不是简单重试，而是让每一步可续：把已完成的结果存下来，重试时从断点继续；对会改变数据的动作做去重，同一件事只做一次。

这部分跟站内「同一笔钱被扣了两次」讲的是同一类问题，只是触发原因换成了模型断线。

七、全都挂了，业务还剩什么

三家同时挂的那天，任何切换都没用。这时候要有降级方案，而不是让页面一直转圈。

客服场景可以转人工，先给用户一个明确的等待提示；内容生成可以排进队列，恢复后再跑；查询类功能可以返回上一次的结果，并标明更新时间。

降级不是把功能关掉就完了，要告诉用户现在是什么状态、大概什么时候恢复。

八、重试要有限度，别把备用也打挂

主模型报错，所有请求一起重试，备用模型会在几秒内收到几倍的流量。

重试要有上限、要有间隔、要加随机抖动；按租户或业务设并发上限，避免一个业务把整条通道占满。

队列要能看见长度。恢复时不要一次把所有积压放出去，分批放。

九、状态页只能参考，探针要自己发

供应商的状态页经常滞后，等你看到红色，业务已经报错几分钟了。

用自己的探针，从自己的网络位置，按固定频率发一个最小请求，记录首字时间、成功率、错误码。三家供应商各一条曲线，放在同一张图上。

这样在换之前，你先知道是哪一家、哪个区域、哪类请求出了问题。

十、合同里的可用性，和业务恢复不是一回事

供应商承诺 99.9%，赔的是服务费，不是你的营业损失。一次两小时的中断，按比例赔下来的钱，通常补不上客服积压和订单流失。

合同里可以争的，是多供应商的接入权、故障通知时限、数据导出，以及退出时的过渡期。这些条款比赔偿比例更有用。

十一、演练一次，比写十页方案有用

选一个低峰时段，手动把主模型转到备用，观察：多久发现、多久切换、多少请求失败、用户看到什么、换回来是否正常。

每季度一次，把时间记下来。第一次可能要二十分钟，第三次可能只要两分钟，这个差距就是冗余真正的价值。

不演练的切换方案，和没有方案差别不大。

十二、换过去之后，质量也要看

接口恢复不等于业务恢复。换到备用模型后，要盯三件事：回答成功率、拒答比例、用户投诉。

备用模型可能更保守，原来能答的现在不答；也可能更长，客服话术超出限制。切换期间把这些指标和主模型基线放在一起看，差太多就换回或调整提示词。

只看请求返回 200 的比例，看不出答得好不好。

十三、小团队先做三件事

第一件，接第二家模型，但把它当成真的备用：同一批请求能跑通，输出结构能对上。

第二件，写一个自动切换条件和一个手动开关，条件按业务定，开关放在值班的人够得着的地方。

第三件，准备一个降级页或降级话术，三家都挂时告诉用户发生了什么、什么时候再来。

这三件事不需要多买一套架构，先把最薄的三处补上。

十四、跟站内几篇的分工

「服务挂过一次，要不要花钱做双活」讲的是自家机房的冗余；「五个服务串起来，超时该谁定」讲的是一次请求经过多个服务时的时间预算；「消息队列挂了，订单还能不能继续下」讲的是排队与补偿；「接了第二家模型，中间那一层谁来管」讲的是模型入口的收口；「模型停用日期不统一，采购合同该怎么写才不被动」讲的是版本下线。

这一篇只讲一件事：模型接口挂了，业务怎么继续。

十五、最后：冗余不是买来的，是练出来的

多签一家供应商，只是多了一张合同。真正让业务不断的是三样东西：不同的故障域、能自动触发的切换、以及切换不了时的降级。

这三样都要在平时练。等到三家一起挂的那天再找备份，通常已经来不及了。