我是怎么定位線上問(wèn)題的？

面試官：「你是怎么定位線上問(wèn)題的？」

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

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

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

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

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

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

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

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

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

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

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

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