# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Railway (@Railway) · 平台：X (Twitter) · 日期：2026-05-21

> 原始來源：https://x.com/Railway/status/2057015079975915763

## 中文摘要

Railway 因帳號遭GCP誤停權導致服務中斷。

Railway 團隊 Chandrika Khanduri 與 Cody De Arkland 發布了此次事件的詳細報告。由於 Google Cloud 的自動化機制錯誤地將 Railway 的生產環境帳號設為停權狀態，導致託管於 GCP 上的控制平面（Control Plane）、API 及網路基礎設施全面離線。儘管 Railway 在 AWS 及自有硬體環境（Railway Metal）上的工作負載並未直接受損，但由於邊緣代理（Edge Proxies）依賴 GCP 託管的控制平面 API 來更新路由表，隨著快取過期，導致所有區域的工作負載皆無法存取，最終造成全平台癱瘓。

**事件影響範圍**
此次中斷發生於 2026 年 5 月 19 日 22:20 UTC 至 5 月 20 日 06:14 UTC，影響時間長達約 8 小時。具體影響如下：
- 使用者在存取儀表板與 API 時出現 503 錯誤，顯示「no healthy upstream」或「unconditional drop overload」訊息，導致無法登入。
- 託管於 GCP 的運算資源直接離線。
- 隨著路由快取過期，原本在 AWS 與 Railway Metal 上運行的工作負載因無法解析路由，開始出現 404 錯誤。
- 恢復期間，GitHub 對 Railway 的 OAuth 與 Webhook 觸發了速率限制（Rate-limiting），進一步阻礙了使用者登入與系統部署。
- 服務條款（Terms-of-service）接受紀錄被重置，導致使用者在恢復後需重新確認。

**事件時間軸摘要**
- 5 月 19 日 22:19 UTC：確認根因為 Google Cloud 帳號遭停權。
- 5 月 19 日 22:29 UTC：正式宣告事件，並恢復 GCP 帳號存取，但運算實例與持久化磁碟仍無法使用。
- 5 月 19 日 23:54 UTC：所有持久化磁碟恢復就緒狀態，但網路控制平面尚未恢復。
- 5 月 20 日 01:38 UTC：網路恢復，邊緣流量開始重新運作。
- 5 月 20 日 02:47 UTC：GitHub 開始對 OAuth 與 Webhook 進行速率限制。
- 5 月 20 日 04:00 UTC：API、儀表板與 OAuth 端點確認運作正常，其餘工作負載持續恢復中。

**架構反思與補救措施**
Railway 承認此次事件暴露了架構上的單點依賴問題，即網路控制平面過度依賴單一雲端供應商。針對未來預防措施，團隊提出以下規劃：
- **移除單點依賴**：目前正致力於將網路控制平面從 GCP 的硬性依賴中解耦，建立真正的網狀網路（Mesh），確保即便單一雲端供應商中斷，網路路徑仍能維持運作。
- **擴展資料庫高可用性**：將資料庫分片（Shards）擴展至 AWS 與 Railway Metal，確保在單一雲端環境完全消失時，資料庫仲裁機制能維持運作並自動故障轉移（Failover）。
- **調整資料平面架構**：計畫將 Google Cloud 服務從資料平面的「熱路徑」（Hot Path）中移除，僅保留作為次要或故障轉移用途。
- **架構升級**：同步進行資料平面與控制平面的架構升級，確保核心服務與使用者面向的組件不再受限於單一供應商。

Railway 強調，無論故障源於 Google 還是 Railway 自身，使用者只會在意產品是否可用，因此團隊將對此次架構決策負起全責，並持續提升系統的韌性。

## 標籤

Deployment, Railway, Google Cloud, AWS