Google Cloud误操作致Railway平台级中断8小时，敲响云厂商单点依赖警钟

Google Cloud误操作引发8小时平台级中断2026年5月19日22:20 UTC至5月20日06:14 UTC约8小时的时间里云原生部署平台Railway遭遇平台级服务中断。起因是Google Cloud在一次自动化操作中错误地将Railway的生产账号置于“暂停”状态导致其所有GCP托管的基础设施瞬间下线。受影响的服务包括Railway的Dashboard、API、控制平面以及部分网络基础设施。虽然Railway自建的数据中心Railway Metal和AWS弹性计算环境的工作负载本身仍在运行但由于Railway的边缘代理依赖托管在Google Cloud的控制平面API来填充路由表随着路由缓存过期这些原本健康的工作负载也逐渐变得不可达最终所有Railway工作负载全部瘫痪。单点依赖架构放大事故影响此次事故的根源在于Google Cloud的自动化操作失误且事前未向单个客户发出预警。而Railway自身架构设计中的单点依赖则放大了事故影响。其网络采用“网状环”架构通过高可用光纤互联连接Metal、GCP和AWS但工作负载的可发现性依赖托管在Google Cloud上的网络控制平面API。这就导致尽管网状架构在缓存有效期内继续运行但一旦路由缓存过期边缘代理无法重新填充路由表整个网络便陷入瘫痪。此外账号恢复后持久化磁盘、计算实例和网络都需要分别恢复这一过程将故障时间延长了数小时。事故引发连锁次生灾害事故还引发了连锁反应。由于缓存被清除后所有请求重新开始重试GitHub开始对Railway的OAuth和Webhook集成进行速率限制导致部分用户无法登录构建任务被阻塞。同时服务条款接受记录也被重置用户需要重新接受条款才能访问Dashboard。Railway宣布多项整改措施Railway在报告中坦承承担架构决策责任并宣布了多项改进措施。一是消除控制平面单点依赖立即着手移除对Google Cloud控制平面的硬依赖实现真正的网状架构。二是扩展高可用数据库分片将其扩展到AWS和Metal。三是调整GCP服务定位将Google Cloud服务从数据平面的热路径中移除仅保留作为备用/故障转移用途。编辑观点此次事故为依赖第三方云服务的平台型企业敲响警钟企业需消除控制平面单点依赖建立跨云容灾机制重视账号权限管理。