Login

Postmortem không đổ lỗi: học hỏi từ sự cố hệ thống

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Hệ thống sập lúc hai giờ sáng. Sau khi khắc phục, câu hỏi đầu tiên của nhiều người là 'ai đã làm?'. Đó là câu hỏi sai. Câu hỏi đúng là 'vì sao hệ thống cho phép điều này xảy ra?'. Postmortem không đổ lỗi biến sự cố thành bài học để hệ thống bền vững hơn.

Postmortem là gì?

Postmortem (hay báo cáo sau sự cố) là buổi nhìn lại và tài liệu ghi chép về một sự cố: chuyện gì đã xảy ra, ảnh hưởng ra sao, đã khắc phục thế nào, nguyên nhân sâu xa là gì, và cần làm gì để tránh lặp lại. Mục tiêu là học hỏi, không phải trừng phạt.

Vì sao phải không đổ lỗi (blameless)?

Nếu người gây ra lỗi bị khiển trách, mọi người sẽ học cách giấu lỗi và giấu thông tin, đúng lúc bạn cần sự trung thực nhất để hiểu chuyện gì đã xảy ra. Hơn nữa, hiếm khi sự cố do một người duy nhất: nó là kết quả của nhiều yếu tố như thiếu kiểm thử, quy trình triển khai thiếu bước chặn lỗi, cảnh báo không rõ ràng. Nếu một người sai một lần mà làm hệ thống sập thì lỗi nằm ở hệ thống thiếu hàng rào bảo vệ, chứ không chỉ ở người đó.

Quy trình xử lý sự cố ngắn gọn

  1. Phát hiện: qua giám sát, cảnh báo hoặc báo cáo từ người dùng.
  2. Phân loại mức độ: sự cố ảnh hưởng bao nhiêu người, mức nghiêm trọng thế nào.
  3. Phân vai: một người điều phối, những người xử lý kỹ thuật, một người cập nhật thông tin cho các bên liên quan.
  4. Giảm thiểu trước: ưu tiên khôi phục dịch vụ (quay lui bản phát hành, tắt tính năng, chuyển hướng lưu lượng) trước khi tìm nguyên nhân gốc.
  5. Giao tiếp: thông báo trạng thái định kỳ, trung thực và ngắn gọn.
  6. Xác nhận đã ổn định rồi mới kết thúc.
  7. Postmortem: thực hiện trong vài ngày sau khi trí nhớ còn mới.

Một bản postmortem gồm những gì?

  • Tóm tắt: vài câu về sự cố và ảnh hưởng.
  • Ảnh hưởng: bao lâu, bao nhiêu người dùng hoặc giao dịch bị tác động.
  • Dòng thời gian: các mốc phát hiện, phản ứng, khắc phục theo giờ cụ thể.
  • Nguyên nhân gốc và các yếu tố góp phần.
  • Điều gì làm tốt: những gì giúp phát hiện hoặc khắc phục nhanh.
  • Điều chưa tốt và những chỗ may mắn.
  • Hành động khắc phục: mỗi mục có người phụ trách và thời hạn.

Tìm nguyên nhân gốc với 5 Whys

Kỹ thuật đơn giản: hỏi 'vì sao?' liên tục (khoảng năm lần) cho đến khi chạm tới yếu tố hệ thống. Ví dụ:

  1. Vì sao website không truy cập được? Vì database hết dung lượng đĩa.
  2. Vì sao đĩa đầy? Vì file log tăng không kiểm soát.
  3. Vì sao log tăng? Vì một lỗi mới ghi log liên tục sau khi triển khai.
  4. Vì sao không ai biết sớm? Vì không có cảnh báo dung lượng đĩa.
  5. Vì sao không có? Vì thiết lập giám sát ban đầu chưa gồm mục này.

Hành động khắc phục không phải 'nhắc người triển khai cẩn thận hơn' mà là thêm cảnh báo, giới hạn log, xoay vòng log. Lưu ý thực tế thường phức tạp hơn một chuỗi thẳng; hãy xem 5 Whys là điểm khởi đầu để đào sâu.

Làm cho hành động khắc phục có ích

  • Ưu tiên giải pháp tự động hơn là phụ thuộc vào trí nhớ con người.
  • Mỗi hành động cụ thể, kiểm chứng được, có người chịu trách nhiệm.
  • Đưa vào backlog và theo dõi cho đến khi xong, vì nhiều postmortem thất bại ở khâu này.
  • Giới hạn số hành động ở những cái thật sự tạo khác biệt.

Cách điều hành buổi họp postmortem

  1. Mời những người liên quan trực tiếp và người có góc nhìn khác.
  2. Bắt đầu bằng việc nhắc quy tắc không đổ lỗi.
  3. Dùng ngôn ngữ như 'hệ thống cho phép' thay vì 'anh A đã sai'.
  4. Dựng dòng thời gian cùng nhau từ log, tin nhắn, biểu đồ.
  5. Chia sẻ bản ghi sau buổi họp để cả tổ chức học theo.

Kết luận

Sự cố là điều không thể tránh, nhưng lặp lại cùng một sự cố là có thể. Postmortem không đổ lỗi giúp nhóm trung thực, tìm ra nguyên nhân hệ thống và biến mỗi lần thất bại thành một bước cải tiến. Hãy thử viết bản đầu tiên cho sự cố gần nhất của bạn, dù nhỏ.

Nếu muốn học cách vận hành hệ thống và xử lý sự cố một cách chuyên nghiệp, hãy xem thêm tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment