Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Chất lượng
  3. /Google Cloud 12/06/2025: kiểm tra hạn ngạch thiế…
Số 152Quản lý Chất lượng

Google Cloud 12/06/2025: kiểm tra hạn ngạch thiếu xử lý lỗi, không có feature flag và dữ liệu trống nhân bản toàn cầu trong vài giây

Một đoạn mã kiểm tra chính sách hạn ngạch thêm vào Service Control ngày 29/05/2025 thiếu xử lý lỗi và không được bảo vệ bởi feature flag. Ngày 12/06, một thay đổi chính sách chứa trường trống nhân bản toàn cầu, làm dịch vụ rơi vào vòng lặp sập ở mọi vùng và trả lỗi 503 cho nhiều sản phẩm. Phân tích về kiểm thử đường mã hiếm, cờ tính năng và triển khai dữ liệu theo giai đoạn.

HP
Nguyễn Thu Hà, PMP
25/09/2026
4 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Ngày 12/06/2025, các yêu cầu API ngoài của Google Cloud, Google Workspace và Google Security Operations trả về lỗi 503. Báo cáo sự cố chính thức của Google nêu chuỗi nguyên nhân như sau:

  • Ngày 29/05/2025, một kiểm tra chính sách hạn ngạch mới được thêm vào Service Control, không có xử lý lỗi phù hợp và không được bảo vệ bằng feature flag.
  • Ngày 12/06, khoảng 10:45 (PDT), một thay đổi chính sách được chèn vào các bảng Spanner vùng có trường trống ngoài ý muốn và được nhân bản toàn cầu trong vài giây.
  • Các kiểm tra hạn ngạch đọc trường trống, gặp con trỏ null chưa được xử lý và rơi vào vòng lặp sập ở mọi vùng.
  • Lỗi không bị phát hiện sớm vì đường mã chỉ chạy khi có một thay đổi chính sách như vậy, mà quá trình triển khai theo từng vùng chưa bao giờ tạo ra thay đổi đó.

Đội SRE bắt đầu xử lý trong 2 phút và xác định nguyên nhân trong 10 phút; một "nút đỏ" (kill switch) vô hiệu hoá đường mã lỗi sẵn sàng sau khoảng 25 phút và triển khai đầy đủ trong khoảng 40 phút. Tuy vậy ở us-central1, việc khởi động lại hàng loạt tác vụ làm quá tải bảng Spanner vì Service Control thiếu cơ chế lùi lại có ngẫu nhiên (randomized exponential backoff); vùng này mất tới khoảng 2 giờ 40 phút để hồi phục, và một số dịch vụ hạ nguồn còn ảnh hưởng đến tối. Trang trạng thái cũng bị ảnh hưởng, và báo cáo đầu tiên đến sau khoảng một giờ.

Google cam kết: module hoá Service Control để kiểm tra lỗi thì "mở" (fail open), triển khai thay đổi dữ liệu nhân bản toàn cầu từng bước có thời gian kiểm chứng, bắt buộc feature flag tắt mặc định cho thay đổi ở nhị phân quan trọng, cải thiện phân tích tĩnh và kiểm thử, rà soát backoff và giữ kênh giám sát, truyền thông hoạt động khi dịch vụ sập.

