前言
在系統上線之後，或多或少總是會存在問題，有機器性能方面的問題，例如CPU Load過高，內存使用率高，RT高，線程池滿，FullGC之類，也有業務邏輯的問題，例如支付系統中金額計算錯誤，狀態校驗錯誤等。爲了儘量減少線上的影響（對用戶造成困擾，甚至導致資金損失等），對系統的穩定性監控建設還是很有必要的。
從方法論的角度來看，很多事情都可以歸納爲信息收集能力，信息的處理能力。穩定性也類似，需要多維的收集信息，然後根據信息發現系統的運行狀態。
數據收集
不過方法論如果抽象層次過高，就變得不易落地的，因此還需要結合具體的場景細化，目標是信息維度足夠詳細，可以有效的輔助問題的分析。結合穩定性場景的話，分爲系統與業務兩部分數據。系統方面數據比較通用，通常包括機器的CPU情況（CPU使用率，LOAD等情況），內存使用率（JVM內存情況，GC的情況），磁盤使用率，網絡的流量情況，以及分佈式中一些中間件的情況，例如服務的RT，線程池使用情況，緩存的RT，命中率，消息的堆積情況，任務調動的執行情況等等，以及數據庫的執行情況，例如慢sql等等。如果存在不同的機房還需要把機房情況也列出來，例如安全生產環境，正式環境，不同的機房，不同的單元等，這樣可以有效定位到影響面。業務數據主要是需要根據具體業務進行分析，梳理出業務關注的指標，不過通用的一般有入口情況（可以分不同的場景，例如PC端，無線端，小程序端等，總量，成功率），依賴情況（依賴服務的成功率， RT等，總量），系統的錯誤碼情況（統一錯誤碼），同樣也需要分不同的機房情況。其他具體業務指標就需要結合業務具體分析了，例如支付系統中，每個支付渠道的提交成功率，支付成功率，耗時等。對於業務指標可以根據線上真實出現過的問題或者自己假想出現一類問題，自己需要哪些信息來慢慢完善。 對於單一的應用系統通常可以比較有效的進行監控與巡檢，如果是全鏈路的系統，就需要對鏈路上的系統分別建設，不過業務上的監控一般可以跨越多系統。
數據處理
數據收集好之後，另外需要了解數據背後的意義，這裏就是基礎知識以及經驗的積累。例如當發現系統提供的服務RT上升時，應該如何排查。當支付寶渠道的支付成功數下降應該如何排查。這些也都可以通過問題處理的經驗梳理處理。
服務RT上升
1. 排查依賴的系統RT是否上升，如何下游系統都是自己域內，那就以此排查，如果不是域內，就需要聯繫對應的owner進行排查
2. 如果依賴的服務RT沒有上升，看是否請求量是否明顯上漲，導致機器負載過高
3. 是否應用機器是否剛剛啓動，由於jvm對代碼進行編譯導致時間過長；
4. 查看CPU使用率，Load，內存使用率，GC的次數，GC耗時，線程數大小，JVM堆內存使用情況
5. 如果是虛擬機，還需要查看宿主機的情況
支付成功數下跌
1. 入口是否有下跌
2. 各渠道成功數是否下跌
3. 對應的渠道收銀臺與支付的報錯
4. 對應的成功回調，從外層到內層依次排查
其他
監控一方面可以提升問題排查的速度，也可以對於問題進行告警，避免問題的放大。