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. /Cloudflare 02/07/2019: một quy tắc WAF được đẩy …
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.

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

Bối cảnh thực tế

Cloudflare vận hành mạng biên phân phối nội dung và bảo mật cho một phần rất lớn lưu lượng web. Một trong các sản phẩm là WAF (tường lửa ứng dụng web) với bộ quy tắc được cập nhật liên tục để đối phó lỗ hổng mới. Ngày 02/07/2019, một kỹ sư hợp nhất một thay đổi nhỏ về phát hiện XSS vào bộ quy tắc này.

Theo bài post-mortem chính thức của Cloudflare:

  • 13:31 (UTC) thay đổi được hợp nhất; 13:37 bộ kiểm thử tự động (CI) báo đạt; 13:42 hệ thống TeamCity bắt đầu triển khai.
  • Một biểu thức chính quy trong quy tắc mới có hiện tượng backtracking quá mức, làm CPU của các máy xử lý HTTP/HTTPS trên toàn mạng gần như chạm 100%. Khách hàng thấy lỗi 502.
  • Quy tắc vốn được định chạy ở chế độ "mô phỏng" (không chặn gì), nhưng biểu thức vẫn được thực thi nên vẫn đốt CPU.
  • Quy trình vận hành chuẩn của WAF cho phép đẩy toàn cầu không qua giai đoạn (khác với phần mềm thông thường phải đi qua dogfood, thí điểm, canary), vì đội cần phản ứng nhanh trước đe doạ. Thay đổi lan ra toàn thế giới chỉ trong vài giây qua kho khoá–giá trị Quicksilver.

Đội kỹ sư dùng cơ chế "global terminate" để tắt WAF trên toàn cầu lúc 14:07; CPU trở lại bình thường khoảng 14:09. Việc truy cập công cụ nội bộ bị chậm vì chính Cloudflare Access cũng bị ảnh hưởng. WAF được bật lại toàn cầu lúc 14:52, sau khi thử nghiệm sửa lỗi ở một thành phố với lưu lượng khách trả phí được chuyển đi. Cloudflare cũng nêu rõ nhiều yếu tố góp phần, trong đó có một biện pháp bảo vệ chống dùng CPU quá mức bị vô tình gỡ trong lần tái cấu trúc trước đó, và bộ kiểm thử không đo mức dùng CPU.

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

  • Kế hoạch quản lý chất lượng (Plan Quality Management) bỏ trống tiêu chí hiệu năng

    Bộ kiểm thử CI đạt nhưng không đo mức tiêu thụ CPU của quy tắc. Chỉ số chất lượng (quality metric) quan trọng nhất của một bộ lọc đứng trước mọi yêu cầu là chi phí xử lý mỗi yêu cầu, thế mà nó không nằm trong tiêu chí chấp nhận. "Qua CI" chỉ có nghĩa nếu CI đo đúng thứ có thể làm hỏng sản xuất.

Đường tắt "khẩn cấp" trở thành quy trình mặc định (Manage Quality)

