Báo cáo sự cố Google Cloud – 2025-06-13
(status.cloud.google.com)- Vào ngày 12 tháng 6 năm 2025, số lượng lỗi 503 trên các yêu cầu API bên ngoài tăng vọt trong Google Cloud, Google Workspace và Google Security Operations, ảnh hưởng đến khách hàng trên toàn thế giới
- Một kiểm tra chính sách quota mới trong Service Control khi gặp dữ liệu chính sách có trường trống đã gây ra vòng lặp crash do null pointer, và đường thực thi này đã không chạy trong quá trình rollout
- Khi thay đổi chính sách được sao chép từ bảng Spanner theo vùng ra toàn cầu chỉ trong vài giây, các deployment Service Control ở từng vùng cùng đi vào đường lỗi giống nhau, lan thành sự cố toàn cầu
- Đội SRE bắt đầu ứng phó trong vòng 2 phút, xác định nguyên nhân trong 10 phút và hoàn tất rollout red-button trong khoảng 40 phút, nhưng us-central1 mất tới khoảng 2 giờ 40 phút để khôi phục
- Các biện pháp ngăn tái diễn tập trung vào việc đóng băng thay đổi Service Control, mặc định tắt feature flag, truyền dần dữ liệu sao chép toàn cầu, và cải thiện xử lý lỗi cùng exponential backoff ngẫu nhiên
Phạm vi sự cố và mốc thời gian
- Số lượng lỗi 503 trên các yêu cầu API bên ngoài tăng lên trong các sản phẩm Google Cloud, Google Workspace và Google Security Operations, ảnh hưởng đến khách hàng
- Tất cả mốc thời gian chính đều theo múi giờ US/Pacific
- Bắt đầu sự cố: 10:49 ngày 12 tháng 6 năm 2025
- Giảm thiểu ở tất cả vùng ngoại trừ us-central1: 12:48
- Kết thúc sự cố: 13:49
- Tổng thời lượng: 3 giờ
- Phạm vi ảnh hưởng: Toàn cầu
- Khách hàng gặp sự cố truy cập API và giao diện người dùng gián đoạn ở các dịch vụ bị ảnh hưởng
- Các luồng streaming hiện có và tài nguyên IaaS không bị ảnh hưởng
Đường kiểm tra do Service Control đảm nhiệm
- API của Google và Google Cloud được cung cấp thông qua mặt phẳng quản lý và điều khiển Google API
- Mặt phẳng quản lý và điều khiển này xác minh các nội dung sau cho từng yêu cầu API
- Yêu cầu có được cấp quyền hay không
- Yêu cầu có vượt qua các kiểm tra như chính sách và quota để có thể đi tới endpoint hay không
- Binary cốt lõi của hệ thống kiểm tra chính sách là Service Control
- Service Control là một dịch vụ theo từng vùng, sử dụng datastore theo vùng để đọc thông tin quota và chính sách
- Metadata của datastore này được sao chép gần như ngay lập tức trên toàn cầu để quản lý quota policy cho Google Cloud và khách hàng
Nguyên nhân trực tiếp: trường chính sách trống và null pointer
- Ngày 29 tháng 5 năm 2025, một tính năng mới phục vụ kiểm tra quota policy bổ sung đã được thêm vào Service Control
- Thay đổi mã và bản phát hành binary đã được rollout theo từng vùng, nhưng đường mã lỗi chỉ chạy khi có một thay đổi chính sách cụ thể nên đã không được xác minh trong quá trình rollout
- Mã có vấn đề có red-button để tắt đường cung cấp chính sách đó, nhưng thiếu xử lý lỗi phù hợp và không có bảo vệ bằng feature flag
- Null pointer không được xử lý đúng cách, dẫn đến binary Service Control bị crash
- Google cho biết nếu được bảo vệ bằng feature flag, vấn đề đã có thể được phát hiện ở staging khi kích hoạt dần theo từng vùng, bắt đầu từ các dự án nội bộ
Quá trình lan rộng trên toàn cầu
- Khoảng 10:45 PDT ngày 12 tháng 6 năm 2025, một thay đổi chính sách được chèn vào bảng Spanner theo vùng mà Service Control dùng cho chính sách
- Dữ liệu chính sách này có chứa một trường trống ngoài ý muốn
- Vì quản lý quota hoạt động ở phạm vi toàn cầu, metadata đó đã được sao chép ra toàn thế giới chỉ trong vài giây
- Khi Service Control ở mỗi vùng thực hiện kiểm tra quota với chính sách trong datastore theo vùng, nó đọc phải trường trống và kích hoạt đường mã gặp null pointer
- Kết quả là binary ở deployment của từng vùng rơi vào vòng lặp crash
Ứng phó và độ trễ khôi phục
- Đội SRE bắt đầu phân loại và ứng phó trong vòng 2 phút sau khi sự cố bắt đầu
- Trong vòng 10 phút, họ xác định được nguyên nhân gốc và bắt đầu áp dụng red-button
- Red-button đã sẵn sàng để rollout khoảng 25 phút sau khi sự cố bắt đầu
- Trong vòng 40 phút sau khi sự cố bắt đầu, rollout red-button đã hoàn tất và các vùng nhỏ bắt đầu có tín hiệu khôi phục
- Ở các vùng lớn như us-central1, khi các tác vụ Service Control khởi động lại, chúng tạo ra herd effect lên hạ tầng phụ thuộc, đặc biệt là các bảng Spanner, gây quá tải
- Service Control không triển khai đầy đủ cơ chế exponential backoff ngẫu nhiên phù hợp để tránh điều này
- us-central1 đã giảm tải bằng cách throttling việc tạo tác vụ và định tuyến lưu lượng sang multi-regional database, nhưng vẫn mất tới khoảng 2 giờ 40 phút để giải quyết hoàn toàn
- Sau đó, Service Control và API serving đã được khôi phục hoàn toàn ở mọi vùng
- Các sản phẩm Google và Google Cloud liên quan được khôi phục tuần tự và với tốc độ khác nhau tùy kiến trúc
Trang trạng thái và liên lạc với khách hàng
- Báo cáo sự cố đầu tiên trên Cloud Service Health được đăng khoảng 1 giờ sau khi crash bắt đầu
- Nguyên nhân chậm trễ là vì chính hạ tầng Cloud Service Health cũng bị sự cố này làm ngừng hoạt động
- Một số khách hàng cũng mất hạ tầng giám sát đang chạy trên Google Cloud nên không thể xác định tín hiệu sự cố hoặc phạm vi ảnh hưởng tới kinh doanh và hạ tầng
- Google cho biết sẽ cải thiện cả liên lạc tự động lẫn thủ công ra bên ngoài để khách hàng nhận được nhanh hơn những thông tin cần thiết nhằm ứng phó sự cố, quản lý hệ thống và hỗ trợ khách hàng của họ
- Google cho biết sẽ bảo đảm hạ tầng giám sát và liên lạc vẫn tiếp tục phục vụ khách hàng ngay cả khi Google Cloud và các sản phẩm giám sát cốt lõi bị gián đoạn
Hành động tức thời và kế hoạch ngăn tái diễn
- Ngay sau khi khôi phục, mọi thay đổi với stack Service Control và mọi đợt đẩy chính sách thủ công đều bị đóng băng
- Google cho biết sẽ ưu tiên và hoàn thành an toàn các biện pháp sau
- Mô-đun hóa kiến trúc Service Control để cô lập chức năng, và chuyển sang cấu trúc fail open để vẫn có thể tiếp tục xử lý yêu cầu API ngay cả khi các kiểm tra liên quan thất bại
- Kiểm tra toàn bộ các hệ thống đang tiêu thụ dữ liệu sao chép toàn cầu
- Ngay cả khi có nhu cầu kinh doanh đòi hỏi tính nhất quán gần như tức thời trên toàn cầu, việc sao chép dữ liệu vẫn sẽ được truyền dần để có đủ thời gian xác minh và phát hiện vấn đề
- Tất cả thay đổi đối với các binary quan trọng sẽ được bảo vệ bằng feature flag và mặc định tắt
- Cải thiện phân tích tĩnh và quy trình kiểm thử để xử lý lỗi đúng cách và có thể fail open khi cần
- Kiểm tra và bảo đảm hệ thống sử dụng exponential backoff ngẫu nhiên
- Cải thiện liên lạc với khách hàng
- Duy trì vận hành hạ tầng giám sát và liên lạc ngay cả trong thời gian Google Cloud và các sản phẩm giám sát cốt lõi gặp sự cố
Các dịch vụ bị ảnh hưởng và tác động còn lại
- Nhiều sản phẩm Google Cloud bị ảnh hưởng, bao gồm Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk và Google Security Operations
- Trong các sản phẩm Google Workspace, AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search và Google Tasks cũng bị ảnh hưởng
- Một số sản phẩm vẫn còn tác động tồn dư sau khi sự cố chính đã được giảm thiểu
- Google Cloud Dataflow dần giải quyết backlog, nhưng vẫn còn độ trễ ở us-central1
- Vertex AI Online Prediction tiếp tục gặp tỷ lệ lỗi 5xx cao với một số mô hình trong Model Garden, và sau đó mới khôi phục hoàn toàn vào 18:18 PDT
- Personalized Service Health bị chậm cập nhật, và khách hàng được khuyến nghị sử dụng bảng điều khiển Cloud Service Health
1 bình luận
Đây là liên kết đến bài viết phiên bản không phải GN+.