電網信息化業務運行監控存在的問題及對策

文/周英耀 張華兵

近年來，電網企業在“集團化運作、一體化管理”戰略要求下，不斷深入和擴展信息化建設，系統及網絡設備規模不斷擴大，多種應用軟件，如數據庫、中間件等不斷增加，業務系統的數量也越來越多。如今，全網統一的企業級系統全面投運，基本實現管理制度化、制度流程化、流程表單化、表單信息化以及各業務之間的橫向協同、縱向貫通。

但是電網企業在信息系統應用性業務運行監控方面的技術手段相對薄弱，無法深入到業務應用內部，難以監控業務流程的每個步驟，從而阻礙了故障的快速定位、診斷和優化，IT運維人員不能精準到感知最終用戶的體驗，不能實時掌握業務運行狀態。

為了使IT運維人員需要快速、準確定位系統性能瓶頸（硬件層面、軟件層面），縮短故障恢復時間，確保業務不間斷。同時對于應用開發人員也需要追溯業務功能及性能數據庫，合理評估系統健康狀態，量化IT運維部門工作，本文深入對業務運行監控進行分析和實踐。

1 業務運行監控現在存在的問題

1.1 缺少對業務管理系統業務運行層面的監控分析手段及指標

目前的運維工具沒有針對業務管理系統業務運行進行專業的監控和分析，業務運行情況的監控和分析處于空白狀態。由于缺少全過程的業務運行監控，故障事后分析診斷條件不足，缺少故障現場溯源數據及相應技術規范及指標，大多情況下只能對設備日志、交易日志等進行分析，很難拿出有力的證據進行取證，另外即使有故障現場數據，問題分析人員面對海量的數據問題分析定位仍需要消耗較長的時間。

1.2 缺少對用戶業務操作的真實體驗的監控

對于用戶業務操作的真實體驗缺少系統的監控和數據支撐。公司現階段的信息化建設，投入了很大精力在IT系統的建設和對IT基礎架構的維護上，但即使部署了最先進的基礎架構，并不間斷地監控PC、網絡、服務器、數據庫等的性能，用戶還是會抱怨系統運行緩慢，不能及時發現哪個業務操作響應慢，IT運維人員也很難向用戶解析清楚問題原因在哪。

1.3 處于被動運維

公司應用系統結構復雜，各功能模塊分布在相對獨立的子系統，通過多個子系統再組合成多環節、長交易鏈條的完整的應用，很容易出現某個環節與其他環節的處理能力不匹配導致性能瓶頸，此類業務應用的性能問題經常發生且難于發現和定位。

因此，目前多數IT運維處于“被動式”管理，運維人員并非是應用系統的使用者，經常是接到投訴電話之后才知道系統出現了問題，再去尋找問題根源，管理十分被動。

圖1

圖2

1.4 IT環境復雜，定位問題困難

現階段公司IT環境日趨復雜，每個企業級應用系統都部署在龐雜的基礎架構上，并且與多個外部系統對接。當問題出現時，發現問題很困難，更談不上快速定位、解決問題。

監控不全面，缺少故障現場溯源數據，事后分析診斷條件不足，難以做到全面診斷且效率低，網絡尤其被動，常常面對指責難以舉證。

2 業務運行監控解決方案

2.1 問題分析

當前的電網企業業務，從物理上，涵蓋多個系統多臺物理服務器的應用；邏輯上，包含多個應用邏輯部件的應用系統——不論從業務邏輯還是數據傳輸，應用都跨越多個資源環境，然后才組合成業務系統。

大多數復合應用為前端用戶提供復雜的業務系統（B/S架構的Web應用），應用中的通用部件又可能被不同應用系統以各種形態相互互連或重用，單個用戶請求可能貫穿甚至多次貫穿系統，業務請求對應的返回數據可能來源于多個子系統。

前端的應用界面隱蔽了應用后端的這種復雜構架，但是不論后端的子系統發生何種異常——不論來自業務請求的異常、系統資源的異常還是應用內部邏輯和代碼的異常——用戶都無法完整發出的交互請求。