Việc đẩy toàn cầu không qua giai đoạn hợp lý khi đang có cuộc tấn công, nhưng SOP áp dụng nó cho cả những cập nhật thường nhật. Khi mọi thay đổi dùng chung một đường nhanh, rủi ro của tình huống hiếm (cần tốc độ) bị áp lên tình huống phổ biến (cập nhật thường).

  • Mất hàng rào bảo vệ qua tái cấu trúc, không có kiểm soát thay đổi rủi ro

    Biện pháp chống dùng CPU quá mức bị gỡ trong một lần refactor mà không ai đánh giá tác động tới an toàn. Đây là thất bại của kiểm soát thay đổi tích hợp (Perform Integrated Change Control): thay đổi "dọn mã" cũng có thể xoá một lớp phòng thủ.

  • Phát hiện và khôi phục chậm hơn cần thiết (Monitor Risks)

    Cảnh báo ban đầu đến muộn, công cụ nội bộ cùng bị ảnh hưởng, còn quy trình rollback chuẩn đòi hỏi chạy toàn bộ bản dựng WAF hai lần. Kế hoạch ứng phó rủi ro chưa tính tới kịch bản "công cụ khôi phục phụ thuộc chính hệ thống đang hỏng".

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

    1. 1

      Bước 1: Đưa hiệu năng vào cổng chất lượng của CI/CD

      Định nghĩa "xong" cho một thay đổi quy tắc phải gồm ngưỡng tài nguyên:

      • Hồ sơ hiệu năng

        Mỗi quy tắc được chạy trên bộ lưu lượng mẫu và đo CPU/độ trễ; vượt ngưỡng thì CI đỏ.

      • Phát hiện sớm

        Cảnh báo CPU toàn mạng và tỷ lệ lỗi 5xx được hiệu chỉnh để kêu trong vài phút đầu, không chờ khách báo.

      • Dừng tự động

        Triển khai tự dừng và hoàn tác khi chỉ số vượt ngưỡng ở nhóm canary.

    2. 2

      Bước 2: Tách hai đường triển khai: thường nhật và khẩn cấp

      Mặc định mọi thay đổi đi theo giai đoạn (nội bộ → một ít điểm hiện diện → toàn cầu). Đường khẩn cấp vẫn tồn tại nhưng cần điều kiện kích hoạt rõ và có người phê duyệt, đúng hướng Cloudflare đã cam kết sau sự cố.

    3. 3

      Bước 3: Bảo vệ hàng rào an toàn bằng kiểm thử và rà soát thay đổi

      Các cơ chế bảo vệ (giới hạn CPU, bộ ngắt mạch) cần có kiểm thử riêng chứng minh chúng còn hoạt động; mọi thay đổi chạm vào chúng đi qua rà soát bắt buộc.

    4. 4

      Bước 4: Diễn tập khôi phục khi công cụ nội bộ cũng hỏng

      Chuẩn bị đường vào dự phòng cho công cụ vận hành và một nút "tắt thành phần toàn cầu" nhanh, rồi diễn tập định kỳ. Sau sự cố, viết post-mortem không đổ lỗi cá nhân, tập trung vào hệ thống như bài viết của Cloudflare.

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

    Tốc độ và an toàn không đối nghịch khi đường nhanh có hàng rào riêng. Quản lý chất lượng không dừng ở "CI xanh": hãy hỏi CI có đo đúng thứ có thể làm sập sản xuất không, và đừng để ngoại lệ khẩn cấp trở thành quy trình mặc định.

    Nguồn tham khảo

    • Details of the Cloudflare outage on July 2, 2019
    #Quản lý chất lượng#Cloudflare#CI/CD#Triển khai theo giai đoạn#Post-mortem#WAF

    Nguồn: Details of the Cloudflare outage on July 2, 2019 (Cloudflare Blog) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Đội của bạn quản lý một bộ lọc nằm trước toàn bộ lưu lượng khách hàng. Sau sự cố một thay đổi cấu hình lan toàn cầu làm quá tải CPU, ban lãnh đạo hỏi cách ngăn tái diễn mà vẫn giữ khả năng phản ứng nhanh khi có tấn công. Đề xuất nào hợp lý nhất?

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

    Với bộ lọc nằm trước mọi yêu cầu của khách hàng, bạn muốn quy tắc mới đượ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

    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
    Số 151Quản lý Chất lượng

    Atlassian tháng 4/2022: script xoá nhầm 883 site của 775 khách hàng và khoảng 14 ngày để khôi phục

    Khi gỡ một ứng dụng cũ, đội Atlassian nhận danh sách ID site thay vì ID ứng dụng; API xoá chấp nhận cả hai loại mà không cảnh báo nên 883 site bị xoá. Dữ liệu sao lưu còn nhưng chưa có runbook hay tự động hoá khôi phục hàng trăm site cùng lúc, khiến một số khách hàng gián đoạn tới 14 ngày. Bài học về xoá mềm, kiểm thử với dữ liệu giống thật và diễn tập thảm hoạ ở quy mô lớn.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận30/09/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)