【51CTO.com快譯】從定義角度來看，故障排查相當(dāng)于對(duì)問題根源進(jìn)行一種邏輯性、系統(tǒng)性搜索，旨在找到將其解決的辦法。然而，結(jié)合實(shí)際情況，可能很少有人能夠?qū)⑵渑c邏輯或者系統(tǒng)這樣的字眼聯(lián)系起來。開什么玩笑——忙著猜測(cè)可能原因才是實(shí)際情況，對(duì)吧?

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

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

　　生產(chǎn)環(huán)境中的故障排查

　　在對(duì)生產(chǎn)環(huán)境中的特定問題進(jìn)行故障排查時(shí)，總會(huì)引發(fā)一系列后續(xù)麻煩。多種多樣的潛在可能性往往令這一過程變成了玄學(xué)性質(zhì)的事物：

　　首先，大家應(yīng)當(dāng)打消“直接重啟讓其恢復(fù)工作”這樣的念頭。雖然這種方式往往能快速解決問題，但卻也會(huì)同時(shí)破壞產(chǎn)生此前問題的重要證據(jù)。而且即使重啟能夠暫時(shí)解決問題，請(qǐng)相信我，只要根本原因仍然存在，那么其早晚還會(huì)再次出現(xiàn)。

　　接下來考慮安全性相關(guān)內(nèi)容，包括確保技術(shù)調(diào)試不會(huì)對(duì)生產(chǎn)環(huán)境造成影響。有時(shí)候我們必須以遠(yuǎn)程方式進(jìn)行環(huán)境訪問，這意味著每項(xiàng)操作都需要跳轉(zhuǎn)多次、增加執(zhí)行時(shí)間周期并可能在此期間丟失部分關(guān)鍵性信息。

　　更糟糕的是，一旦我們向生產(chǎn)環(huán)境中發(fā)布了不確定能否奏效的補(bǔ)丁，那么其相關(guān)測(cè)試與應(yīng)用工作可能耗時(shí)數(shù)小時(shí)甚至數(shù)天，這進(jìn)一步增加了修復(fù)問題的周期。如果需要使用大量這類猜測(cè)性補(bǔ)丁，那么也許問題要到數(shù)周后才能徹底得到解決。

　　***同樣重要的是，我們?cè)诮鉀Q問題過程中所使用的實(shí)際工具。其中部分工具可能會(huì)對(duì)最終用戶造成負(fù)面影響。舉例來說：

　　從JVM進(jìn)行轉(zhuǎn)儲(chǔ)可能導(dǎo)致JVM本身卡住數(shù)十秒。

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

　　附加分析器的資源消耗可能導(dǎo)致本已運(yùn)行緩慢的應(yīng)用徹底崩潰。

　　總而言之，從編寫腳本到將補(bǔ)丁投放至生產(chǎn)環(huán)境，整個(gè)過程往往需要數(shù)天或者數(shù)周。

　　正因?yàn)榇嬖谏鲜鲭y題，因此我們大多會(huì)在不同環(huán)境中實(shí)施故障排查舉措。

　　在測(cè)試與開發(fā)環(huán)境中進(jìn)行故障排查

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

　　測(cè)試環(huán)境與生產(chǎn)環(huán)境使用的數(shù)據(jù)源不同。 這意味著由數(shù)據(jù)量引發(fā)的問題無法在測(cè)試環(huán)境內(nèi)重現(xiàn)。

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

　　應(yīng)用本身并不完全相同。生產(chǎn)部署與配置方案間可能存在些許差別。這種差異包括不同操作系統(tǒng)、集群化功能、啟動(dòng)參數(shù)甚至是不同build。

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

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

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

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

　　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$

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

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

　　收集不同指標(biāo)(CPU、內(nèi)存、IO、網(wǎng)絡(luò)等)。

　　分析應(yīng)用日志。

　　分析GC日志。

　　捕獲并分析線程轉(zhuǎn)儲(chǔ)。

　　捕獲并分析堆轉(zhuǎn)儲(chǔ)。

　　可資利用的此類工具多種多樣，然而經(jīng)驗(yàn)的缺乏往往導(dǎo)致您不了解其中哪些工具適用于哪些情況，這意味著大家需要耗費(fèi)大量時(shí)間嘗試其實(shí)際效果。

　　解決故障排查難題

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

　　首先需要強(qiáng)調(diào)，本文并不涉及對(duì)技術(shù)堆棧本身的分析。相反，我們關(guān)注的是對(duì)應(yīng)用程序內(nèi)各組件的了解，包括其具體內(nèi)存占用量，這能夠有效防止最終用戶在實(shí)際使用時(shí)遭遇問題。

　　然而，數(shù)據(jù)的差異導(dǎo)致我們只能發(fā)現(xiàn)一部分生產(chǎn)環(huán)境中可能出現(xiàn)的問題。各類前瞻性問題解決手段往往無法有效完成故障排查中的根源追溯任務(wù)。

　　QA測(cè)試

　　在QA(即質(zhì)量保證)階段，我們應(yīng)當(dāng)以自動(dòng)化方式建立測(cè)試機(jī)制。這類測(cè)試能夠進(jìn)一步降低生產(chǎn)環(huán)境中出現(xiàn)的問題數(shù)量。

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

　　生產(chǎn)環(huán)境監(jiān)控

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

　　為了更好地籌備生產(chǎn)環(huán)境故障排查工作，我們應(yīng)當(dāng)提升生產(chǎn)環(huán)境的透明度。當(dāng)問題出現(xiàn)時(shí)，大家***已經(jīng)掌握全部證據(jù)并進(jìn)行針對(duì)性解決。

　　遺憾的是，監(jiān)管工作同樣需要通過多種方式才能實(shí)現(xiàn)。典型Web應(yīng)用的部署工具就至少包括：

　　日志監(jiān)控。從生產(chǎn)堆棧中的各節(jié)點(diǎn)處進(jìn)行日志匯總，保證工程團(tuán)隊(duì)能夠快速搜索信息、進(jìn)行日志可視化并標(biāo)記異常警報(bào)。目前最為常見的解決方案為ELK堆棧，其中日志存儲(chǔ)于Elasticsearch中，由Logstash負(fù)責(zé)分析，并由Kibana進(jìn)行可視化處理。

　　系統(tǒng)監(jiān)控。對(duì)基礎(chǔ)設(shè)施內(nèi)的系統(tǒng)級(jí)指標(biāo)進(jìn)行聚合與可視化既能夠帶來顯著收益，又切實(shí)可行。我們應(yīng)著眼于CPU、內(nèi)存、網(wǎng)絡(luò)及磁盤資源使用量，從而及時(shí)發(fā)現(xiàn)系統(tǒng)級(jí)問題并對(duì)異常狀況進(jìn)行警報(bào)。

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

　　總結(jié)

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

　　原文標(biāo)題：Why Is Troubleshooting So Hard?

　　原文作者：Ivo Magi

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】