当备份也救不了你：铁路系统宕机的背后故事
多云架构：表面很安全，其实暗藏杀手
很多人都觉得多云就是保险。把服务同时扔到 AWS、Google Cloud 还有自己的服务器上，好像就再也不怕一家宕机了。听起来很合理，但现实往往不按剧本走。
Railway 就是个例子。这家云部署平台把客户的应用同时放在了 Google Cloud、AWS 以及自己维护的裸金属服务器上。按理说冗余做得够充分了。
可 2026 年 5 月 19 日晚上，Google Cloud 的自动系统突然把他们的生产账号封了。没有任何预警。工程师连夜抢救，八小时后才恢复。
最讽刺的是：真正的应用容器其实一直都在正常跑。
控制平面才是命门
问题出在流量怎么找到这些容器。
用户请求不是直接打到应用上，而是先经过一堆边缘代理。这些代理需要知道「这个应用现在跑在哪台机器上」。这个信息来自控制平面——简单说就是一张路由表。
Railway 的控制平面全放在 Google Cloud 上。账号被封后，控制平面直接失联。
好在代理有缓存，能顶 35 分钟。但缓存一过期，代理就不知道该把请求发给谁了。结果不管应用在 AWS 还是裸金属上，全都返回 404。用户看到的，就是整个平台挂了。
连锁反应来了
更糟的是，后续触发了 GitHub 的限流机制。
因为失败请求太多，GitHub 以为是攻击，所以把 Railway 的 OAuth 接口给限流了。用户没法登录，也没法触发新部署。控制平面恢复后，这件事依然挡住了用户。
就像好不容易把门打开，结果报警器还在响。
分布式不等于安全
这个事件说明一个关键点：把应用分到多云是一回事，把控制权也分散是另一回事。
Railway 的应用容器确实分布在多处，但决定流量去哪里的「大脑」却只有一个。Google Cloud 的自动风控系统一拍板，整个路由系统就废了。
这也是为什么现在越来越多人在讨论控制平面冗余。它不像性能测试那样显眼，但一旦失败，后果往往是灾难性的。
给你什么启示
如果你也在做基础设施，这里有几条血的教训：
控制平面和数据平面不能混。应用可以分散，但路由、发现、协调这些核心功能如果都扎堆在一个云上，你的多云就只是摆设。
缓存只能救一时。Railway 的缓存给了 35 分钟缓冲，但时间一到就必须面对现实。靠缓存撑场子不是长久之计。
连锁故障会快速放大。GitHub 限流后，恢复难度大幅上升。一次故障很容易引发第二波、第三波。Incident Response 流程和架构本身一样<|eos|>