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