Postmortem sự cố nhỏ nên ghi những gì để lỗi không lặp lại?

Một sự cố nhỏ vẫn đáng viết postmortem (báo cáo phân tích sau sự cố) nếu nó ảnh hưởng người dùng, buộc bạn rollback hoặc reboot, cần can thiệp ngoài giờ hay chỉ được phát hiện nhờ khách hàng báo.

Bạn không cần một tài liệu dài. Một postmortem đủ dùng cần trả lời ba lớp câu hỏi:

1. Sự thật: điều gì xảy ra, ảnh hưởng ai và diễn biến theo thời gian ra sao?
2. Giải thích: trigger nào kích hoạt lỗi và những điều kiện nào khiến lỗi tác động tới người dùng?
3. Thay đổi: cần phòng ngừa, phát hiện hoặc giảm tác động tốt hơn bằng việc gì, ai theo dõi?

Phần cuối quyết định giá trị của tài liệu. Nếu postmortem chỉ kể lại sự cố rồi kết thúc bằng “lần sau cẩn thận hơn”, lỗi vẫn có thể lặp lại theo cùng cơ chế.

Khi nào một sự cố nhỏ nên có postmortem?

Không cần đợi website ngừng hoạt động hàng giờ. Nên viết khi sự cố có ít nhất một trong các dấu hiệu:

• Người dùng không truy cập được hoặc một chức năng quan trọng bị suy giảm.
• Có lỗi dữ liệu, dù phạm vi nhỏ và đã khôi phục.
• Người trực phải rollback, reboot, chuyển traffic hoặc dùng quyền khẩn cấp.
• Thời gian phục hồi dài hơn mức chấp nhận của hệ thống.
• Monitoring không phát hiện; khách hàng hoặc nhân viên phát hiện trước.
• Một near miss có thể gây tác động lớn nếu điều kiện hơi khác.
• Sự cố tương tự đã xuất hiện trước đó.

Bạn nên xác định tiêu chí này từ trước. Nếu chỉ quyết định sau mỗi sự cố, những lần “chưa đủ nghiêm trọng” dễ bị bỏ qua dù đang báo hiệu cùng một điểm yếu.

Với sự cố rất nhỏ, postmortem có thể chỉ một hoặc hai trang. Độ dài không quan trọng bằng việc tác động được ghi rõ và action item được theo dõi.

Viết sớm, nhưng sau khi hệ thống đã ổn định

Hãy bắt đầu khi dịch vụ đã trở lại mức chấp nhận, dữ liệu quan trọng đã được xác nhận và người xử lý không còn phải chạy theo cảnh báo.

Đừng chờ nhiều tuần. Timeline, lý do chọn một biện pháp và những tín hiệu đã bị bỏ lỡ sẽ nhanh chóng trở nên mơ hồ. Tốt nhất, dùng ngay ghi chép từ quá trình xử lý sự cố làm bản nháp đầu tiên.

Bài Quy trình 30 phút đầu khi website production gặp sự cố có mẫu timeline ngắn để bạn lưu dữ kiện ngay trong lúc phản ứng.

Người viết không nhất thiết phải là quản lý. Người trực tiếp tham gia thường có dữ liệu chính xác nhất. Nếu nhiều người cùng xử lý, hãy để họ bổ sung và xác nhận phần liên quan trước khi chốt.

Bắt đầu bằng summary mà người ngoài sự cố vẫn hiểu

Summary nên trả lời trong một đoạn:

• Dịch vụ hoặc chức năng nào bị ảnh hưởng.
• Thời điểm bắt đầu, phát hiện và phục hồi.
• Triệu chứng người dùng gặp phải.
• Trigger hoặc nguyên nhân chính ở mức đã xác nhận.
• Biện pháp đã khôi phục dịch vụ.

Ví dụ:

Từ 09:12 đến 09:41, trang đăng nhập trả lỗi 502 cho phần lớn request. Một lần deploy đã thay đổi port của application nhưng cấu hình reverse proxy chưa được cập nhật cùng lúc. Monitoring phát hiện error rate tăng sau 4 phút. Đội vận hành rollback application về phiên bản trước và xác nhận đăng nhập hoạt động lại lúc 09:41.

