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ý Rủi ro
  3. /Kakao và đám cháy trung tâm dữ liệu Pangyo (10/2…
Quản lý Rủi ro

Kakao và đám cháy trung tâm dữ liệu Pangyo (10/2022): hệ thống dự phòng có sẵn nhưng quyền kích hoạt nằm ngay trong toà nhà bị cháy

Ngày 15/10/2022, đám cháy ở phòng pin của trung tâm dữ liệu SK C&C tại Pangyo (Hàn Quốc) làm các dịch vụ của Kakao gián đoạn 127 giờ 30 phút. Kết luận điều tra chính phủ: pin không được tách khỏi hệ thống nguồn dự phòng, hệ thống chữa cháy không phù hợp, và hệ thống dự phòng của Kakao không thể kích hoạt kịp vì cơ chế cấp quyền vẫn nằm ở trung tâm bị cháy. Bài học về khôi phục thảm hoạ và điểm lỗi đơn.

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

Bối cảnh thực tế

Kakao vận hành KakaoTalk, ứng dụng nhắn tin phổ biến nhất Hàn Quốc, cùng nhiều dịch vụ đi kèm. Phần lớn chức năng cốt lõi của Kakao được đặt trong trung tâm dữ liệu Pangyo của SK C&C (tỉnh Gyeonggi), nơi cũng chứa máy chủ của Naver.

Ngày 15/10/2022, một đám cháy bùng lên trong phòng pin ở tầng hầm 3 của trung tâm dữ liệu này. Theo bản điều tra do Bộ Khoa học và ICT, Uỷ ban Truyền thông Hàn Quốc và Cơ quan Phòng cháy chữa cháy quốc gia công bố ngày 6/12/2022, dịch vụ của Kakao bị gián đoạn 127 giờ 30 phút.

Những phát hiện được báo chí Hàn Quốc tóm tắt:

  • Nguyên nhân cháy chưa được xác nhận chắc chắn, nhưng nhiều khả năng bắt đầu từ pin lithium-ion.
  • Hệ thống giám sát pin của SK C&C không phát hiện bất thường; trung tâm không có hệ thống chữa cháy phù hợp với đám cháy pin lithium-ion.
  • Pin nằm cùng phòng với hệ thống nguồn dự phòng nên khi cháy, toàn bộ nguồn của máy chủ, kể cả nguồn dự phòng, bị cắt.
  • Kakao có hệ thống dự phòng ở trung tâm dữ liệu khác, nhưng quyền kích hoạt chuyển đổi chỉ chạy qua các máy chủ đặt trong trung tâm bị cháy, nên không chuyển kịp.
  • Naver chỉ bị gián đoạn một phần nhờ có nhiều trung tâm dữ liệu và hệ thống kép.

Co-CEO của Kakao khi đó từ chức sau sự cố; các công ty được yêu cầu trong vòng một tháng đưa ra biện pháp chống tái diễn, và chính phủ dự kiến công bố kế hoạch cải thiện chung vào quý đầu năm sau.

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

  • Điểm lỗi đơn (single point of failure) không được nhận diện trong sổ đăng ký rủi ro

    Dịch vụ cốt lõi tập trung trong một trung tâm dữ liệu là rủi ro có xác suất thấp nhưng tác động cực lớn. Quy trình Nhận diện rủi ro và phân tích định tính phải đặt "mất toàn bộ một địa điểm" vào danh mục, với chủ sở hữu rủi ro ở cấp ban điều hành chứ không chỉ ở đội hạ tầng.

  • Kế hoạch dự phòng có lỗ hổng phụ thuộc vòng tròn

Hệ thống dự phòng tồn tại nhưng cơ chế cấp quyền để kích hoạt nó lại nằm trong khu vực bị hỏng. Đây là lỗi thiết kế điển hình khi kiểm tra kế hoạch chỉ xem từng thành phần có sẵn mà không chạy thử toàn bộ kịch bản; kế hoạch phản ứng (contingency/fallback plan) phải được diễn tập đầu–cuối để bộc lộ các phụ thuộc ẩn.

  • Rủi ro từ nhà cung cấp (SK C&C) được giao nhưng không được kiểm chứng

    Chuyển giao rủi ro bằng cách thuê trung tâm dữ liệu không chuyển được tác động lên khách hàng của Kakao. Theo Kiểm soát mua sắm, bên mua cần kiểm tra an toàn cháy nổ, thiết kế nguồn dự phòng và phương án xử lý pin lithium-ion như một phần của thẩm định nhà cung cấp và kiểm toán định kỳ.

  • Thiếu kế hoạch truyền thông và dự phòng cho người dùng

    Sự cố kéo dài hơn năm ngày cho thấy kế hoạch khôi phục chưa tính tới thời gian khôi phục mục tiêu (RTO) thực tế. Cơ quan chức năng yêu cầu bổ sung kế hoạch thảm hoạ và phương án bồi thường cho người dùng — các hạng mục lẽ ra nằm sẵn trong kế hoạch quản lý rủi ro và truyền thông.

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

    1. 1

      Bước 1: Phân hạng dịch vụ và đặt mục tiêu RTO/RPO theo mức quan trọng

      Xác định chức năng nào phải khôi phục trong vài phút (nhắn tin, đăng nhập), chức năng nào có thể chậm hơn; từ đó quyết định đầu tư vào dự phòng liên vùng cho đúng chỗ thay vì dàn trải.

    2. 2

      Bước 2: Diễn tập khôi phục đầu–cuối với kịch bản "mất cả địa điểm"

      Chạy thử chuyển đổi dự phòng thật, kèm điều kiện như mất quyền truy cập vào mọi hệ thống ở địa điểm chính:

      • Độc lập địa điểm

        Quyền kích hoạt, danh tính, cấu hình và dữ liệu then chốt có bản sao ở địa điểm dự phòng; không bước nào đi qua địa điểm chính.

      • Kết quả diễn tập

        Mỗi lần diễn tập ghi nhận thời gian khôi phục thực tế so với RTO; chênh lệch lớn thì mở hạng mục khắc phục có hạn chót.

      • Ngưỡng dừng phát hành

        Không cho phép đưa dịch vụ mới vào danh mục "cốt lõi" khi chưa vượt qua diễn tập chuyển đổi dự phòng.

    3. 3

      Bước 3: Thẩm định và kiểm toán nhà cung cấp hạ tầng

      Đưa yêu cầu về phân tách pin – nguồn, giám sát và chữa cháy phù hợp công nghệ pin vào hợp đồng, kèm quyền thanh tra độc lập; tách nhà cung cấp cho ít nhất hai địa điểm cho chức năng cốt lõi.

    4. 4

      Bước 4: Chuẩn bị sẵn kế hoạch truyền thông và bồi thường

      Soạn trước mẫu thông báo, kênh thay thế khi ứng dụng chính ngừng, và nguyên tắc bồi thường để phản ứng nhanh, nhất quán khi sự cố xảy ra.

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

    Có hệ thống dự phòng chưa có nghĩa là có khả năng khôi phục. Hãy tìm các phụ thuộc ẩn (như quyền kích hoạt nằm ở địa điểm chính), diễn tập kịch bản mất cả địa điểm và thẩm định nhà cung cấp hạ tầng — kế hoạch chưa từng chạy thử chỉ là giả định.

    Nguồn tham khảo

    • Korea JoongAng Daily — ICT Ministry completes its probe of Kakao service outage
    #Quản lý rủi ro#Khôi phục thảm hoạ#Điểm lỗi đơn#Kakao#Trung tâm dữ liệu#Hàn Quốc

    Nguồn: Korea JoongAng Daily — ICT Ministry completes its probe of Kakao service outage ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Công ty bạn có kế hoạch khôi phục thảm hoạ với trung tâm dữ liệu dự phòng và đã kiểm tra từng thành phần đều sẵn sàng. Một kỹ sư phát hiện: lệnh kích hoạt chuyển đổi dự phòng phải xác thực qua máy chủ danh tính đặt ở trung tâm chính. Bạn nên làm gì?

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

    Nếu ngân sách chỉ cho phép một khoản đầu tư khôi phục thảm hoạ trong năm nay, bạn chọn hướng 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ý Rủi ro

    SolarWinds Orion (2020): khi chính bản cập nhật phần mềm tin cậy trở thành vũ khí xâm nhập hàng nghìn tổ chức

    Kẻ tấn công cài mã độc vào quy trình build của SolarWinds, khiến các bản cập nhật Orion từ tháng 3 đến tháng 6/2020 mang theo cửa hậu; khoảng 18.000 khách hàng tải về. Vụ việc chỉ lộ ra khi FireEye điều tra vụ xâm nhập chính mình. Phân tích dưới góc nhìn rủi ro: tài sản nào cần được bảo vệ như "sản phẩm", và vì sao rủi ro phần mềm bên thứ ba phải nằm trong sổ đăng ký rủi ro của người mua lẫn người bán.

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

    Target 2013: kẻ tấn công vào mạng qua nhà thầu điều hoà, cảnh báo của hệ thống phát hiện xâm nhập không ai xử lý

    Cuối năm 2013, tin tặc đánh cắp thông tin khoảng 40 triệu tài khoản thẻ và dữ liệu cá nhân của tới 70 triệu khách hàng Target. Báo cáo của Uỷ ban Thương mại Thượng viện Mỹ cho thấy điểm vào là tài khoản của một nhà thầu điều hoà, mạng không được phân tách và các cảnh báo không được hành động. Phân tích dưới góc nhìn rủi ro: nhận diện, đánh giá và ứng phó rủi ro từ bên thứ ba.

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

    Log4Shell (2021): một thư viện nguồn mở do tình nguyện viên duy trì và cuộc chạy đua tìm xem "mình đang dùng nó ở đâu"

    Lỗ hổng CVE-2021-44228 trong thư viện ghi nhật ký Log4j có điểm CVSS 10, tồn tại từ năm 2013 và ảnh hưởng 93% môi trường đám mây doanh nghiệp theo khảo sát của Wiz và EY. Hội đồng Rà soát An toàn Mạng Mỹ gọi đây là lỗ hổng "đặc hữu". Bài học rủi ro: không có bản kê thành phần phần mềm thì không thể ứng phó nhanh, và phụ thuộc nguồn mở cần được quản lý như phụ thuộc nhà cung cấp.

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