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ý Giao tiếp
  3. /Fastly 08/06/2021: lỗi phần mềm tiềm ẩn bị một c…
Quản lý Giao tiếp

Fastly 08/06/2021: lỗi phần mềm tiềm ẩn bị một cấu hình khách hàng kích hoạt và cách truyền thông sự cố trong 49 phút

Sáng 08/06/2021, một khách hàng đẩy lên một thay đổi cấu hình hợp lệ và vô tình kích hoạt lỗi phần mềm chưa được phát hiện, khiến khoảng 85% mạng của Fastly trả về lỗi. Fastly phát hiện sau chưa đầy một phút, đăng thông báo trạng thái sau 11 phút và khôi phục phần lớn mạng trong 49 phút, rồi công bố bản tóm tắt kèm cam kết khắc phục. Phân tích dưới góc nhìn quản lý truyền thông: tốc độ xác nhận, nội dung thông báo, kênh dành cho khách hàng và cách báo cáo sau sự cố giữ niềm tin.

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

Bối cảnh thực tế

Fastly là nhà cung cấp mạng phân phối nội dung và điện toán biên (edge cloud) mà rất nhiều trang tin tức, thương mại điện tử và dịch vụ công dùng để tăng tốc và bảo vệ website. Vì thế, khi mạng của Fastly gặp trục trặc, hàng loạt website không liên quan nhau cùng ngừng hoạt động.

Theo bản tóm tắt do chính Fastly công bố, nguyên nhân là một lỗi phần mềm chưa được phát hiện, được đưa vào mạng qua một đợt triển khai bắt đầu từ ngày 12/05/2021. Lỗi chỉ lộ ra khi một khách hàng đẩy một thay đổi cấu hình hoàn toàn hợp lệ vào sáng 08/06/2021. Mốc thời gian (giờ UTC) do Fastly nêu:

  • 09:47 — sự cố bắt đầu trên diện rộng; 09:48 — hệ thống giám sát của Fastly nhận diện được.
  • 09:58 — đăng thông báo trạng thái đầu tiên.
  • 10:27 — kỹ sư xác định được cấu hình khách hàng gây lỗi; 10:36 — dịch vụ bắt đầu hồi phục.
  • 11:00 — phần lớn dịch vụ đã trở lại; 12:35 — sự cố được coi là đã giảm nhẹ; 17:25 — bắt đầu triển khai bản sửa lỗi vĩnh viễn.

Fastly cho biết khoảng 85% mạng trả về lỗi và trong vòng 49 phút, 95% mạng đã hoạt động bình thường. Trong bài viết, công ty cũng nói sẽ liên hệ trực tiếp khách hàng, mở hộp thư hỗ trợ cho các câu hỏi, và cam kết làm hậu kiểm đầy đủ, tìm hiểu vì sao lỗi lọt qua kiểm thử và xem xét cách rút ngắn thời gian khắc phục.

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

  • Kế hoạch quản lý truyền thông (Plan Communications Management) cho kịch bản "sự cố toàn cầu"

    Thông báo đầu tiên lên trang trạng thái sau khoảng 11 phút kể từ lúc sự cố bắt đầu cho thấy nhóm đã có quy trình và người chịu trách nhiệm đăng tin sẵn. Một kế hoạch truyền thông tốt xác định trước: ai tuyên bố sự cố, kênh nào dùng đầu tiên, tần suất cập nhật và mẫu nội dung — để lúc căng thẳng không phải tranh luận.

  • Quản lý sự tham gia của các bên liên quan là khách hàng doanh nghiệp

