軟體工程師該如何做好事故檢討?

先前我們分別談了 《軟體工程師該如何做好監控 (monitoring)？》 和 《軟體工程師該如何值班 (on-call)?》，這篇文將延續這個主題，來聊事故完後的檢討。

一般來說，假如只是一個沒有對終端使用者太多影響的小問題，可以不須用開事故檢討；然而，如果有造成一定程度的影響，事故檢討就會有必要。開事故檢討不是要找戰犯，而是要確保問題能夠被根治，以及確保未來不會再發生類似問題。

在業界，事故檢討一般有幾個名稱，包含 incident review (直譯就是事故檢討)、sev review (sev 是在 軟體工程師該如何做好監控 (monitoring)? 一文有談到的概念，也代表事故)，以及 postmortem (英文的另一個意思是驗屍，事故檢討本質跟驗屍有些類似，都是事後回頭找發生事情的原因)。

事故檢討的本質

要做好事故檢討這件事，需要先釐清事故檢討的本質。造成事故對個人與團隊肯定都會有傷害，然而沒有人是完美不會犯錯的，所以事故是在所難免。不過，當事故已經發生了，該專注的就是解決，以及確保未來可以做更好。

所謂做更好，具體來說，首先是要去釐清如何確保同樣的問題，在未來不會再次發生? 假如真的無法完全避免問題，那有沒有方法能讓問題及早被發現? 以及當發現問題後，有沒有更快解決問題的方法?

找出上面這幾個問題的答案，才是事故檢討應該做的。

而在事故檢討時，每位參與的人員，要抱持著「從錯誤中學習」的心態。從事故檢討學習到的，也需要進一步傳承，這也是為什麼許多制度完善的公司，在事故檢討時，都會有完整的會議記錄，來確保其他團隊，甚至公司中其他組的人，都能一起從該經驗中學習。

不指責人的事故檢討

談到事故檢討不能不提的點，那就是「不指責人的事故檢討」。

如上面提到，事故檢討的本質是為了避免未來再出現同樣的問題。基於這個本質，要盡可能避免在事故檢討中去找戰犯。這世界沒有完美的人，也沒有完美的流程，犯錯總是難免的，只是如果同樣的錯誤再犯就不應該；因此團隊該關注的，不是誰犯錯，而是如何讓未來不會再犯同樣的錯。

先前 Meta 工程副總 Vijaye 在 2021 年 Meta 全球規模重大事故後，有發一篇分享 (連結)，談到不指責人的事故檢討 (blameless SEV review)。他提到，在事故檢討時，不應該問「誰造成這次事故」，因為在這個時機點找戰犯，不僅對於解決問題沒幫助，也會導致未來大家不敢做有風險的創新嘗試。

在台灣軟體史上，有一個叫趨勢 594 的歷史事件，是當年趨勢科技有工程師發布程式碼前測試不完全，導致客戶的系統癱瘓，造成趨勢科技市值蒸發 170 億元台幣。當時趨勢的執行長受訪的報導 (連結)有這麼一個段落：

「我相信，我只要問一句：『誰寫的？為什麼沒測試好就發出來了？』我想， （公司）從此就完蛋了！」陳怡樺說， 當時不斷提醒自己，不要傷害員工創新精神， 「不要問我是哪個員工幹的？是哪個部門？」

事件過去 8 年，「元兇」是誰，仍是趨勢內部的一個謎，只有少數高層才知道。

危機就是轉機，因為這起「失誤的創新」，讓陳怡樺開始思考， 是否可以「不要把更新病毒碼的程式放在客戶的電腦裡」， 也因此讓趨勢領先同業至少三、四年發展雲端技術， 趨勢才有機會成為如今伺服器安全市場的龍頭。

這是一個很好的示範，說明了什麼是不指責的檢討，以及為什麼要不指責。事實上，當一個組織文化演變成找戰犯、指責人的情況，當問題發生時，犯錯的那個人或團隊，很可能會試圖掩蓋問題 (因為不想被指責或背鍋)，這對於解決問題反而是不利的。這也是為什麼多數有良好文化的組織，會強調在出事故時不指責人，而是專注在針對事。

閱讀更多

如果你對於如何做好事故檢討感興趣，我們在 E+ 有寫更深入詳細的內容，包含具體在開事故檢討會議有什麼要訣? 如何做好事故檢討的文件紀錄? 業界有哪些推薦的參考資源? 有興趣的讀者，歡迎加入 E+ 成長計畫。

本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)