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

banq發表於2021-01-15

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

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

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

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

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

相關文章