Đừng viết “server gặp vấn đề” hoặc “deployment lỗi”. Những câu này không cho người đọc biết phạm vi, thời lượng hay cơ chế thất bại.

Ghi tác động bằng dữ kiện

Tác động không chỉ là thời gian hệ thống đỏ trên dashboard. Hãy mô tả từ góc nhìn người dùng và nghiệp vụ:

• URL hoặc critical flow nào bị lỗi.
• Tỷ lệ request lỗi hoặc số lần kiểm tra thất bại.
• Khoảng thời gian ảnh hưởng.
• Số người dùng, đơn hàng, form hoặc job bị ảnh hưởng nếu đo được.
• Dữ liệu có mất, trùng, chậm xử lý hoặc cần đối soát không.
• Phạm vi địa lý, tenant hoặc nhóm tài khoản nếu chỉ ảnh hưởng một phần.

Nếu không có số chính xác, hãy ghi một ước lượng kèm cách tính và mức độ chắc chắn. Ví dụ: “Khoảng 40–60 lượt đăng nhập có thể bị lỗi, ước tính từ access log; chưa có số người dùng duy nhất.” Một ước lượng có nguồn tốt hơn câu “ảnh hưởng một số khách hàng”.

Không đưa dữ liệu cá nhân, secret, IP quản trị hoặc thông tin nhạy cảm vào tài liệu được chia sẻ rộng. Có thể lưu bằng chứng chi tiết ở nơi hạn chế quyền và chỉ liên kết bằng mã tham chiếu.

Dựng timeline bằng cùng một múi giờ

Timeline giúp người đọc thấy khoảng trống giữa sự kiện, phát hiện, quyết định và phục hồi.

Dùng một múi giờ xuyên suốt và ghi nguồn khi cần: dashboard, deploy log, journal hoặc trao đổi trong kênh sự cố. Không cần đưa từng lệnh nhỏ vào bảng; giữ những mốc giúp giải thích tác động và quyết định.

Timeline trả lời “chuyện gì xảy ra theo thứ tự nào”, nhưng chưa trả lời “vì sao hệ thống cho phép chuyện đó xảy ra”. Phần phân tích phải làm việc tiếp theo.

Phân biệt trigger và các yếu tố góp phần

Trigger là sự kiện kích hoạt failure mode. Trong ví dụ trên, trigger là lần deploy có application port mới.

Nếu dừng ở “deploy sai”, postmortem chưa đủ. Hãy hỏi vì sao thay đổi đó có thể tới production và vì sao tác động kéo dài:

• Cấu hình proxy và application nằm ở hai nơi nhưng không được kiểm tra như một bộ.
• Healthcheck chỉ kiểm tra process chạy, không kiểm tra đường đăng nhập qua proxy.
• Deploy không có bước xác nhận port có hiệu lực.
• Alert chỉ theo dõi homepage nên phát hiện lỗi đăng nhập chậm.
• Runbook rollback không ghi rõ phiên bản cấu hình đi cùng image.

Đây là các yếu tố góp phần. Một sự cố thường cần nhiều điều kiện cùng xuất hiện; không phải lúc nào cũng có một “nguyên nhân gốc” duy nhất.

Tránh câu “do An nhập sai port”. Hãy viết cơ chế hệ thống: “Pipeline chấp nhận image và proxy config không tương thích vì chưa có kiểm tra contract giữa hai thành phần.” Cách viết này tạo đầu vào cho cải tiến có thể kiểm chứng.

Blameless không có nghĩa mọi quyết định đều đúng hoặc không ai chịu trách nhiệm theo dõi cải tiến. Nó có nghĩa phần phân tích tập trung vào điều kiện, công cụ và quy trình thay vì quy kết phẩm chất của một người.

Ghi rõ cách phát hiện và phục hồi

Detection

Trả lời:

