Làm thế nào để chạy một blameless post-mortem sau sự cố?

Question

Accepted Answer

Một **blameless post-mortem** xem sự cố như thất bại của *hệ thống và điều kiện*, không phải của con người. Câu hỏi không bao giờ là "ai đã làm hỏng" mà là "hệ thống của chúng ta đã để một người hợp lý gây ra điều này như thế nào, và làm sao để lần sau điều đó bất khả thi?"

## Quy trình

1. **Dựng timeline.** Tái hiện những gì đã xảy ra từng phút: phát hiện, leo thang, giảm thiểu, khắc phục. Bám sát sự thật.
2. **Tìm các yếu tố góp phần.** Hầu hết sự cố có nhiều yếu tố. Dùng kỹ thuật như **5 Whys** để vượt qua triệu chứng bề mặt đến **root cause** — thiếu alert, một deploy dễ gãy, một runbook không rõ ràng.
3. **Tạo ra action item.** Mỗi mục phải **cụ thể, có người chủ và có deadline**. "Cẩn thận hơn" không phải là action item; "thêm kiểm tra migration trước khi deploy" mới là.
4. **Chia sẻ rộng rãi.** Công bố bản viết để cả tổ chức học hỏi, không chỉ những người có mặt trong phòng.

## Blameless trong thực tế

- Mô tả **chuyện gì** đã xảy ra và **tại sao lúc đó nó hợp lý**, không phải **ai** đáng trách.
- Giả định mọi người đã hành động hợp lý với thông tin họ có.
- Nếu một hành động đơn lẻ của con người có thể đánh sập production, đó là **lỗ hổng hệ thống**, không phải lỗi cá nhân.

## Tại sao psychological safety quan trọng

Khoảnh khắc mọi người sợ bị đổ lỗi, họ giấu chi tiết, giảm nhẹ vai trò của mình, và nguyên nhân thực sự vẫn bị chôn vùi. **Psychological safety thúc đẩy sự trung thực**, và trung thực là thứ duy nhất tạo ra những bản sửa thực sự bền vững.

## Tại sao điều này quan trọng

Sự cố là học phí đắt đỏ — blameless post-mortem là cách bạn thực sự rút ra được bài học. Làm tốt, cùng một sự cố không tái diễn, hệ thống trở nên kiên cường hơn sau mỗi lần hỏng, và nhóm tin rằng việc nhận lỗi khiến mọi thứ tốt hơn, chứ không tệ đi.