谷歌 GCP 意外封禁了其大客户 Railway 账号，引发 8 小时宕机事故-低调大师

谷歌 GCP 意外封禁了其大客户 Railway 账号，引发 8 小时宕机事故

2026-05-21 6

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

微信关注我们

原文链接：https://www.oschina.net/news/443618

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Mozilla 宣布放弃 asm.js：Firefox 148 开始默认禁用，WebAssembly 完成历史交接

Mozilla近日宣布Firefox 148将开始默认禁用SpiderMonkey的asm.js优化，并计划在未来版本中完全移除该代码。这意味着一项Web性能史上最具开创性的技术实验即将落幕。 SpiderMonkey是Mozilla的JavaScript和WebAssembly引擎，被广泛应用于Firefox、Servo以及其他众多项目中。它采用C++、Rust和JavaScript编写。您可以将其嵌入到C++和Rust项目中，也可作为独立shell运行。此外，它还可以编译为WASI。 asm.js诞生于2013年Firefox 22发布之时，它是一个JavaScript的严格静态类型子集，...

2026-05-21

5

腾讯宣布旗下操作系统层级 AI 助手 Marvis（马维斯）正式上线，由腾讯应用宝团队打造，能把整台电脑变成可对话的对象。开箱即用，支Windows端、Mac端、安卓端版本同步上线，无需邀请码。根据介绍，Marvis 将终端系统、文件、应用、算力和跨端连接纳入同一个 AI 中间层。目前，每位用户每天可享 1000 万免费 Token。 Marvis 提供 2 种模式，用户可根据电脑硬件配置，按需切换效率模式：可体验端云协同，又快又准隐私模式：可使用端侧大模型，文件0上传，最大程度保护你的隐私

2026-05-21

5

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。