我是怎么定位線上問題的?
面試官:「你是怎么定位線上問題的?」
這個面試題我在兩年社招的時候遇到過,前幾天面試也遇到了。我覺得我每一次都答得中規(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ù)寫唄。
