IncidentHub 的 2026 上半年云与 SaaS 可靠性报告统计了 1,082 家服务商的 30,246 次中断（1 月至 6 月），其中 5 月单月最多，达 6,070 次；云服务商这一类别贡献了 86 家服务商的 4,723 次中断。报告给整个半年下的判断只有一个词：依赖风险（dependency risk）——故障沿着控制平面、边缘/CDN、身份认证、AI 接口一层层往下传导。
三个值得记住的案例
- Railway，5 月 19 日，约 8 小时：起因是 Google Cloud 的自动化账号封禁击穿了它的控制平面、API 与数据库，导致所有 Railway 工作负载不可达——包括跑在 Railway 自有裸机和 AWS 上的那些。这类故障不是硬件坏了，而是平台的自动化策略执行，报告把它单列为一类新兴风险。
- Google Cloud，德里/孟买机房火灾：印度区域相关流量出现了 21 天 12 小时的降级。全年 GCP 只记录了 2 次事件，但单次持续时间说明「次数少」不等于「影响小」。
- Azure，4 月 24 日 East US 控制平面中断超过 12 小时：原因涉及锁竞争与故障转移未完成。控制平面挂掉时数据平面往往还活着，但你无法创建、扩容或修改任何资源——恰恰是事故处置最需要这些操作的时候。
另外两个数字也值得记：Cloudflare 上半年记录了 487 次事件（4 月最多，98 次），Hetzner 对象存储 nbg1 与 hel1 分别出现 27 天 16 小时和 31 天 13 小时的降级。趋势上，短时故障变得更常见——这类故障不会上新闻，但会把你的告警系统训练成「狼来了」。
先分清控制平面和数据平面
很多人把「服务商挂了」理解成网站打不开。实际的破坏方式往往更别扭：网站还在跑，但你什么都改不了——不能扩容、不能改防火墙规则、不能签发证书、不能登录控制台。做应急预案时，一定要分别回答两个问题：「服务不可用怎么办」和「服务可用但我失去控制权怎么办」。
把依赖图画出来（用不了半小时）
列一张表，每一行是一个第三方，三列分别是「它挂了会怎样」「换掉它要多久」「有没有备选」：
- DNS：最该和 CDN 分开的一项。DNS 在别处，你才有可能把流量绕过出问题的 CDN。
- CDN / 反代：确认源站在没有 CDN 的情况下能独立提供服务——包括证书。很多站点的源站只对 CDN 回源 IP 开放，CDN 一挂就彻底失联。
- 证书签发：ACME 自动续期失败时你有没有告警？有没有一份手动签发的备用证书？
- 对象存储与备份：备份必须至少有一份在另一家，并且做过还原演练。同一服务商内的多可用区，防不住账号级别的问题。
- 账号与账单本身：付款方式过期、联系邮箱失效、被自动风控命中——Railway 的例子说明这条足以让一切归零。定期确认账单联系人、付款方式和账号验证状态。
- 带外访问：SSH 私钥、控制台恢复码、机房工单入口，是否有一份不依赖于「先登录出问题的那家平台」的副本。
为什么一台朴素的独立 VPS 是有价值的兜底层
不是说自建就更可靠——单机没有多可用区，硬件坏了就是坏了。但在一个由托管服务层层堆叠的架构里，一台你完全掌控、能直接 SSH 进去、能独立提供静态页面和基本服务的实例，是恢复顺序里非常有用的一环：它可以是维护页的托管处、是 DNS 切换后的临时源站、是备份的第二落点。SharkCloud 在日本、新加坡、香港、美国均有节点，把兜底实例放在与主力平台不同的服务商、不同的地区，这件事本身就是依赖图上最容易补的一格。