Bài 55: Postmortem không đổ lỗi sau sự cố

Bài 55: Postmortem không đổ lỗi sau sự cố

Bài này chi tiết hóa Postmortem theo hướng vận hành bền vững: có mẫu kiểm tra, tình huống thực tế, checklist và bài tập.

Sau bài này anh sẽ biết:

  • Postmortem giúp hệ thống vận hành bền vững như thế nào.
  • Các lệnh, tài liệu hoặc cấu hình nên kiểm tra.
  • Cách phản ứng khi có sự cố thực tế.
  • Cách biến kinh nghiệm vận hành thành checklist/runbook.

1. Bối cảnh thực tế

Postmortem thuộc nhóm kỹ năng giúp hệ thống không chỉ “chạy được”, mà còn dễ quan sát, dễ bảo vệ, dễ khôi phục và dễ học từ sự cố. Đây là phần quan trọng để vận hành lâu dài.

2. Khái niệm cần nắm

  • Visibility: phải nhìn thấy log, metric, trạng thái và thay đổi.
  • Actionable alert: cảnh báo phải dẫn tới hành động rõ ràng.
  • Recovery: có kế hoạch khôi phục trước khi thảm họa xảy ra.
  • Continuous improvement: sau sự cố phải có bài học và action item.

3. Lab thực hành / mẫu kiểm tra

Mục tiêu: xây thói quen kiểm tra, ghi nhận và phản ứng có quy trình.
# mẫu postmortem
Incident:
Impact:
Timeline:
Detection:
Root cause:
Contributing factors:
What went well:
What went wrong:
Action items:
Owner / Deadline:

4. Tình huống thực tế

Một deploy làm website lỗi 30 phút. Postmortem giúp thêm health check, canary/rollback tốt hơn và cập nhật runbook, không phải để đổ lỗi cá nhân.

5. Quy trình áp dụng

  1. Xác định mục tiêu: quan sát, bảo vệ, khôi phục hay cải thiện.
  2. Thu thập trạng thái hiện tại: log, metric, config, tài liệu.
  3. Thiết kế checklist hoặc rule đơn giản trước.
  4. Test trong lab/staging nếu có.
  5. Áp dụng production theo từng bước nhỏ.
  6. Theo dõi sau thay đổi và ghi lại kết quả.
  7. Cập nhật tài liệu/runbook để lần sau xử lý nhanh hơn.

6. Lỗi thường gặp

  • Có dashboard nhưng không có alert.
  • Có alert nhưng không có runbook.
  • Có backup nhưng chưa từng restore.
  • Có chính sách bảo mật nhưng không audit định kỳ.
  • Sau incident chỉ sửa tạm, không rút kinh nghiệm.
Lưu ý production: Vận hành bền vững cần tài liệu và kiểm tra định kỳ. Đừng đợi đến lúc sự cố mới đi tìm log, backup, owner hoặc quyền truy cập.

7. Checklist

  • Có log/metric đủ để điều tra.
  • Có cảnh báo có ý nghĩa hành động.
  • Có runbook cho alert quan trọng.
  • Có backup/restore/DR được test.
  • Có audit quyền truy cập và secret.
  • Có postmortem sau incident lớn.

8. Bài tập

  1. Chọn một hệ thống nhỏ và viết checklist vận hành.
  2. Tạo một alert giả định kèm runbook xử lý.
  3. Viết kế hoạch backup/restore/DR ngắn.
  4. Viết mẫu postmortem cho một sự cố giả định.

Tác giả: Mạnh Hoàng

Tôi là Hoàng Mạnh, người sáng lập blog SysadminSkills.com. Tôi viết về quản trị hệ thống, bảo mật máy chủ, DevOps và cách ứng dụng AI để tự động hóa công việc IT. Blog này là nơi tôi chia sẻ những gì đã học được từ thực tế – đơn giản, ngắn gọn và áp dụng được ngay.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *