電網(wǎng)信息化業(yè)務(wù)運(yùn)行監(jiān)控存在的問題及對(duì)策

文/周英耀 張華兵

近年來，電網(wǎng)企業(yè)在“集團(tuán)化運(yùn)作、一體化管理”戰(zhàn)略要求下，不斷深入和擴(kuò)展信息化建設(shè)，系統(tǒng)及網(wǎng)絡(luò)設(shè)備規(guī)模不斷擴(kuò)大，多種應(yīng)用軟件，如數(shù)據(jù)庫(kù)、中間件等不斷增加，業(yè)務(wù)系統(tǒng)的數(shù)量也越來越多。如今，全網(wǎng)統(tǒng)一的企業(yè)級(jí)系統(tǒng)全面投運(yùn)，基本實(shí)現(xiàn)管理制度化、制度流程化、流程表單化、表單信息化以及各業(yè)務(wù)之間的橫向協(xié)同、縱向貫通。

但是電網(wǎng)企業(yè)在信息系統(tǒng)應(yīng)用性業(yè)務(wù)運(yùn)行監(jiān)控方面的技術(shù)手段相對(duì)薄弱，無法深入到業(yè)務(wù)應(yīng)用內(nèi)部，難以監(jiān)控業(yè)務(wù)流程的每個(gè)步驟，從而阻礙了故障的快速定位、診斷和優(yōu)化，IT運(yùn)維人員不能精準(zhǔn)到感知最終用戶的體驗(yàn)，不能實(shí)時(shí)掌握業(yè)務(wù)運(yùn)行狀態(tài)。

為了使IT運(yùn)維人員需要快速、準(zhǔn)確定位系統(tǒng)性能瓶頸（硬件層面、軟件層面），縮短故障恢復(fù)時(shí)間，確保業(yè)務(wù)不間斷。同時(shí)對(duì)于應(yīng)用開發(fā)人員也需要追溯業(yè)務(wù)功能及性能數(shù)據(jù)庫(kù)，合理評(píng)估系統(tǒng)健康狀態(tài)，量化IT運(yùn)維部門工作，本文深入對(duì)業(yè)務(wù)運(yùn)行監(jiān)控進(jìn)行分析和實(shí)踐。

1 業(yè)務(wù)運(yùn)行監(jiān)控現(xiàn)在存在的問題

1.1 缺少對(duì)業(yè)務(wù)管理系統(tǒng)業(yè)務(wù)運(yùn)行層面的監(jiān)控分析手段及指標(biāo)

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

1.2 缺少對(duì)用戶業(yè)務(wù)操作的真實(shí)體驗(yàn)的監(jiān)控

對(duì)于用戶業(yè)務(wù)操作的真實(shí)體驗(yàn)缺少系統(tǒng)的監(jiān)控和數(shù)據(jù)支撐。公司現(xiàn)階段的信息化建設(shè)，投入了很大精力在IT系統(tǒng)的建設(shè)和對(duì)IT基礎(chǔ)架構(gòu)的維護(hù)上，但即使部署了最先進(jìn)的基礎(chǔ)架構(gòu)，并不間斷地監(jiān)控PC、網(wǎng)絡(luò)、服務(wù)器、數(shù)據(jù)庫(kù)等的性能，用戶還是會(huì)抱怨系統(tǒng)運(yùn)行緩慢，不能及時(shí)發(fā)現(xiàn)哪個(gè)業(yè)務(wù)操作響應(yīng)慢，IT運(yùn)維人員也很難向用戶解析清楚問題原因在哪。

1.3 處于被動(dòng)運(yùn)維

公司應(yīng)用系統(tǒng)結(jié)構(gòu)復(fù)雜，各功能模塊分布在相對(duì)獨(dú)立的子系統(tǒng)，通過多個(gè)子系統(tǒng)再組合成多環(huán)節(jié)、長(zhǎng)交易鏈條的完整的應(yīng)用，很容易出現(xiàn)某個(gè)環(huán)節(jié)與其他環(huán)節(jié)的處理能力不匹配導(dǎo)致性能瓶頸，此類業(yè)務(wù)應(yīng)用的性能問題經(jīng)常發(fā)生且難于發(fā)現(xiàn)和定位。

