加快生產故障排除的 7 種調試技術

為應用程序提供生產支持是軟件開發中最具挑戰性的方面之一。 開發人員被分配到維護團隊並致力於修補應用程序上的錯誤。 但是，如果發生生產中斷，它們也可以隨時待命，在這種情況下，它們會努力使應用程序盡快回到正軌。

本文旨在提供一組精心策劃的建議，以便您可以防止生產中的錯誤，並更快地發現問題。 在生產環境中處理這些應用程序是一項複雜的任務：通常沒有可用的文檔，或者應用程序是在遺留技術堆棧中編寫的，或者兩者兼而有之。 培訓課程很少，並且通常會被要求為您知之甚少的應用程序提供支持。

許多開發人員沒有在生產環境中處理應用程序的經驗。 生產環境中發生的一系列問題會導致錯誤和中斷，通常會給公司造成數千甚至數百萬美元的收入損失。 此外，由於大多數開發人員沒有接觸過環境，他們不斷地犯一些錯誤，進而導致這些問題。 通過從生產經驗中進行教學，此提示列表應該可以減輕您的工作痛苦。

提示 #1：刪除或自動化應用程序運行所需的所有配置。

在新服務器上安裝軟件需要多少配置？ 過去，每次團隊中有新開發人員時，有時可能需要三天才能完成。 安裝應用程序需要許多必須手動執行的步驟。 隨著時間的推移，軟件發展到與這些指令不兼容的新版本，當然，指令通常不會更新。 突然之間，您花費的時間比必要的多，只是為了啟動和運行應用程序。

隨著容器化的出現，提供一種讓應用程序立即啟動並運行的方法變得更加容易，零配置和額外的好處是，由於 Docker 映像是自包含的，因此您運行的速度要低得多使用不同版本的操作系統、語言和框架時遇到問題的風險。

同樣，簡化開發人員設置，因此啟動和運行不需要太多時間，包括 IDE 設置。 開發人員應該能夠在不到 30 分鐘的時間內從零變成英雄。

當生產問題發生時，有時您最好的專家可能不在（例如，休假或生病），而您希望您提出的任何人都能夠快速解決它。

提示 #2：不要落入技術棧湯陷阱。

使用的技術越少越好。 當然，有時，您必須使用正確的工具來完成這項工作。 但是，請注意不要過度使用“正確的工具”。 如果你喝得太多，即使是喝水也會導致嚴重的健康問題。 添加到技術堆棧中的每一種新語言和框架都必須經過一個明確定義的決策過程，並仔細考慮影響。

• 不要僅僅因為您需要StringUtils類而添加新的框架依賴項。
• 不要僅僅因為您需要編寫一個快速腳本來移動文件而添加一種全新的語言。

當庫變得不兼容或在框架本身或其傳遞依賴項上發現安全威脅時，一大堆依賴項會讓你的生活變得悲慘。

此外，請記住，增加的堆棧複雜性使得為團隊尋找和培訓新開發人員變得具有挑戰性。 人們轉移到其他公司的新角色，你必須找到新的。 工程團隊的人員流動率非常高，即使是在那些以擁有豐厚福利和工作與生活平衡而聞名的公司中也是如此。 您希望盡快找到新的團隊成員。 在技​​術堆棧之上添加的每一項新技術都會增加尋找新候選人的時間，並且有可能使新員工變得越來越昂貴。

提示 #3：日誌記錄必須引導您找到問題，而不是用無用的細節淹沒您。

日誌記錄與評論非常相似。 有必要記錄正在採取的所有關鍵決策以及在調試技術中使用的所有信息。 這並不簡單，但只要有一點經驗，就可以繪製出一些可能的生產中斷場景，然後放入必要的日誌記錄以至少解決這個問題。 當然，日誌記錄與代碼庫一起發展，具體取決於出現的問題類型。 一般來說，您應該將 80% 的日誌記錄在最重要的 20% 代碼上——使用最多的部分。 例如，重要信息是傳遞給方法的參數的值、子類的運行時類型以及軟件做出的重要決策——即，它處於十字路口的時間，它選擇了左還是右。

提示#4：處理意外情況。

非常清楚地標出代碼的假設是什麼。 如果某個變量應始終包含值 2、5 或 7，請確保它是枚舉類型，而不是 int。 大規模生產中斷的第一個來源是某個假設失敗。 每個人都在錯誤的地方尋找問題，因為他們認為一些事情是理所當然的。

假設應該明確記錄，並且這些假設的任何失敗都應該引起足夠的警報，以便生產支持團隊可以快速糾正這種情況。 還應該有代碼來防止數據進入無效狀態，或者至少在這種情況下創建某種警報。 如果某些信息應該存儲在一個記錄中，而突然有兩個記錄，則應發出警告。

提示#5：複製發生在客戶身上的問題應該很簡單。

最困難的步驟之一始終是複制客戶面臨的問題。 很多時候，您將花費 95% 的時間來嘗試複製問題，然後在您可以復制它的那一刻，修補、測試和部署只需幾分鐘。 因此，應用程序架構師應該確保複製問題非常簡單和快速。 發生很多這種情況是因為，為了達到與客戶相同的情況，開發人員必須進行大量的應用程序配置。 存儲了許多記錄，這些記錄共同構成了客戶所處的情況——問題是您作為開發人員必須準確猜測客戶做了什麼。 有時，他們執行了一系列步驟，他們只記得最後一個。

此外，客戶將用業務術語解釋問題，然後開發人員必須將其轉換為技術術語。 如果開發人員對應用程序的經驗較少，他們將不知道要詢問缺失的細節，因為他們甚至還不知道缺失的細節。 將整個生產數據庫複製到您的機器是不可行的。 所以應該有一個工具可以從生產數據庫中快速導入模擬情況所需的少數記錄。

假設客戶對訂單屏幕有疑問。 您可能需要導入他們的一些訂單、他們的客戶記錄、一些訂單詳細記錄、訂單配置記錄等。然後您可以將其導出到 Docker 實例中的數據庫中，啟動該實例，就像這樣，您看到與客戶看到的相同的東西。 當然，所有這一切都應該以適當的謹慎來完成，以確保沒有開發人員可以訪問敏感數據。

提示 #6：在應用程序中放置斷點的位置應該很明顯。

如果您有一個客戶屏幕，則應該有一些客戶對象，您可以在其中放置斷點以在該屏幕上調試問題。 有時開發人員會陷入抽象熱，並提出一些關於如何處理用戶界面事件的非常聰明的概念。 相反，我們應該始終依賴 KISS 原則（保持簡單、簡潔、愚蠢），並為每個 UI 事件提供一個易於定位的方法。 同樣，對於批處理作業和計劃任務——應該有一種簡單的方法來確定斷點的位置，以評估該代碼是否工作。

提示 #7：確保所有外部依賴項都明確記錄在案。

理想情況下，在源代碼控制系統的 README 文件中執行此操作，這樣文檔就不會丟失。 記錄應用程序正常運行必須可用的任何外部系統、數據庫或資源。 此外，請注意其中哪些是可選的，並添加有關如何在它們是可選且不可用時進行處理的說明。

超越調試技術

一旦在創建新功能或為系統提供維護時遵循這些建議，生產支持將變得更加容易，您的公司將花費更少的時間（和金錢）。 如您所知，在解決生產錯誤和崩潰問題時，時間至關重要——任何可以節省的時間都會對利潤產生重大影響。 快樂編碼！