Phân tích sự cố không đổ lỗi (blameless post-mortem) là cách nhìn lại một sự cố trong đó câu hỏi trung tâm không phải "ai gây ra" mà là "vì sao những gì người trong cuộc đã làm lại có vẻ hợp lý với họ vào lúc đó". Mục tiêu là tìm ra những điều kiện trong hệ thống — quy trình, công cụ, áp lực thời gian, thông tin thiếu — đã khiến sự cố dễ xảy ra, để sửa những điều kiện ấy.
"Không đổ lỗi" không có nghĩa là không ai chịu trách nhiệm. Nó có nghĩa là trách nhiệm được hiểu theo hướng kể lại đầy đủ và cùng sửa, thay vì chịu phạt rồi im lặng. Lý do rất thực dụng: nơi nào phạt người kể lại sai sót, nơi đó sai sót sẽ bị giấu đi, và hệ thống mất đi nguồn thông tin quý nhất của mình.
Bài này tập trung vào kỹ năng nhìn lại: cách đặt câu hỏi, cách dựng dòng thời gian, cách tránh cái bẫy của trí khôn sau sự việc. Phần xây văn hoá và chính sách nhân sự xung quanh việc này là một chủ đề riêng.
Từ hàng không, y tế tới các nhóm vận hành phần mềm
Cách nhìn sự cố theo hệ thống có gốc rễ lâu đời trong hàng không, nơi các cuộc điều tra tai nạn từ lâu tập trung vào chuỗi điều kiện dẫn đến tai nạn hơn là vào một phi công. Nhà tâm lý học James Reason, trong cuốn Human Error (1990), đưa ra hình ảnh được biết đến rộng rãi là "mô hình pho mát Thuỵ Sĩ": mỗi lớp phòng vệ của tổ chức đều có lỗ, và sự cố xảy ra khi các lỗ ở nhiều lớp tình cờ thẳng hàng.
Trong y tế, báo cáo To Err Is Human của Viện Y học Hoa Kỳ năm 1999 góp phần chuyển cách nhìn sai sót y khoa từ lỗi cá nhân sang lỗi hệ thống. Sidney Dekker, qua các cuốn sách về "lỗi con người", phổ biến ý tưởng rằng lỗi con người là điểm bắt đầu của cuộc điều tra, không phải kết luận của nó.
Giới vận hành phần mềm đưa cách làm này vào công việc hằng ngày. John Allspaw, khi làm ở Etsy, viết bài nổi tiếng năm 2012 về post-mortem không đổ lỗi; cuốn Site Reliability Engineering của Google (2016) dành hẳn một chương cho văn hoá post-mortem. Từ đó, khái niệm này lan ra nhiều ngành khác — sản xuất, logistics, dịch vụ khách hàng — bất cứ đâu có sự cố lặp lại và có người phải xử lý nó dưới áp lực.
Vì sao đổ lỗi làm hỏng việc học
Đổ lỗi dừng cuộc tìm hiểu quá sớm. Khi đã có một cái tên để chỉ, mọi người thấy câu chuyện đã khép lại. Câu hỏi "vì sao một người cẩn thận vẫn mắc lỗi ấy" không bao giờ được hỏi, và người kế tiếp ở cùng vị trí sẽ gặp đúng cái bẫy đó.
Đổ lỗi khiến thông tin biến mất. Người từng bị phạt vì kể thật sẽ không kể thật lần thứ hai. Những sự cố suýt xảy ra — loại cảnh báo rẻ nhất — sẽ không còn ai báo nữa.
Thay người không thay hệ thống. Nếu giao diện dễ bấm nhầm, quy trình có bước chồng chéo, ca trực quá dài, thì đổi người chỉ là chờ người mới bấm nhầm.
Đổ lỗi dựa trên trí khôn sau sự việc. Người phân tích biết kết cục, người trong cuộc thì không. Từ chỗ đã biết đáp án, mọi dấu hiệu đều trông rõ ràng và mọi lựa chọn sai đều trông ngớ ngẩn.
Không đổ lỗi không phải dung túng. Hành vi cố ý gây hại hoặc cố tình bỏ qua quy định an toàn vẫn được xử lý theo quy định. Nhưng đó là ngoại lệ hiếm; phần lớn sự cố đến từ người tử tế làm việc trong điều kiện không tốt.
Câu hỏi nên dùng và câu hỏi nên tránh
Kỹ năng cốt lõi của người phân tích là đặt câu hỏi khiến người trong cuộc kể lại tình huống, không phải bào chữa. Một vài cặp so sánh:
| Nên tránh | Nên hỏi | Vì sao |
|---|---|---|
| Tại sao bạn không kiểm tra lại? | Lúc đó bạn đang dựa vào thông tin nào để quyết định? | Câu đầu đã ngầm kết luận; câu sau mở ra bối cảnh thông tin |
| Bạn không thấy cảnh báo à? | Cảnh báo đó hiện ra ở đâu, cùng lúc với những gì khác? | Có thể cảnh báo bị chìm giữa hàng chục thông báo khác |
| Ai cho phép làm vậy? | Cách làm này có phổ biến trong nhóm không? Từ khi nào? | Thói quen tắt bước thường do cả nhóm hình thành, không phải một người |
| Lẽ ra bạn phải biết chứ? | Điều gì sẽ giúp bạn nhận ra sớm hơn? | Câu sau chuyển thẳng sang hướng sửa |
| Sao không gọi cấp trên? | Lúc đó gọi cấp trên có dễ không? Có ai đã từng gọi và nhận phản ứng thế nào? | Rào cản leo thang thường là chuyện văn hoá, không phải quên |
Câu hỏi khởi đầu bằng "tại sao bạn…" gần như luôn được nghe như lời buộc tội, dù người hỏi không có ý đó. Đổi sang "điều gì…", "lúc đó…", "thông tin nào…" là thay đổi nhỏ trong câu chữ nhưng làm khác hẳn chất lượng câu trả lời.
Các bước một buổi phân tích sự cố
Với sự cố có ảnh hưởng đáng kể, buổi phân tích thường đi qua các bước sau. Thời gian từ vài giờ tới vài ngày tuỳ độ phức tạp.
- Ổn định trước, phân tích sau. Không mở buổi phân tích khi sự cố còn đang xử lý. Nhưng cũng đừng để quá lâu; trong vòng vài ngày là hợp lý.
- Gom dữ kiện. Nhật ký hệ thống, tin nhắn trao đổi trong lúc xử lý, thời điểm từng quyết định. Phỏng vấn riêng từng người trước khi họp chung để không ai bị kéo theo lời kể của người khác.
- Dựng dòng thời gian. Ghi lại theo phút hoặc theo giờ: ai biết gì, lúc nào, làm gì. Đánh dấu những điểm có quyết định quan trọng.
- Tại mỗi điểm quyết định, hỏi vì sao nó hợp lý lúc đó. Đây là trái tim của phương pháp: tái dựng góc nhìn của người trong cuộc với thông tin, công cụ và áp lực họ có.
- Liệt kê các yếu tố góp phần, không tìm một nguyên nhân duy nhất. Sự cố phức tạp hiếm khi có một gốc; thường là vài lỗ hổng thẳng hàng.
- Chọn hành động. Ưu tiên những thay đổi làm cho việc làm đúng trở nên dễ hơn và việc làm sai khó hơn, thay vì chỉ "nhắc nhở cẩn thận".
- Chia sẻ rộng. Bản tóm tắt gửi cho cả những nhóm không liên quan trực tiếp, vì nhiều lỗ hổng tồn tại ở nhiều nơi cùng lúc.
Cái bẫy của trí khôn sau sự việc
Từ thập niên 1970, nhà tâm lý học Baruch Fischhoff đã mô tả hiện tượng mà ngày nay gọi là thiên kiến hồi tưởng: khi đã biết kết cục, người ta đánh giá kết cục ấy là dễ đoán hơn nhiều so với thực tế. Trong phân tích sự cố, thiên kiến này khiến người phân tích thấy mọi dấu hiệu cảnh báo "rõ như ban ngày", trong khi lúc đó chúng nằm lẫn giữa hàng trăm tín hiệu bình thường.
Đi kèm là thiên kiến kết cục: cùng một quyết định, nếu kết cục tốt thì được khen là nhanh nhạy, nếu kết cục xấu thì bị chê là liều lĩnh. Một buổi phân tích tốt phải tách đánh giá quyết định khỏi kết cục, bằng câu hỏi: với thông tin có lúc đó, một người có năng lực khác ở vị trí này có làm khác không?
Một kỹ thuật hữu ích là thay thế người trong cuộc: hỏi nhóm "nếu là một người khác cũng có kinh nghiệm như vậy, trong ca đêm thứ mười hai liên tiếp, với cùng màn hình và cùng hướng dẫn, liệu họ có làm khác không?". Nếu câu trả lời là "có lẽ cũng vậy", vấn đề nằm ở hệ thống. Đây cũng là lý do người dẫn buổi phân tích nên là người không có lợi ích gắn với kết luận, và nên chủ động nhắc nhóm mỗi khi câu chữ trượt về phía "lẽ ra phải".
Hành động sau phân tích: mạnh và yếu
Không phải hành động nào chốt ra cũng có giá trị như nhau. Sắp từ mạnh đến yếu theo khả năng ngăn sự cố lặp lại:
- Loại bỏ khả năng sai: thiết kế lại để bước nguy hiểm không thể làm nhầm, ví dụ hai thao tác giống nhau không còn nằm cạnh nhau.
- Tự động hoá phần dễ sai: chuyển bước kiểm tra thủ công lặp đi lặp lại sang cho công cụ làm.
- Buộc dừng để xác nhận: thêm bước xác nhận ở đúng chỗ rủi ro cao, nhưng chỉ ở đó — xác nhận ở mọi nơi thì người ta bấm qua theo phản xạ.
- Cải thiện thông tin: làm cảnh báo rõ hơn, bớt cảnh báo nhiễu, đưa thông tin cần thiết đến đúng người đúng lúc.
- Sửa quy trình và tài liệu: có ích nhưng yếu hơn, vì phụ thuộc vào việc người ta đọc và nhớ.
- Đào tạo lại, nhắc nhở cẩn thận: yếu nhất. Nếu đây là hành động duy nhất của buổi phân tích, rất có thể buổi phân tích chưa tìm ra yếu tố hệ thống nào.
Thứ tự này phỏng theo cách các ngành an toàn thường xếp biện pháp kiểm soát: biện pháp nằm trong thiết kế mạnh hơn biện pháp dựa vào trí nhớ và sự chú ý của con người.
Nhìn lại cả những lần suýt xảy ra sự cố
Một sự cố có thiệt hại thật thì ai cũng muốn phân tích. Nhưng những lần suýt xảy ra — đơn hàng giao nhầm được phát hiện ở cổng kho, lệnh chuyển tiền sai được chặn lại trước khi duyệt, bản cập nhật lỗi bị kiểm thử bắt được vào phút cuối — mới là nguồn học rẻ nhất. Chúng có cùng chuỗi điều kiện như sự cố thật, chỉ khác là một lớp phòng vệ cuối cùng đã kịp chặn.
Vấn đề là gần như không ai báo những lần suýt sai. Người trong cuộc thấy ngượng, thấy "có sao đâu mà kể", hoặc sợ bị đánh giá là bất cẩn. Muốn nhóm kể lại những chuyện này, cần ba điều: kênh báo nhanh và đơn giản, không hỏi tội người báo, và người báo thấy được thông tin của mình dẫn tới thay đổi cụ thể.
Phân tích một lần suýt xảy ra không cần đầy đủ như sự cố thật. Thường chỉ cần hỏi ba câu: lớp phòng vệ nào đã chặn được, nếu lớp đó không có thì chuyện gì xảy ra, và những lớp phía trước vì sao đã để lọt. Câu cuối quan trọng nhất, vì nó cho thấy những lỗ hổng đang mở mà chưa ai trả giá. Nhiều nhóm gom các lần suýt sai lại và nhìn chung mỗi tháng một lần; khi một kiểu suýt sai lặp lại ba bốn lần, đó là lúc chuyển sang phân tích đầy đủ.
Câu hỏi thường gặp
Không đổ lỗi thì người làm sai có bị xử lý gì không?
Phân tích không đổ lỗi tách việc học khỏi việc xử lý kỷ luật. Sai sót do điều kiện làm việc thì sửa điều kiện. Hành vi cố ý gây hại hoặc cố tình bỏ qua quy định an toàn vẫn được xử lý theo quy chế, nhưng qua kênh riêng, không qua buổi phân tích.
Có nên nêu tên người trong báo cáo phân tích sự cố không?
Nhiều nhóm dùng vai trò thay cho tên, ví dụ "người trực ca", "kỹ sư triển khai". Cách này giữ trọng tâm vào tình huống và giúp báo cáo dễ chia sẻ rộng mà không gây tổn thương cho cá nhân.
Sự cố nhỏ có cần phân tích kỹ như vậy không?
Không cần đầy đủ các bước. Sự cố nhỏ dùng một buổi nhìn lại nhanh. Nhưng sự cố nhỏ lặp lại nhiều lần thì nên gom lại phân tích chung, vì đó thường là dấu hiệu của một lỗ hổng hệ thống đang chờ gây chuyện lớn.
Làm sao phỏng vấn người trong cuộc khi họ đang căng thẳng?
Gặp riêng, nói rõ mục đích là hiểu tình huống chứ không phải đánh giá. Để họ kể theo trình tự của họ trước, chỉ hỏi chi tiết sau. Nếu người đó bị ảnh hưởng tâm lý nặng sau sự cố, ưu tiên hỗ trợ họ trước, việc phân tích có thể chờ.
Năm câu hỏi vì sao có dùng được trong phân tích không đổ lỗi không?
Dùng được cho sự cố đơn giản, nhưng có nhược điểm: dễ đi theo một chuỗi duy nhất và dừng lại ở một con người. Với sự cố phức tạp, nên hỏi vì sao theo nhiều nhánh và chấp nhận rằng có nhiều yếu tố góp phần.
Ai nên đọc bản phân tích sự cố?
Ngoài nhóm trực tiếp liên quan, nên gửi cho những nhóm làm công việc tương tự và cấp quản lý có quyền sửa quy trình, công cụ. Giá trị lớn nhất của một bản phân tích là giúp nơi khác tránh được sự cố tương tự trước khi nó xảy ra với họ.