SOA監控相關功能的易用性優化(2.18)

最近開始對已有的SOA管控平臺的監控相關功能做易用性方面的優化，這篇作為易用性優化的簡單總結。

服務執行監控和執行分析類功能，主要分為三大類，其中一類是對服務執行問題排查用的功能，另外一類是我們做服務執行整體統計分析用的功能，還有一類是服務實時監控類的功能 。而這三類功能本身使用場景和驅動也存在差異。

對於問題排查往往是問題驅動，問題來了要馬上定位分析；對於實時監控類功能是準實時的定頻率監控使用，監控具備準實時和定頻率的特徵；而對於執行整體分析往往則用於日報分析，週報和月報分析，使用頻率相對較低。對於以上三類都需要考慮易用性優化，只是關注點可能不同而已。

問題排查類功能優化

重點就是要根據使用者反饋的問題提供的關鍵欄位，例項號，時間段或者關鍵字等能夠快速的找到具體的異常記錄和異常日誌。同時要確保異常記錄完整，異常日誌無丟失。同時對於異常問題類功能要確保異常的邊界明確，即通過提供的日誌能夠明確判斷出具體的問題究竟出再哪方，具體的日誌記錄是如何的。

問題排查類功能優化還需要考慮，一個是業務系統通過自服務的方式進行進行問題分析和排查，一類是由SOA雲和管理人員進行問題分析和排查，這兩類場景需要單獨分析和處理。其次，對於問題發現後，如何觸發具體的工單，方便後續的問題閉環跟蹤也是必須要考慮的一個關鍵問題。

統計分析類功能優化

首先要做到我們做分析報表的時候需要的資料都能夠通過Excel完全匯出，沒有資料缺失。其次對於匯出的Excel資料我們能夠做最小的資料加工和整理就形成我們需要的統計報表資料。

在原來的統計分析功能中，我們發現有一些功能最終查詢結果出來的資料，我們在進行統計分析的時候還要人工篩選出需要納入統計範圍的資料，或者刪除一些資料，這些都增加了後期處理工作量，因此這些都應該變更查詢統計規則，或者增加查詢條件。

舉例來說對於服務執行效能監控，我們統計分析結果包括了異常服務資料，這個導致服務執行時長值明顯偏大，而對於異常服務資料本身是由於發版導致的服務呼叫異常。那麼我們就有兩種處理方法，一個是配置發版週期和時間間隔，在發版週期裡面不進行計算。其次就是我們可以選擇是統計所有服務，還是隻統計正常執行服務。

實時監控類功能

對於實時系統監控類功能，核心就是告警策略和指標的設計，以區別自動監控到的異常是真正的系統異常，否則將導致大量的異常誤報。

對於人工定時監控的功能，那麼重點就是如何快速的查詢是否存在異常記錄或可疑記錄，而減少人工篩選的工作量。比如我們異常日誌查詢，查詢出大量異常日誌，但是大部分異常是不需要我們關注的，而真正需要關注的往往就會不容易找出來，這些都需要我們在監控功能優化的時候考慮如何增加快速定位的方便些。

還有一種做法是我們將我們定時監控的查詢條件配置為自定義查詢，固化這些查詢指標，而每次只需要根據預設的查詢條件進行查詢和分析即可。

服務執行篩選條件很重要，我們一天的服務執行日誌就上千萬次，即使喜歡到1分鐘都上萬次的服務呼叫，因此必須細化查詢條件，篩選方式，以方便快速的定位問題。比如我們要檢視某個週期有無大資料量呼叫，原來只能匯出特定週期服務執行例項，再人工篩選。那麼考慮到易用性，這種就需要優化為增加報文量的查詢條件方便我們快速的篩選異常呼叫類服務。

對於基準監控也是我們不斷優化調整的功能，目的就是基準告警要越來越準確，減少誤報和漏報的情況。

當我們能夠做到我們基於特定條件查詢出的基準預警結果完全不再需要人工篩選就能夠分發給業務系統，那麼就說明這個功能可以做到完全的自動化，不再需要人工監控和干預。

這也是我經常說到的，即：

當任何一個監控功能或稽核功能，我們通過人工監控方式不斷的優化和調整監控規則和策略，當優化和調整到足夠準確的時候，那麼這個功能就最終自動化掉，不再需要人工干預和處理。 這個也是我們要做到服務監控運維自動化的一個必經之路。因為一開始，你很難立刻給出明確的規則定義。

方便第一時間快速的分析和定位問題，方便統計分析的時候快速的生成需要的資料和圖表而少做人工處理和加工，方便基於不同關鍵業務場景的快速的篩選。這些就是對於監控類功能優化的重點。