第四方风险：当供应商的供应商掌控了你客户的故障

你与模型提供商签订了合同。你的运行手册（runbook）处理了该提供商降级的情况。当他们的仪表板变黄时，你的状态页订阅会向你发送告警。你觉得万无一失。然后，在某个周三下午，你提供商运行的基础云区域开始出现局部降级，你提供商的故障转移区域也受到了影响，因为他们为了控制单位经济效益而整合了容量。由于签署合同时上游两层的供应商决策，你的产品在 90 分钟内处于半瘫痪状态。

第二天早上，客户的事后分析（postmortem）请求出现在你的收件箱里。他们想要找到根本原因。根本原因存在于你的状态页无法看到的层级，也是你的合同无法约束的层级。这一层级正是所谓的第四方风险——它不是一个采购复选框，而是一个无形的依赖层，它会向上层传导故障，只会衰减而不会被吸收。

在金融服务和医疗保健领域，第四方风险多年来一直是一项受监管的规范。但在 LLM 驱动的产品中，人们大多默认一个未经建模的假设：你调用的供应商就是技术栈的最底层。事实并非如此。你的推理提供商运行在别人的 GPU 上，在别人的数据中心里，由别人的网络骨干网支撑，而且通常集中在整个行业共享的少数几个区域。你与之签约的可见层只是技术栈的最顶端，无论你是否将其计入成本，这一技术栈都掌控着你的可用性状况。

合同之下的技术栈

一个典型的 LLM 驱动产品至少有四个风险层级叠加在一起。团队通常只对前两层进行建模。

第一层：你的代码。 你的服务部署、拥有并运行的部分。这是可观测性最高的一层，也是最没有借口出现故障的一层。

第二层：你的直接提供商。 模型 API、嵌入服务、推理网关。你在这一层有合同、状态页，通常还有采购记录。你的 SRE 团队可以与这一层协商 SLA 和赔付。

第三层：你提供商的基础设施。 你提供商运行所在的云区域。他们购买的加速器供应。他们支付的网络传输。你没有与这一层签署合同。你的提供商签署了，但他们没有义务向你分享其安全态势。

第四层及以下：上游基座。 数据中心所在的电网。两个大都市之间你的“地理冗余”提供商恰好都在使用的单一光纤路径。解析多个“独立”端点的 DNS 权威机构。因为折扣力度大而为互不相关的服务提供前端服务的 CDN。这一层正是行业集中度无形中转化为关联风险的地方。

当第四层发生故障时，第三层会有强烈感受，第二层会有明显的噪声，而第一层——你的产品——则会收到告警。故障模式并不是底层坏了，而是底层坏了之后，中间层在合同上没有义务告诉你原因、时间以及还要持续多久。

名不副实的跨供应商冗余

面对供应商停机，本能的反应是增加第二个供应商。你与另一家推理提供商签约，编写了回退路由，并觉得万无一失。事实并非如此，原因在于几何学：合同层的独立性并不能带给你基座层的独立性。

两个提供商可能解析到同一个云区域。两个云区域可能解析到同一个大都市区的电网。两个大都市区可能解析到同一条长途光纤走廊。2024 年的 CrowdStrike 事件是横向传播的教科书案例，它穿透了看似独立的供应商生态系统——一个单一的第四方更新同时禁用了数十个供应商的服务，因为这些供应商都在无形中趋同于使用同一个内核级代理。大多数运行“冗余”LLM 提供商的团队，在合同之下的一个或多个层级上也存在类似的趋同现象。

这种模式表现为三种具体方式：

身份联邦死锁。 两个提供商都针对同一个 SSO 租户进行身份验证。该 SSO 租户发生降级。虽然两个提供商技术上都没有下线，但由于鉴权层瘫痪，它们都不会接受你的流量，你的“故障转移”也因此失效。

故障转移期间的元数据风暴。 主提供商的错误率为 60%。路由器将 100% 的流量切换到备用提供商。备用提供商的单租户速率限制是根据你的稳态份额确定的，而不是为了应对突发流量，于是它也开始拒绝请求。原本应该是恢复的切换变成了第二次停机。

放大到共享尾部延迟的重试。 两个提供商都通过同一个在对等互联点轻微降级的 Tier-1 ISP 进行路由。两个提供商的尾部延迟都变长了。你为独立故障编写的重试策略成倍增加了负载。原本一秒的 p99 变成了两个提供商同时出现的 40 秒卡顿。

在每种情况下，架构诊断都是一样的。你的冗余策略是在合同层建模并在 API 层测试的，但故障却在两者之下的层级发生了关联。在没有梳理其下层基座的情况下增加第二个供应商，只能买到采购上的心理安慰，而对真正的可用性提升微乎其微。

绘制你不拥有的层级地图

修复始于一张延伸至第一层合同关系之外的依赖图谱。你无法要求供应商提供完整的地图——他们不会分享的——但你可以提取足够的信号来识别主要的集中度风险。

成本最低的切入点是 SOC 2 Type II 报告。其中的“子服务组织”（subservice organizations）部分列出了你的服务提供商所依赖的关键服务供应商。仔细阅读这一部分。编录其中提到的云服务、身份验证、可观测性和 CDN 提供商。然后向你的其他“冗余”供应商索要他们的 SOC 2 报告并进行对比。如果在你四个“独立”供应商中的三个供应商的子服务部分都出现了同一个名字，那么你并没有实现四路冗余。你实际上只有一个共享的依赖项，只不过套了四个不同的 Logo。

除了 SOC 2，合同条款也可以强制要求披露一些信息，这些信息通常是采购部门愿意谈判但工程部门很少要求的。以下是至关重要的条款：

