【51CTO.com快譯】從定義角度來看，故障排查相當于對問題根源進行一種邏輯性、系統性搜索，旨在找到將其解決的辦法。然而，結合實際情況，可能很少有人能夠將其與邏輯或者系統這樣的字眼聯系起來。開什么玩笑——忙著猜測可能原因才是實際情況，對吧?

　　如果您也有這樣的感受，那么您最終一定會在尋找答案中浪費大量時間。更糟糕的是，也許問題始終無法得到解決。

　　在今天的文章中，我們將立足于幾項根本問題嘗試找到解決思路。而在后半段內容里，我們則將分享相關工具與人為因素等議題。

　　生產環境中的故障排查

　　在對生產環境中的特定問題進行故障排查時，總會引發一系列后續麻煩。多種多樣的潛在可能性往往令這一過程變成了玄學性質的事物：

　　首先，大家應當打消“直接重啟讓其恢復工作”這樣的念頭。雖然這種方式往往能快速解決問題，但卻也會同時破壞產生此前問題的重要證據。而且即使重啟能夠暫時解決問題，請相信我，只要根本原因仍然存在，那么其早晚還會再次出現。

　　接下來考慮安全性相關內容，包括確保技術調試不會對生產環境造成影響。有時候我們必須以遠程方式進行環境訪問，這意味著每項操作都需要跳轉多次、增加執行時間周期并可能在此期間丟失部分關鍵性信息。

　　更糟糕的是，一旦我們向生產環境中發布了不確定能否奏效的補丁，那么其相關測試與應用工作可能耗時數小時甚至數天，這進一步增加了修復問題的周期。如果需要使用大量這類猜測性補丁，那么也許問題要到數周后才能徹底得到解決。

　　***同樣重要的是，我們在解決問題過程中所使用的實際工具。其中部分工具可能會對最終用戶造成負面影響。舉例來說：

　　從JVM進行轉儲可能導致JVM本身卡住數十秒。

　　增加日志記錄長度可能引發其它并發問題。

　　附加分析器的資源消耗可能導致本已運行緩慢的應用徹底崩潰。

　　總而言之，從編寫腳本到將補丁投放至生產環境，整個過程往往需要數天或者數周。

　　正因為存在上述難題，因此我們大多會在不同環境中實施故障排查舉措。

　　在測試與開發環境中進行故障排查

　　在其它環境中進行故障排查時，大家可以有效避免生產環境內可能出現的種種弊端。然而，大家仍然面對著其它一些完全不同的問題，情況甚至可能更糟：某些在生產環境中出現的性能問題難以重現。其它因素亦會對故障排查工作造成不利影響：

　　測試環境與生產環境使用的數據源不同。 這意味著由數據量引發的問題無法在測試環境內重現。

　　很難針對特定問題重現將其引發的使用模式。某些問題可能只會出現在2月29日，且要求兩位用戶通過Windows ME同時訪問同一特定功能。

　　應用本身并不完全相同。生產部署與配置方案間可能存在些許差別。這種差異包括不同操作系統、集群化功能、啟動參數甚至是不同build。

　　這些差別直接引發了“在我的機器上沒問題”這類令人頭痛的狀況。

　　除了環境之外，其它一些影響因素也會增加故障排查流程中的不確定性。

　　成熟的工具與高水平人員能否解決問題?

　　如果配合正確的工具以及嚴格而成熟的故障排查流程，那么環境層面的差異將不再是問題。然而，在現實當中即使是專門負責解決問題的工程技術人員，往往也不具備任何預定義流程完成這項工作。對此抱有異議?大家不妨看看以下Shell代碼——您能弄清其具體執行順序嗎?

　　my-precious:~ me$ sar

　　sar: failed to open input file [-1][/var/log/sa/sa06]

　　/usr/bin/sar [-Adgpu] [-n { DEV | EDEV | PPP }] [-e time] [-f filename] [-i sec] [-s time]

　　my-precious:~ me$ man sar

　　my-precious:~ me$ sar 1

　　15:29:02 %usr %nice %sys %idle

　　15:29:03 1 0 2 97

　　Average: 1 0 2 97

　　my-precious:~ me$ sar 1 1000

　　15:29:06 %usr %nice %sys %idle

　　15:29:07 2 0 2 97

