我是怎么定位線上問題的?

面試官：「你是怎么定位線上問題的？」

這個面試題我在兩年社招的時候遇到過，前幾天面試也遇到了。我覺得我每一次都答得中規(guī)中矩，今天來梳理復(fù)盤下，下次又被問到的時候希望可以答得更好。下一次我應(yīng)該會按照這個思路去答：

1、如果線上出現(xiàn)了問題，我們更多的是希望由監(jiān)控告警發(fā)現(xiàn)我們出了線上問題，而不是等到業(yè)務(wù)側(cè)反饋。所以，我們需要對核心接口做好監(jiān)控告警的功能。

2、如果是業(yè)務(wù)代碼層面的監(jiān)控報警，那我們應(yīng)該是可以很快地定位出是哪兒的問題，畢竟告警邏輯都是我們寫的嘛。如果是服務(wù)器資源/所依賴的中間件告警，那我們可能就要花點時間去排查啦。

3、不管怎么樣，無論是系統(tǒng)告警還是是業(yè)務(wù)側(cè)反饋系統(tǒng)或者接口出了問題。我們要想想在近期有沒有發(fā)布過系統(tǒng)，如果近期發(fā)布過系統(tǒng)，判斷能不能立馬回滾到上一個版本，恢復(fù)系統(tǒng)平穩(wěn)正常運行（在線上環(huán)境下，可用性是相當重要的）?；貪L的時候要考慮接口有無依賴性，是否需要跟業(yè)務(wù)側(cè)同步此次的回滾以及做相關(guān)的配合。

4、因為線上大多數(shù)的問題都來源于系統(tǒng)的變更，可能我們只是變更了很少的代碼，但只要有一絲的邏輯沒留意到，就真的很可能會導(dǎo)致出現(xiàn)問題，回滾很可能是最快能恢復(fù)線上正常運行的辦法。

5、如果近期都沒發(fā)布過系統(tǒng)，是系統(tǒng)告的警，那追蹤下告警和報錯日志，應(yīng)該是可以很快地就能定位出問題。

6、如果不是系統(tǒng)告的警，是業(yè)務(wù)側(cè)反饋出了問題，那這時候需要業(yè)務(wù)側(cè)明確是哪個具體的功能/接口出了問題，有沒有保留請求入?yún)?，有沒有返回錯誤的信息，有何現(xiàn)象

7、知道了問題的現(xiàn)象之后，就需要根據(jù)經(jīng)驗排查可能是哪塊出了問題了。我的經(jīng)驗一般是：先查存儲側(cè)有沒有瓶頸(MySQL 的CPU有沒有飆高，主從同步延遲是否很大，有沒有慢SQL。Redis是不是內(nèi)存滿了，走了淘汰策略。搜索引擎有沒有慢Query)，把該服務(wù)所依賴的中間件的指標看一遍，這個過程中也要去看看服務(wù)接口的QPS/RT相關(guān)的監(jiān)控。如果有某項指標不對勁，那順著寫入邏輯也應(yīng)該很快能看出來

8、一般到這里，大多數(shù)的問題都能查出來?？赡苁沁壿嫳旧淼膯栴}，可能是請求入?yún)?dǎo)致慢查詢，可能是中間件的網(wǎng)絡(luò)抖動，可能是突發(fā)或者異常請求的問題。

9、如果都不是，回歸到應(yīng)用和機器本身的監(jiān)控：應(yīng)用GC的表現(xiàn)、機器本身的網(wǎng)絡(luò)/磁盤/內(nèi)存/CPU 各種的指標有沒有發(fā)現(xiàn)異常的情況。這里可能是需要運維側(cè)一起配合看看有沒有做過改動。

10、要是還定位不出來，看能不能復(fù)現(xiàn)，能復(fù)現(xiàn)都好說，肯定是能解決的。

11、要是不能復(fù)現(xiàn)，只能在懷疑的地方打上詳細的日志再好好觀察（問題定位不出來，很多時候就是日志不夠詳細，而日志在正常情況下也不應(yīng)該打太多）

這個我估摸想要考察的是看看你平時是怎么去定位問題的，定位問題的思路是什么，自己有沒有方法論之類的。話雖如此，這也只是我這幾年的定位問題的模式，也未必對，也不知道有沒有缺少了哪一個重要的環(huán)節(jié)。面小公司總體下來會問些方法論的多，不會很專研某項技術(shù)的問題。 我瞅瞅還有啥可以拉出來復(fù)盤下，繼續(xù)寫唄。