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. /Amazon S3 ngày 28/02/2017: một tham số nhập sai …
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.

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

Bối cảnh thực tế

Sáng 28/02/2017, đội S3 của Amazon điều tra vì sao hệ thống tính phí S3 xử lý chậm hơn kỳ vọng. Theo bản tóm tắt chính thức của AWS, lúc 9:37 (giờ Thái Bình Dương), một thành viên được ủy quyền làm theo playbook đã có và chạy lệnh nhằm gỡ một số ít máy chủ khỏi một hệ thống con phục vụ quá trình tính phí.

Một tham số đầu vào của lệnh bị nhập sai, nên số máy chủ bị gỡ lớn hơn dự định rất nhiều. Số máy chủ này nằm trong hai hệ thống con quan trọng của vùng US-EAST-1:

  • Hệ thống chỉ mục (index) lưu siêu dữ liệu và vị trí mọi đối tượng, cần cho GET, LIST, PUT, DELETE.
  • Hệ thống phân bổ (placement) cấp vùng lưu trữ cho đối tượng mới, phụ thuộc vào chỉ mục.

Cả hai hệ thống phải khởi động lại; chúng chưa được khởi động lại ở quy mô đó trong nhiều năm và việc kiểm tra an toàn mất thời gian. Chỉ mục khôi phục một phần lúc 12:26, đầy đủ lúc 13:18; hệ thống phân bổ hoàn tất lúc 13:54, tức gián đoạn kéo dài khoảng 4 giờ 17 phút. Các dịch vụ khác như EC2, EBS và Lambda cũng bị ảnh hưởng. Một chi tiết đáng chú ý: bảng điều khiển quản trị của Service Health Dashboard cũng phụ thuộc S3 nên AWS không cập nhật được trạng thái từng dịch vụ cho đến 11:37, và phải dùng Twitter làm kênh thông báo tạm.

AWS cam kết sửa công cụ để gỡ dung lượng chậm hơn, thêm cơ chế chặn mọi thao tác làm một hệ thống con xuống dưới dung lượng tối thiểu, rà soát các công cụ khác, đẩy nhanh việc chia chỉ mục thành các "cell" nhỏ hơn và chuyển bảng điều khiển trạng thái sang chạy đa vùng.

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

  • Công cụ vận hành không chống được lỗi người (Plan Quality Management)

    Lỗi nhập một tham số không nên đủ để gỡ cả phần lớn hệ thống. Nguyên lý "poka-yoke" (chống nhầm lẫn) yêu cầu thiết kế để sai sót khó xảy ra hoặc không gây hậu quả lớn: kiểm tra giới hạn, xác nhận phạm vi, gỡ từng chút một.

  • Playbook được tin tưởng mà thiếu chốt an toàn tự động (Manage Quality)

Quy trình được viết sẵn tạo cảm giác an toàn, nhưng nếu bước thực thi nằm ở một dòng lệnh tự do thì chất lượng phụ thuộc hoàn toàn vào sự cẩn thận khi gõ. Cần biến kiểm tra thành rào chắn của công cụ chứ không phải kỷ luật của cá nhân.

  • Thời gian khôi phục chưa được kiểm chứng ở quy mô hiện tại (Plan Risk Responses)

    Hệ thống lớn lên nhiều năm nhưng quy trình khởi động lại không được kiểm tra lại, làm khôi phục lâu hơn dự kiến. Mục tiêu thời gian khôi phục phải được thử định kỳ khi quy mô tăng.

  • Phụ thuộc ngầm của kênh truyền thông (Manage Communications)

    Trang trạng thái phụ thuộc vào đúng dịch vụ đang hỏng. Kênh truyền thông sự cố cần được liệt kê trong phân tích phụ thuộc như một thành phần quan trọng.

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

    1. 1

      Bước 1: Đặt hàng rào an toàn vào công cụ, không vào trí nhớ con người

      Yêu cầu chất lượng cho công cụ vận hành phải có tiêu chí chấp nhận cụ thể:

      • Giới hạn dung lượng tối thiểu

        Công cụ từ chối mọi thao tác đưa hệ thống con xuống dưới ngưỡng tối thiểu đã khai báo.

      • Tốc độ thao tác

        Gỡ máy chủ theo từng đợt nhỏ, có thời gian quan sát giữa các đợt.

      • Xác nhận phạm vi

        Công cụ hiển thị số máy sẽ bị ảnh hưởng và yêu cầu xác nhận nếu vượt mức thông thường.

    2. 2

      Bước 2: Giảm bán kính ảnh hưởng bằng phân vùng

      Chia hệ thống thành các cell nhỏ để một lỗi chỉ ảnh hưởng một phần, và để khởi động lại nhanh hơn, đúng hướng AWS đã đẩy sớm sau sự cố.

    3. 3

      Bước 3: Diễn tập khởi động lại định kỳ

      Lập lịch kiểm tra khôi phục các hệ thống con quan trọng ở quy mô hiện tại và ghi kết quả vào kế hoạch quản lý rủi ro.

    4. 4

      Bước 4: Tách kênh truyền thông khỏi dịch vụ chính

      Chạy trang trạng thái độc lập, nhiều vùng, và có kênh dự phòng. Viết post-mortem công khai, tập trung vào cải tiến hệ thống như AWS đã làm.

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

    Đừng coi lỗi con người là nguyên nhân gốc; hãy hỏi vì sao hệ thống cho phép một lỗi gõ phím gây ra hậu quả lớn đến vậy. Chất lượng của công cụ vận hành cũng quan trọng không kém chất lượng sản phẩm.

    Nguồn tham khảo

    • Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region
    #Quản lý chất lượng#AWS#Poka-yoke#Playbook vận hành#Post-mortem#Đám mây

    Nguồn: Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Trong buổi post-mortem, một đồng nghiệp đề nghị kỷ luật kỹ sư đã nhập sai tham số làm sập dịch vụ. Với vai trò PM, hướng xử lý nào phù hợp nhất với quản lý chất lượng?

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

    Công cụ vận hành của bạn nên bảo vệ trước lỗi nhập liệu bằng cách nào là chính?

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