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. /Facebook ngoại tuyến 04/10/2021: một lệnh bảo tr…
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.

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

Bối cảnh thực tế

Ngày 04/10/2021, các dịch vụ của Facebook, Instagram và WhatsApp đồng loạt không truy cập được. Bài giải thích do bộ phận kỹ thuật của Meta đăng ngày hôm sau cho biết diễn biến như sau:

  • Trong một đợt bảo trì định kỳ, một lệnh nhằm đánh giá dung lượng mạng xương sống toàn cầu đã vô tình ngắt toàn bộ kết nối trong mạng này, tách các trung tâm dữ liệu khỏi nhau.
  • Hệ thống kiểm tra (audit) lệnh vốn được thiết kế để chặn lệnh kiểu này, nhưng một lỗi trong chính công cụ kiểm tra khiến nó không ngăn được.
  • Máy chủ DNS của Facebook tự rút các thông báo định tuyến BGP khi mất liên lạc với trung tâm dữ liệu (cơ chế an toàn tự kiểm tra sức khoẻ). Hậu quả: các máy chủ DNS vẫn chạy nhưng cả Internet không tìm thấy chúng.

Việc khôi phục chậm vì cả đường truy cập chính lẫn đường quản trị ngoài băng (out-of-band) đều đã sập, nhiều công cụ nội bộ dựa vào DNS cũng hỏng; kỹ sư phải tới trực tiếp các trung tâm dữ liệu, nơi các biện pháp an ninh vật lý và hệ thống vốn được thiết kế rất chặt cũng làm thao tác lâu hơn. Khi kết nối trở lại, đội ngũ bật dịch vụ từ từ vì tải điện của mỗi trung tâm dữ liệu đã giảm hàng chục megawatt và bật lại đột ngột có thể gây hỏng hệ thống điện và bộ nhớ đệm.

Meta cho biết các cuộc diễn tập "storm" trước đó (giả lập mất dịch vụ, trung tâm dữ liệu hoặc cả vùng) đã giúp khôi phục an toàn, nhưng họ chưa từng giả lập mất toàn bộ mạng xương sống, và cam kết bổ sung diễn tập kiểu đó.

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

  • Rào chắn thay đổi đặt sai chỗ tin cậy (Perform Integrated Change Control)

    Lớp kiểm tra lệnh là chốt duy nhất giữa một thao tác thường nhật và hậu quả toàn cầu, và chốt này lại có lỗi. Một thay đổi có bán kính ảnh hưởng toàn mạng cần nhiều lớp độc lập (mô phỏng trước, xác nhận hai người, giới hạn phạm vi), không chỉ một công cụ.

  • Công cụ kiểm tra không được kiểm thử như sản phẩm (Control Quality)

Công cụ audit là một phần của hệ thống an toàn nên phải có bộ kiểm thử, kể cả thử bằng các lệnh nguy hiểm đã biết. Quản lý chất lượng áp dụng cho cả công cụ vận hành, không chỉ sản phẩm hướng khách hàng.

  • Phụ thuộc vòng giữa công cụ khôi phục và hệ thống bị hỏng (Plan Risk Responses)

    Chẩn đoán cần DNS, DNS cần mạng, mạng là thứ đang hỏng. Kế hoạch ứng phó rủi ro thiếu giả định "công cụ của ta cũng sẽ sập". Đường truy cập ngoài băng cũng sập cùng lúc cho thấy nó chưa độc lập thật sự.

  • Phạm vi diễn tập chưa phủ kịch bản xấu nhất

    Các cuộc diễn tập có giá trị (Meta ghi nhận chúng giúp khôi phục có kiểm soát) nhưng chưa bao gồm mất mạng xương sống. Danh mục kịch bản kiểm thử nên được rà soát theo "điều gì sẽ làm sập mọi thứ cùng lúc".

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

    1. 1

      Bước 1: Xếp hạng thay đổi theo bán kính ảnh hưởng và gắn lớp kiểm soát tương ứng

      Thao tác chạm mạng lõi thuộc nhóm rủi ro cao nhất và phải vượt nhiều cổng:

      • Chạy thử khô

        Công cụ in ra những kết nối sẽ bị ảnh hưởng và chặn nếu vượt ngưỡng phạm vi.

      • Hai người xác nhận

        Một kỹ sư độc lập duyệt đầu ra của chạy thử khô trước khi thực thi.

      • Dừng cứng

        Lệnh ngắt toàn bộ một lớp hạ tầng bị cấm ở cấp công cụ, cần quy trình riêng để mở khoá.

    2. 2

      Bước 2: Kiểm thử chính công cụ kiểm tra

      Duy trì bộ lệnh "nguy hiểm đã biết" chạy tự động để chứng minh audit vẫn chặn được; mỗi lần sửa audit phải chạy lại bộ này.

    3. 3

      Bước 3: Thiết kế đường khôi phục độc lập

      Công cụ chẩn đoán, truy cập ngoài băng và liên lạc nhóm phải không phụ thuộc hạ tầng chính, và được kiểm tra định kỳ bằng diễn tập mất toàn bộ mạng.

    4. 4

      Bước 4: Chuẩn bị khôi phục tải dần dần

      Lập kịch bản bật lại dịch vụ theo bậc để tránh quá tải điện và bộ nhớ đệm, và viết post-mortem không đổ lỗi, như Meta đã công bố.

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

    Một lớp kiểm soát duy nhất, dù thông minh, vẫn là điểm lỗi đơn. Hãy xếp hạng thay đổi theo bán kính ảnh hưởng, kiểm thử cả công cụ an toàn lẫn đường khôi phục, và diễn tập kịch bản mà bạn mong là không bao giờ xảy ra.

    Nguồn tham khảo

    • More details about the October 4 outage — Engineering at Meta
    #Quản lý chất lượng#Meta#kiem-soat-thay-doi#DNS#Diễn tập sự cố#SRE

    Nguồn: More details about the October 4 outage (Engineering at Meta) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Sau một sự cố, kỹ sư của bạn không vào được công cụ chẩn đoán vì chúng phụ thuộc vào đúng hạ tầng đang hỏng. Hành động cải tiến nào giải quyết gốc rễ?

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

    Để giảm rủi ro một lệnh bảo trì làm sập toàn bộ mạng lõi, bạn ưu tiên đầu tư vào đâu trước?

    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ố 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)