2026年5月19日,云原生部署平台Railway遭遇平台级服务中断,起因竟是Google Cloud误将其生产账号标记为"已暂停"。这场持续8小时的故障不仅影响了Railway自身的服务,还波及了托管在其平台上的所有用户工作负载,再次敲响云厂商单点依赖的警钟。

事故概述
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工作负载——无论托管在哪个云平台——全部瘫痪。
时间线还原
根据Railway发布的详细事故报告,事件发展如下:
- 22:10 UTC— 自动化监控检测到API健康检查失败,值班工程师开始调查
- 22:11 UTC— Dashboard返回503错误,用户无法登录
- 22:19 UTC— 根因定位:Google Cloud Platform暂停了Railway的生产账号
- 22:22 UTC— 向Google Cloud提交P0工单,直接联系GCP客户经理
- 22:29 UTC— 事故升级;GCP账号访问恢复,但所有计算实例仍处于停止状态,持久化磁盘无法访问
- 22:35 UTC— 缓存的网络路由开始过期;Railway Metal和AWS上的工作负载开始返回404错误
- 23:09 UTC— 首个持久化磁盘恢复在线
- 23:54 UTC— 所有持久化磁盘恢复就绪,但网络仍未恢复
- 01:30 UTC(次日)— 计算实例开始恢复
- 01:38 UTC— 边缘流量重新服务,网络恢复
- 02:47 UTC— GitHub开始对Railway的OAuth和Webhook集成进行速率限制
- 04:00 UTC— API、Dashboard和OAuth端点确认运行正常
- 06:14 UTC— 事故转入监控状态
- 07:58 UTC— 事故完全解决
根因分析
这场事故的根源在于Google Cloud的一次自动化操作失误。Google Cloud将Railway的生产账号错误地置于"暂停"状态,且由于是平台级操作,事前并未向单个客户发出预警。
然而,Railway自身架构设计中的单点依赖放大了事故影响。Railway的网络采用"网状环"架构,通过高可用光纤互联连接Metal、GCP和AWS。但问题在于,工作负载的可发现性仍然依赖托管在Google Cloud上的网络控制平面API。这意味着,尽管网状架构在缓存有效期内继续运行,但一旦路由缓存过期,边缘代理无法重新填充路由表,整个网络便陷入瘫痪。
此外,账号恢复后,各项服务并非自动恢复。持久化磁盘、计算实例和网络都需要分别恢复,这一过程将故障时间延长了数小时。
次生灾害
事故还引发了连锁反应。由于缓存被清除后所有请求重新开始重试,GitHub开始对Railway的OAuth和Webhook集成进行速率限制,导致部分用户无法登录,构建任务被阻塞。同时,服务条款接受记录也被重置,用户需要重新接受条款才能访问Dashboard。
整改措施
Railway在报告中坦承:"我们完全承担导致单一上游供应商行为演变为平台级宕机的架构决策责任。"
为防止类似事件再次发生,Railway宣布了以下改进措施:
1. 消除控制平面单点依赖
Railway正在立即着手移除对Google Cloud控制平面的硬依赖,实现真正的网状架构。这意味着即使任意互联链路中断,云之间始终存在可用路径。
2. 扩展高可用数据库分片
将高可用数据库分片扩展到AWS和Metal。未来,如果某个云平台的实例瞬间全部消失,数据库仲裁机制将保持一切运行,并立即将故障工作负载切换到其他可用区域。
3. 调整GCP服务定位
计划将Google Cloud服务从数据平面的热路径中移除,仅保留作为备用/故障转移用途。同时实施新的数据平面和控制平面架构,确保核心服务(尤其是面向用户的组件)不依赖任何单一供应商或平台。
对于依赖第三方云服务的平台型企业而言,这起事故提供了重要教训:
- 真正的多云架构需要消除控制平面层面的单点依赖,而非仅仅在数据层面做冗余
- 云厂商的自动化操作可能带来不可预见的风险,企业需要建立跨云厂商的容灾机制
- 账号级别的权限管理同样关键,需要与云厂商建立直接沟通渠道以应对紧急情况
正如Railway在报告中所说:"你的客户不在乎故障是Google还是Railway造成的;他们看到的是你的产品。确保可用性是我们的责任。"
参考来源:
Railway Blog - Incident Report: May 19, 2026 - GCP Account Suspension (2026-05-20) https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage