看似無章可循問題進行排查時可以說是世界上最緊張且難度、強度最大的工作之一，尤其面對極高收入的業務、海量服務運營，帶來極大的恐慌感並引發腎上腺素飆升，壓力的存在可能誘發我們犯下的低階失誤。克服這種白痴般的本能，我們需要剋制自己快要爆發的一腔怒火、強迫自己以有條不紊的方式逐一開展嘗試。其實做運維練就的是一種心態，足夠淡定遇事而不亂，從容應對才是真。

排查出問題並找到根本原因加以解決，個人認為是一件很成就感的事情。曾經有人問過我：“你是怎麼想到問題出現在xxx的？又是怎麼確認根本原因是xxx的？”，我只能輕描淡寫的回答：“靠經驗”，然後感覺這個逼裝得還可以。其實這裡說的“靠經驗”是很模糊的，一直以來大家可能都覺得排查問題要靠經驗，但是又說不出具體通過什麼樣的經驗排查出了問題，最後讓排查問題逐漸變成了一門玄學。其實問題排查工作往往遵循一些通用且不成文的實踐規則，並不是一門所謂的玄說，結合自身經歷、總結，希望能為大家的實際工作帶來助益。

從入行到現在，遇到過各式各樣，千奇百怪的問題，然而每個業務形態和系統均不一樣，我們往往能搜尋到很多某一個或一類問題解決辦法，但個人覺得認知方法、經驗難複製，所以抽（套）象（路）說說關於“問題排查”的方法論，希望能與您產生更多的共鳴。

排查問題猶如破案

運維排查線上問題猶如警察破案一樣，是一個不停分析線索，推理的過程，但在準備排查問題之前，我們應該明白三個認知：

認知，幾乎是人和人之間唯一的本質差別。 —— 傅盛《認知升級三部曲》

系統出現異常是正常

時至今日計算機系統已經變得異常複雜，一次使用者請求可能要經過傳送請求，DNS解 析，運營商網路，負載均衡，伺服器，虛擬機器（容器），視業務邏輯的複雜程度可能 還要呼叫元件，快取，儲存和資料庫等。每個環節都可能出現問題，有的元件又是分散式的，大大增加的排查問題的難度，所以出現問題後不要慌，保持好的心態。

首要任務是恢復系統

“飛機在發生緊急情況下，飛行員的首要任務是保持飛機飛行，相比保證乘客與飛機安全著陸，故障定位和排除是次要目標”，所以恢復線上系統是首要任務，而不是立馬找到它發生的原因。

真相永遠只有一個計算機是一門科學，而且計算機的世界裡都是由0或1組成，在這個世界裡只有是或否，沒有中間地帶，所以在計算機世界凡事都有根本原因，沒有偶然發生，一切都是必然。

瞭解案情，評估大小

先評估出這個問題的影響範圍，是全網，某些地區，還是某條鏈路不可用的問題，還是很多業務線都出現問題，評估出案情的大小，到底是普通的民事案件，還是刑事案件。

理清線索，整理分析

理清手頭已得到的資訊或線索，比如監控上有網路報警，有使用者反饋無法訪問，有開發人員反饋伺服器有問題，同時間段有做變更等等，儘量不要漏掉這些看似無關緊要的線索，把這些線索先整理下來，後面一併分析。

推理的過程，就是根據已知線索，通過合理的想象、推斷得出一個唯一的結果。線索是整個推理過程的起點，線索給出的好有不好、是否有錯誤，直接會影響推理的質量，因此是最基礎、也是最重要的一環。線索的梳理，最常犯錯誤就是資訊不足，主觀臆斷。

擴大你的資訊量

主動擴大資訊的接收面，比如問詢一下開發或演算法同學，今天有沒有做線上改動，網路組有無重大調整。從中獲取到有價值的資訊點，對於排查問題至關重要。檢視監控，細看某個監控項的變化，追蹤日誌和除錯資訊都是擴大資訊量的手段。

拓展知識面，閒暇時間多些瞭解相關聯絡統，比如架構，部署，邏輯等。一旦故障發生，討論中也可提供你解決辦法的思路，舉一反三，推進問題的排查與解決。

分析證詞，甄別對錯

如果是外部提出的問題，比如業務投訴，使用者反饋等資訊，有時候是可信的，有時候人卻是不可信的，舉個例子之前有開發反饋效果有問題，有些廣告位bias異常，有些正常，讓我們幫查查系統的問題，但是最後是程式碼呼叫一處動態配置造成的。有些時候反饋的資訊，是經過描述者過濾加工過的資訊，他的排查和分析有可能把你帶偏了，在收集資訊同時需要以審視、懷疑的態度，分析每個人的證詞。

每個人的學習能力其實都很強的，隨著經驗的積累，甄別證詞能力也會逐漸提升。

看清問題本質