正是由于復合應用系統的“復合”特性（業務邏輯和數據傳輸跨越多個資源環境），從優化其性能和可用性角度來看，它難以設計、難以構架、難以測試、難以管理；傳統分立的塊狀系統管理工具和方法論也很難很好的對它進行管理和優化。

2.2 解決思路

為此我們提出如下的解決思路：

2.2.1 模擬用戶交互監控

（1）完全站在用戶的角度；

（2）監控交互的可用性, 交互的總體相應時間, 交互在各個資源上的相應時間；

（3）定時,定量監控IT系統對業務服務的支持水平與服務質量。

2.2.2 通過“解剖”交互，查找，定位故障根源，為資源級故障診斷指明方向

（1）對用戶交互進行解剖,直到最基本的部件；

（2）對發生問題時記錄的上下文信息從應用開發角度進行分析。

2.3 解決方案

基于這樣的思路，電網企業提出包含以下3點的解決方案。

（1）采用對J2EE的應用程序進行實時監控和歷史數據分析，發現并且報告J2EE應用的健康度。監控貫穿整個應用流程，如應用程序服務器、中間件適配器、傳輸協議、數據庫、并且能夠監控后臺如CICS、IMS等主機系統。收集應用程序請求周期的數據，然后存儲到監控數據庫，數據包括請求開始，結束的時間，所用的中央處理器時間等等，并且能夠通過一層層的遞進跟蹤找到每個類，每個方法的響應時間，中央處理器時間，從而定位發生交易失敗、響應惡化的請求，并找到應用程序需要改進優化的地方。

（2）采用端到端的應用監控，跨節點，粗粒度監控響應時間，從而找到問題的根源。圖1能很好的展示端到端的應用監控作用。

當一個應用跨越多個節點，出現不可用，或者響應緩慢的時候，第一步是需要知道慢在哪個節點上（哪臺機器上），然后才能去診斷為什么那個節點會慢。以圖1為例子，通過應用的拓撲圖和每個節點上的響應時間，我們能很快的定位到“潛在出問題”的節點上。進而通過ITCAM for WR/DB/MSG來查看容器的性能指標找到問題根源。

（3）采用用戶終端視角搜集響應時間。所監控的響應時間是指從客戶端發起請求到服務端返回整個交易所消耗的時間：響應時間 = 客戶端運行時間 + 網絡時間 + 服務端運行時間。監控獲取HTTP協議的響應點來實現對Web服務器的無侵入式監控，它不需要在Web服務器中安插任何代碼，而是通過獲取每個IP包的拷貝做協議棧分析來獲得具體的響應時間，因此，理論上可以支持任何HTTP服務器。圖2是所度量的響應時間。

其中圖2編號分別代表：

（1）瀏覽器向Web服務器發出頁面請求；

（2）服務器接收請求；

（3）服務器發出第一個包；

（4）瀏覽器請求第一個嵌入式對象；

（5）服務器發送頁面HTML的最后一個包；

（6）服務器發送最后一個嵌入式對象的最后一個包；

（7）瀏覽器接收最后一個嵌入式對象的最后一個包。

3 總結

針對電網信息化業務運行監控，本文首先提出了業務運行監控現存的4個問題；并通過分析找出問題在技術上的根源：業務邏輯和數據傳輸跨越多個資源環境是業務運行監控難以管理的技術根源。

然后本文提出了模擬用戶交互監控和通過“解剖”交互,查找,定位故障根源,為資源級故障診斷指明方向的解決思路。

最后本文提出了具體的解決方案，方案包括：

（1）采用對J2EE的應用程序進行實時監控和歷史數據分析，發現并且報告J2EE應用的健康度；

（2）采用端到端的應用監控，跨節點，粗粒度監控響應時間，從而找到問題的根源；

（3）采用用戶終端視角搜集響應時間。使得業務運行監控可以深入到業務應用內部，監控業務流程的每個步驟，從而使得故障得以快速定位、診斷和優化，IT運維人員精準到感知最終用戶的體驗，實時掌握業務運行狀態。