Blameless Postmortem:把故障變成組織的學習

上一篇講怎麼找到 root cause——但找到之後呢?Postmortem(事後檢討) 就是把一次昂貴的故障,轉化成整個組織的學習:記錄發生什麼、影響多大、時間軸、真因、怎麼修的、怎麼防止再發生。而它的靈魂,是一個看似簡單卻極難做到的詞:blameless(對事不對人)。

靈魂是 blameless:對事不對人

同一場故障,「究責」和「blameless」會把團隊帶向兩個完全相反的循環:

為什麼究責這麼致命?因為它嚇跑了真相。當犯錯要被懲罰,人就會本能地隱藏錯誤、修飾時間軸、不敢說「其實我當時看到 X 但沒在意」——而你要學到教訓,偏偏就需要那個完整、誠實的真相。blameless 不是「當爛好人、沒人負責」,是為了拿到真相而刻意設計的安全感。

人幾乎從來不是 root cause

blameless 還有一個更硬的底層邏輯:人一定會犯錯,這是常數;所以「防止人犯錯」是徒勞的,該做的是「讓人犯錯也不會釀成災難」。 舉個經典例子——有人一行指令誤刪了正式資料庫:

所以 postmortem 有個重要前提:假設每個人當下都是根據他手上的資訊,做了合理的決定(assume good intentions)。 沒有人早上起床想著「今天來搞垮系統」。當你這樣假設,注意力就自然從「這個人怎麼這麼笨」轉向「什麼樣的系統、流程、資訊落差,讓一個合理的人做出了會出事的動作」——而後者才修得動。

Blameless 不等於不負責

要澄清一個常見誤解:blameless 不是「沒人負責、大家和稀泥」。 它一樣要有明確的 action items、要有人 own、要追蹤到完成——只是焦點放在改系統,不是罰個人。而 action item 必須具體、可執行:「幫刪除指令加上二次確認」「把備份還原演練排進每月」是 action item;「大家以後小心一點」不是——那只是把同樣的痛,原封不動留給下一次。

反思

Blame 的代價,是把「學習」嚇跑了

究責最大的傷害,其實不是落在被罵的那個人身上,而是它讓「說真話」變得危險。一旦承認錯誤要付代價,整個團隊就會開始隱藏、修飾、防衛——而你最需要的,偏偏是那個沒被修飾的完整真相。所以我越來越把 blameless 看成一種很務實的設計,不是道德姿態:你放棄追究個人,是為了換取誠實;而誠實,是團隊能從失敗學到東西的唯一前提。 這跟我在帶人、在 Tech Leader 那條線上一直相信的心理安全感是同一件事——人只有覺得安全,才敢誠實;而不誠實的團隊,再多故障也學不會。

如果一個人手滑就能搞垮系統,那是系統的問題

這句話我想放大講,因為它硬到可以當信條。人會犯錯是常數,不是變數;既然你消不掉它,把力氣花在「防止人犯錯」上就是白費。真正該做的是讓系統對人的錯誤有韌性——防呆、二次確認、最小權限、能快速還原。誤刪資料庫的 root cause 從來不是「Alice 手滑」,是「系統允許一次手滑就毀掉一切」。這跟 第一篇講的「容錯不是無錯」根本是同一句話,只是這次容的是人的錯:好系統假設人會犯錯,然後讓犯錯也不至於釀成災難。

沒寫 postmortem,等於白痛一次

故障的學費非常貴——熬夜、道歉、掉信任、燒掉 error budget。這麼貴的東西,如果不換成一份能讓組織記住、能防止再犯的 postmortem,那就是純虧。我現在把寫 postmortem 當成「把痛苦變成資產」的動作:反正都痛了,至少要換到一個更穩的系統、和一群真的學到東西的人。而這筆交易能不能成立,全看 action item 是不是具體、有 owner、追得到——這也呼應 上一篇說的「記錄你做了什麼」:除錯留下的軌跡,正是 postmortem 最好的原料。痛都痛了,別讓它白白過去。