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

2024年9月26日

💎 加入 E+ 成長計畫 與超過 400+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

先前我們分別談了 《軟體工程師該如何做好監控 (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+ 的詳細介紹)

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們