Phân tích nguyên nhân theo chuẩn PMP

  • Đường mã hiếm không được kiểm thử (Control Quality)

    Đoạn mã chỉ chạy khi có loại thay đổi dữ liệu cụ thể, nên suốt hai tuần lên sản xuất nó không bị kích hoạt. Chiến lược kiểm thử phải bao gồm đầu vào bất thường (trường trống, giá trị biên) cho mọi nhánh, không chỉ đường chạy thường gặp.

  • Thiếu feature flag cho thay đổi ở thành phần lõi (Plan Quality Management)

    Nếu đoạn kiểm tra mới nằm sau một cờ tắt mặc định, nhóm có thể bật dần và quan sát. Chính sách phát hành cần quy định mọi thay đổi ở thành phần quan trọng đều có cờ, và đây là điều Google đưa vào cam kết.

  • Dữ liệu cấu hình được coi là rủi ro thấp hơn mã (Perform Integrated Change Control)

    Triển khai mã đi theo từng vùng, còn dữ liệu chính sách nhân bản toàn cầu tức thì. Dữ liệu cấu hình cũng là thay đổi của hệ thống và cần cùng mức kiểm soát với mã: giai đoạn, kiểm chứng và khả năng dừng.

  • Phục hồi gây quá tải thứ cấp (Plan Risk Responses)

    Thiếu backoff có ngẫu nhiên khiến khởi động lại hàng loạt làm sập bảng dữ liệu. Kế hoạch ứng phó rủi ro cần xét hiệu ứng "bầy đàn" khi hệ thống phục hồi.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Chuẩn hoá chính sách phát hành cho thành phần quan trọng

      Mọi thay đổi vào thành phần nằm trên đường phục vụ chính phải thoả ba điều kiện:

      • Feature flag tắt mặc định

        Bật dần theo vùng hoặc tỷ lệ, có thể tắt tức thì không cần triển khai lại.

      • Xử lý lỗi an toàn

        Đầu vào không hợp lệ dẫn tới hành vi dự phòng (fail open hoặc fail closed có chủ ý), không làm sập tiến trình.

      • Kiểm thử đầu vào bất thường

        Có ca kiểm thử bắt buộc cho trường trống và dữ liệu sai cấu trúc trước khi hợp nhất.

    2. 2

      Bước 2: Triển khai dữ liệu cấu hình theo giai đoạn

      Thay đổi chính sách nhân bản dần qua các vùng với thời gian kiểm chứng giữa các bước, thay vì tức thì toàn cầu.

    3. 3

      Bước 3: Chuẩn bị kill switch và diễn tập

      Duy trì nút tắt nhanh cho đường mã mới, đo thời gian kích hoạt trong diễn tập, như cách đội SRE đã dùng để giảm thiểu trong chưa đến một giờ.

    4. 4

      Bước 4: Thiết kế phục hồi có kiểm soát

      Áp dụng backoff ngẫu nhiên và giới hạn tốc độ tạo tác vụ để việc khởi động lại không đè lên hệ thống phụ thuộc. Giữ kênh truyền thông độc lập với dịch vụ chính.

    PM Takeaway (Bài học rút ra)

    Mã chưa chạy không có nghĩa là mã đã đúng. Hãy bắt buộc feature flag, kiểm thử đầu vào bất thường và coi dữ liệu cấu hình là thay đổi cần phát hành theo giai đoạn như mã.

    Nguồn tham khảo

    • Google Cloud incident report: multiple products, 12 June 2025
    #Quản lý chất lượng#Google Cloud#Feature flag#Kill switch#Triển khai dữ liệu#SRE

    Nguồn: Google Cloud incident report: multiple products, 12 June 2025 ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Một đoạn mã mới ở thành phần lõi đã nằm trên sản xuất hai tuần mà chưa bị kích hoạt, rồi sập khi gặp dữ liệu hiếm. Biện pháp phòng ngừa nào bao quát nhất?

    Bạn chọn phương án nào?

    Thay đổi cấu hình có thể ảnh hưởng toàn cầu nên được phát hành theo cách nào?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Chất lượng

    Cloudflare 02/07/2019: một quy tắc WAF được đẩy toàn cầu trong vài giây, không qua canary, làm CPU toàn mạng kịch trần

    Ngày 02/07/2019, một thay đổi nhỏ trong bộ quy tắc WAF của Cloudflare chứa biểu thức chính quy gây backtracking khủng khiếp, khiến CPU của mọi máy xử lý HTTP/HTTPS trên toàn cầu gần như 100% và khách hàng nhận lỗi 502 khoảng 27 phút. Bài học về kiểm thử hiệu năng trong CI, quy trình triển khai theo giai đoạn và việc "ngoại lệ khẩn cấp" trở thành đường tắt mặc định.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Số 149Quản lý Chất lượng

    Facebook ngoại tuyến 04/10/2021: một lệnh bảo trì, công cụ kiểm tra có lỗi và hệ thống khôi phục phụ thuộc chính mạng đã sập

    Ngày 04/10/2021, một lệnh bảo trì định đánh giá dung lượng mạng xương sống đã ngắt toàn bộ kết nối giữa các trung tâm dữ liệu của Facebook; công cụ kiểm tra lệnh có lỗi nên không chặn được. DNS biến mất khỏi Internet, công cụ nội bộ hỏng theo và kỹ sư phải đến tận nơi. Phân tích dưới góc nhìn kiểm soát thay đổi, kiểm thử tình huống thảm hoạ và phụ thuộc vòng của công cụ khôi phục.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận11/10/2026
    Số 150Quản lý Chất lượng

    Amazon S3 ngày 28/02/2017: một tham số nhập sai trong lệnh gỡ máy chủ làm gián đoạn dịch vụ lưu trữ khoảng 4 giờ 17 phút

    Trong lúc điều tra hệ thống tính phí S3 chạy chậm, một thành viên được ủy quyền chạy lệnh trong playbook nhưng nhập sai một tham số, gỡ ra nhiều máy chủ hơn dự định ở vùng US-EAST-1. AWS sau đó sửa công cụ để gỡ chậm hơn, chặn việc đưa hệ thống xuống dưới dung lượng tối thiểu và rà soát các công cụ khác. Bài học về thiết kế công cụ vận hành chống lỗi người.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận06/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)