1 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Sự cố gián đoạn dịch vụ trên diện rộng của Railway đã được khắc phục, và nguyên nhân được xác định là do tài khoản Google Cloud của Railway bị chặn
  • Trong thời gian sự cố, người dùng có thể gặp "no healthy upstream", "unconditional drop overload", đăng nhập thất bại, không thể truy cập bảng điều khiển
  • Railway đã liên hệ trực tiếp với đội hỗ trợ Google Cloud để khôi phục quyền truy cập tài khoản, đồng thời tiến hành khôi phục control plane và workload
  • Trong quá trình khôi phục, sự cố mạng phía Google Cloud vẫn còn tồn tại khiến một số dịch vụ không thể khởi động, và các bản build không thuộc enterprise bị giới hạn tạm thời
  • Dịch vụ đã được khôi phục hoàn toàn, nhưng một số workload được phát hiện ở trạng thái bất thường đang được tự động triển khai lại, và nếu cần thì người dùng phải tự triển khai lại thủ công

Tổng quan sự cố và trạng thái cuối cùng

  • Railway đã khắc phục sự cố gián đoạn dịch vụ trên diện rộng, và có thể xem phân tích hậu sự cố tại Incident Report
  • Trong thời gian sự cố, người dùng có thể gặp "no healthy upstream", "unconditional drop overload", đăng nhập thất bại, không thể truy cập bảng điều khiển
  • Nguyên nhân là do tài khoản Google Cloud của Railway bị chặn, khiến một số dịch vụ của Railway không thể sử dụng
  • Railway đã liên hệ trực tiếp với đội hỗ trợ Google Cloud để khôi phục quyền truy cập tài khoản và tiến hành khôi phục workload
  • Dịch vụ đã được khôi phục hoàn toàn, nhưng một số workload được phát hiện ở trạng thái bất thường đang được tự động triển khai lại và các dịch vụ có phản hồi không bình thường có thể cần người dùng tự triển khai lại thủ công

Diễn biến khôi phục và ảnh hưởng đến người dùng

  • Điều tra ban đầu và xác nhận nguyên nhân

    • Railway đã khôi phục hạ tầng Google Cloud vận hành control plane cho bảng điều khiển, API và mạng nội bộ
    • Ngay cả sau khi quyền truy cập vào nhà cung cấp cloud cấp trên được khôi phục, bảng điều khiển Railway và các dịch vụ chạy trên hạ tầng cloud vẫn có thể tiếp tục bị ảnh hưởng cho đến khi bản sửa lỗi được triển khai
    • Sau khi tài khoản Google Cloud bị chặn, đội nền tảng Railway đã xác nhận quyền truy cập vào một phần hạ tầng được lưu trữ trên Google Cloud và khôi phục quyền truy cập cho các dịch vụ còn lại
  • Google Cloud và sự cố mạng

    • Railway đã khôi phục compute trên Google Cloud, nhưng sự cố mạng phía Google Cloud vẫn còn khiến một số dịch vụ không thể khởi động
    • Trong quá trình khôi phục, các workload được lưu trữ trên Google Cloud có thể tiếp tục gặp sự cố gián đoạn không liên tục
    • Đội hạ tầng Railway cũng đồng thời xem xét các tuyến thay thế để đưa các dịch vụ bị ảnh hưởng trở lại trạng thái trực tuyến
  • Giới hạn build và triển khai

    • Các workload metal của Railway bắt đầu được khôi phục dần
    • Trong quá trình khôi phục, tất cả các bản build không thuộc enterprise bị giới hạn tạm thời để tránh quá tải hạ tầng build
    • Sau đó, việc triển khai non-enterprise vẫn tạm thời bị dừng, còn triển khai enterprise không bị ảnh hưởng
    • Ngay cả sau khi có thể triển khai trở lại, các workload còn nằm trên Google Cloud vẫn có thể gặp sự cố gián đoạn không liên tục cho đến khi việc khôi phục hoàn tất
  • Hành động hiện tại

    • Các dịch vụ Railway đã được khôi phục hoàn toàn, và các dịch vụ có phản hồi không bình thường cần được triển khai lại từ bảng điều khiển hoặc CLI
    • Có thể xem thêm ngữ cảnh tại FAQ, và nếu cần hỗ trợ trực tiếp thì có thể mở thread tại Railway Station

