王春波 胡亞 陳剛

【摘要】 SAP系統(tǒng)作為江蘇電力公司的核心系統(tǒng)，承擔(dān)著人、財(cái)、物等核心業(yè)務(wù)功能，系統(tǒng)的健康穩(wěn)定運(yùn)行就顯得尤為重要。但實(shí)際運(yùn)維過程中往往是在系統(tǒng)出現(xiàn)故障時(shí)才能發(fā)現(xiàn)問題。不僅對(duì)業(yè)務(wù)操作產(chǎn)生一定的影響，有時(shí)甚至產(chǎn)生無法挽回的直接經(jīng)濟(jì)損失。因此，有必要深入研究如何能夠及時(shí)有效監(jiān)控SAP系統(tǒng)運(yùn)行狀態(tài)，實(shí)現(xiàn)主動(dòng)運(yùn)維，保證系統(tǒng)健康穩(wěn)定運(yùn)行。

【關(guān)鍵詞】 SAP 信息系統(tǒng) 監(jiān)控平臺(tái)

前言

從2007年6月啟動(dòng)以來， 江蘇電力SG186工程項(xiàng)目經(jīng)歷了業(yè)務(wù)流程優(yōu)化、試點(diǎn)單位實(shí)施、推廣單位實(shí)施和持續(xù)深化應(yīng)用等階段，已構(gòu)建了覆蓋核心業(yè)務(wù)的一體化業(yè)務(wù)應(yīng)用平臺(tái)，目前正在進(jìn)行SG-ERP的深入建設(shè)。隨著越來越多的系統(tǒng)投入正式運(yùn)行，使公司各基層單位、各個(gè)部門之間的相互聯(lián)系日益增強(qiáng)。同時(shí)各個(gè)系統(tǒng)在縱向、橫向耦合程度日益加深，公司信息化水平已發(fā)生了質(zhì)的飛躍。為了保障公司各項(xiàng)業(yè)務(wù)在信息系統(tǒng)的支撐下能夠正常開展，江蘇省電力公司越來越關(guān)注本公司的系統(tǒng)運(yùn)維。SAP系統(tǒng)作為江蘇電力公司的核心系統(tǒng)，承擔(dān)著人、財(cái)、物等核心業(yè)務(wù)功能，系統(tǒng)的健康穩(wěn)定運(yùn)行就顯得尤為重要。

目前在SAP系統(tǒng)的運(yùn)行維護(hù)工作中，往往是在系統(tǒng)出現(xiàn)故障時(shí)才能發(fā)現(xiàn)問題，運(yùn)維人員疲于應(yīng)急維修，不僅對(duì)業(yè)務(wù)操作產(chǎn)生一定的影響，有時(shí)甚至產(chǎn)生無法挽回的直接經(jīng)濟(jì)損失。因此，有必要深入研究如何能夠及時(shí)有效監(jiān)控SAP系統(tǒng)運(yùn)行狀態(tài)，并且運(yùn)用信息化手段，主動(dòng)運(yùn)維監(jiān)測(cè)系統(tǒng)狀態(tài)，保證系統(tǒng)健康穩(wěn)定運(yùn)行。

一、開發(fā)平臺(tái)設(shè)計(jì)

該監(jiān)控平臺(tái)是基于SAP系統(tǒng)運(yùn)行情況進(jìn)行二次開發(fā)，采用的是C/S架構(gòu)?？蛻舳朔植荚诟鳂I(yè)務(wù)部門的終端。服務(wù)器統(tǒng)一存放在省信通公司，便于設(shè)備的日常維護(hù)和檢修。

1.1操作系統(tǒng)選擇

Linux是一個(gè)多用戶、多任務(wù)、支持多線程和多CPU的操作系統(tǒng)，是一個(gè)性能穩(wěn)定的多用戶網(wǎng)絡(luò)操作系統(tǒng)。SAP系統(tǒng)也安裝在此操作系統(tǒng)上，因此，本平臺(tái)的服務(wù)器也選擇Linux。