“聽到馬蹄聲時，猜馬，不要猜斑馬”看到一件現象或一件事情，要看實質而不只是表面的東西，聽到馬蹄聲時候猜是什麼馬，是什麼人的馬，是來幹什麼的而不是猜它是斑馬還是白馬還是黑馬。

排查問題也一樣切忌先入為主，有時候看似不可能發生、極其簡單的事情可能就是最終原因，不要輕易的排除掉某項原因，比如“宇宙射線引發SSD資料錯誤”。

很早之前碰到過一個某svr耗時高問題，查了很久也做了一些調優依然不見效，最後發現其實是網絡卡跑滿了。

確定方向，開展定位

確定偵查方向，如從大到小，從上到下排查步驟，從大到小先看比如IDC網路，機房狀態等比較巨集觀的地方是否有問題，逐一排除，逐步縮小問題範圍。從上到下先從現象發生的頂端呼叫鏈逐一排查，逐步向下深入。

並不是所有問題都從大到小從上到下，巨集觀問題只有達到一定量級才會引發”質變”，從而引起的注意，在通往質變過程中，你的業務可能已經收到某中影響而表現的很明確，此時需要微觀分析，然後再逐漸到巨集觀來診斷。

總結記錄，破案歸檔

好記性不如爛筆頭，然而在一片混亂問題分析當中，讓運維心平氣和地記錄下問題與判斷確實有點不切實際。但即使如此，我們仍然可以在事情結束後為保留一份分析資料，總結並記錄處理過程中的執行步驟以及解決途徑，則能幫助自己和團隊積累寶貴的處理經驗。

以上方法流程翻譯成運維術語：

吃一塹長一智

出了問題並不可怕，怕的是我們從問題中學不到什麼，怕的是類似的問題重現，提高問題定位的效率，有哪些值得去做，比如：

建立長效錯誤碼機制，使用具統計、可視意義的數字來簡短描述錯誤含義和範疇，正所謂濃縮就是精華，這一點在錯誤碼屢試不爽。

編寫有效的錯誤日誌，建立日誌標準。正常程式中打錯誤日誌主要是為了更好地排查問題和解決問題，提供重要線索和指導。但是在實際中打的錯誤日誌內容和格式變化多樣，錯誤提示上可能殘缺不全、沒有相關背景、不明其義，使得排查解決問題成為非常不方便或者耗時的操作。而實際上只要開發稍加用心，也需就會減少排查問題的很多無用功。如何編寫有效的錯誤日誌，建立日誌標準，也是非常有利於問題分析的。

定位問題避免二次損害，當某個看似難以捉摸的難題出現時，本能可能是重啟，儘快讓系統恢復正常。雖然這樣的方式經常能夠解決問題而且起效神速，但同時也很可能把情況推向令人難以置信的惡化深淵。問題排查手段包括重新啟動不穩定系統、嘗試自動記錄資料庫、檔案系統修復等等，這些方式往往確實能搞定難題並讓系統重回生產軌道，但同時也沒準導致資料恢復努力付之東流，毀掉確定問題根本原因的機會甚至大大延長關鍵性系統的停機時間。保留現場也非常重要，跟破案現場要要求現場勘察、樣本採集、排查、鎖定如出一轍，對於難以重現問題，儘量創造條件保留了可以用於故障重現的資料或現場。

線上環境複雜多變，雖然這一點並不能馬上解決問題起到直接作用，但堅持這種處理思路，為開發和測試創造條件，降低因難以重現的疑難故障的掛起率，最終有助於業務的長期穩定。

建立集中的資料可視平臺，不至於遇到問題才開始著手分析，若是對業務沒有足夠的瞭解又沒有資料依賴，就很可能在解決問題時雪上加霜。

建立沙箱影子系統，模擬複雜多變的現網環境，規避線上影響，重現或壓測問題，如tcpcopy、dubbocopy等

搭建開源的日誌可視方案，協助我們去解決最後”一公里”的問題，常見如ELK、Log.io等

善其事必先利其器，常見系統排查工具perf、iptraf、netperf、tcpdump、gdb、pstack、jstack、strace，top、iotop、tsar等

……

結語

總結這幾年處理問題的一些思路和經驗，可以歸納提煉如下幾句：

收集資訊，隨時記錄

協調資源，把控影響

冷靜判斷，沉著分析

大膽假設，謹慎嘗試

積極總結，以備後用

運維專家或許是每個運維人追尋的夢想，他們敏銳的嗅覺似乎總能揪出系統故障的根本原因。這種快速反應、準確定位的能力源自多年來處理複雜系統難題的經驗積累與個人知識儲備，而且其成功很難被複制。雖然沒有哪家機構願意為其頒發認證資質，儘管如此，這仍然是大家所樂於追尋的一種“超自然”的本領。

原文來自：http://server.51cto.com/ManageDC-588028.htm

本文地址：https://www.linuxprobe.com/operation-old-drivers.html編輯：CG.JIANG，稽核員：逄增寶