　　15:29:08 1 0 2 97

　　^CAverage: 1 0 1 97

　　my-precious:~ me$ man sar

　　my-precious:~ me$ sar -G 1 3

　　sar: illegal option -- G

　　/usr/bin/sar [-Adgpu] [-n { DEV | EDEV | PPP }] [-e time] [-f filename] [-i sec] [-s time]

　　my-precious:~ me$ asdöäaskdasäl;

　　-bash: asdöäaskdasäl: command not found

　　my-precious:~ me$

　　是不是看起來很眼熟，別擔心，您絕對不是一個人。事實上，大多數工程師都缺少深層故障排查經驗，因此無法快速發現其中的共通性模式。除非您是天才，否則一般需要經過上萬小時的故障排查工作才能真正掌握這方面技能。

　　經驗的匱乏往往影響到您用于處理問題的具體信息收集工具，其中包括但不限于：

　　收集不同指標(CPU、內存、IO、網絡等)。

　　分析應用日志。

　　分析GC日志。

　　捕獲并分析線程轉儲。

　　捕獲并分析堆轉儲。

　　可資利用的此類工具多種多樣，然而經驗的缺乏往往導致您不了解其中哪些工具適用于哪些情況，這意味著大家需要耗費大量時間嘗試其實際效果。

　　解決故障排查難題

　　除了投入大量時間進行實踐外，我們還可以通過以下方式快速解決故障排查難題。

　　首先需要強調，本文并不涉及對技術堆棧本身的分析。相反，我們關注的是對應用程序內各組件的了解，包括其具體內存占用量，這能夠有效防止最終用戶在實際使用時遭遇問題。

　　然而，數據的差異導致我們只能發現一部分生產環境中可能出現的問題。各類前瞻性問題解決手段往往無法有效完成故障排查中的根源追溯任務。

　　QA測試

　　在QA(即質量保證)階段，我們應當以自動化方式建立測試機制。這類測試能夠進一步降低生產環境中出現的問題數量。

　　然而，QA中的投入往往很難獲得明確的回報。畢竟與新型功能相比，“性能測試”或者“可接受度測試”之類的東西顯然沒什么吸引力。為了證明投資回報，我們應當將其與明確的指標加以聯系。在生產環境中將性能問題減少至三分之一能夠帶來怎樣的實際經濟收益，這樣的結論不僅能夠讓管理層下定決心，亦足以幫助營銷團隊開展工作。

　　生產環境監控

　　我們必須接受一項事實，即無論如何生產部署都有可能出現問題。即使是美國宇航局也遭遇過火箭爆炸事故，因此大家***為這些潛在問題作好充分準備。

　　為了更好地籌備生產環境故障排查工作，我們應當提升生產環境的透明度。當問題出現時，大家***已經掌握全部證據并進行針對性解決。

　　遺憾的是，監管工作同樣需要通過多種方式才能實現。典型Web應用的部署工具就至少包括：

　　日志監控。從生產堆棧中的各節點處進行日志匯總，保證工程團隊能夠快速搜索信息、進行日志可視化并標記異常警報。目前最為常見的解決方案為ELK堆棧，其中日志存儲于Elasticsearch中，由Logstash負責分析，并由Kibana進行可視化處理。

　　系統監控。對基礎設施內的系統級指標進行聚合與可視化既能夠帶來顯著收益，又切實可行。我們應著眼于CPU、內存、網絡及磁盤資源使用量，從而及時發現系統級問題并對異常狀況進行警報。

　　應用性能監控與用戶體驗監控。關注用戶交互過程中的性能水平與可能造成負面影響的可用性問題。至少，大家應當在應用發生故障時及時得到提醒。另外，如果配合使用Plumbr，則能夠更為具體地查看源代碼中的問題根源。

　　總結

　　故障排查是件讓人頭痛但又不得不做的工作。而且很明顯，我們無法忽視不同環境中的差異性因素，也不可能一夜之間成為技術專家。因此，請確保在開發與測試階段進行應用分析，減少生產環境中出現故障的頻率。另外，提升生產性部署透明度，從而以更快、更可預見的方式處理問題。只有這樣，我們的應用才能夠以更為穩健的方式為客戶服務。

　　原文標題：Why Is Troubleshooting So Hard?

　　原文作者：Ivo Magi

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】