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. /Instapaper (02/2017): bảng dữ liệu chạm giới hạn…
Số 387Quản lý Rủi ro

Instapaper (02/2017): bảng dữ liệu chạm giới hạn tệp 2 TB của Amazon RDS và hơn 31 giờ ngừng dịch vụ

Bảng lưu bài viết của người dùng Instapaper chạm giới hạn kích thước tệp 2 TB, áp dụng cho các phiên bản Amazon RDS tạo trước tháng 4/2014. Không có cảnh báo nào báo trước, và đội không có kế hoạch khôi phục cho kịch bản này. Dịch vụ ngừng hơn 31 giờ, mất gần một tuần để khôi phục toàn bộ kho lưu trữ. Bài học về rủi ro giới hạn kỹ thuật ẩn trong dịch vụ đám mây.

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

Bối cảnh thực tế

Instapaper là ứng dụng lưu bài viết để đọc sau, khi đó thuộc Pinterest, chạy MySQL trên Amazon RDS. Bảng "bookmarks" chứa mọi bài viết người dùng đã lưu.

Theo bài postmortem của kỹ sư Brian Donohue và TechCrunch:

  • Các phiên bản RDS tạo trước tháng 4/2014 có giới hạn kích thước tệp 2 TB. Bảng bookmarks chạm giới hạn này vào tháng 2/2017, gây lỗi ghi.
  • Bảng điều khiển RDS không có giám sát, cảnh báo hay log nào báo trước việc sắp chạm giới hạn.
  • Dịch vụ ngừng hơn 31 giờ. Để trở lại nhanh, đội khôi phục trước chỉ sáu tuần dữ liệu gần nhất; xuất toàn bộ dữ liệu mất rất lâu nên phải dựng phiên bản mới trên hệ thống tệp khác.
  • Kho lưu trữ đầy đủ được khôi phục lúc 1 giờ sáng ngày 14/2/2017, không mất dữ liệu.
  • Bài học được công bố: chưa có kế hoạch khôi phục thảm hoạ cho kịch bản này và sẽ xây dựng; thiết lập kênh leo thang ngay tới đội SRE của Pinterest; kiểm thử sao lưu MySQL hằng tháng thay vì ba tháng một lần.

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

  • Giới hạn kỹ thuật ẩn không được nhận diện

    Giới hạn 2 TB phụ thuộc vào thời điểm tạo phiên bản — một chi tiết lịch sử dễ bị lãng quên. Nhận diện rủi ro cần rà soát các giới hạn của dịch vụ đám mây đang dùng.

  • Giả định "nhà cung cấp lo" về giám sát

    Dùng dịch vụ quản lý (managed service) không có nghĩa mọi rủi ro được giám sát. Không có chỉ số kích thước tệp theo bảng nên không có cảnh báo.

  • Thiếu kế hoạch ứng phó cho kịch bản dữ liệu lớn

    Không có kế hoạch khôi phục cho trường hợp phải di chuyển một bảng hàng terabyte, nên mọi phương án phải tự nghĩ ra giữa sự cố.

  • Đội nhỏ thiếu kênh leo thang

    Một đội sản phẩm nhỏ trong tập đoàn lớn chưa có đường leo thang nhanh tới chuyên gia SRE.

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

  1. 1

    Bước 1: Rà soát giới hạn của mọi dịch vụ đám mây đang dùng

    Lập danh sách giới hạn cứng (kích thước, số kết nối, hạn ngạch), đo mức hiện tại và tốc độ tăng.

    • Xa

      Dưới 50% giới hạn và dự báo trên 2 năm mới chạm: theo dõi định kỳ.

    • Gần

      50–80% hoặc dự báo chạm trong 12 tháng: lên kế hoạch di chuyển.

    • Nguy cấp

      Trên 80% hoặc không đo được: xử lý ngay như một hạng mục dự án.

  2. 2

    Bước 2: Tự xây cảnh báo khi nhà cung cấp không có

    Tự đo kích thước bảng, tốc độ tăng và đặt cảnh báo theo ngưỡng.

  3. 3

    Bước 3: Diễn tập khôi phục ở quy mô thực

    Thử khôi phục sao lưu định kỳ và đo thời gian thực tế, để biết trước cần bao lâu và cần phương án khôi phục từng phần.

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

Dịch vụ đám mây không xoá bỏ rủi ro, nó chỉ thay đổi hình dạng rủi ro. Hãy biết giới hạn của nền tảng bạn dùng, tự giám sát những gì nhà cung cấp không giám sát, và chuẩn bị sẵn phương án khôi phục từng phần cho dữ liệu lớn.

Nguồn tham khảo

  • TechCrunch — Instapaper says it is now fully restored after last week’s outage
  • Instapaper (Medium) — Instapaper Outage Cause & Recovery
#Quản lý rủi ro#Phát triển phần mềm#Cơ sở dữ liệu#Điện toán đám mây#Kế hoạch khôi phục#Postmortem

Nguồn: TechCrunch — Instapaper says it is now fully restored after last week’s outage (14/02/2017) ↗ (mở trong thẻ mới)

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

Câu 1/1
Sản phẩm của bạn dùng cơ sở dữ liệu được quản lý trên đám mây đã vài năm. Đội cho rằng "nhà cung cấp sẽ báo nếu có vấn đề". Hành động quản lý rủi ro nào nên làm trước tiên?

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

Khi phải khôi phục kho dữ liệu khổng lồ, bạn có chọn khôi phục từng phần như Instapaper khô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 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)