因此，目前多數(shù)IT運(yùn)維處于“被動(dòng)式”管理，運(yùn)維人員并非是應(yīng)用系統(tǒng)的使用者，經(jīng)常是接到投訴電話之后才知道系統(tǒng)出現(xiàn)了問題，再去尋找問題根源，管理十分被動(dòng)。

圖1

圖2

1.4 IT環(huán)境復(fù)雜，定位問題困難

現(xiàn)階段公司IT環(huán)境日趨復(fù)雜，每個(gè)企業(yè)級(jí)應(yīng)用系統(tǒng)都部署在龐雜的基礎(chǔ)架構(gòu)上，并且與多個(gè)外部系統(tǒng)對(duì)接。當(dāng)問題出現(xiàn)時(shí)，發(fā)現(xiàn)問題很困難，更談不上快速定位、解決問題。

監(jiān)控不全面，缺少故障現(xiàn)場(chǎng)溯源數(shù)據(jù)，事后分析診斷條件不足，難以做到全面診斷且效率低，網(wǎng)絡(luò)尤其被動(dòng)，常常面對(duì)指責(zé)難以舉證。

2 業(yè)務(wù)運(yùn)行監(jiān)控解決方案

2.1 問題分析

當(dāng)前的電網(wǎng)企業(yè)業(yè)務(wù)，從物理上，涵蓋多個(gè)系統(tǒng)多臺(tái)物理服務(wù)器的應(yīng)用；邏輯上，包含多個(gè)應(yīng)用邏輯部件的應(yīng)用系統(tǒng)——不論從業(yè)務(wù)邏輯還是數(shù)據(jù)傳輸，應(yīng)用都跨越多個(gè)資源環(huán)境，然后才組合成業(yè)務(wù)系統(tǒng)。

大多數(shù)復(fù)合應(yīng)用為前端用戶提供復(fù)雜的業(yè)務(wù)系統(tǒng)（B/S架構(gòu)的Web應(yīng)用），應(yīng)用中的通用部件又可能被不同應(yīng)用系統(tǒng)以各種形態(tài)相互互連或重用，單個(gè)用戶請(qǐng)求可能貫穿甚至多次貫穿系統(tǒng)，業(yè)務(wù)請(qǐng)求對(duì)應(yīng)的返回?cái)?shù)據(jù)可能來源于多個(gè)子系統(tǒng)。

前端的應(yīng)用界面隱蔽了應(yīng)用后端的這種復(fù)雜構(gòu)架，但是不論后端的子系統(tǒng)發(fā)生何種異?！徽搧碜詷I(yè)務(wù)請(qǐng)求的異常、系統(tǒng)資源的異常還是應(yīng)用內(nèi)部邏輯和代碼的異?！脩舳紵o法完整發(fā)出的交互請(qǐng)求。

正是由于復(fù)合應(yīng)用系統(tǒng)的“復(fù)合”特性（業(yè)務(wù)邏輯和數(shù)據(jù)傳輸跨越多個(gè)資源環(huán)境），從優(yōu)化其性能和可用性角度來看，它難以設(shè)計(jì)、難以構(gòu)架、難以測(cè)試、難以管理；傳統(tǒng)分立的塊狀系統(tǒng)管理工具和方法論也很難很好的對(duì)它進(jìn)行管理和優(yōu)化。

2.2 解決思路

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

2.2.1 模擬用戶交互監(jiān)控

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

（2）監(jiān)控交互的可用性, 交互的總體相應(yīng)時(shí)間, 交互在各個(gè)資源上的相應(yīng)時(shí)間；

（3）定時(shí),定量監(jiān)控IT系統(tǒng)對(duì)業(yè)務(wù)服務(wù)的支持水平與服務(wù)質(zhì)量。

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

（1）對(duì)用戶交互進(jìn)行解剖,直到最基本的部件；

（2）對(duì)發(fā)生問題時(shí)記錄的上下文信息從應(yīng)用開發(fā)角度進(jìn)行分析。

2.3 解決方案

基于這樣的思路，電網(wǎng)企業(yè)提出包含以下3點(diǎn)的解決方案。

