以前我以為，線上系統的問題，只需要好好檢查代碼即可找出原因，可是作業后發現，現實并非如此，往往線上系統的問題來源于資訊不對稱，這種資訊不對稱體現在團隊成員之間沒有好好溝通，了解彼此對系統的改動，以及跨部門、跨系統、跨平臺之間的資訊不對稱，
其實，當線上問題來臨時，心態很重要，新人往往在系統出故障時（尤其是故障是自己負責的部分）感到很慌張，我一開始也是如何，但后來漸漸看開了，程式員進行代碼開發總是會出現bug的，慌張對于解決系統故障并無好處，反而容易因為慌張而導致忽略了必要的流程，從而導致修復故障程序出錯，除此之外，我在系統出現故障時，會思考這個故障對于系統業務的影響有多大（比如：對于一個訂單處理系統，其排序錯亂不符合預期，這種對業務影響不大，但是如果訂單丟失，對業務影響是巨大的），故障對于資料造成的影響有多大（如果資料可以修復，那么影響不大，如果資料不可修復，那影響很大），
當系統出現問題時，要冷靜下來，用邏輯分析問題，絕對不能靠猜，往往可以借助排除法來分析問題所在，
比如：對于介面執行速度慢這個問題，第一步：先列出所有可能引起這個問題的因素，可能是資料庫、外部系統介面呼叫、執行緒池、網路、記憶體、cpu、死鎖、gc、介面代碼本身效率低下等因素引起，第二步：將這些因素一個一個通過監控、除錯、測驗等手段證明或證偽其對問題的影響，如果最終排除了所有選項依然沒有找到問題，這說明要么還有因素沒有找到（往往是資訊不對稱），要么是第二步出錯（資訊錯誤），
分析如何更快解決線上問題之前，我們先從反面想想如何阻礙程式員查找線上問題，阻礙查找問題的因素往往是：
1.團隊成員之間沒有好好交流
2.監控不到位或監控資料錯誤
3.沒有權限查看資料
4.缺乏日志
要想更快解決線上問題，必須將這些阻礙解決，于是，我們可這樣：
在重大問題發生時，如果一時無法解決，就讓團隊成員將各自對于系統版本變更以來所有的改動點進行充分交流，將這些改動點用排除法來確定哪些對故障產生有影響，需要注意的是，故障可以來源于代碼之外，想快速確認是否是代碼引起的問題，那就可以將上個版本的代碼發布，如果問題依然存在，那就是代碼之外的問題了，回顧我多次故障處理經歷，往往我在代碼中怎么也找不到原因時，可以在外部介面呼叫、資料庫、容器、網路連接這些方面找到問題所在，
問題來臨時，一定要好好在監控中對比例外狀態跟平時的區別，從監控中尋找跟問題相關的資料例外，需要注意的是，不要忽略監控資料本身是錯誤的這個可能性，查問題時沒有權限往往阻礙團隊成員查找問題，主管需要進行適當的放權，幫助團隊成員更便捷查找問題，而作為下級，應該積極向有權限的人求助，讓他幫忙處理，
日志是定位問題不可或缺的利器，日志列印有些原則，對于外部介面呼叫，必須列印請求體和回應資料以及耗時，資料庫耗時、多執行緒處理耗時也應該記錄下來，例外錯誤應該在日志中能夠搜索到，
我想列舉下我多次處理線上事故的經歷：
hashCode變化引起的Set記憶體泄露
該系統是一個websocket訊息推送的服務，在一次次發版后，記憶體會緩慢增長，直到占用100%記憶體自動重啟，重啟后記憶體如一般一樣降到30%，然后依然是記憶體不斷增長，對比發版代碼，發現代碼中用到了一個Set<WebSocketServer>，仔細追查原始碼發現，WebSocketServer的Session成員變數的hashCode會變化，而WeboSocketServer的hashCode計算是每次獲取其成員變數計算的，這樣的話，這個Set占用空間會越來越大，永不釋放記憶體，
解決辦法：將hashCode快取起來
特定資料庫分庫鍵設定不一致導致插入資料無法查詢
由于我們的資料量特別大，一個月積累幾十億的資料，因此很多地方進行了分庫，我們所有的庫都是按照（假設為)mall_id分庫的，唯獨這一個特定資料庫是按照另一個欄位（假設為）spec，我們這個時候在進行資料庫改造，插入資料庫操作是利用資料庫中間件來的，資料庫中間件是按照spec來分庫插入的，但是我們查詢是直連資料庫且按照mall_id來查的，這就導致插入的資料莫名丟失，問題關鍵是這個按照spec分庫這個規則是我不知道的，團隊成員資訊不對稱導致的問題，
解決方案：插入和查詢按照相同的分庫規則來
內網網路連接不穩定導致系統整體RT飆升
系統發版時改動挺多，有整體資料源的改動，有資料庫連接池的改動，也有執行緒池的改動，而且RT飆升前依賴的外部平臺掛了一段時間，從日志看有70%的介面呼叫耗時是正常的，偶爾有些好幾秒的介面呼叫，而且從客服那得知反饋系統慢的主要是某一模塊的介面慢，于是，一開始懷疑執行緒池配置有問題，改成以前的配置也無效，然后從監控看到慢的介面其有很多sql執行，并且資料源切換時間很長，我們一般是用執行緒池來進行批量執行sql，并且我們的分庫很多，也就是說我們有上百個資料源，從監控看資料庫cpu很閑，慢查詢有所上漲但并不多，期間還發現有后臺執行腳本同時洗掉資料庫資料，kill掉腳本依然無濟于事，在優化掉一部分慢查詢sql后再上一版代碼依然沒用，這時候我們已經把所有可能的內部因素都排查了，于是我們開始懷疑是不是我們依賴的平臺的問題，因為我們的服務器、資料庫、網路都是在這個云平臺，于是我們上線了一版以前的代碼，發現依然RT很高，這時可以判斷是云平臺的問題，聯系對方技術，他們說我們的連接數相比昨天增加了70%，繼續排查，發現是他們的虛擬ip的有問題導致我們的網路連接不正常，有20%概率獲取一次網路連接超過100ms，對方優化虛擬ip問題后，rt恢復正常，事后看資料源切換時間長暗示了網路連接不正常，但是我們當時被慢查詢吸引了，沒考慮到這個問題，
解決方案：聯系云平臺解決虛擬ip導致的網路連接問題
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/150026.html
標籤：其他