- Sự cố trên toàn nền tảng Railway kéo dài khoảng 8 giờ từ 22:20 UTC ngày 19 tháng 5 năm 2026, và nguyên nhân trực tiếp là việc tài khoản production của Google Cloud bị đình chỉ
- Dashboard và API ngay lập tức trả về lỗi 503, còn hạ tầng compute, database, control plane và burst-compute được lưu trữ trên Google Cloud chuyển sang trạng thái offline
- Các workload trên Railway Metal và AWS vẫn tiếp tục chạy, nhưng edge proxy phụ thuộc vào control plane API được lưu trữ trên Google Cloud, nên sau khi cache route hết hạn thì lỗi 404 lan rộng
- Ngay cả sau khi khôi phục quyền truy cập tài khoản, persistent disk, compute instance và networking vẫn phải được khôi phục riêng lẻ; giới hạn tốc độ với GitHub OAuth và webhook tiếp tục cản trở đăng nhập và build
- Railway thừa nhận trách nhiệm với quyết định kiến trúc đã khiến hành động từ một nhà cung cấp upstream duy nhất leo thang thành sự cố toàn diện, và đang tiến hành tái thiết kế để loại bỏ Google Cloud khỏi hot path của data plane
- Từ 22:20 UTC ngày 19 tháng 5 năm 2026 đến khoảng 06:14 UTC ngày 20 tháng 5, Railway gặp sự cố trên toàn nền tảng trong khoảng 8 giờ
- Khi Google Cloud đình chỉ dịch vụ của tài khoản production của Railway, API, control plane, database và hạ tầng compute được lưu trữ trên Google Cloud đều chuyển sang offline
- Người dùng ngay lập tức gặp lỗi 503 trên dashboard và API, đồng thời không thể đăng nhập với các thông báo
"no healthy upstream" và "unconditional drop overload"
- Toàn bộ workload được lưu trữ trên Google Cloud compute đều bị offline
- Bản thân các workload trong môi trường Railway Metal và AWS burst-cloud vẫn tiếp tục chạy, nhưng edge proxy của Railway phụ thuộc vào control plane API được lưu trữ trên Google Cloud để điền bảng định tuyến
- Khi các route mạng được cache hết hạn, ngay cả workload bên ngoài Google Cloud cũng không còn truy cập được, và network control plane không thể phân giải route của các instance đang hoạt động nên trả về lỗi 404
- Ở thời điểm ảnh hưởng nghiêm trọng nhất, các workload Railway ở mọi region đều không thể truy cập được
- Trong quá trình khôi phục môi trường Google Cloud, build và deploy trên toàn nền tảng bị chặn khi từng dịch vụ riêng lẻ được phục hồi
- Sau khi toàn bộ hạ tầng được khôi phục, một lượng lớn tác vụ deploy đang chờ được xử lý dần dần để tránh làm quá tải nền tảng
- Đồng thời, GitHub áp giới hạn tốc độ với tích hợp OAuth và webhook của Railway, khiến đăng nhập và build tạm thời bị chặn
- Lượng gọi tăng vọt là hệ quả của việc cache bị xóa sạch do sự cố Google Cloud
- Bản ghi đồng ý với điều khoản dịch vụ cũng bị đặt lại, nên người dùng phải đồng ý lại khi truy cập dashboard lần tiếp theo
- Railway thừa nhận trách nhiệm với quyết định kiến trúc đã cho phép hành động từ một nhà cung cấp upstream duy nhất lan rộng thành sự cố toàn nền tảng
- 22:10 UTC ngày 19 tháng 5: Hệ thống giám sát tự động phát hiện health check API thất bại và cảnh báo cho người trực on-call
- 22:11 UTC ngày 19 tháng 5: Dashboard trả về lỗi 503 và người dùng không thể đăng nhập
- 22:19 UTC ngày 19 tháng 5: Xác nhận nguyên nhân gốc là việc Google Cloud Platform đình chỉ tài khoản production của Railway
- 22:22 UTC ngày 19 tháng 5: Gửi vé P0 cho Google Cloud và account manager GCP của Railway trực tiếp tham gia xử lý
- 22:29 UTC ngày 19 tháng 5: Sự cố được chính thức công bố
- 22:29 UTC ngày 19 tháng 5: Quyền truy cập tài khoản GCP được khôi phục, nhưng mọi compute instance vẫn dừng và persistent disk chưa thể truy cập
- 22:35 UTC ngày 19 tháng 5: Khi các route mạng được cache bắt đầu hết hạn, workload trên Railway Metal và AWS bắt đầu trả về lỗi 404
- 23:09 UTC ngày 19 tháng 5: Persistent disk đầu tiên hoạt động trở lại
- 23:54 UTC ngày 19 tháng 5: Tất cả persistent disk được khôi phục về trạng thái ready, nhưng mạng vẫn còn down
- 00:39 UTC ngày 20 tháng 5: Xác nhận disk đã ở trạng thái ready, và việc khôi phục bị chặn ở khâu khôi phục networking của Google Cloud
- 01:30 UTC ngày 20 tháng 5: Compute instance bắt đầu được khôi phục
- 01:38 UTC ngày 20 tháng 5: Edge traffic bắt đầu được phục vụ trở lại và networking được khôi phục
- 01:57 UTC ngày 20 tháng 5: Hạ tầng orchestration và build được khôi phục; deploy tạm dừng để tránh việc các tác vụ chờ đồng thời chạy và làm hệ thống quá tải
- 02:04 UTC ngày 20 tháng 5: Các compute host dần quay lại trạng thái online
- 02:47 UTC ngày 20 tháng 5: GitHub bắt đầu áp giới hạn tốc độ với tích hợp OAuth và webhook của Railway, khiến một số người dùng không thể đăng nhập và build bị chặn
- 02:55 UTC ngày 20 tháng 5: Dashboard có thể truy cập trở lại
- 03:59 UTC ngày 20 tháng 5: Việc xử lý deploy được khởi động lại trên mọi tier
- 04:00 UTC ngày 20 tháng 5: Xác nhận API, dashboard và OAuth endpoint đã hoạt động; việc khôi phục các workload còn lại tiếp tục diễn ra
- 06:14 UTC ngày 20 tháng 5: Sự cố chuyển sang giai đoạn theo dõi
- 07:58 UTC ngày 20 tháng 5: Sự cố được giải quyết
-
Tài khoản Google Cloud bị đình chỉ
- Vào 22:20 UTC ngày 19 tháng 5, Google Cloud đã chuyển nhầm tài khoản production của Railway sang trạng thái đình chỉ như một phần của hành động tự động
- Hành động này ảnh hưởng đến nhiều tài khoản trong Google Cloud
- Vì đây là biện pháp ở cấp độ toàn nền tảng nên không có liên hệ trước với từng khách hàng trước khi bị hạn chế
- Trạng thái đình chỉ đã vô hiệu hóa hạ tầng liên quan đến GCP, bao gồm Railway Dashboard, API, một phần hạ tầng mạng và hạ tầng burst-compute bổ sung được lưu trữ trên Google Cloud
-
Phụ thuộc vào control plane
- Control plane của Railway là tập hợp các phụ thuộc cốt lõi dùng để phục vụ dashboard, xử lý build và deploy, đồng thời điền bảng định tuyến mà edge sử dụng
- Tất cả workload trên Google Cloud đều bị ảnh hưởng ngay lập tức
- Edge proxy của Railway duy trì cache bảng định tuyến của network control plane được lưu trữ bên trong Google Cloud
- Trong lúc cache còn hiệu lực, các workload trên Railway Metal và AWS vẫn tiếp tục phục vụ traffic
- Khi cache hết hạn, edge không còn phân giải được route của các instance đang hoạt động, và workload ở mọi region, bao gồm Metal và AWS, bắt đầu trả về lỗi 404
- Bản thân các workload vẫn online, nhưng tác động của sự cố mạng đã lan sang cả các region ngoài Google Cloud
-
Giới hạn của thiết kế high availability
- Hạ tầng của Railway được thiết kế hướng tới high availability; database chạy trên nhiều availability zone và mạng sử dụng các kết nối dự phòng giữa AWS, GCP và Railway Metal
- Ngay cả khi quyền truy cập tài khoản được khôi phục, từng dịch vụ riêng lẻ cũng không tự động được phục hồi
- Persistent disk, compute instance và networking đều cần quy trình khôi phục riêng, và đặc tính khôi phục này khiến sự cố kéo dài thêm nhiều giờ
- Disk được phục hồi về trạng thái ready lúc 23:54 UTC, nhưng networking cốt lõi và edge routing không được khôi phục hoàn toàn cho đến khoảng 01:30 UTC ngày 20 tháng 5
- Railway đang chờ xác nhận liệu độ trễ và các lỗi liên quan này có phát sinh từ phía Google hay không
-
Khôi phục theo từng giai đoạn và tác động thứ cấp
- Khi networking được khôi phục, các dịch vụ cốt lõi của Railway và workload của người dùng cuối được xác minh theo từng lớp
- Deploy bị tạm dừng để tránh quá tải hệ thống build, sau đó được nối lại dần dần
- Song song với việc khôi phục các hệ thống cốt lõi, GitHub áp giới hạn tốc độ với tích hợp OAuth và webhook của Railway
- Do khối lượng và tính bùng nổ của tất cả các yêu cầu retry, việc đăng nhập và build của người dùng tạm thời bị chặn
- Vào khoảng 04:00 UTC ngày 20 tháng 5, API, dashboard và OAuth endpoint được xác nhận là đang hoạt động, và việc khôi phục các workload còn lại tiếp tục diễn ra
-
Thiết kế khả năng phục hồi hiện có
- Network control plane của Railway được thiết kế theo cấu hình multi-AZ, multi-zone, có thể tiếp tục hoạt động mà không ảnh hưởng người dùng ngay cả khi mất nhiều máy và component
- Thiết kế này đã được kiểm thử trên môi trường staging và trên traffic thực trước khi phát hành vài tháng
- Sau các sự cố trước đó, Railway đã đầu tư vào khả năng phục hồi, và nhờ vậy từng có kinh nghiệm khôi phục ổn định việc cài đặt GitHub của người dùng mà không gặp giới hạn tốc độ thứ cấp
-
Loại bỏ phụ thuộc đơn lẻ
- Mạng Railway là một mesh ring gồm các kết nối quang liên thông high availability giữa Metal <> GCP <> AWS
- Nhưng ngay cả trong vòng ring này, khả năng khám phá workload vẫn còn phụ thuộc chặt vào network control plane API chạy trên máy Google Cloud
- Mesh tiếp tục hoạt động trong khoảng một giờ, nhưng khi cache route hết hạn thì không thể điền lại bảng định tuyến nên bị lỗi
- Railway đang ngay lập tức loại bỏ phụ thuộc này để biến nó thành một mesh thực sự
- Mục tiêu là luôn còn đường đi giữa các cloud ngay cả khi bất kỳ kết nối liên thông nào bị đứt
-
Cải thiện database và failover
- Railway dự định mở rộng các shard database high availability trên AWS và Metal
- Trong tương lai, ngay cả khi mọi instance trên một cloud cụ thể biến mất ngay lập tức, quorum của database vẫn sẽ duy trì dịch vụ và lập tức failover các workload không còn chạy nữa
-
Tái thiết kế data plane và control plane
- Kế hoạch loại bỏ các dịch vụ Google Cloud khỏi hot path của data plane và chỉ giữ lại cho mục đích dự phòng hoặc failover đang được triển khai
- Việc này diễn ra song song với nỗ lực triển khai kiến trúc mới cho data plane, thứ cho phép kết nối host, và cho control plane, thứ vận hành dashboard nơi người dùng truy cập và quản lý Railway
- Nâng cấp này nhằm bảo đảm các dịch vụ cốt lõi, đặc biệt là các component hướng tới người dùng, không còn phụ thuộc vào bất kỳ vendor hay nền tảng đơn lẻ nào
Trách nhiệm và kết luận
- Trách nhiệm về lựa chọn vendor thuộc về Railway, và lựa chọn lần này cuối cùng cũng là trách nhiệm của Railway
- Khách hàng nhìn vào chính sản phẩm hơn là nguyên nhân thất bại thuộc về Google hay Railway, và uptime của Railway là trách nhiệm của Railway
1 bình luận
Ý kiến trên Hacker News
Phần thú vị và vẫn chưa được giải thích là vì sao Google gắn cờ tài khoản
Dù có đưa vào bao nhiêu dấu thời gian quan sát được trong phần phân tích hậu sự cố đi nữa, nguyên nhân gốc vẫn không được đề cập
Khả năng cao là trong phần “không hợp lý” của câu chuyện có một lời giải thích thực sự mà đến giờ vẫn chưa ai muốn công khai
Google tắt tài khoản mà không báo trước, trong khi lúc đó chúng tôi chi khoảng 10.000 USD mỗi tháng
Ngay cả tài khoản hỗ trợ cao cấp cũng bị khóa, nên chúng tôi còn không thể báo cho đội hỗ trợ rằng “chúng tôi đang bị khóa”
Khoảng 8 giờ sau, một kỹ sư hỗ trợ Google ngẫu nhiên nói rằng lý do là vì chúng tôi đào Bitcoin, điều này hoàn toàn vô lý
Chúng tôi có biểu đồ sử dụng CPU và log của toàn bộ khoảng thời gian đó, và không hề có đột biến nào
Khoảng 12 giờ sau họ bật lại và nói đó là “lỗi cấu hình phát hiện lạm dụng”, đồng thời cho khoảng 100 USD tín dụng
Dù có chê AWS thế nào đi nữa, nếu là AWS thì họ đã không làm chuyện này với khách hàng mà không có người phụ trách liên hệ trước
Từ đó về sau tôi không còn tin GCP
Hệ thống tự động có thể mắc lỗi, nhưng vấn đề lớn hơn là nó hoàn toàn thiếu minh bạch
Rất có thể ngay cả Google cũng không biết chính xác hệ thống đó hoạt động như thế nào
Nếu ý là Railway nên dồn sức vào việc này thay vì rời GCP, thì trừ khi họ định kiện GCP để đòi lại thiệt hại về thương hiệu và giữ chân khách hàng dài hạn, tôi không hiểu vì sao họ phải làm vậy
Ngay khoảnh khắc GCP tắt mà không hề cảnh báo trước thì coi như chuyện đã xong, tôi không nghĩ cần hỏi thêm nữa
Có vẻ Railway có hình ảnh không tốt lắm trên báo chí công nghệ trong tháng này
Ở cả hai trường hợp, danh tiếng đều bị tổn hại do quy trình tự động hóa từ phía bên kia
Ban đầu tôi định nói với người phụ trách Google về vụ giết chết Gemini CLI, nhưng vụ này còn đáng lo hơn nhiều
Chỉ có họ là người đưa thông tin xác thực tài khoản quản trị cho AI
Và họ cũng không chịu trách nhiệm cá nhân, điều đó rõ ràng đã làm hỏng danh tiếng
Lần này ít nhất họ cũng thừa nhận trách nhiệm ở một mức độ nào đó, nên tôi công nhận đây là một sự cải thiện
Ngoài ra, vấn đề độ ổn định của GCP và hỗ trợ khách hàng của Google thật sự rất nghiêm trọng
Sửa: ở dưới tôi mới biết hai đoạn đầu đã bị gán nhầm, và đó là chuyện của khách hàng Railway chứ không phải Railway. Xin lỗi nhé, Railway!
Công ty chúng tôi trước đây từng dùng một nhà cung cấp hosting kiểu thêm vài đảm bảo bổ sung lên trên AWS
Giờ AWS đã trực tiếp cung cấp các tính năng cần thiết, nên chúng tôi đã hoàn tất việc di chuyển sang AWS thuần
Đáng tiếc là vì chuyện này mà hôm qua tôi đã phải di chuyển khẩn cấp sang Azure
May là chúng tôi không đặt cơ sở dữ liệu trên Railway nên đã khôi phục được trong vài giờ
Sự đơn giản mà Railway mang lại thật sự rất tuyệt, nhưng đã có quá nhiều sự cố và giới hạn để tiếp tục chạy ứng dụng B2B enterprise của chúng tôi trên hạ tầng đó
Một ngày buồn :(
Tôi không quá quen dịch vụ này, nên không rõ là vì một tính năng độc đáo nào đó hay thực chất chỉ dùng như máy ảo?
Nếu là vì tính năng độc đáo thì tôi cũng muốn biết việc di chuyển ra khỏi đó khó đến mức nào
Với các công cụ SaaS nhỏ hoặc sản phẩm nội bộ, nếu một đội không muốn tự quản lý AWS hay nhà cung cấp IaaS khác, thì đâu là lựa chọn thay thế tốt?
Ngay cả khi dùng thứ như AWS, nếu bạn không cấu hình dự phòng qua nhiều availability zone thì thỉnh thoảng vẫn sẽ có downtime
Dù có cấu hình dự phòng qua nhiều availability zone, AWS cũng không có kiến trúc cách ly hoàn toàn nên một số dịch vụ vẫn có thể lỗi và vẫn có thể có downtime
Vậy nên cứ chấp nhận downtime và dùng công cụ phù hợp nhất với mình. Trừ những trường hợp tệ hại ở mức GitHub
Nếu hoàn toàn không thể chấp nhận downtime, thì bạn sẽ cần hàng triệu USD và nhiều tháng làm việc để có được mức độ tin cậy đủ để kỳ vọng không có downtime
Cỡ Chaos Monkey của Netflix và hạ tầng của họ thì mới đủ
Ít nhất cần hai nhà cung cấp có đầy đủ năng lực vận hành
Không cần tính phí theo mức sử dụng mà vẫn có thể đi được khá xa
Các nhà cung cấp cloud lớn đưa ra dịch vụ chỉ khó hơn chút ít so với những gì Railway làm, và khi nhu cầu tăng lên thì có thể mở rộng sang các tính năng cao cấp hơn
Không cần thêm một bên thứ ba kiểm soát tính năng, bảo mật và khả dụng
Ví dụ, theo dòng thời gian này thì GCP đã phản hồi trong vòng 7 phút
Nếu dùng Cloud Run, downtime đã có thể ngắn hơn hơn 7 giờ, và nếu trigger không rõ nguồn gốc đó liên quan đến hoạt động của khách hàng khác hoặc hành vi bất thường của Railway thì có lẽ ngay từ đầu đã không bị sập
Cũng có yếu tố phức tạp
Phần lớn hạ tầng phức tạp mà Railway nói họ phải sửa có lẽ đã không cần thiết nếu chỉ dùng tài khoản riêng của mình
Đoạn code đó chắc chắn làm việc hữu ích, nhưng với nhà cung cấp hosting thì có rất nhiều bộ phận chuyển động cần thiết, còn với người dùng thông thường thì không
Sự cố lần này đã quật ngã tất cả cùng lúc, nhưng người dùng AWS riêng lẻ hay bare metal riêng lẻ vốn dĩ đã không bị ảnh hưởng
Không có một lời giải tối ưu chung cho tất cả, nhưng các lập trình viên có xu hướng đánh giá thấp đáng kể chi phí trực tiếp và chi phí vô hình của việc làm trong môi trường của người khác so với lượng thời gian tiết kiệm được nhờ bớt đi vài bước triển khai
“19 tháng 5, 22:10 UTC - hệ thống giám sát tự động phát hiện lỗi kiểm tra tình trạng API, gọi người trực on-call và những người phụ trách bắt đầu điều tra”
“19 tháng 5, 22:20 UTC - Google Cloud nhầm chuyển tài khoản production của Railway sang trạng thái đình chỉ như một phần của hành động tự động”
Nếu dấu thời gian chính xác, thì lỗi 10 phút trước khi tài khoản bị đình chỉ là do điều gì gây ra?
Giải thích đơn giản nhất là một trong hai dấu thời gian bị sai, và bản thân điều đó không phải chuyện lớn
Nhưng nếu còn không chắc về dấu thời gian, thì việc đưa vào báo cáo như thể đã xác nhận dù chúng mâu thuẫn rõ ràng với nhau là khá kỳ lạ
Phần timeline có 22:10 tự nó nhất quán, và còn bao gồm nội dung sau
“19 tháng 5, 22:19 UTC - xác định nguyên nhân gốc: Google Cloud Platform đình chỉ tài khoản production của Railway”
Không thể xác định nguyên nhân gốc trước khi sự việc xảy ra
Ví dụ, một nhân viên Google có thể đã cấu hình sai gì đó, tạo ra tín hiệu khiến việc đình chỉ có vẻ cần thiết như các sự cố trước đây, rồi phải mất 10 phút để đi hết quy trình đình chỉ
Hoặc một khách hàng của Railway đã làm điều gì đó gian lận hoặc trông giống gian lận, và hệ thống Google bắt đầu hạn chế truy cập rồi mất 10 phút để quyết định nâng lên thành đình chỉ
Nếu có người tham gia vào quy trình phê duyệt thì lại càng hợp lý
Chỉ là rõ ràng người đó đã không đào đủ sâu để thấy rằng không nên làm như vậy
Đây nên là lời cảnh báo cho bất kỳ ai đang chạy trên GCP
Có vẻ GCP cứ đình chỉ tài khoản khắp nơi mà chẳng suy nghĩ xem họ đang làm gì
Cứ như thể họ đang giao các quyết định production cho Gemini 3.1 Pro
TK có tiền sử phá hỏng hoàn toàn văn hóa tổ chức như ở OCI, và theo những gì tôi nghe được thì ở GCP cũng tương tự
GCP và Google là những tổ chức làm việc hoàn toàn khác nhau
Đừng nhìn cái tên mà kỳ vọng chất lượng của Google
Nó giống một thương hiệu cũ giờ được dán lên các sản phẩm cấp phép giá rẻ, kiểu như Nokia. Có hơi cường điệu nhưng không xa sự thật
Không chỉ vậy, họ còn nổi tiếng vì ngẫu nhiên khai tử dịch vụ rồi cho khoảng 6 tháng để di chuyển
Họ có nhiều kỹ sư nhàn rỗi nên có thể điều sang kéo người dùng nội bộ ra khỏi dịch vụ đó, nhưng đa số khách hàng thì không làm được vậy
Từng có một bài viết rất hay của một cựu nhân viên GCP, nhưng giờ tôi không tìm lại được
Nếu làm kinh doanh nghiêm túc thì hãy tránh GCP như tránh dịch
Sửa: trớ trêu là Gemini đã tìm lại bài đó cho tôi. Đáng đọc: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
Đủ có tên tuổi để lên đầu trang chủ HN, và ở một thời điểm nào đó có lẽ cũng đủ quy mô để tìm được người ở Google chịu can thiệp
Nếu đó là sản phẩm nhỏ do tôi làm thì hẳn đã không có bất kỳ cách cứu vãn nào
Chất lượng sản phẩm thực tế thì khá tốt, nên lại càng đáng tiếc
Họ lẽ ra có thể dễ dàng là nhà cung cấp số 2, vì Azure thì cực kỳ bất ổn và tài liệu cũng dưới chuẩn
Việc GCP đứng thứ 3 phần lớn là kết quả do chính họ tạo ra
Đánh giá hoàn toàn không có cơ sở của tôi là ông ấy được đưa vào làm vai người lớn có kỷ luật để chấn chỉnh cách tiếp cận enterprise lỏng lẻo của Google
Như sự cố này cho thấy, vẫn còn cả chặng đường dài, nhưng để trở thành một tổ chức enterprise “nghiêm túc” thì có lẽ điều đó là cần thiết
Chỉ có thể trong quá trình đó ông ấy đã tạo ra một nền văn hóa xung đột với phần còn lại của Google
Dù vậy, liệu bộ phận OCI của Oracle có sẵn một nền văn hóa đáng để phá hủy hay không? Ngược lại, có vẻ TK đã mang văn hóa đó vào Google
Tuyệt đối đừng dùng cho việc gì quan trọng
Đây không phải lần đầu Google Cloud làm hỏng nghiêm trọng tài khoản khách hàng: https://cloud.google.com/blog/products/infrastructure/detail...
“Railway chịu trách nhiệm về lựa chọn nhà cung cấp, và cuối cùng lựa chọn này cũng là trách nhiệm của chúng tôi. Khách hàng không quan tâm sự cố là do Google hay do Railway. Điều khách hàng nhìn thấy là sản phẩm của chúng tôi. Uptime của các bạn là trách nhiệm của chúng tôi, và chúng tôi sẽ tiếp tục cung cấp điều đó”
Đáng khen là họ đã thừa nhận điều này chứ không chỉ nói kiểu PR
Việc tin GCP là một thất bại kiến trúc từ phía Railway, và điều này cho thấy họ đang cố sửa nó
Lẽ ra có nên lường trước không? Có. Nhưng muộn còn hơn không
“Cuối cùng, chúng tôi đang lập kế hoạch loại bỏ các dịch vụ Google Cloud khỏi hot path của data plane và chỉ giữ lại cho mục đích dự phòng/failover”
Khá rõ ràng
Google không còn có thể được tin cậy như một nhà cung cấp dịch vụ B2B nữa
Có công ty từng bị ứng dụng OAuth của Meta rơi vào trạng thái hoàn toàn không dùng được chỉ vì tài khoản Facebook cá nhân của một nhân viên lập trình bị Meta khóa mà không rõ lý do
Họ đã escalte nhiều lần nhưng vẫn không đến được đâu cả
Meta còn tệ hơn vì tài khoản phải là “cá nhân”
Dù có Business Manager thì mọi người dùng thêm vào đó vẫn đều bị gắn với tài khoản Meta/Facebook cá nhân
Thật vô lý
Google đã nhiều lần chứng minh rằng không thể tin họ như một nhà cung cấp dịch vụ chính vì những vấn đề như thế này
Vì thế cần phải chia nhỏ họ thành hàng chục mảnh
Thường chỉ sau khi người dùng công khai phẫn nộ và vụ việc lan rộng thì họ mới muộn màng đảo ngược quyết định
Google luôn hành xử như thể họ không có bất kỳ nghĩa vụ nào với khách hàng trả phí
Theo tôi đó mới là phần quan trọng nhất
Nhà cung cấp cloud sẽ không đình chỉ toàn bộ tài khoản mà không có lý do nào cả