Báo cáo sự cố: Railway bị Google Cloud khóa tài khoản gây gián đoạn toàn hệ thống

Railway, nền tảng triển khai ứng dụng phổ biến, vừa công bố báo cáo chi tiết về sự cố gián đoạn dịch vụ nghiêm trọng xảy ra vào ngày 19/5/2026. Nguyên nhân chính xuất phát từ việc Google Cloud (GCP) thực thi một hành động tự động, vô tình đặt tài khoản sản xuất của Railway vào trạng thái bị đình chỉ (suspended).

Hình ảnh minh họa

Mặc dù các workloads trên Railway Metal và AWS ban đầu vẫn hoạt động, sự cố đã lan rộng toàn hệ thống khi bộ nhớ đệm định tuyến (route cache) tại các proxy biên hết hạn. Do hệ thống điều khiển mạng (network control plane) phụ thuộc vào GCP, việc mất kết nối này khiến toàn bộ hạ tầng không thể định tuyến traffic, dẫn đến lỗi 404 và 503 cho người dùng.

Diễn biến sự cố

Vào lúc 22:20 UTC ngày 19/5, Railway phát hiện lỗi kiểm tra sức khỏe (health check) và xác định nguyên nhân gốc rễ là tài khoản GCP bị khóa. Mặc dù quyền truy cập tài khoản được khôi phục nhanh chóng sau đó, các dịch vụ riêng lẻ như ổ đĩa lưu trữ (persistent disks), máy tính (compute instances) và mạng lưới cần thời gian để khởi động lại riêng biệt.

Quá trình khôi phục kéo dài khoảng 8 giờ, với các mốc thời gian quan trọng:

• 22:29 UTC: Tài khoản GCP được khôi phục, nhưng dịch vụ vẫn offline.
• 22:35 UTC: Cache định tuyến hết hạn, gây lỗi lan sang AWS và Railway Metal.
• 01:30 UTC ngày 20/5: Mạng lưới được khôi phục, traffic bắt đầu được phục vụ.
• 06:14 UTC: Sự cố được coi là đã giải quyết cơ bản.

Ngoài ra, trong quá trình khôi phục, GitHub cũng áp dụng giới hạn tốc độ (rate-limit) cho các tích hợp OAuth và webhook của Railway do lượng yêu cầu thử lại quá lớn, gây khó khăn thêm cho việc đăng nhập và triển khai mã nguồn.

Nguyên nhân và Kiến trúc

Theo báo cáo, hành động đình chỉ tài khoản của Google Cloud là một quy trình tự động áp dụng cho nhiều tài khoản mà không có cảnh báo trước. Tuy nhiên, Railway thừa nhận trách nhiệm về thiết kế kiến trúc đã cho phép sự cố từ một nhà cung cấp duy nhất (single point of failure) làm sập toàn bộ hệ thống.

"Chúng tôi chịu hoàn toàn trách nhiệm về các quyết định kiến trúc cho phép một hành động từ nhà cung cấp thượng nguồn duy nhất lan rộng thành sự cố toàn nền tảng," - đại diện Railway chia sẻ.

Hệ thống mạng của Railway được thiết kế dạng lưới (mesh ring) kết nối Metal, GCP và AWS. Tuy nhiên, vẫn tồn tại sự phụ thuộc "cứng" vào API của hệ thống điều khiển mạng được host trên GCP để khám phá workloads. Khi cache hết hạn và GCP không phản hồi, toàn bộ mạng lưới bị tê liệt.

Biện pháp phòng ngừa

Để tránh lặp lại sự cố tương tự, Railway đang triển khai các thay đổi kiến trúc lớn:

• Loại bỏ sự phụ thuộc vào GCP trong đường dẫn dữ liệu nóng (hot path) của data plane.
• Mở rộng các shard cơ sở dữ liệu khả dụng cao (high availability) sang AWS và Metal để đảm bảo tính toàn vẹn dữ liệu và chuyển đổi failover tức thì.
• Chuyển đổi mạng lưới thành "mesh thực sự", đảm bảo luôn có đường dẫn kết nối giữa các đám mây ngay cả khi một liên kết bị mất.

Railway cam kết sẽ tiếp tục nâng cấp kiến trúc để đảm bảo các dịch vụ cốt lõi, đặc biệt là các thành phần hướng tới người dùng, không còn phụ thuộc vào bất kỳ nhà cung cấp hay nền tảng duy nhất nào.