1.2數(shù)據(jù)庫(kù)選擇

Oracle是應(yīng)用廣泛的主流數(shù)據(jù)庫(kù)，江蘇電力的SAP系統(tǒng)也采用Oracle作為后臺(tái)數(shù)據(jù)庫(kù)，為了系統(tǒng)更好的集成，方便維護(hù)，本平臺(tái)也采用Oracle作為數(shù)據(jù)庫(kù)

1.3開發(fā)語言選擇

為了更好的與SAP系統(tǒng)集成，本平臺(tái)開發(fā)使用ABAP語言，通過Html來進(jìn)行平臺(tái)無關(guān)的頁(yè)面展示，采用Div+Css技術(shù)進(jìn)行強(qiáng)大靈活的屏幕自適應(yīng)布局，配合JavaScript來實(shí)現(xiàn)豐富的動(dòng)畫過渡和信息交互。

二、功能設(shè)計(jì)

SAP系統(tǒng)運(yùn)行狀態(tài)監(jiān)控平臺(tái)由四個(gè)功能模塊（指標(biāo)調(diào)度模塊、監(jiān)控計(jì)算指標(biāo)模塊、指標(biāo)匯總及分析處理模塊、監(jiān)控指標(biāo)配置模塊）構(gòu)成。ERP信息系統(tǒng)狀態(tài)評(píng)估系統(tǒng)應(yīng)用功能如圖1所示。

三、系統(tǒng)開發(fā)與功能實(shí)現(xiàn)

3.1系統(tǒng)進(jìn)程監(jiān)控

SAP應(yīng)用服務(wù)器進(jìn)程類型共有6種：DIA（對(duì)話進(jìn)程）、UPD（更新進(jìn)程）、ENQ（隊(duì)列進(jìn)程）、BTC（批處理進(jìn)程）、SPO（脫機(jī)進(jìn)程）、UP2（V2更新進(jìn)程）。

特定類型的任務(wù)只能通過特定類型的進(jìn)程進(jìn)行處理，而每臺(tái)服務(wù)器針對(duì)各類型都有一定的比例分配，若同種類型的任務(wù)同一時(shí)間段大量爆發(fā)，那么就會(huì)造成任務(wù)的堵塞，排隊(duì)的任務(wù)就有可能出現(xiàn)等待超時(shí)而導(dǎo)致業(yè)務(wù)操作受影響，甚至對(duì)業(yè)務(wù)數(shù)據(jù)產(chǎn)生影響。我們通過對(duì)各服務(wù)器的進(jìn)程使用情況的監(jiān)控來進(jìn)行壓力風(fēng)險(xiǎn)規(guī)避，監(jiān)控的參數(shù)包括各服務(wù)器各類型進(jìn)程的進(jìn)程使用率、進(jìn)程CPU占比、進(jìn)程占用內(nèi)存，進(jìn)程DB交互，進(jìn)程I/O等。

3.2內(nèi)存監(jiān)控

內(nèi)存對(duì)于系統(tǒng)來說毫無疑問是非常重要的參數(shù)。需要對(duì)每臺(tái)服務(wù)器的內(nèi)存進(jìn)行監(jiān)控，服務(wù)器上的內(nèi)存一旦不夠，發(fā)生的業(yè)務(wù)問題所帶來的影響都無發(fā)預(yù)測(cè)和估計(jì)，當(dāng)內(nèi)存使用率接近極限值的時(shí)候需要進(jìn)行告警。

雖然進(jìn)程監(jiān)控中也涉及一部分進(jìn)程占用的內(nèi)存監(jiān)控，但還需從服務(wù)器層面對(duì)內(nèi)存進(jìn)行的監(jiān)控，是服務(wù)器級(jí)別的系統(tǒng)健康運(yùn)行的重要參數(shù)之一。這里主要針對(duì)空閑內(nèi)存（Spared Memory）、堆內(nèi)存（Heap Memory）和擴(kuò)展內(nèi)存（Extended Memory）進(jìn)行監(jiān)控。

