選工作前，先了解該公司怎麼做事故檢討

今晚在寫 E+ 的主題文時，看一些資料看到 AWS S3 在 2017 年有個重大事故，導致損失超過 1.5 億美元，而該重大事故的原因是來自打錯字 (typo)。

多數人看到這，可能第一時間想 AWS 這麼大一間公司，怎麼會犯「打錯字」這種低級錯誤? 過程中沒有檢查機制嗎? 出問題怎麼會直接影響全球，沒有先金絲雀部署嗎?

當年我造成的事故

但我看到這個事件的歷史資料時，第一個想到的是我在前公司造成的一個事故，雖然不是因為打錯字，但因為處理某個配置的資料格式有誤，導致數十個模組在生產環境直接被影響到。

那時我被拉進一個線上會議，裡面有各地辦公室加起來快五十個工程師，因為他們負責的東西都被影響到。

好在前公司在部署回滾的整體配套很完整，整個事故不到十分鐘被回滾解決，但是突然被拉進那麼多人的會議，然後發現自己竟然是搞出事故的人，那種頭腦一片白、全身起雞皮疙瘩的感覺，至今想忘都忘不掉。

然而，如同所有事故，緩解事故本身重要，但事故後的檢討更重要。更進一步說，如何檢討事故又更加重要。

不指責人的事故檢討很重要

記得當時的主管跟我說，不要擔心，就把這當一個學習經驗，然後確保未來同樣的問題不會再發生。

在那之前我其實已經讀過不指責人的事故檢討 (blameless postmortem) 的概念，只是當自己成為造成事故的事主後，才更加意識到這種做法的重要性。

那次的事故檢討後，做了許多實際的調整。這讓我在看 S3 2017 年事故的檢討時，覺得特別熟悉，因為他們檢討後做出的改進，幾乎跟我當年造成的事故後的具體調整很相似。

除了最基本在配置檔案加上格式校驗的邏輯外，原本只有程式碼部署強制走金絲雀 (canary)，後來配置也加上強制金絲雀，然後直接把監控面板跟金絲雀部署的流水線 (pipeline) 串一起，每個配置部署時都確保有完整監控。以及當事故發生時，根據監控的設定，在偵測事故時把部署自動回滾 (rollback)。

因為加上這些機制，在未來同樣的低級錯誤，變得不可能發生。這類從工程的角度來避免人為錯誤的可能性，是事故檢討的價值所在。

面試時記得問對方如何做事故檢討

因為那次經驗，後來找工作時，在面試階段的提問時間，我一定會問面試官如何做事故檢討。因為確保是用不指責人、專注在改善的方式，才會是我會想去的團隊。

這世界沒有完美的人，也沒有完美的流程，犯錯總是難免的，只是如果同樣的錯誤再犯就不應該；因此團隊該關注的，不是誰犯錯，而是如何讓未來不會再犯同樣的錯。

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

如果你對這個主題感興趣，或者對於成為資深工程師該具備哪些軟硬實力感興趣，歡迎加入我參與製作內容的 E+ 成長計畫，在 E+ 裡面當中有更深度的內容，E+ 的介紹可以在這個 連結 看到。