• 入驻时及此后每年一次的分包商披露要求，注明实体名称及其提供的服务。
• 当提供商增加、移除或重大变更涉及你流量的第四方关系时的通知义务。
• “同等标准”条款，要求提供商将其对安全和可用性的要求下传至其关键分包商。
• 针对第四方事件的漏洞通知窗口，范围限定在影响你的数据或可用性的事件。

这些条款并不能消除风险。它们使风险变得清晰可见，而这是后续一切行动的前提。

能在预设故障中幸存的 SLO

标准的提供商 SLO 只衡量一件事——供应商的端点是否正常——而几乎不涉及你的冗余策略是否真正奏效。购买了第二个提供商的团队需要一个不同的指标：故障多样性 SLO（outage diversity SLO），用于衡量冗余策略是否能在其预设的故障中幸存，而不仅仅是供应商报告的故障。

这种 SLO 的形式很简单。对于每个定义的故障场景——主区域局部故障、身份提供商降级、传输路径拥塞、重试放大的长尾延迟——记录在那种场景下你的路由层能成功切换的流量比例。分子是“幸存场景数”，分母是“设计的场景总数”。一个拥有 99.99% 端点 SLO 但只有 40% 故障多样性 SLO 的系统，意味着你买了一个通常在线的提供商，但却买了一套通常无法救命的冗余策略。

这一指标需要大多数团队都会跳过的两项操作规范。

首先，路由层的健康检查探针必须能够检测到关联性降级，而不仅仅是单个提供商的可用性。一个从两个提供商都返回 200 的探针无法告诉你它们的共享传输路径是否拥塞。探针需要将延迟分布和错误率作为一个联合信号来衡量，而不是两个独立的信号。当联合信号降级而单个信号看起来正常时，说明底层架构发生了故障，而提供商的仪表盘在接下来的十五分钟内可能都不会显示这一点。

其次，必须对故障场景进行演练。模拟城市级光缆中断、区域性云服务局部故障或身份提供商降级的 Game-day 演练，才能将纸面上的冗余转化为实际观测到的冗余。从未进行过演练的团队，实际上订阅了一个他们无法从合同中读出的可用性概况。

你无法完整编写的复盘报告

当关联性故障最终降临时——对于任何运行在共享底层架构上的产品来说，这都是必然的——面向客户的复盘报告（Postmortem）是最难制作的产物。你面临一个你不拥有的事故。你有一个无法证实的根本原因。你有一个仍在调查中且不允许你引用其内部分析的供应商。而客户想要一个名字和一个解决方案。

在这种情况下，能立得住脚的规范是将复盘报告分为两层编写，且两层都要保持诚实。

外层描述你观察到的现象和你采取的行动。你的错误率、你的流量切换行为、你的路由层检测到关联性降级的时刻、你向供应商升级问题的时刻、客户恢复时间。这一层完全在你的控制之下，且完全可验证。

内层描述上游原因，程度仅限于你可以从供应商的公开通信中确认的范围，不多也不少。“供应商的状态页面确认从 UTC 时间 14:02 开始错误率上升，其公开更新归因于其底层云提供商的区域性基础设施事件。”这句话是真实的、有出处的且有边界的。它并不试图说明云提供商的根本原因是什么，因为你并不知道。

客户想要更深层的答案。而深层答案正是合同没能带给你的东西。在复盘报告中指出这一差距——而不去指责一个你无法控制的供应商——是你所能产出的最诚实的、前瞻性的产物，也是为下一个预算周期的采购谈判提供依据的证明。

真正冗余的成本

在底层基础设施层（substrate layers）实现真正的冗余，其成本往往超出了团队在第一次关联性停机（correlated outage）迫使他们直面这个问题之前的预算。这种成本体现在三个方面。

采购成本。寻找一个底层基础设施完全独立于第一家供应商的备选供应商，比仅仅寻找第二个品牌（second logo）要难得多，而且价格差异是实实在在的。跨区域或跨云的数据传输并非免费。第二好的供应商之所以通常是第二好的，是有原因的。

工程成本。处理关联性降级的路由器、衡量联合信号的健康检查探针，以及演练基础设施故障的“演练日”（game-day）计划，这些都是数月的工程工作，且不会产生任何可见的功能。

运营成本。让两家供应商都保持足够的热备状态以吸收完整的流量转移，而不是为了省钱而保持冷备，意味着你要为你平时并不使用的容量付费。其经济逻辑类似于保险：在稳态下支付保费，在事故发生时获得赔付。

没有支付这些成本的团队，在一次涉及采购团队和法务团队的客户投诉升级中，才领悟到真正的代价。而支付了这些成本的团队，则能写出更简短的事后总结（postmortem）。

架构上的觉醒

你签约的供应商只是你不拥有的技术栈中可见的一层。合同描述的是一个层级（tier），而底层基础设施（substrate）才描述了真实的可用性状况。大多数团队只优化他们可以签约的层级，却忽略了决定签约是否有意义的底层。

第四方风险（Fourth-party risk）是指底层基础设施的故障模式传播到表面，而你的合同对此却无能为力。解决之道不是增加更多的供应商，而是提高可见性——深入洞察合同之下的层级，了解那些所谓的独立供应商之间的关联性，以及你的冗余策略实际针对的故障场景。建立这种可见性的团队将写出更简短的事后总结。而不这样做的团队，将不断被他们从未计入成本的可用性状况所震惊。

下次当客户询问“你的模型供应商是谁”时，更有价值的答案是列出其下的四个层级，并说明你的团队实际对其中哪些层级进行了建模。这个答案更难给出。但它也是唯一能在合同未能预见的事故中幸存下来的答案。