3.3系統(tǒng)鎖情況監(jiān)控

業(yè)務(wù)對(duì)象（Business Object）在SAP中是很重要的存在，核心的系統(tǒng)業(yè)務(wù)操作實(shí)際上是對(duì)業(yè)務(wù)對(duì)象的操作，所有的業(yè)務(wù)操作都需要保證業(yè)務(wù)對(duì)象事務(wù)的ACID特性。以項(xiàng)目為例，圍繞項(xiàng)目來進(jìn)行業(yè)務(wù)發(fā)生和管控，假設(shè)要在這個(gè)項(xiàng)目下進(jìn)行采購(gòu)訂單的創(chuàng)建，同時(shí)也要為這個(gè)項(xiàng)目進(jìn)行預(yù)算調(diào)整分配，但不能同時(shí)進(jìn)行兩件事（比如預(yù)算調(diào)減，同時(shí)創(chuàng)建訂單，最終結(jié)果很可能是超預(yù)算，這樣的內(nèi)控就沒控?。?，而訂單和預(yù)算是兩個(gè)不同的東西，如何保證兩個(gè)操作的串行發(fā)生，就需要對(duì)業(yè)務(wù)對(duì)象進(jìn)行加鎖以保證業(yè)務(wù)的不沖突。

鎖的重要性不言而喻，而對(duì)于SAP這種業(yè)務(wù)高度集成的軟件來說，保障其正常的使用，就顯得尤為重要。這里就需要監(jiān)控：

系統(tǒng)鎖的總數(shù)：系統(tǒng)鎖的數(shù)量有限制的，若系統(tǒng)當(dāng)前鎖個(gè)數(shù)超過這個(gè)限制，那么就會(huì)導(dǎo)致鎖等待的發(fā)生，操作可能會(huì)因?yàn)槌瑫r(shí)而dump；

系統(tǒng)鎖的信息維度分析：對(duì)系統(tǒng)正常運(yùn)行，以1000個(gè)鎖為例，若是在一個(gè)幾千人使用的系統(tǒng)環(huán)境里，這個(gè)指標(biāo)看起來是很健康的，但是，如果是由同一個(gè)人或同一個(gè)程序產(chǎn)生的，那么這種情況是否應(yīng)該值得關(guān)注呢？單憑某一時(shí)刻的體量是無法暴露出這樣的隱患的，所以要根據(jù)創(chuàng)建賬號(hào)，創(chuàng)建程序，訪問終端等維度對(duì)系統(tǒng)鎖進(jìn)行記錄統(tǒng)計(jì)。

3.4系統(tǒng)TRFC/QRFC狀態(tài)監(jiān)控

TRFC（事務(wù)RFC，Transactional Remote-Function-Call）和QRFC（隊(duì)列RFC，Queue Remote-Function-Call）是和外圍系統(tǒng)或自身進(jìn)行異步交互的重要方式之一，實(shí)際上QRFC是TRFC中的特例，所不同的是，QRFC是無序的，而QRFC是存在隊(duì)列進(jìn)行控制的，即串行發(fā)生的。若系統(tǒng)中的TRFC和QRFC出現(xiàn)信道堵塞或隊(duì)列堵塞的話，那么也是會(huì)對(duì)業(yè)務(wù)產(chǎn)生影響的。所以不僅要監(jiān)控未處理和處理錯(cuò)誤的TRFC和QRFC數(shù)量，還要按照程序、賬戶、終端等維度進(jìn)行監(jiān)控記錄統(tǒng)計(jì)，對(duì)于各維度極端異常的情況需要暴露給運(yùn)維人員。

3.5系統(tǒng)dump數(shù)據(jù)監(jiān)控