Login

Học từ postmortem: cách đọc báo cáo 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

Mọi hệ thống phần mềm đều có lúc gặp sự cố. Điều phân biệt các đội giỏi không phải việc họ không bao giờ gặp sự cố, mà là cách họ học từ chúng. Báo cáo postmortem (phân tích sau sự cố) là tài liệu quý giá để học miễn phí từ trải nghiệm của người khác.

Postmortem là gì?

Postmortem, còn gọi là báo cáo sau sự cố hay phân tích nguyên nhân gốc, là tài liệu ghi lại điều gì đã xảy ra, vì sao xảy ra, tác động ra sao và làm gì để không lặp lại. Nhiều tổ chức công khai bản đã lược bỏ chi tiết nhạy cảm để cộng đồng cùng học. Mục tiêu không phải là tìm người đáng trách mà là cải thiện hệ thống và quy trình.

Văn hóa không đổ lỗi (blameless)

Một postmortem tốt thường theo tinh thần không đổ lỗi: coi lỗi của con người là dấu hiệu hệ thống thiếu rào chắn, chứ không phải nguyên nhân gốc. Nếu một kỹ sư chạy nhầm lệnh gây sự cố, câu hỏi hay là: vì sao hệ thống cho phép lệnh đó gây hại lớn đến vậy mà không có cảnh báo hay bước xác nhận?

Cấu trúc thường gặp của một báo cáo

PhầnNội dung
Tóm tắtChuyện gì đã xảy ra, trong bao lâu, ảnh hưởng ai
Dòng thời gianCác mốc từ lúc bắt đầu, phát hiện, xử lý đến khôi phục
Nguyên nhân gốcChuỗi yếu tố dẫn đến sự cố
Điều làm tốtNhững gì giúp giảm thiệt hại
Điều chưa tốtNhững chỗ chậm phát hiện, thiếu công cụ, tài liệu
Hành động khắc phụcViệc cụ thể, có người phụ trách, có thời hạn

Những mẫu sự cố hay gặp

  • Thay đổi cấu hình sai: một tham số thay đổi gây ảnh hưởng ngoài dự kiến.
  • Quá tải tài nguyên: đĩa đầy, bộ nhớ cạn, kết nối cơ sở dữ liệu hết.
  • Phụ thuộc bên ngoài lỗi: dịch vụ thứ ba chậm hoặc ngừng hoạt động.
  • Triển khai lỗi: bản phát hành mới có lỗi và thiếu cách quay lui nhanh.
  • Chứng chỉ hết hạn, hết hạn miền: tưởng nhỏ nhưng dễ gây gián đoạn lớn.
  • Thiếu giám sát: sự cố kéo dài vì không ai biết sớm.

Cách đọc để học được nhiều nhất

  1. Đọc dòng thời gian trước: thấy được nhịp độ phát hiện và phản ứng.
  2. Hỏi "Mình có đang gặp rủi ro tương tự không?" Hệ thống của bạn có điểm yếu giống vậy?
  3. Chú ý nhiều yếu tố đồng thời: sự cố hiếm khi do một lý do duy nhất.
  4. Xem các hành động khắc phục: chúng gợi ý các thực hành tốt như kiểm thử trước khi triển khai, cảnh báo sớm.
  5. Ghi lại bài học áp dụng cho dự án của bạn.

Tự viết postmortem cho dự án nhỏ

Ngay cả dự án cá nhân cũng nên viết khi có sự cố, ví dụ website sập một buổi tối. Một bản ngắn gồm năm câu hỏi là đủ:

  1. Chuyện gì đã xảy ra, bắt đầu và kết thúc lúc nào?
  2. Bạn phát hiện bằng cách nào?
  3. Nguyên nhân gốc là gì?
  4. Bạn đã làm gì để khôi phục?
  5. Bạn sẽ làm gì để lần sau không lặp lại hoặc phát hiện sớm hơn?

Những cải tiến phổ biến sau sự cố

  • Thêm kiểm thử tự động cho trường hợp đã gây lỗi.
  • Thêm cảnh báo và bảng giám sát.
  • Viết sổ tay xử lý (runbook) cho tình huống tương tự.
  • Thêm bước xác nhận hoặc giới hạn quyền với thao tác nguy hiểm.
  • Triển khai từng phần để giảm phạm vi ảnh hưởng.
  • Tập luyện quay lui và khôi phục dữ liệu định kỳ.

Nhìn nhận sự cố tích cực

Sự cố là cơ hội học tập đắt giá. Đội nào biến mỗi sự cố thành một cải tiến cụ thể sẽ dần xây được hệ thống đáng tin hơn. Là người mới, đọc báo cáo của người khác giúp bạn tích lũy trực giác kỹ thuật mà không phải trả giá bằng sự cố của chính mình.

Câu hỏi thường gặp

Có nên công khai postmortem không?

Với tổ chức, công khai bản đã lược chi tiết nhạy cảm giúp xây dựng niềm tin và chia sẻ bài học. Với cá nhân, nên chia sẻ nếu có ích cho người khác.

Làm sao tránh biến postmortem thành tìm người có lỗi?

Tập trung vào quy trình và hệ thống, đặt câu hỏi 'vì sao hệ thống cho phép điều này' thay vì 'ai làm sai'.

Hành động khắc phục nên có bao nhiêu?

Ít nhưng cụ thể, có người phụ trách và thời hạn. Quá nhiều hành động mơ hồ thường không được thực hiện.

Nên viết postmortem trong bao lâu sau sự cố?

Càng sớm càng tốt khi ký ức còn rõ, thường trong vài ngày, nhưng cần đủ thời gian để phân tích kỹ.

Kết luận

Postmortem là món quà cho cả cộng đồng. Hãy đọc với tinh thần học hỏi, hỏi mình rủi ro tương tự ở đâu và tập thói quen ghi lại bài học sau mỗi sự cố. Dần dần, bạn sẽ thiết kế hệ thống chắc chắn hơn từ đầu.

Hiểu hạ tầng và triển khai sẽ giúp bạn ứng phó sự cố tốt hơn; xem các khóa DevOps tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment