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. /Atlassian tháng 4/2022: script xoá nhầm 883 site…
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.

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

Bối cảnh thực tế

Atlassian đang gỡ bỏ ứng dụng độc lập "Insight – Asset Management", vốn đã được tích hợp vào Jira Service Management từ năm 2021. Theo bản đánh giá sau sự cố do chính công ty công bố, sự cố không phải tấn công mạng và hơn 99,6% khách hàng không bị ảnh hưởng. Tuy vậy:

  • 883 site bị xoá, thuộc 775 khách hàng; việc xoá bắt đầu lúc 07:38 UTC ngày 05/04/2022 và script chạy xong lúc 08:01.
  • Do thiếu thông tin giữa hai đội, đội yêu cầu cung cấp ID site thay vì ID ứng dụng. API xoá nhận cả hai mà không cảnh báo, nên truyền ID site là xoá luôn cả site.
  • Rà soát đồng nghiệp chỉ kiểm tra endpoint và phương thức, không kiểm tra giá trị ID; kiểm thử ở môi trường staging không bắt được lỗi vì các ID đó không tồn tại ở đó.
  • Lần chạy đầu trên 30 site trong sản xuất diễn ra bình thường; lần thứ hai trên 883 site thì gây thảm hoạ. Hệ thống giám sát không báo động vì việc xoá chạy qua quy trình chuẩn.

Khôi phục bắt đầu từ 08/04 và hoàn tất 18/04, có khách hàng gián đoạn tới 14 ngày. Atlassian nêu rõ nguyên nhân chậm: chưa có runbook hay tự động hoá cho việc khôi phục hàng loạt nhiều site và nhiều sản phẩm liên kết, dữ liệu nằm trong kho nhiều khách hàng dùng chung nên phải trích thủ công từ bản sao lưu, và quy trình quản lý sự cố không được thiết kế cho hàng trăm kỹ sư làm song song. Mục tiêu điểm khôi phục (RPO) 1 giờ đạt được, nhưng mục tiêu thời gian khôi phục (RTO) thì không.

Công ty cam kết: chặn xoá site hàng loạt, áp dụng xoá mềm có lộ trình triển khai và kế hoạch hoàn tác, tăng tốc chương trình khôi phục thảm hoạ tự động, soạn sổ tay cho sự cố lớn và cải thiện truyền thông.

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

  • Giao diện API mơ hồ: hai loại ID, một hành vi nguy hiểm (Plan Quality Management)

    API xoá chấp nhận cả ID site lẫn ID ứng dụng và không phân biệt ngữ cảnh. Thiết kế "dễ dùng" này làm tăng khả năng nhầm lẫn nghiêm trọng. Yêu cầu chất lượng với thao tác phá huỷ phải gồm kiểm tra kiểu đầu vào và xác nhận rõ ràng.

  • Rà soát đồng nghiệp và kiểm thử không phủ rủi ro dữ liệu (Manage Quality)

    Reviewer nhìn mã, không nhìn dữ liệu đầu vào; staging không có dữ liệu giống thật. Danh sách kiểm tra rà soát cho thao tác phá huỷ cần có mục "đầu vào có đúng loại, đúng phạm vi không".

  • Giao tiếp giữa các đội thiếu định nghĩa chung (Manage Communications)

    Hai đội dùng từ "ID" cho hai đối tượng khác nhau. Một mẫu yêu cầu có trường bắt buộc nêu loại ID có thể ngăn nhầm lẫn từ đầu.

  • Khôi phục thảm hoạ chưa thử ở quy mô nhiều site (Plan Risk Responses)

    Quy trình khôi phục chỉ đã được kiểm chứng cho từng site lẻ. Giả định "khôi phục hàng loạt cũng giống từng cái" là rủi ro chưa được kiểm tra, và quy trình quản lý sự cố cũng chưa tính tới nhiều luồng việc song song.

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

    1. 1

      Bước 1: Đặt tiêu chí chấp nhận cho mọi thao tác xoá hàng loạt

      Một kế hoạch xoá an toàn cần ba lớp:

      • Xoá mềm

        Dữ liệu chỉ bị đánh dấu xoá và giữ lại một thời gian, khôi phục được bằng một thao tác.

      • Lô nhỏ tăng dần

        Chạy theo lô tăng dần, có điểm dừng kiểm tra kết quả trước khi chạy lô kế tiếp.

      • Ngưỡng dừng

        Nếu số đối tượng bị xoá vượt dự kiến hoặc có đối tượng không thuộc danh sách, tự dừng script.

    2. 2

      Bước 2: Kiểm thử bằng dữ liệu đại diện và đối chiếu đầu vào

      Staging cần có ID thật hoặc dữ liệu giả lập đúng cấu trúc; script phải kiểm tra loại ID trước khi gọi API.

    3. 3

      Bước 3: Diễn tập khôi phục ở quy mô tương xứng

      Đặt mục tiêu RTO cho kịch bản mất hàng trăm khách hàng, tự động hoá khôi phục, và thử định kỳ để runbook không chỉ tồn tại trên giấy.

    4. 4

      Bước 4: Chuẩn bị quản lý sự cố cho quy mô lớn

      Soạn sổ tay cho sự cố nhiều luồng song song, có kênh liên lạc dự phòng ngoài sản phẩm, và truyền thông sớm. Viết đánh giá sau sự cố không đổ lỗi như Atlassian đã công bố.

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

    Sao lưu chỉ có giá trị khi khôi phục được đúng quy mô và đúng thời gian cam kết. Với mọi thao tác không thể hoàn tác, PM phải đòi xoá mềm, lô nhỏ tăng dần và bài diễn tập khôi phục thật.

    Nguồn tham khảo

    • Post-Incident Review: April 2022 Atlassian outage
    #Quản lý chất lượng#Atlassian#Khôi phục thảm hoạ#Xoá mềm#Post-incident review#SaaS

    Nguồn: Post-Incident Review: April 2022 Atlassian outage ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Bạn chuẩn bị chạy script gỡ bỏ hàng trăm tài nguyên của khách hàng khỏi môi trường sản xuất. Lần chạy thử trên 30 tài nguyên diễn ra tốt. Bước nào đúng nhất trước khi chạy toàn bộ?

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

    Bạn đầu tư vào đâu trước để tránh một sự cố xoá nhầm dữ liệu 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ý 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ố 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

    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)