前言

今天我們來聊聊“問題排查”這個話題，本人到目前為止還在參與一線運維的工作，遇到過很多“稀奇古怪”的線上故障和問題，結合SRE中給出的一些方法，來說說“問題排查”那點事。

排查問題不是玄學

排查出線上問題，并找到根本原因加以解決，是一件很有成就感的事情，曾經有人問過我，“你是怎么想到問題出現在xxx的？又是怎么確認根本原因是xxx的？”，我只能淡淡的說：“靠經驗”，然后感覺這個逼裝的自己還算滿意。

其實這個“靠經驗”說的很模糊，一直以來，大家都覺得排查問題要靠經驗，但是又說不出具體通過啥經驗排查出了問題，最后讓排查問題逐漸變成了一門玄學。

排查問題猶如破案

排查線上問題，就和偵探破案一樣，就是一個不停分析線索，推理的過程，在你準備破案之前，先要明確以下兩點。

系統異常是正常的，正常是特例

時至今日，計算機系統已經變得異常復雜，一次用戶請求可能要經過發送請求，DNS解析，運營商網絡和IP轉換，負載均衡，服務器硬件，虛擬機/容器,視業務邏輯的復雜程度，可能還要調用其它組件，存儲，數據庫，緩存等。每個環節都可能出現問題，有的組件又是分布式的，大大增加的排查問題的難度。

所以出現問題后，不要著急，保持好心態，要認為“系統異常是正常的，正常是特例”。

飛行員首要任務是保持飛機飛行

在初級飛行員的課程中撿到，在緊急情況中，飛行員的首要任務是保持飛機飛行，相比保證乘客與飛機安全著陸，故障定位和排除是次要目標。—SRE

所以，恢復線上系統是首要任務，而不是找到它發生的原因。

明確案情

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

真相只有一個

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

所以，你要堅信真相只有一個。

理清線索

理清目前得到的線索和信息，比如監控上有網絡報警，有用戶反饋無法訪問，有開發人員反饋服務器有問題，不要漏掉看似無關緊要的線索，把這些線索先整理下來，后面一并分析。

擴大信息量

盡可能擴大你接受到的信息量，比如問詢一下開發人員今天有沒有做線上改動，網絡組有無重大調整。獲取到有價值的信息，對于排查問題至關重要。

查看監控，細看某個監控項的變化，追蹤日志和調試信息都是擴大信息量的手段。

分析證詞

分析用戶反饋的現象，數據是可信的，有時候人說的是不可信的，舉個例子，之前有開發反饋我們虛擬機有問題，有些虛擬機接口返回異常，有些正常，他就讓我們幫查查虛擬機的問題，但是最后是代碼調用一處動態配置造成的。

很多反饋的信息描述，是經過描述者過濾加工過的信息，他的排查和分析有可能把你“帶歪了”，先要用懷疑的態度，分析每個人的證詞。

當你聽到蹄子聲響時，應該先想到馬，而不是斑馬

排查問題不要先入為主，有時候你覺得極其簡單，看似非常不可能發生的事情，可能就是原因，不要輕易的排除掉某項原因，比如“宇宙射線導致某個電路信號出錯”。

我們之前有個mysql連接異常的問題，查了很久，做了很多調優都沒有解決，最后發現是網卡跑滿了。

從大到小，從上到下

排查步驟，先“從大到小”，先看比如運營商網絡，機房狀態等比較宏觀的地方是否有問題，逐一排除，逐步縮小問題范圍。“從上到下”，先從現象發生的頂端調用鏈逐一排查，逐步向下深入。

SRE給出的一些方法

SRE給出了一些方法可以借鑒：

• 問題排查的幾個步驟：定位，檢查，診斷，測試/修復，治愈。

• 什么，哪里和為什么，找出系統正在執行“什么”，詢問系統“為什么”執行這些操作，以及系統的資源都被用在了“哪里”可以幫助你了解系統為什么出錯。

• 確定“最后一個修改”發生的時間。

• 提供豐富的診斷和監控工具。