Khách hàng của một CDN lại có người dùng cuối riêng đang hỏi họ "chuyện gì xảy ra". Họ cần thông tin đủ nhanh và đủ rõ để tự truyền thông lại: phạm vi, trạng thái, thời điểm cập nhật tiếp theo. Bản đồ các bên liên quan (stakeholder register) nên tách "khách hàng trực tiếp" và "người dùng của khách hàng" để chọn nội dung phù hợp.

  • Nguyên nhân kỹ thuật gốc nằm ở kiểm soát chất lượng và phát hành

    Lỗi được triển khai gần bốn tuần trước khi bị kích hoạt, tức là kiểm thử và triển khai theo từng đợt không bắt được tổ hợp điều kiện hiếm này. Quy trình Quản lý chất lượng (Manage Quality) cần xem xét vì sao tổ hợp cấu hình hợp lệ nhưng hiếm không nằm trong tập kiểm thử, và phát hành dần (canary) có phủ được loại điều kiện đó không.

  • Báo cáo sau sự cố như một sản phẩm truyền thông

    Việc công bố bản tóm tắt cùng ngày, nêu cả mốc thời gian chi tiết lẫn các cam kết cụ thể là cách giữ niềm tin: người đọc biết điều gì đã xảy ra, đã làm gì và sẽ làm gì tiếp. Cam kết chỉ có giá trị khi sau đó có người sở hữu, hạn chót và kết quả được báo lại — nếu không, đó chỉ là lời hứa chung chung.

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

    1. 1

      Bước 1: Chuẩn bị sẵn mẫu thông báo và phân vai trước khi có sự cố

      Soạn trước các mẫu thông báo theo ba giai đoạn (đang điều tra, đã xác định nguyên nhân, đã khắc phục) và phân vai rõ ràng: người chỉ huy sự cố, người viết thông báo, người liên lạc với khách hàng lớn. Mỗi thông báo cần đạt:

      • Nội dung

        Nêu phạm vi ảnh hưởng, trạng thái hiện tại và giờ cập nhật kế tiếp bằng ngôn ngữ người ngoài đọc hiểu được.

      • Mức chắc chắn

        Chỉ nêu nguyên nhân khi đã xác minh; chưa chắc thì nói "đang điều tra", không đoán công khai.

      • Điều cấm

        Không đổ lỗi cho khách hàng hay bên thứ ba khi chưa có bằng chứng, không hứa mốc khôi phục không có cơ sở.

    2. 2

      Bước 2: Tách kênh cho từng nhóm bên liên quan

      Trang trạng thái công khai cho tất cả; hộp thư và đầu mối riêng cho khách hàng doanh nghiệp; bản tóm tắt kỹ thuật cho đội kỹ sư của khách. Mỗi kênh có người cập nhật và nhịp cập nhật riêng, tránh một thông điệp "một cỡ cho tất cả".

    3. 3

      Bước 3: Biến cam kết khắc phục thành hạng mục có người sở hữu

      Mỗi cam kết trong báo cáo (tìm hiểu vì sao lỗi lọt qua kiểm thử, rút ngắn thời gian khắc phục…) được đưa vào nhật ký hành động với người chịu trách nhiệm, hạn chót và cách kiểm chứng; báo cáo tiến độ cho khách hàng sau một khoảng thời gian cam kết trước.

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

    Trong sự cố, truyền thông nhanh, đúng đối tượng và trung thực về mức hiểu biết quan trọng không kém việc sửa lỗi. Chuẩn bị mẫu, phân vai và kênh trước; sau sự cố, biến báo cáo thành cam kết có chủ sở hữu để niềm tin được củng cố thay vì chỉ được xoa dịu.

    Nguồn tham khảo

    • Fastly — Summary of June 8 outage
    #Quản lý truyền thông#Fastly#Truyền thông sự cố#CDN#Báo cáo sau sự cố#Trang trạng thái

    Nguồn: Fastly — Summary of June 8 outage ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Bạn là PM phụ trách dịch vụ cho nhiều khách hàng doanh nghiệp. Một sự cố diện rộng vừa bắt đầu cách đây 10 phút; kỹ sư chưa xác định được nguyên nhân, còn khách hàng liên tục hỏi. Bạn nên làm gì tiếp theo về mặt truyền thông?

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

    Sau khi khắc phục sự cố, bạn ưu tiên hình thức nào để báo cáo cho khách hàng?

    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ý Giao tiếp

    Khách hàng đòi thay thế Tech Lead & Nghệ thuật Bảo vệ Đội ngũ

    Mảng kiến thức trọng tâm: Quản lý Nguồn lực, Quản lý Các bên liên quan & Lãnh đạo Phục vụ (Resource Management, Stakeholder Engagement & Servant Leadership - PMBOK 6/7)

    1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Quản lý Giao tiếp

    "Hố sâu chuyển giao" (Operational Transition Gap) – Khi Đội Vận hành từ chối tiếp nhận hệ thống

    Mảng kiến thức trọng tâm: Chuyển giao từ Dự án sang Vận hành & Quản lý Các bên liên quan nội bộ (Project-to-Operations Transition, Operational Readiness & Internal Stakeholder Engagement - PMBOK 6/7)

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận13/10/2026
    Quản lý Giao tiếp

    Slack 22/02/2022: nâng cấp Consul làm bộ nhớ đệm rơi, cơ sở dữ liệu quá tải và cách vừa giảm tải vừa thông tin cho người dùng

    Sáng 22/02/2022, đúng giờ cao điểm, nhiều người dùng Slack không kết nối được. Nguyên nhân là một chuỗi yếu tố: nâng cấp Consul theo từng bước 25%, bộ nhớ đệm mất hiệu quả, truy vấn quét mọi shard làm Vitess quá tải và máy khách thử lại dồn dập. Slack giảm tải có kiểm soát, thông báo trên mạng xã hội rồi công bố bản post-mortem kỹ thuật vào cuối tháng 4. Phân tích dưới góc nhìn quản lý truyền thông sự cố.

    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)