（1）采用對(duì)J2EE的應(yīng)用程序進(jìn)行實(shí)時(shí)監(jiān)控和歷史數(shù)據(jù)分析，發(fā)現(xiàn)并且報(bào)告J2EE應(yīng)用的健康度。監(jiān)控貫穿整個(gè)應(yīng)用流程，如應(yīng)用程序服務(wù)器、中間件適配器、傳輸協(xié)議、數(shù)據(jù)庫(kù)、并且能夠監(jiān)控后臺(tái)如CICS、IMS等主機(jī)系統(tǒng)。收集應(yīng)用程序請(qǐng)求周期的數(shù)據(jù)，然后存儲(chǔ)到監(jiān)控?cái)?shù)據(jù)庫(kù)，數(shù)據(jù)包括請(qǐng)求開始，結(jié)束的時(shí)間，所用的中央處理器時(shí)間等等，并且能夠通過一層層的遞進(jìn)跟蹤找到每個(gè)類，每個(gè)方法的響應(yīng)時(shí)間，中央處理器時(shí)間，從而定位發(fā)生交易失敗、響應(yīng)惡化的請(qǐng)求，并找到應(yīng)用程序需要改進(jìn)優(yōu)化的地方。

（2）采用端到端的應(yīng)用監(jiān)控，跨節(jié)點(diǎn)，粗粒度監(jiān)控響應(yīng)時(shí)間，從而找到問題的根源。圖1能很好的展示端到端的應(yīng)用監(jiān)控作用。

當(dāng)一個(gè)應(yīng)用跨越多個(gè)節(jié)點(diǎn)，出現(xiàn)不可用，或者響應(yīng)緩慢的時(shí)候，第一步是需要知道慢在哪個(gè)節(jié)點(diǎn)上（哪臺(tái)機(jī)器上），然后才能去診斷為什么那個(gè)節(jié)點(diǎn)會(huì)慢。以圖1為例子，通過應(yīng)用的拓?fù)鋱D和每個(gè)節(jié)點(diǎn)上的響應(yīng)時(shí)間，我們能很快的定位到“潛在出問題”的節(jié)點(diǎn)上。進(jìn)而通過ITCAM for WR/DB/MSG來查看容器的性能指標(biāo)找到問題根源。

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

其中圖2編號(hào)分別代表：

（1）瀏覽器向Web服務(wù)器發(fā)出頁面請(qǐng)求；

（2）服務(wù)器接收請(qǐng)求；

（3）服務(wù)器發(fā)出第一個(gè)包；

（4）瀏覽器請(qǐng)求第一個(gè)嵌入式對(duì)象；

（5）服務(wù)器發(fā)送頁面HTML的最后一個(gè)包；

（6）服務(wù)器發(fā)送最后一個(gè)嵌入式對(duì)象的最后一個(gè)包；

（7）瀏覽器接收最后一個(gè)嵌入式對(duì)象的最后一個(gè)包。

3 總結(jié)

針對(duì)電網(wǎng)信息化業(yè)務(wù)運(yùn)行監(jiān)控，本文首先提出了業(yè)務(wù)運(yùn)行監(jiān)控現(xiàn)存的4個(gè)問題；并通過分析找出問題在技術(shù)上的根源：業(yè)務(wù)邏輯和數(shù)據(jù)傳輸跨越多個(gè)資源環(huán)境是業(yè)務(wù)運(yùn)行監(jiān)控難以管理的技術(shù)根源。

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

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

（1）采用對(duì)J2EE的應(yīng)用程序進(jìn)行實(shí)時(shí)監(jiān)控和歷史數(shù)據(jù)分析，發(fā)現(xiàn)并且報(bào)告J2EE應(yīng)用的健康度；

（2）采用端到端的應(yīng)用監(jiān)控，跨節(jié)點(diǎn)，粗粒度監(jiān)控響應(yīng)時(shí)間，從而找到問題的根源；

（3）采用用戶終端視角搜集響應(yīng)時(shí)間。使得業(yè)務(wù)運(yùn)行監(jiān)控可以深入到業(yè)務(wù)應(yīng)用內(nèi)部，監(jiān)控業(yè)務(wù)流程的每個(gè)步驟，從而使得故障得以快速定位、診斷和優(yōu)化，IT運(yùn)維人員精準(zhǔn)到感知最終用戶的體驗(yàn)，實(shí)時(shí)掌握業(yè)務(wù)運(yùn)行狀態(tài)。