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

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

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

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

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

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

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

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

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

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

8、一般到這里，大多數(shù)的問題都能查出來。可能是邏輯本身的問題，可能是請(qǐng)求入?yún)?dǎo)致慢查詢，可能是中間件的網(wǎng)絡(luò)抖動(dòng)，可能是突發(fā)或者異常請(qǐng)求的問題。

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

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

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