1 bình luận

 
Ý kiến trên Hacker News
  • Railway đã khắc phục sự cố này và công bố bản phân tích hậu kiểm
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    Tính đến 07:57 UTC ngày 20 tháng 5, trang trạng thái cũng đã được đăng
    https://status.railway.com/incident/I23M92U0

    • Trong trường hợp như thế này, tôi nghĩ phải có khả năng yêu cầu Google bồi thường thiệt hại. Đây không phải kiểu vấn đề có thể nằm trong điều khoản như lỗi mạng hay thất bại dịch vụ
    • Railway nói rằng sự cố đã được xử lý, nhưng vẫn còn nhiều dịch vụ trả về 502 và đang bị sập. Bên tôi chỉ khôi phục sau khi kích hoạt triển khai lại thủ công, và tôi nghĩ Railway lẽ ra phải tự động làm việc đó
      Tổng cộng thời gian downtime bên tôi là hơn 11 giờ
  • Lại thêm 0 ngày kể từ lần gần nhất GCP đánh sập một startup
    Có cảm giác chuyện này ít nhất cũng xảy ra mỗi năm một lần, còn với AWS hay Azure thì tôi chưa từng nghe thấy
    Nói nghiêm túc thì đó là lý do tôi không dùng GCP. Đây là cloud dễ dùng nhất trong big 3, nhưng họ tự phá hỏng mình vì kiểu tai tiếng này

    • Ngược lại, tôi lại không nhớ rõ lần nào GCP gặp sự cố nghiêm trọng. AWS/Azure thì có vẻ mỗi năm vài lần sập theo kiểu thảm họa
    • AWS làm việc đó hiệu quả hơn. Khi us-east-1 sập, họ kéo theo nhiều startup một lúc
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure năm ngoái cũng từng làm hỏng front door của toàn bộ dịch vụ Azure và O365
      Mỗi công ty này đều có thế mạnh riêng, nhưng thỉnh thoảng vẫn gây ra các vụ lớn
    • Có lần AWS throttle dịch vụ của chúng tôi nặng đến mức không thể vận hành được. Tôi từng định viết rằng họ đã chặn đà tăng trưởng của chúng tôi suốt một tháng, nhưng giờ có vẻ chuyện đó cũng chẳng còn nhiều ý nghĩa
    • Bên tôi cũng không đụng đến GCP vì cùng lý do đó
  • Ai cũng muốn đổ lỗi cho Google, nhưng với tư cách là người đã dùng Railway khá lâu, tôi muốn nghe phía GCP trước khi kết luận. Railway cũng từng có những vấn đề kiểu này trước đây, và cách đội ngũ đó xử lý không tạo được sự tin cậy
    Dù sao thì với tôi, đây cũng là giọt nước tràn ly

    • Tôi cũng đồng ý, dù chỉ là ở mức giai thoại. Đội dev của Railway cho cảm giác làm việc khá lỏng lẻo, trộn đủ kiểu vibe coding ở khắp nơi. Có một mức độ mà bạn có thể nói “họ vẫn là startup, hãy thông cảm”, và Railway đã vượt qua ranh giới đó
    • Đúng vậy. Ở các thread khác cũng thấy nhiều tài khoản chỉ trích rất nặng nhà cung cấp cloud, nhưng điều lạ là trong làn sóng phẫn nộ này, gần như không ai tỏ ra muốn tìm hiểu hay xem xét khả năng về nguyên nhân gốc rễ
    • Hai năm trước tôi cần hỗ trợ nhưng họ quá tệ, nên tôi chuyển sang Vercel và bảo họ biến đi
      Sau đó tôi cần thứ tương tự cho các dịch vụ khác và tìm thấy coolify. Nếu dùng được coolify thì hoàn toàn không có lý do gì để dùng Railway
    • Nếu bạn có thể chia sẻ các trường hợp cụ thể trước đây thì tôi muốn đọc
    • Tôi đã nghe được những chi tiết mà lẽ ra tôi không nên biết. Tôi có thể tự tin nói rằng vụ này 100% là lỗi của Google, và sẽ khá thất vọng nếu Railway không thể chia sẻ thêm
      Railway thực sự không có cách nào để ngăn chuyện này, ngoài việc tránh dùng GCP hoàn toàn
  • Còn có sự cố UniSuper vào tháng 5 năm 2024: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    Theo tuyên bố chung của CEO UniSuper Peter Chun và CEO Google Cloud Thomas Kurian, một lỗi cấu hình bất cẩn đã xảy ra trong quá trình provision dịch vụ Private Cloud của UniSuper, và cuối cùng đã khiến đăng ký Private Cloud của UniSuper bị xóa
    Google Cloud nói đây là một “sự cố cá biệt chỉ xảy ra một lần” chưa từng có với bất kỳ khách hàng Google Cloud nào trên toàn thế giới, nhưng việc xóa đăng ký này đã dẫn đến việc xóa ở cả hai vùng, khiến quá trình khôi phục phải phục hồi hàng trăm máy ảo, cơ sở dữ liệu và ứng dụng

    • Khi đó tôi đã viết về sự cố UniSuper: https://danielcompton.net/google-cloud-unisuper
      Đây là một bug khá nghiêm trọng, và môi trường VMWare của họ được tạo với thời hạn hết hạn 1 năm, nhưng từ góc nhìn của Google Cloud thì đó chỉ là một “resource”
    • “Việc xóa đăng ký Private Cloud đã dẫn đến việc xóa ở cả hai vùng” chính là thứ được gọi là điểm lỗi đơn, và với bất kỳ ai từng chịu trách nhiệm về an toàn, đó là một cơn ác mộng
    • Một cấu trúc mà chỉ cần đóng hoặc xóa đăng ký là gây ra xóa dây chuyền trên toàn cầu nghe như công thức cho thảm họa. Tôi không hiểu vì sao họ không chỉ đánh dấu xóa rồi đợi một ngày hay một tuần sau mới xóa thật
  • Tôi không hiểu làm sao chuyện như vậy lại có thể xảy ra với một công ty có mức chi tiêu hàng tháng lớn. Ở công ty cũ của tôi, khi AWS phát hiện workload đáng ngờ đang chạy, TAM đã liên hệ trước khi thực hiện hành động
    Tôi đoán vụ này là một dạng tự động hóa AI bị lỗi, và có lẽ GCP không thích thực sự liên hệ con người để nhận phản hồi, nên sau vài tiếng một nhân sự outsource mới thấy trong hàng chờ hỗ trợ rồi gửi lại một câu trả lời mẫu

    • Nếu là chuyện liên quan đến hỗ trợ GCP thì giờ chẳng còn gì làm tôi ngạc nhiên nữa. Chúng tôi có hơn 12 Account Executive thay đổi trong 6 năm qua dù hoàn toàn không cần, và tất cả đều vô dụng
      Mỗi lần họ đều tự giới thiệu, xin sắp xếp cuộc họp với đội kỹ thuật, mang đến một bộ slide mẫu chẳng liên quan gì tới chúng tôi khiến ai cũng chỉ biết cười, rồi lần liên hệ tiếp theo là khi một AE mới lại được phân công
      Tôi thích GCP và các dịch vụ của họ, và đã hài lòng trong nhiều năm, nhưng phần con người thì thực sự tệ hại và tôi không hiểu vì sao họ còn duy trì nó
    • Có vẻ ở thread khác cũng đã có vài câu trả lời có ý nghĩa. Bên tôi cuối cùng cũng lấy lại được tài khoản, nhưng ngay cả khi có Account Rep và CSM thì vẫn mất thời gian mới hiểu được chuyện gì đã xảy ra
      Nếu không có người phụ trách tài khoản thì có lẽ còn tệ hơn nữa
    • Vì đó là Google. Họ cho bạn dùng dịch vụ, rồi ngay khi bạn lệch khỏi chuẩn mực của họ thì họ đình chỉ bạn
  • Với tư cách là người vận hành API công khai, lượng spam đến từ IP của Railway là nhiều đến vô lý. Khả năng chống lạm dụng rất tệ, và tôi hy vọng vụ này sẽ là cơ hội để họ cải thiện vận hành

    • Khi điều hành một công ty hosting, xung đột cốt lõi chính là chuyện này. Nếu làm đăng ký dễ thì sẽ có nhiều người dùng mới, nhưng lạm dụng cũng kéo vào nhiều
      Nếu thêm biện pháp chống lạm dụng thì sẽ có các false positive gây ồn ào, và vụ GCP lần này cũng có thể là như vậy
      Tôi không ghen tị với người điều hành công ty hosting. Internet thực sự rất bẩn bên dưới bề mặt
      Nói thêm thì AWS làm phần này cực kỳ tốt. Có lẽ nhờ khoảng 30 năm kinh nghiệm xử lý gian lận bán lẻ và lạm dụng
  • Khoan đã, Railway chạy trên GCP sao? Chẳng phải họ từng nói rất lớn rằng “không xây cloud trên một cloud khác” à?
    Hay ý họ là không thuê VPS mà chỉ thuê bare metal từ nhà cung cấp cloud?
    Ít nhất tôi đã hy vọng có một nhà cung cấp khác không chỉ trả tiền cho một hyperscaler mà còn làm colocation và sở hữu nhiều hơn trong stack
    https://blog.railway.com/p/heroku-walked-railway-run

    • Bài được liên kết xem qua Wayback Machine có đoạn như sau
      “Ngay từ ngày đầu tiên, chúng tôi đã đặt ý tưởng này ở tuyến đầu.
      Và một điều khác mà chúng tôi trực giác nhận ra là bạn không thể xây dựng cloud trên một cloud khác. Chúng tôi đã dành nhiều năm để vận hành máy chủ của riêng mình và làm tốt việc cùng tồn tại với các cloud khác, để doanh nghiệp của Railway, và cuối cùng là doanh nghiệp của khách hàng, vững chắc nhất có thể.”
    • Đúng, và đó là lý do tôi bực. Họ đã nói dối. Họ hoàn toàn phụ thuộc vào GCP
      Giờ tôi phải tìm hiểu thêm rồi. Tôi cần thứ gì đó ổn định hơn và ít phụ thuộc hơn vào sự thất thường của một công ty duy nhất
      Đây cũng là chuyện tệ với chính Railway, vì nó đánh thẳng vào cốt lõi tuyên bố lớn của họ về triển khai phần mềm trong yên bình. Đây là hỗn loạn
  • Tôi cứ tưởng Railway đang xây dựng trung tâm dữ liệu riêng [0]
    “Về cơ bản, bạn không thể xây cloud trên cloud của người khác.”
    Hóa ra đúng là vậy thật…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel có vẻ đang làm được điều đó. PlanetScale cũng vậy nếu chỉ tính mảng cơ sở dữ liệu, mà suy cho cùng thì mọi thứ đều là cơ sở dữ liệu
  • Cách Railway xác nhận lúc đăng ký rằng bạn đã đọc và hiểu điều khoản về lạm dụng hệ thống, đào coin bằng crypto, v.v. là khá đặc biệt
    Tôi đoán có rất nhiều người dùng lạm dụng gói miễn phí và gây ra vấn đề cho nhà cung cấp dịch vụ
    Dù ở vị thế đối thủ cạnh tranh, tôi cũng không vui vẻ gì khi thấy Railway hứng đòn như thế này, nhưng compute miễn phí luôn thu hút đủ loại người dùng kỳ quặc. Chúng tôi cũng đã trải qua chuyện đó, và quyết định tránh compute miễn phí từ sớm dù điều đó làm giảm lượng người vào đầu phễu

  • Tôi thấy khó mà chỉ đổ lỗi cho Google. Có vẻ Railway ngày càng gặp khó trong việc duy trì độ ổn định của nền tảng
    Chuyện kiểu này không nên làm sập toàn bộ dịch vụ. Nếu công việc kinh doanh đúng nghĩa là cung cấp backend ổn định thì phải có phương án dự phòng. Trong mắt tôi đây là kế hoạch yếu kém

    • Tôi không chắc ý bạn là gì. Bạn thực sự kỳ vọng Railway phải dùng kiến trúc đa đám mây để host mọi project của khách hàng sao? Nhìn tổng thể thì làm vậy có vẻ còn làm giảm tính sẵn sàng
    • Chẳng phải khôi phục sau thảm họa rất tốn kém sao? Nhất là ở quy mô của Railway thì lại càng có vẻ đúng