香港服务器接的几个海外服务一起挂，多半不是巧合

栏目里 9 月 9 日那篇讲的是"你接的某个海外 API 挂了三小时该怎么办"，给的是超时、重试和降级的参数。8 月 24 日那篇讲的是挂在你前面的 CDN 出问题怎么切。这两篇处理的都是单点——一个东西坏了，你怎么绕过去。

这篇补上一种更难受的情况：好几个东西同时坏了，而且你换不过去，因为备选那个也坏了。

9 月 3 日就发生了一次。UTC 15:49 前后，Downdetector 上 ChatGPT、Claude、Grok 的报障量几乎同步冲高，报障用户以美国为主。差不多同一时刻，另一家监测平台记录到微软 Azure East US 区域出现入口失败。三家彼此激烈竞争的公司，在同一分钟一起趴窝。

有意思的是对照组：跑在谷歌自有基础设施上的 Gemini，同一时间窗基本正常。

需要说清楚一件事——到现在为止，没有任何一家厂商发布正式的事后分析，确认这三起故障出自同一个根因。能确认的事实只有"三家在相近时间窗都承认了服务异常，随后陆续恢复"。但对运维来说，这个悬而未决的结论反而更值得警惕：在官方复盘出来之前，你唯一能做的假设是它还会再发生。

你的"多供应商"，可能只是一个供应商

大多数团队做技术选型时，有一份供应商清单：主力用 A，备用 B，出问题切 C。清单上三个名字，看着挺稳。

问题在于，这份清单记的是品牌，不是机房。

A 和 B 可能都是 SaaS 产品，各自的后端却都托管在同一家公有云的同一个区域；C 用的 CDN，和 A 的边缘节点可能是同一家。真出事的时候，你切到 B，发现 B 也在报错；再切 C，C 的控制台都打不开。这时候你才会明白，你买的不是三份冗余，是三张贴在同一个篮子上的标签。

9 月 3 日那次就是这个形状：三个应用层完全独立、商业上互为对手的产品，因为共用了同一片计算区域，表现出了完全一致的故障曲线。

同样的逻辑在更小的规模上每天都在发生。你的香港服务器上可能接着：一个海外支付网关、一个短信/邮件服务、一个对象存储、一个 AI 接口、一个汇率 API。这五个服务分属五家公司，但它们的机器有多大概率落在同一片区域？大多数人从来没查过。

把"供应商清单"改写成"故障域清单"

这件事可以做，而且不难。花半天时间，把你现在这份按公司名排列的清单，重写成按位置排列的清单。

第一步，查 IP 和 ASN。 对每一个外部依赖的域名，做一次解析，拿到 IP，再查这个 IP 属于哪个 ASN、注册在哪家公司名下。whois、dig、或者任意一个 ASN 查询站都能做。你会很快发现一批看起来毫不相干的服务，IP 落在同一个自治域里。

第二步，看区域线索。 很多服务商会在文档、状态页或者返回头里暴露区域信息。us-east-1、East US、asia-east1 这类字样值得记下来。拿不到的，看延迟——从你的香港服务器 ping 过去，20ms 和 180ms 是完全不同的两块大陆。

第三步，订阅状态页，而不是等用户投诉。 每个关键依赖的官方状态页都提供 RSS 或者 webhook，把它们汇总到一个群或者一个面板里。9 月 3 日那种情况，最先给你信号的不会是你的监控，是别人的状态页。

第四步，把清单按故障域折叠。 五个供应商折下来可能只剩两个故障域。这个数字才是你真实的冗余度。如果折完只剩一个，那你其实没有备份方案，只有一个心理安慰。

降级要按故障域设计，不是按功能设计

这是和 9 月 9 日那篇最大的区别。

那篇讲的是单个 API 超时了怎么办：设超时、退避重试、走缓存、做兜底文案。这套在单点故障下很有效。

但如果同一个故障域里的五个依赖一起失联，你的重试逻辑反而会变成伤害——五个服务同时超时，每个都在退避重试，把你香港服务器的连接池、线程池和出向带宽全部吃满，最后连能正常工作的那部分业务也被拖垮。

所以要多加一层：同故障域的依赖，要有共同的熔断开关。

具体做法是给每个外部依赖打上故障域标签，熔断器按标签聚合统计。当某个标签下的失败率整体超阈值时，直接把这一整组依赖切到降级模式——不再重试，直接返回兜底结果，把资源留给还活着的链路。

另外，把"核心路径"和"增强路径"分清楚。用户下单必须走通的是核心路径，AI 摘要、智能推荐、实时汇率刷新这类是增强路径。增强路径的依赖，默认就该是"挂了也不影响主流程"，而不是等它挂了才临时去改代码。

最后一层：你自己的落点也要算进去

前面讲的都是出向依赖。但同样的问题也适用于你自己的服务器。

如果你的主站、数据库、备份、监控告警全部放在同一个机房的同一排机柜，那么无论前面的依赖梳理得多干净，机房层面出一次事，你还是全军覆没。这里有个特别容易踩的坑：告警系统和被告警的系统放在一起。机房断网的时候，你收不到任何通知，得靠客户打电话告诉你。

比较实际的做法是，核心业务放一个地域，监控告警和最近一份备份放另一个地域，两边的网络路径和上游运营商不重叠。对做亚太业务的团队来说，香港服务器做主力、日本或新加坡节点做监控与冷备是常见组合；如果业务同时覆盖北美，那把备份落点放美国服务器也能顺带解决跨洲访问的问题。

SellBGP 的香港机房接入 CTGNet/CN2 GIA、HGC、HKBN 等多路回国网络，日本、新加坡、韩国、美国节点在物理与网络路径上彼此独立，适合用来拆开故障域。如果只是想先有一个轻量的第二落点跑监控和备份，香港云服务器秒级创建，跑最小配置的成本很低，不用为了容灾先付一整台独服的钱。

真正的冗余从来不是买了几家的服务，而是这几家坏掉的时候，不会在同一分钟。