• Tín hiệu đầu tiên là gì?
• Alert, người dùng hay người vận hành phát hiện trước?
• Từ khi ảnh hưởng bắt đầu tới khi phát hiện mất bao lâu?
• Alert có chỉ đúng chức năng bị lỗi và có đủ ngữ cảnh để hành động không?
• Tín hiệu nào đáng ra có thể phát hiện sớm hơn?

Nếu khách hàng phát hiện trước monitoring, đây là một khoảng trống cần ghi nhận, không phải chi tiết nên làm nhẹ đi.

Mitigation và resolution

Tách hai khái niệm:

• Mitigation làm giảm hoặc dừng tác động, chẳng hạn rollback, cô lập worker hoặc chuyển traffic.
• Resolution xử lý failure mode đã biết, chẳng hạn sửa contract cấu hình, thêm validation rồi triển khai lại.

Trong một sự cố nhỏ, hai việc có thể trùng nhau. Nhưng nếu reboot chỉ giúp website chạy lại mà chưa tìm được memory leak, reboot là mitigation chứ chưa phải resolution. Bài Khi nào reboot VPS là hợp lý và cần lưu lại gì trước đó? giải thích ranh giới này.

Ghi hành động nào không hiệu quả và vì sao. Điều này giúp người xử lý lần sau không lặp lại cùng một nhánh điều tra.

Điều gì làm tốt, điều gì cần cải thiện và đã may mắn ở đâu?

Ba mục này giúp bài học cân bằng hơn một danh sách lỗi.

Điều làm tốt

• Monitoring chỉ đúng critical flow.
• Rollback đã được chuẩn bị và chạy đúng.
• Timeline được giữ đầy đủ.
• Người xử lý biết dừng deploy tiếp theo.

Điều cần cải thiện

• Alert đến chậm hoặc thiếu ngữ cảnh.
• Dashboard không có metric cần thiết.
• Quyền truy cập recovery mất thời gian xác nhận.
• Runbook thiếu một bước quan trọng.
• Thay đổi quá lớn nên khó xác định thành phần gây lỗi.

Đã may mắn ở đâu

• Sự cố xảy ra ngoài giờ cao điểm.
• Database không bị ảnh hưởng dù application lỗi.
• Người có quyền rollback vẫn đang trực.
• Một dependency khác không lỗi cùng lúc.

“May mắn” cho biết blast radius tiềm ẩn. Nếu lần sau điều kiện đó không còn, tác động có thể lớn hơn và cần được cân nhắc trong mức ưu tiên action item.

Action item phải có kết quả kiểm tra được

Một action item tốt trả lời:

• Làm gì: thay đổi cụ thể nào sẽ được thực hiện?
• Loại: phòng ngừa, phát hiện, giảm tác động, quy trình hay điều tra?
• Mức ưu tiên: dựa trên tác động và khả năng tái diễn.
• Owner: một người chịu trách nhiệm theo dõi, dù có nhiều người cùng làm.
• Tracking: issue hoặc backlog item nào giữ trạng thái?
• Hoàn tất khi nào: điều kiện nào chứng minh việc đã xong?
• Mốc rà soát: khi nào cần đánh giá tiến độ hoặc quyết định lại?

Ví dụ:

Tên trong bảng chỉ là minh họa. Trong tài liệu thực tế, owner phải là người đã xác nhận trách nhiệm theo dõi.

Tránh các action item như:

• “Cẩn thận hơn khi deploy.”
• “Cải thiện monitoring.”
• “Tối ưu server.”
• “Viết lại toàn bộ backend.”

Chúng không có phạm vi hoặc tiêu chí hoàn tất. Một giải pháp quá lớn cho failure mode hiếm gặp cũng có thể tạo thêm phức tạp và rủi ro. Hãy cân đối tác động, khả năng tái diễn, chi phí và hiệu quả giảm rủi ro.

Mẫu postmortem ngắn

Bạn có thể dùng cấu trúc sau:

# [Tên sự cố] — [Ngày]

