聊聊事故檢討今晚在寫 E+ 的主題文時，看一些資料看到 AWS S3 在 2017 年有個重大事故，導致損失超過 1.5 億美元，而該重大事故的原因是來自打錯字 (typo)。多數人看到這，可能第一時間想 AWS 這麼大一間公司，怎麼會犯「打錯字」這種低級錯誤? 過程中沒有檢查機制嗎? 出問題怎麼會直接影響全球，沒有先金絲雀部署嗎? 但我看到這個事件的歷史資料時，第一個想到的是我在前公司造成的一個事故，雖然不是因為打錯字，但因為處理某個配置的資料格式有誤，導致數十個模組在生產環境直接被影響到。那時我被拉進一個線上會議，裡面有各地辦公室加起來快五十個工程師，因為他們負責的東西都被影響到。好在前公司在部署回滾的整體配套很完整，整個事沒多久就被回滾解決，但是突然被拉進那麼多人的會議，然後發現自己竟然是搞出事故的人，那種頭腦一片白、全身起雞皮疙瘩的感覺，至今想忘都忘不掉。 (留言續)

串文

2024-11-12 13:42

讚

124

回覆

轉發

作者

工程師 Li 的後設思考
mtbyli

粉絲

1,604

串文

57+

讚

回覆

轉發

24小時粉絲增長

發文前

1,250

發文後24小時

1,283

變化

+33 (2.64%)

互動率

(讚 + 回覆 + 轉發) / 粉絲數

8.79%

回覆 (BETA)

最先回覆的內容
發文後	用戶	內容
幾秒內	工程師 Li 的後設思考 mtbyli	然而，如同所有事故，緩解事故本身重要，但事故後的檢討更重要。更進一步說，如何檢討事故又更加重要。記得當時的主管跟我說，不要擔心，就把這當一個學習經驗，然後確保未來同樣的問題不會再發生。在那之前我其實已經讀過不指責人的事故檢討 (Blameless postmortem) 的概念，只是當自己成為造成事故的事主後，才更加意識到這種做法的重要性。那次的事故檢討後，做了許多實際的調整。這讓我在看 S3 2017 年事故的檢討時，覺得特別熟悉，因為他們檢討後做出的改進，幾乎跟我當年造成的事故後的具體調整很相似。除了最基本在配置檔案加上格式校驗的邏輯外，原本只有程式碼部署強制走金絲雀 (canary)，後來配置也加上強制金絲雀，然後直接把監控面板跟金絲雀部署的流水線 (pipeline) 串一起，每個配置部署時都確保有完整監控。以及當事故發生時，根據監控的設定，在偵測事故時把部署自動回滾 (rollback)。加上這些機制後，同樣的低級錯誤，變得不可能發生。這類從工程的角度來避免人為錯誤的可能性，是事故檢討的價值所在。 (留言續)
15 小時內	Jubilee Tan jubileetan1010	這個很強，尤其是低級錯誤，越難誠實面對
16 小時內	lhf_516	十分同意不過很好奇你是怎樣問面試官的呢？要知道面試的時候一定只會說自己怎樣好，一定不會說自己會怪責別人所以想知道你是怎樣令到他說出真心話呢？
16 小時內	Nobody theon.lin	沒事的，之前有遇過團隊的小白工程師把線上客戶的資料庫清空了，還好我們有每天備份，再加上比較敏感的金錢交易，都有兩套以上的log，可以至少重建這幾個小時的交易。大家說要給新人犯錯的空間，但代價都是客戶在損失，說一句話客戶真的因此倒了，真的是賣屁股一輩子也賠不起的，怕爆