Ngày 12/6/2025, hàng trăm dịch vụ của Google Cloud và Google Workspace đồng loạt trả lỗi. Compute Engine, Cloud Storage, BigQuery, Gmail đều bị ảnh hưởng.
Tác động lan cả sang những dịch vụ bên ngoài xây trên nền tảng này. Lúc cao điểm, Downdetector nhận khoảng 46.000 lượt báo về Spotify và 11.000 về Discord — hai cái tên chẳng liên quan gì tới Google trong mắt người dùng.
Google sau đó công bố bản phân tích và chỉ đích danh một thành phần: Service Control, hệ thống chịu trách nhiệm cấp phép cho các lệnh gọi API.
Đoạn mã nằm im hai tuần
Câu chuyện bắt đầu ngày 29/5/2025. Hôm đó Google phát hành một đoạn mã bổ sung phần kiểm tra chính sách hạn ngạch. Đoạn mã được đưa lên nhưng nằm im, vì chưa có dữ liệu nào kích hoạt nó.
Nó ở đó suốt hai tuần mà không ai biết là nó có vấn đề. Đoạn mã ấy thiếu một bước kiểm tra giá trị rỗng.
Có một chi tiết trong bản phân tích đắt hơn cả lỗi kỹ thuật. Đoạn mã mới được bật ở trạng thái hoạt động trên mọi vùng cùng lúc, không có cờ để bật tắt dần. Không có cách nào thả nó ra từng phần, cũng không có cách nào tắt đi mà không phát hành lại.
Con trỏ rỗng và vòng lặp sập
10 giờ 49 sáng ngày 12/6 giờ Thái Bình Dương, một bản dữ liệu hạn ngạch chứa các trường rỗng được triển khai.
Đoạn mã nằm im hai tuần bấy giờ mới chạm vào nó, và gặp lỗi truy cập con trỏ rỗng. Lỗi cơ bản, nhưng hậu quả nặng vì nó nằm trên đường đi bắt buộc của mọi yêu cầu.
Các tiến trình Service Control sập theo vòng lặp: khởi động lên, đọc dữ liệu sai, sập tiếp. Dữ liệu xấu lan khắp các vùng qua cơ chế nhân bản toàn cầu — chính thứ vốn để bảo đảm mọi nơi thấy cùng một cấu hình.
Tốc độ phát hiện không phải vấn đề. Đội trực bắt đầu xử lý lúc 10 giờ 53, tức bốn phút sau. Tới khoảng 11 giờ 03 đã khoanh được nguyên nhân về đúng thành phần. Một công tắc chặn toàn cầu được đẩy đi lúc 11 giờ 30.
Nhưng lưu lượng API chỉ ổn định trở lại lúc 13 giờ 49. Hai tiếng mười chín phút sau khi bản sửa đã ở đúng chỗ.
Vì sao sửa xong rồi mà vẫn chưa hết
Khoảng cách giữa 11 giờ 30 và 13 giờ 49 là phần đáng học nhất của vụ này.
Riêng vùng us-central1 mất nhiều thời gian hơn hẳn, vì hạ tầng ở đó bị đè bởi lượng lớn yêu cầu thử lại. Hàng triệu máy khách cùng gọi lại một lúc, ngay khi dịch vụ vừa nhúc nhích trở lại.
Khi một hệ thống lớn khôi phục, chính lưu lượng thử lại trở thành đợt tấn công vào nó. Vì vậy các nhà cung cấp thường mở lại từng phần thay vì bật hết cùng lúc. Và vì vậy phần khôi phục thường lâu hơn phần sửa lỗi.
Không chạy máy chủ ở đó vẫn bị ảnh hưởng
Phần lớn công ty trong nước không chạy máy chủ trên Google Cloud. Nhưng họ dùng Gmail, Google Drive và Google Workspace hằng ngày. Khi lớp cấp phép hỏng, những dịch vụ này không truy cập được.
Các phần mềm doanh nghiệp có tích hợp đăng nhập bằng tài khoản Google cũng dừng theo. Chuỗi phụ thuộc đó ít ai vẽ ra trên giấy — cho tới hôm nó gãy.
Có một điểm đáng chú ý cho đội phát triển trong nước. Nếu ứng dụng tự động thử lại khi gặp lỗi mà không có độ trễ tăng dần, bạn đang góp phần làm sự cố kéo dài. Và làm hoá đơn của chính mình tăng lên. Cơ chế thử lại có chờ tăng dần kèm chút ngẫu nhiên có sẵn trong mọi thư viện gọi API. Viết một lần rồi dùng mãi.
Điểm cuối cùng đáng rút ra từ vụ này là sự bất đối xứng. Google phát hiện lỗi trong bốn phút, nhưng gỡ dữ liệu sai ra khỏi toàn hệ thống mất ba tiếng. Cấu hình đẩy đi thì nhanh, thu về thì chậm — và mọi hệ thống phân phối cấu hình tự động đều mang sẵn đặc tính đó.
