面試官：「你是怎么定位線上問題的？」
這個面試題我在兩年社招的時候遇到過，前幾天面試也遇到了，我覺得我每一次都答得中規中矩，今天來梳理復盤下，下次又被問到的時候希望可以答得更好，
下一次我應該會按照這個思路去答：
1、如果線上出現了問題，我們更多的是希望由監控告警發現我們出了線上問題，而不是等到業務側反饋，所以，我們需要對核心介面做好監控告警的功能，
2、如果是業務代碼層面的監控報警，那我們應該是可以很快地定位出是哪兒的問題，畢竟告警邏輯都是我們寫的嘛，如果是服務器資源/所依賴的中間件告警，那我們可能就要花點時間去排查啦，
3、不管怎么樣，無論是系統告警還是是業務側反饋系統或者介面出了問題，我們要想想在近期有沒有發布過系統，如果近期發布過系統，判斷能不能立馬回滾到上一個版本，恢復系統平穩正常運行（在線上環境下，可用性是相當重要的），回滾的時候要考慮介面有無依賴性，是否需要跟業務側同步此次的回滾以及做相關的配合，
4、因為線上大多數的問題都來源于系統的變更，可能我們只是變更了很少的代碼，但只要有一絲的邏輯沒留意到，就真的很可能會導致出現問題，回滾很可能是最快能恢復線上正常運行的辦法，
5、如果近期都沒發布過系統，是系統告的警，那追蹤下告警和報錯日志，應該是可以很快地就能定位出問題，
6、如果不是系統告的警，是業務側反饋出了問題，那這時候需要業務側明確是哪個具體的功能/介面出了問題，有沒有保留請求入參，有沒有回傳錯誤的資訊，有何現象
7、知道了問題的現象之后，就需要根據經驗排查可能是哪塊出了問題了，我的經驗一般是：先查存盤側有沒有瓶頸(MySQL 的CPU有沒有飆高，主從同步延遲是否很大，有沒有慢SQL，Redis是不是記憶體滿了，走了淘汰策略，搜索引擎有沒有慢Query)，把該服務所依賴的中間件的指標看一遍，這個程序中也要去看看服務介面的QPS/RT相關的監控，如果有某項指標不對勁，那順著寫入邏輯也應該很快能看出來
8、一般到這里，大多數的問題都能查出來，可能是邏輯本身的問題，可能是請求入參導致慢查詢，可能是中間件的網路抖動，可能是突發或者例外請求的問題，
9、如果都不是，回歸到應用和機器本身的監控：應用GC的表現、機器本身的網路/磁盤/記憶體/CPU 各種的指標有沒有發現例外的情況，這里可能是需要運維側一起配合看看有沒有做過改動，
10、要是還定位不出來，看能不能復現，能復現都好說，肯定是能解決的，
11、要是不能復現，只能在懷疑的地方打上詳細的日志再好好觀察（問題定位不出來，很多時候就是日志不夠詳細，而日志在正常情況下也不應該打太多）
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/551381.html
標籤：其他
上一篇：行程
下一篇：返回列表