三家不同厂商同一早晨失灵：相关性风险不在合同里｜洹拓科技
一、同时坏掉这件事本身就是要记录的信号
一则公开报道讲了这样一件事：同一天早晨，三家彼此竞争的模型服务同时出现异常，对话界面停在加载、请求反复报错、页面空白；故障监测平台上其中一家在短时间内收到的用户报告超过一万两千条。报道没有给出根因、持续时长与影响范围，洹拓也不去猜。这篇要谈的只是那个结构性的部分：三家互相竞争、彼此看不上的服务，在同一个时间段里一起失灵，而把它们放在一起用的那些团队，恰好在同一时刻一起失去能力。
据公开报道的那个大数字不是本篇任何判断的依据，本篇的依据是一个更朴素的事实：多供应商冗余这个做法的隐含假设是相互独立，而这个假设从来没有人验证过。合同上写的是三家不同公司，故障域上可能是一条共同的路径。做云服务和模型交付的团队，要把这件事从心理安慰变成可检查的清单。
二、四类可查的故障域重叠面
故障域重叠，指的是两家或多家供应商在出问题时会因为同一个原因一起倒下。它有四类常见面，每一类都有不依赖供应商坦诚的查法。
| 重叠面 | 为什么会让多家一起倒 | 可操作的查询方法 |
|---|---|---|
| 托管区域与可用区 | 多家把算力放在同一片区域，区域级事件一起受影响 | 让客户方或供应商提供接入点解析到的 IP 段归属地登记，与公开的区域网段做对照，落在同段的记为同域 |
| 同一家上游基础设施 | 模型厂商本身就是同一家云的大客户 | 看各家对外披露的基础设施合作与自建比例，自述缺失时按容量级归类，容量级相近且区域相同的按同域保守处理 |
| 同一 CDN 与 DNS 服务商 | 域名解析与静态分发是共同入口，入口抖三家一起打不开 | 用拨测记录各家域名的解析链与调度节点归属，统计解析服务商集中度 |
| 同一开源组件或推理框架版本 | 同一次共性缺陷或同一类负载形状触发相同故障 | 要求供应商提供组件与版本清单入档，无清单时以行为特征近似归类，并标注证据强度 |
查询方法的核心不是拿到确切答案，而是拿到一个可登记的答案：这两家在我们能看到的信息范围内是不是同域，证据是什么，置信度多高。这条记录要进依赖清单，而不是留在工程师的脑子里。
三、配了三家备份为什么经常不生效
原因之一，是重试逻辑把三方一起耗尽。三家同时不可用时，客户端按顺序轮询三家并对每家重试若干次，看似有备份，实际是在同一时刻把三家的配额与超时都烧完，用户等到的是最长的等待和最空的返回。
原因之二，是请求超时设置远大于恢复时间。上游可能十几分钟就恢复，但队列里堆积的长超时请求在恢复瞬间全部涌回，把刚起的服务再次压垮，同时把网关与线程池占满，看起来像故障延长了。
原因之三，是熔断没有跨供应商的全局档。单接口有熔断、单供应商有熔断，就是没有三家同时不健康时的整体保守模式，于是系统在最坏的时刻继续按平时的负载形状接收请求，故障被自己放大。
这三条都是设计问题，与选哪三家无关。把第四家加进来不解决任何一条，反而让依赖清单更长、演练更难安排。更麻烦的是，它们在平稳期几乎看不见：三家轮流小幅抖动的时候，轮询与重试看起来正是系统在自愈，容量评估因此得出过于乐观的结论。等到三家一起倒下才看出来，所谓自愈很多时候只是把故障期拉长成了等待期。
四、要落地的六件事
第一，依赖清单要落到厂商背后的厂商。每家供应商至少登记上游基础设施、解析与分发路径、可获得的组件版本信息三项，缺项标注为未证实而不是空白。
第二，统计口径按故障域分组，不按品牌分组。报表上写的是域的数量与每个域承载的流量占比，三家落在两个域里，就写两个域。
第三，全局降级顺序要写成一句话并能执行：先切功能，再切模型，最后切人工。切功能是关掉非核心能力，切模型是换到本地小模型或缓存答复，切人工是转入工单排队。顺序反过来就会在最忙的时候去研究该说什么。
第四，请求级预算要跨供应商共享。给每个用户请求设总重试次数上限与总时延上限，三家共用这一份预算，而不是各给一份，这样三家同时坏时最坏路径是确定的。
第五，熔断分三层：单接口、单供应商、跨供应商。第三层触发条件是两家以上同时越界，动作是进入保守模式，只保留核心链路，其余一律排队或拒绝。
第六，故障期间的输出留证与告知口径要事先定。留证包括请求标识、所选供应商、返回状态、耗时与降级动作；告知口径要统一，避免一线与状态页各说一套。
五、降级要按业务分档，有一档永远不许自动答
不是所有功能都能降级成缓存回答。我们建议按后果分档：信息检索与解释类可以走缓存或延后处理，明确标注答案的时间与来源；生成草稿类可以换到成本更低的本地模型，接受质量下降；交易与流程推进类要么正常执行，要么停在可恢复的检查点，不许带不确定结论继续往下走。
有一档必须写死：法务、财务、对外承诺这三类内容一律降级为待人工处理。它们不是模型质量不够好的问题，而是错误结论会直接进入合同、报表或对客户的表述。这一档的规则要落到代码与流程里，不接受临时判断，也不接受在故障期间为了稳住指标而放开。
分档的价值在演练中能体现：故障时没有人来得及重新讨论该切什么，只有事先写好的表能被执行。
六、复盘、SLA 读法与那个唯一有用的指标
事件复盘要补三个字段，缺一不可。三家各自的恢复时刻与恢复顺序，用来判断是否存在共同上游与共用路径；跨供应商同时不可用的重叠时长，也就是三家全都不健康的那段分钟数，它是损失最集中的区间；我们的降级实际生效点与预期差距，比如文档写的是三十秒切换、实测是四分钟，差在哪一步。这三个字段比故障描述更有用，因为它们能对比、能沉淀成趋势。
SLA 的正确读法是把它当赔偿条款而不是能力声明。多数模型服务的可用性承诺并不覆盖供应商自己上游的故障，赔付口径与可用性口径也对不上真实业务损失。结论不是去谈判提高赔付，而是承认合同帮不上忙，在合同之外自建容量、预算与降级。
运维侧留一条一等指标：多供应商同时不可用的分钟数。按周记录，标注涉及哪几家、属于哪个重叠面。单个供应商的可用性各家都在报，只有这个重叠分钟数能量化相关性风险，也是唯一能证明某次改造让系统更抗造的数字。