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.109 người đã truy cậpPhiên bản 1.15.0
  1. /Tình huống
  2. /Quản lý Rủi ro
  3. /AWS US-EAST-1 (07/12/2021): hoạt động tự động mở…
Số 370Quản lý Rủi ro

AWS US-EAST-1 (07/12/2021): hoạt động tự động mở rộng gây tắc nghẽn mạng nội bộ, đội vận hành mất cả công cụ giám sát

Một hoạt động tự động mở rộng năng lực trên mạng chính của AWS kích hoạt hành vi bất thường ở rất nhiều client trong mạng nội bộ, gây tắc nghẽn thiết bị mạng nối hai mạng suốt nhiều giờ. Lỗi tiềm ẩn khiến client không lùi lại (back-off) như thiết kế; giám sát và trang trạng thái cũng bị ảnh hưởng. Bài học về rủi ro dây chuyền và phụ thuộc vòng.

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

Bối cảnh thực tế

AWS tách mạng nội bộ (chạy các dịch vụ nền tảng, giám sát, DNS nội bộ) khỏi mạng chính phục vụ khách hàng; hai mạng nối với nhau qua một lớp thiết bị mạng.

Theo bản tóm tắt AWS công bố ngày 10/12/2021:

  • Khoảng 7:30 sáng (giờ PST) ngày 7/12/2021, một hoạt động tự động mở rộng năng lực cho một dịch vụ trên mạng chính kích hoạt hành vi bất ngờ ở rất nhiều client trong mạng nội bộ.
  • Lượng kết nối tăng vọt làm quá tải thiết bị mạng nối hai mạng; việc thử lại liên tục duy trì tắc nghẽn. Một lỗi tiềm ẩn khiến client không lùi lại như thiết kế.
  • Tắc nghẽn làm đội vận hành mất giám sát thời gian thực, phải chẩn đoán qua log. Công cụ cập nhật Service Health Dashboard không chuyển được sang vùng dự phòng; việc tạo ca hỗ trợ bị gián đoạn từ 7:33 đến 14:25.
  • Thiết bị mạng hồi phục hoàn toàn lúc 14:22; một số dịch vụ như EventBridge còn trễ đến 18:40.
  • Khắc phục: tắt hoạt động mở rộng gây sự cố cho đến khi mọi biện pháp được triển khai, cô lập nguồn lưu lượng lớn, sửa lỗi back-off, làm Service Health Dashboard mới và hệ thống hỗ trợ đa vùng.

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

  • Rủi ro dây chuyền không được nhận diện

    Một hành động tự động "thường ngày" trên mạng chính lại gây hiệu ứng lên mạng nội bộ. Đăng ký rủi ro hiếm khi ghi nhận kịch bản tương tác giữa các hệ thống tự động — đúng nơi rủi ro hệ thống ẩn nấp.

  • Cơ chế phòng vệ chưa từng được kiểm chứng

    Back-off là biện pháp giảm thiểu rủi ro quá tải đã có trong thiết kế, nhưng lỗi tiềm ẩn khiến nó không hoạt động. Biện pháp ứng phó rủi ro chưa được kiểm thử thì chỉ là giả định.

  • Công cụ ứng cứu phụ thuộc chính hạ tầng bị sự cố

    Giám sát, trang trạng thái và hệ thống hỗ trợ cùng chịu ảnh hưởng. Kế hoạch ứng phó rủi ro phải giả định rằng công cụ của chính mình có thể hỏng cùng lúc.

  • Truyền thông rủi ro tới khách hàng chậm

    Thông báo bị trễ và được đăng dưới dạng banner khó thấy. Khách hàng không thể kích hoạt kế hoạch dự phòng của họ khi không biết chuyện gì đang xảy ra.

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

    1. 1

      Bước 1: Phân tích rủi ro tương tác giữa các hệ thống tự động

      Với mỗi tác vụ tự động (scale, failover, deploy), hỏi: nó tạo ra lưu lượng hay tải gì lên hệ thống khác? Điều gì xảy ra nếu hàng nghìn client phản ứng cùng lúc?

    2. 2

      Bước 2: Kiểm thử biện pháp giảm thiểu như kiểm thử tính năng

      Diễn tập quá tải có kiểm soát để xác nhận back-off, giới hạn tốc độ và ngắt mạch thực sự hoạt động.

    3. 3

      Bước 3: Tách công cụ ứng cứu khỏi hạ tầng được giám sát

      Trang trạng thái, kênh liên lạc và giám sát khẩn cấp đặt ở hạ tầng độc lập, được kiểm tra định kỳ khả năng chuyển vùng.

    4. 4

      Bước 4: Dừng tự động hoá có điều kiện

      Tắt tác vụ gây sự cố cho đến khi biện pháp khắc phục xong — và ghi rõ tiêu chí để bật lại — như AWS đã làm.

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

    Rủi ro lớn nhất của hệ thống phân tán thường nằm ở chỗ các thành phần tự động tương tác với nhau. Hãy kiểm chứng biện pháp phòng vệ trước khi cần đến nó, và đảm bảo công cụ ứng cứu không sập cùng hệ thống bạn đang cứu.

    Nguồn tham khảo

    • AWS — Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region
    #Quản lý rủi ro#Phát triển phần mềm#Điện toán đám mây#SRE#Ứng phó sự cố#Postmortem

    Nguồn: AWS — Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region (12/2021) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Trong buổi rà soát đăng ký rủi ro, kỹ sư cho biết client nội bộ "đã có cơ chế back-off nên không lo quá tải". Cơ chế này chưa từng được thử ở quy mô lớn. PM nên làm gì?

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

    Sau sự cố, 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 tương tự

    Số 474Quản lý Rủi ro

    Cầu Morandi (Genova, 2018): rủi ro ăn mòn cáp đã biết hàng chục năm, gói gia cố 20 triệu euro mời thầu ba tháng trước khi cầu sập

    Ngày 14/8/2018, một nhịp của cầu cạn Morandi ở Genova (Ý) đổ sập trong mưa giông, làm 43 người chết. Cây cầu khánh thành năm 1967 có lịch sử ăn mòn cáp văng được ghi nhận từ thập niên 1990; tháng 2/2018, một cuộc họp của cơ quan bộ đã nêu tiết diện cáp giảm trung bình 10–20% nhưng không áp biện pháp phòng ngừa. Gói gia cố khoảng 20 triệu euro chỉ được mời thầu tháng 5/2018. Bài học về rủi ro đã biết, ngưỡng hành động và cái giá của sự trì hoãn.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận29/10/2026
    Quản lý Rủi ro

    Khủng hoảng Rò rỉ Dữ liệu & Quy trình Ứng phó Sự cố An ninh mạng

    Dự án xây dựng nền tảng hồ sơ sức khỏe và bảo hiểm số đang ở tuần thứ 36 trên tổng tiến độ 40 tuần, chuẩn bị bước vào giai đoạn nghiệm thu kỹ thuật và diễn tập Golive. Hệ thống chứa cơ sở dữ liệu định danh cá nhân (PII) và lịch sử khám chữa bệnh nhạy cảm của hơn 150.000 người dùng thử nghiệm.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận23/10/2026
    Số 382Quản lý Rủi ro

    Toyota (29/08/2023): bảo trì cơ sở dữ liệu làm hết dung lượng đĩa, hệ thống dự phòng cùng lỗi và 14 nhà máy tại Nhật ngừng một ngày

    Sau đợt bảo trì định kỳ dọn dẹp dữ liệu tích luỹ, máy chủ xử lý đơn đặt linh kiện của Toyota dừng vì không đủ dung lượng đĩa. Máy dự phòng chạy cùng hệ thống nên gặp lỗi tương tự, không chuyển sang được. Toàn bộ 14 nhà máy lắp ráp tại Nhật ngừng một ngày. Bài học về rủi ro trong bảo trì và giả định "đã có dự phòng".

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