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

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

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

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

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

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

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

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

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

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

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

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

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

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