Trạng thái: Draft / Reviewed / Actions in progress / Closed
Owner postmortem:
Khoảng ảnh hưởng:

## 1. Summary
[Điều gì xảy ra, ảnh hưởng chính, cách khôi phục]

## 2. Impact
- Chức năng/người dùng bị ảnh hưởng:
- Thời lượng:
- Error/latency hoặc số liệu nghiệp vụ:
- Dữ liệu bị ảnh hưởng:
- Nguồn và mức độ chắc chắn của số liệu:

## 3. Detection
- Tín hiệu đầu tiên:
- Thời gian từ impact tới detection:
- Khoảng trống monitoring:

## 4. Timeline
| Thời điểm | Sự kiện/quan sát | Hành động | Kết quả |

## 5. Trigger và yếu tố góp phần
- Trigger:
- Cơ chế failure:
- Yếu tố góp phần:

## 6. Mitigation và resolution
- Điều đã giảm tác động:
- Fix đã thực hiện hoặc trạng thái điều tra:

## 7. Bài học
- Điều làm tốt:
- Điều cần cải thiện:
- Đã may mắn ở đâu:

## 8. Action items
| Hành động | Loại | Ưu tiên | Owner | Tracking | Hoàn tất khi | Trạng thái |

## 9. Bằng chứng tham chiếu
[Dashboard, log, deploy record hoặc issue; không chép secret]

Nếu một mục chưa biết, ghi CHƯA XÁC ĐỊNH và tạo action điều tra có đầu ra cụ thể. Đừng lấp chỗ trống bằng suy đoán rồi trình bày như kết luận.

Khi nào postmortem được coi là hoàn tất?

Tài liệu có thể được review xong trong khi action item vẫn đang triển khai. Hãy tách hai trạng thái.

Postmortem đủ để review khi:

• Impact và timeline đã được kiểm tra bằng nguồn phù hợp.
• Trigger, failure mechanism và yếu tố góp phần được phân biệt.
• Mitigation cùng resolution được mô tả đúng trạng thái.
• Action item có phạm vi, owner, priority và nơi theo dõi.
• Nội dung nhạy cảm đã được giới hạn đúng quyền.

Vòng học hỏi chỉ khép lại khi action item quan trọng đã hoàn tất, được xác nhận bằng test/monitoring, hoặc được quyết định lại với lý do rõ ràng. Việc chuyển tất cả action sang backlog rồi không quay lại không ngăn sự cố tái diễn.

Checklist trước khi chốt

• ☐ Summary cho người không tham gia vẫn hiểu được.
• ☐ Impact nói về người dùng/chức năng, không chỉ metric máy chủ.
• ☐ Số liệu có nguồn hoặc ghi rõ là ước lượng.
• ☐ Timeline dùng một múi giờ và có mốc detection, mitigation, recovery.
• ☐ Trigger được tách khỏi các yếu tố góp phần.
• ☐ Không có câu quy kết phẩm chất hoặc động cơ cá nhân.
• ☐ Đã ghi điều làm tốt, điều cần cải thiện và nơi đã may mắn.
• ☐ Action item cụ thể, có owner, priority, tracking và success condition.
• ☐ Có ít nhất hành động phù hợp với failure mode: prevent, detect hoặc mitigate.
• ☐ Secret, dữ liệu khách hàng và chi tiết quản trị nhạy cảm không nằm trong bản chia sẻ rộng.
• ☐ Có mốc rà soát action item sau khi tài liệu được duyệt.

Kết luận

Postmortem không cần dài để có giá trị. Nó cần trung thực về tác động, rõ về chuỗi sự kiện và đủ sâu để chuyển từ “ai đã làm gì” sang “hệ thống đã cho phép lỗi xảy ra và lan rộng như thế nào”.

Quan trọng nhất, mỗi bài học phải đi tới một hành động có thể kiểm tra và có người theo dõi. Khi đó, sự cố nhỏ không chỉ kết thúc ở việc website hoạt động lại; nó giúp lần vận hành tiếp theo an toàn và dễ xử lý hơn.