經驗分享：一位初級工程師如何在亞馬遜五年時間內修復數百個Bug？

banq發表於2021-01-15
工程師亞馬遜

Curtis Einsmann在亞馬遜的5年中已經診斷並解決了數百個錯誤。作為一名初級工程師，大型軟體系統中的錯誤診斷具有挑戰性。 下面是他的經驗總結：
原因的診斷很重要。不成熟的解決方案使得問題持續存在，這些微小的缺陷很容易被開發人員忽略。診斷原因是修復的第一步。
清晰表達問題：
  • -預期會發生什麼行為？
  • -是否有錯誤程式碼或螢幕截圖？
  • -是否可以使用已知的識別符號進行診斷？
  • -確切的時間（和時區）？

這種清晰性為我提供了一個具體的起點。
將所有書面交流都視為故事，這可能是對也可能是錯。問題描述講述了發生的事情。系統文件講述了事情的運作方式。故事不是100％的真理。我懷著懷疑的態度閱讀。事實是在程式碼和日誌中。
我確保我正在瀏覽正確的日誌和程式碼提交。我避免了以下常見的令人沮喪的錯誤：
  • -讀取錯誤的日誌
  • -讀取錯誤的時間跨度
  • -在與事件時間不一致的提交中瀏覽原始碼

這樣可以節省時間（和我的理智）。
我同時閱讀日誌和程式碼。日誌告訴我執行了什麼程式碼。該程式碼告訴我要查詢哪個日誌語句。我按已知的識別符號過濾日誌：請求ID、實體ID、使用者ID。 此過程需要時間和耐心。
我會注意誤導日誌。堆疊跟蹤和錯誤訊息非常有用，只要它們與問題相關。有時候，現象欺騙了我。我跳進坑，把自己從大坑裡拉出來。迭代之後，我會對發生的事情提出了一個假設。
我檢驗我的假設。這對於確認發生了什麼是必要的。我使用alpha或beta環境。根據情況，這可以是手動測試和/或單元測試。如果被證明是錯誤的；回到日誌。如果證明是正確的，是時候修復該錯誤了。
經過測試暴露後，我修復了該錯誤。錯誤修復是使用嚴格的TDD方法的絕好機會。我編寫一個失敗的測試，更改程式碼，並觀察透過的測試。
我會在修復報告ticket中記錄了詳細資訊：
  • -根本原因
  • -日誌連結
  • -過濾器表示式或Linux命令
  • -相關指標
  • -我如何修復它保持記錄。

它會幫助以後的同行遵循類似的流程。
我會為診斷期間遇到的痛點建立了積壓任務：
  • -很難找到日誌嗎？
  • -日誌不足或不正確？
  • -診斷乏味嗎？
  • -為方便起見，

我們會編寫運維指令碼，這改善了長期的卓越運營。
這就是我診斷和解決大型軟體系統中的錯誤的方式。

相關文章