Ngày 22/10/2026, Google công bố báo cáo sơ bộ về vụ Google Cloud London sập hơn 6 giờ vào ngày 20/10. Nguyên nhân không phải lỗi phần mềm hay tấn công mạng. Theo Google, trung tâm dữ liệu bị mất điện lưới, và hệ thống tự động đã không khởi động được máy phát diesel dự phòng. Sự cố ở một zone sau đó lan ra cả vùng europe-west2, ảnh hưởng hơn 40 dịch vụ.

Vụ việc là lời nhắc rằng ngay cả nhà cung cấp đám mây lớn nhất cũng có thể gặp lỗi ở tầng hạ tầng vật lý cơ bản nhất: điện.

Diễn biến sự cố Google Cloud London

Theo trang Service Health của Google Cloud, các mốc chính như sau (quy đổi sang giờ Việt Nam):

Thời điểm (giờ Việt Nam)Sự kiện
12:53 ngày 20/10Trung tâm dữ liệu chứa zone europe-west2-b bị mất điện lưới
13:00 ngày 20/10Sự cố chính thức bắt đầu
13:08 ngày 20/10Hệ thống giám sát tự động cảnh báo kỹ sư Google
18:46 ngày 20/10Compute Engine cho tạo máy ảo mới trở lại
19:10 ngày 20/10Phần lớn tải đã phục hồi, hơn 99% máy ảo hoạt động bình thường
15:42 ngày 22/10Google đăng báo cáo sơ bộ

Tổng thời gian sự cố là 6 giờ 10 phút. Một số khách hàng Compute Engine phục hồi chậm hơn và được Google đề nghị mở yêu cầu hỗ trợ nếu máy ảo vẫn lỗi.

The Register dẫn dữ liệu Down Detector cho biết người dùng của Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix và Revolut đã báo lỗi trong thời gian này. Đây là dữ liệu từ người dùng báo cáo, Google không xác nhận danh sách khách hàng bị ảnh hưởng.

Nguyên nhân: máy phát diesel không khởi động

Báo cáo sơ bộ mô tả chuỗi lỗi như sau:

  1. Điện lưới cấp cho trung tâm dữ liệu chứa zone europe-west2-b bị gián đoạn.
  2. Toàn bộ tải chuyển sang dàn ắc quy UPS, đúng như thiết kế.
  3. Hệ thống tự động hóa PLC, cả bộ chính lẫn bộ dự phòng, đều không khởi động được máy phát diesel khẩn cấp. Máy phát không nhận tải.
  4. Khi ắc quy cạn, máy chủ, thiết bị mạng và hệ thống lưu trữ trong zone mất điện hoàn toàn.

Kỹ sư tại chỗ đã khôi phục điện lưới ổn định trong khoảng một giờ, sau đó đặt lại và kiểm tra bộ điều khiển máy phát. Google khởi động lại hạ tầng theo từng giai đoạn và chỉ cho lưu lượng quay lại zone sau khi kiểm tra sức khỏe hệ thống và tính toàn vẹn của dữ liệu lưu trữ.

Vì sao một zone sập kéo theo cả vùng

Vùng europe-west2 có ba zone: a, b và c. Về lý thuyết, mất một zone thì hai zone còn lại vẫn gánh được. Nhưng theo Google, lưu lượng chuyển sang và các yêu cầu thử lại (retry) đã làm quá tải dung lượng ở hai zone còn lại. Các lệnh gọi liên zone của tầng điều khiển (control plane) tới zone b bị treo, gây hàng đợi, chuyển đổi cơ sở dữ liệu chậm và lỗi HTTP 500, 503 ngắt quãng.

Để xử lý, Google cô lập zone b bằng cách định tuyến lưu lượng của cả vùng tránh khỏi zone này. Google cũng điều chỉnh lại bộ lập lịch và giới hạn dung lượng, ưu tiên các reservation đang chạy của khách hàng.

Dịch vụ bị ảnh hưởng

Danh sách của Google gồm hơn 40 dịch vụ. Những dịch vụ phổ biến với người làm web gồm:

  • Compute Engine, Persistent Disk, Google Kubernetes Engine
  • Cloud Run, App Engine, Cloud Load Balancing, Cloud NAT
  • Cloud SQL, AlloyDB for PostgreSQL, Cloud Spanner, Firestore
  • Cloud Storage, Filestore, Memorystore (Redis, Valkey, Memcached)
  • BigQuery, Pub/Sub, Dataflow, Cloud Composer

Google chưa công bố biện pháp phòng ngừa cụ thể. Báo cáo cuối cùng sẽ được đăng sau khi phân tích nguyên nhân gốc hoàn tất.

Bài học cho chủ website và người thuê VPS

Sự cố không ảnh hưởng trực tiếp tới hệ thống đặt tại Việt Nam hay châu Á. Tuy nhiên, chuỗi lỗi này có thể xảy ra ở bất kỳ trung tâm dữ liệu nào. Vài điểm đáng rút ra:

  • Nhiều zone chưa chắc đủ. Kiến trúc đa zone trong cùng một vùng vẫn có thể sập theo nếu tầng điều khiển và dung lượng dự phòng không chịu nổi lượng tải dồn sang. Với hệ thống quan trọng, cân nhắc phương án dự phòng ở vùng khác.
  • Sao lưu ra ngoài nhà cung cấp. Giữ một bản sao lưu ở nhà cung cấp hoặc vùng địa lý khác, để có thể dựng lại dịch vụ nếu nơi đang chạy gặp sự cố kéo dài.
  • Kiểm soát retry. Ứng dụng nên dùng giới hạn thử lại và độ trễ tăng dần (exponential backoff). Retry ồ ạt là một trong các yếu tố làm sự cố lan rộng.
  • Hỏi nhà cung cấp về nguồn điện. Khi chọn hosting hay VPS, nên hỏi trung tâm dữ liệu có UPS, máy phát, được kiểm tra định kỳ ra sao và cam kết SLA thế nào.
  • Theo dõi trang trạng thái. Đăng ký nhận thông báo từ trang status của nhà cung cấp để biết sớm khi có sự cố.

Nếu bạn đang chạy dịch vụ trên Google Cloud vùng London, hãy kiểm tra lại máy ảo, ổ đĩa và cơ sở dữ liệu, và theo dõi báo cáo cuối cùng của Google để biết các thay đổi về hạ tầng điện.

Nguồn tham khảo