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