校園一體化運維平臺建設探索

郭 濤， 孫洪磊， 劉長龍

（哈爾濱工業大學網絡安全和信息化辦公室， 哈爾濱 150001）

0 引 言

隨著信息化應用越來越廣泛，網絡環境也變得日益復雜。 復雜的環境、復雜的配置、系統集成管理、硬件軟件故障、人為操作失誤、惡意攻擊、系統設備陳舊、設備更新等種種問題，使各個系統平臺越來越難于管理［1－2］。 為了確保學校各類系統穩定可靠的運行，建設網絡監控管理平臺的需求越來越迫切。

目前，學校應用的網絡運維工具主要有基線網絡監控系統、MRTG 開源鏈路流量負載監控系統。使用狀況大致如下：基線網絡監控軟件是通過簡單網絡管理協議獲得被監控網絡設備、通訊鏈路的狀態數據，系統操作員可手動將需要管理區域的網絡設備及拓撲添加到顯示區域內。 學校網絡區域劃分為一校區、二校區、科學園3 個校區辦公樓宇、學生公寓、家屬區住宅的200 多棟樓宇的有關數據，包含千臺設備、上萬節點的網絡拓撲，但隨著學校網絡規模的擴大，設備的劇增，該軟件已經無法管理學校規模龐大、網絡設備眾多、拓撲復雜的網絡。 由于網絡龐大，拓撲內網絡設備過多。 監控系統每次通過簡單網絡管理協議（SNMP 協議）獲取網絡設備的網絡狀態數據都需要很長時間。 若設備發生故障，網絡管理人員很難快速發現并予以處理。

MRTG 是通過SNMP 協議得到設備的流量數據，并將流量負載以圖形文檔方式顯示給用戶。MRTG 為免費的開源軟件，成本較低，因此在社會上有廣泛的應用性。 該軟件雖然實用但功能單一，只能監測流量占用情況，對于網絡運行環境中是否存在壓力等其它指標無法進行準確檢測。

綜上，一體化運維平臺應用需求日益強烈，建設統一的運維管理體系可以對校園內網絡、設備、數據庫、中間件及應用系統等資源進行全面監控，有利于各部門對其負責的資源進行管理；有效的ITIL［3－4］流程，可以對日常運行維護工作提供高效的管理框架，建立更好的部門間溝通平臺。 統一運維管理體系的建設將很大程度簡化運維流程、提高運維效率，同時可使面向全校各級部門的信息化服務質量和水平得到大幅度提升。 為了更好的網絡管理和運維，學校當前急需一個統一的運維管理體系平臺，此平臺需具備規范化、透明化、智能化、互動化運維服務能力。

1 一體化運維平臺需求分析

綜合的運維管理平臺需要從理念、架構、工具、系統等多方面來設計，應具有前瞻性、可擴展性［5］等重要特性。 其中，網絡資源管理要具備統一且完善的安全機制，以此做好被管設備信息資源的信息安全［6］。

1.1 監控網絡運維設備需求

根據學校實際情況，需要對多廠家設備進行統一管理：除了對H3C 的網絡設備管理外，還需對主流廠商（如：華為、思科、華三等）網絡設備進行分類和識別；對設備狀態和基本信息的管理，不僅要包含設備的運行信息、接口信息、性能數據和告警信息，還應在增加其他組件后，顯示擴展的業務信息。

資源監控管理可通過SNMP／PING 協議監控納管設備，將所有網絡資源納入系統中統一管理，提供全面的豐富多樣的管理和配置功能，將網絡中的所有設備狀態信息和運行數據，通過圖形化的手段，清晰、直觀的展示，實現從核心到匯聚再到接入層網絡設備的全部覆蓋。

1.2 ITSM（IT 服務管理）服務管理需求

運維平臺將采用IT 服務管理標準（ITIL）的最佳實踐和服務臺技術平臺功能，并針對客戶的具體業務需求，在事件管理流程方面實現如下IT 支持服務功能：

（1）確定合理的IT 支持服務模式和服務臺架構，實現所有用戶的IT 事件統一處理，提供高效高質量的IT 服務［7］。

（2）制定合理的人員角色和職責考核機制，通過SLA 的管理模型，對于維護人員處理工單的相應時間、處理時間與事件處理正確率進行控制，對于超時或違反操作規范的事件進行上報與升級，以實現對運維人員的量化管理和資源的有效利用。

（3）從技術和流程相結合的角度，對事件內容進行梳理，形成標準事件分類支撐的服務目錄，確保問題事件記錄處理的正確性與完整性。

（4）制定通知策略，定義合理的事件通知機制，使管理人員第一時間收到待處理的問題，加快故障的解決時間，及時將處理結果通知給用戶，并快速得到用戶對服務的反饋，以此提高服務質量與用戶的滿意度。 采用通知的方式包括企業微信、微校園，微信公眾號等。

（5）通過與知識庫的集成，加快知識積累和傳播，幫助執行人員快速解決問題，提高故障的解決效率和質量；對于一些通用的解決方法，可以提交為知識庫進行共享。

（6）將服務臺與其他系統（如：監控平臺、統一身份認證平臺、數據共享平臺、大屏展示平臺等）進行聯動，建立數據通信接口，使得整個IT 管理平臺聯為一體，信息統一，集中展示，加快故障的解決時間。

（7）設立合理的業績績效指標（KPI），利用開發視圖等手段對流程的執行提供查詢、統計、分析和監控等功能；用戶可查看本人提交的服務申請處理進程和狀態，查詢相應的知識和解決方案等；避免人工錄入產生的差錯；使得支持人員可以快速解決大量事件，也可以從大量重復事件中迅速總結出問題，實現和問題流程關聯，對一些需要追查故障根源的事件發起問題單。

1.3 數據可視化展示的需求

隨著大數據和互聯網時代的到來，傳統的統計圖表很難適應現代復雜的需求。 相對于傳統可視化工具開發的圖表和數據儀表盤，可視化大屏可以搭載地理軌跡、區塊、3D 地圖／地球，多圖層疊加等技術，打破數據隔離，通過數據采集、清洗、直觀實時地將數據可視化，呈現隱藏在瞬息萬變且龐雜數據背后的業務洞察，能更加生動友好地活化數據，同時也能結合豐富的交互功能，讓數據開口說話，傳達超出本身的信息。

網絡中心使用大屏的方式展示數據，可以將實際運維過程中一些關鍵信息進行展示，如設備告警狀態、設備連接狀態、各出口使用情況等。 當相關設備出現問題時，有關人員可以第一時間看到問題所在并進行跟進，其它人員也能實時地觀看到維修進度。

2 平臺系統架構及功能設計

2.1 系統設計

系統架構采用運維管理平臺與呼叫中心集成，如圖1 所示。 最底層是IT 基礎設施層，其包含學校網絡與信息中心運行管理的管理對象，其中包括網絡設備、安全設備、服務器、存儲設備、系統應用、中間件、虛擬化資源等。

圖1 運維平臺整體功能架構圖Fig. 1 The overall functional architecture of the operation and maintenance platform

運行監控管理模塊主要實現對IT 基礎架構的監控，通過監控采集數據和進行數據處理，實現對被管理運行對象的監控，掌握運行資源的配置狀況、監控對象的運行狀態和性能參數。 其采集數據支持第三方監控集成，同時可將告警、性能、數據處理分析信息提供給其他系統，實現如告警自動派發工單、短信通知等功能。

2.1.1 采集層

采集層由各種協議適配器構成，使用SNMP、TELNET、SSH、TRAP 及第三方接口。 主要采集3 個園區（一校區、二校區、科學園區）的IT 基礎設備信息，其中涵蓋網絡、存儲、數據庫、服務器、虛擬化等數據資源。 同時具備強大的歷史記錄能力，可實現45 萬KPI 的指標數據至少存儲1 年；可對每個設備分別按照周／月／季度、1 年等時間段進行整體趨勢分析，從歷史層面分析出業務運行規律，方便發現業務運行異常；多指標相對分析，實現管理對象的縱向比較，找到異常的指標集。

2.1.2 處理層

所有采集的基礎數據由于設備類型不同，分成不同的數據維度，如告警維度、性能維度、拓撲維度等，每個維度相對獨立，且之間的關系均為松耦合。層次與層次之間的溝通均通過API 接口，各個業務模塊面對統一的數據模型，使其對資源的管理方式一致并處于單一的可控路徑下，方便對資源進行權限管理。 將采集的數據經過數據聚集，再進行數據清洗和過濾、最后通過數據分類后寫入數據庫，以供展示層從數據庫調用監控數據；同時也用于處理展示層傳遞的用戶操作與設定。

2.1.3 展示層

主要將數據處理層處理后的數據進行分類展示，展示層完全以B／S 方式來展示各個管理模塊，用于監控拓撲展示、3D 機房呈現、統計報表、大屏呈現，提供統一的Portal，以及告警、報表、歷史記錄、智能分析、數據統一展現等。 實現與用戶互動，響應用戶的操作與設定，利用分布式總線實現各邏輯層之間的通信，功能模塊之間通過內部定義數據接口，利用消息總線進行交互式操作。

2.2 功能設計

一體化運維平臺功能包括資源監控管理（IOM）、資源配置管理（CMDB）、 IT 服務管理（ITSM）、定制可視化大屏（CVC）等模塊。 平臺能夠對監控對象進行分組分類，可根據不同用戶實現分權分域管理，結合IT 服務管理模塊，實現高水平的服務質量、服務請求和IT 資源管理；通過服務水平協議（SLA），制定符合學校實際業務的指標規則，并無縫兼容市面上的多種呼叫中心系統；結合IP 電話與坐席，實現自動建立工單，并能將電話的錄音留存；偶遇突發狀況時，可以發布語音公告和文字公告，大大降低故障報修數量，提高運維的工作效率。

2.2.1 呼叫中心

呼叫中心是客服中心統一接入平臺，以集中式坐席為服務熱線和企業微信線上自助報修的形式，將數據信息統一管理，24 小時不間斷地提供服務。

如圖2 所示，呼叫中心采用新一代多媒體呼叫中心系統，其功能強大，而且性能穩定、維護簡單，集合了先進的計算機技術、通信技術、網絡技術、數據庫等技術，實現了語音、傳真、VOIP、短消息、等多種方式。 其中包含自動語音應答、自動話務分配、電話錄音、來電彈屏與ITSM 集成功能，實現不漏接任意資源、報修電話，并自動記錄、錄音，便于事后追溯。

圖2 呼叫中心架構Fig. 2 Call center architecture diagram

2.2.1.1 來電關聯工單

呼叫中心通過與一體化運維平臺中的ITSM 組件關聯，實現系統收到報修電話后，則根據報修人信息自動創建工單。 話務組收到工單后，再對用戶進行反饋，或轉派給其它對應部門進行處理。

一線維修人員通過企業微信通知打開工單，可以看到報修工單的故障內容摘要、報修人地址、電話等信息，從而進行相應操作處理。

2.2.1.2 自助服務臺

將呼叫中心系統與ITSM 系統進行深入對接，并在ITSM 系統增加呼叫中心配置界面，為每位話務人員配置具體的接口地址、ACD 隊列號與注冊號。 實現電話鈴聲響起時，系統自動創建工單，同時在表單中同步顯示來電用戶的姓名、住址、來電號碼等信息的功能。 話務組人員只需要判斷故障類別，記錄故障內容，選擇故障地點，即可快速提交工單，使該條工單進入到工單處理環節，最終實現工單的秒接、秒辦。

2.2.1.3 運維工作區

運維用戶可定制個性化工作區，可在工作區中提供和自己相關的運維工作內容。 其中包括“流程監控”、“待處理的任務”、“我創建的流程”、“與我相關的流程”、“我管理的流程”等。

ITSM 提供了服務、請求／事件／故障、問題、知識庫等管理功能。 所有的運維活動，都可以在這個運維工作區中銜接完成，管理人員可以將各種故障處理的步驟和方法寫入知識庫。

按照運維管理的相關規定，規劃建立相應的故障處理工作流程，提供方便易用的用戶工作界面。

2.2.2 資源監控管理模塊

管理中心以業務管理和業務流程模型為核心，采用面向服務（SOA）的軟件設計思想，基于主流的J2EE 架構平臺，在保持技術先進性、擴展性的基礎上，采用子系統、層次化、模塊化的設計理念，以全開放的、組件化的架構原型，通過消息總線進行集成，將實現基礎設施監控、CMDB 配置管理、運維流程管理等功能整合成一個綜合平臺。 此外，平臺還提供了分布式、分級式的部署模式，二級代理支持橫向擴展，提供可靠的、可擴展的、高性能的一體化運維管理平臺，并具備開放的restful web services 接口，用來集成。

如圖3 所示，資源管理模塊由資源管理及日志采集適配層、系統功能層及web 應用層組成。 資源管理和日志采集適配層支持豐富的設備訪問協議，通過SNMP、CLI（telnet／SSH）、netconf、TR069、FTP、TFTP、SCP、RADIUS、HTTP 等協議實現傳統網絡及SDN（軟件定義網絡）網絡等設備和軟件的統一監控和配置管理；通過IPMI、SMI－S、SNMP、SSH 等協議實現對服務器、存儲等設備的硬件監控和操作系統自動安裝；通過RESTful 接口、SOAP、powershell 等實現對各大主流廠商等虛擬化產品的統一管理；通過WMI、JDBC、SSH、Telnet、SOAP、http／https 等協議實現對操作系統、數據庫、中間件、應用系統的統一監控和管理。

圖3 資源管理模塊數據架構Fig. 3 Resource management module data rrchitecture

系統功能層包含了資源監控、CMDB、運維流程管理模塊。 其中，資源監控將協議適配層采集的各類告警和性能數據存入到統一的性能數據及告警庫中；CMDB 采用開放可持續集成框架，使用者可定義個性化的定義模型，并且可通過資源監控模塊實現數據配置信息的自動發現和更新。 運維流程管理組件基于開源的JBPM 流程引擎，在此之上開發了事件管理、問題管理、變更管理等多種流程實例，實現運維管理流程化。

2.2.3 告警管理模塊

告警管理亦稱故障管理，為用戶提供統一的全流程故障管理體系。 通過設備運行日志自動上報與主動輪詢雙向處理，確保快速準確發現網絡故障。通過實時告警關聯分析，屏蔽重復無效告警，分析告警生成原因。 通過實時告警與拓撲提示、告警板聲光提示、手機短信、Email、微信等遠程提示，快速將詳細準確的故障信息通知到網絡管理員。 通過固化用戶維護經驗，為后續相關告警處理提供經驗參考與快速定位指導。

2.2.4 ITSM 模塊ITSM 服務流程管理模塊遵循國際ITIL 標準，采用平臺設計理念及模塊化設計，系統功能全面、操作簡便、高度集成、性能穩定。

采用ITSM 服務，可以提高信息系統運維的可視化水平、提升運行質量及運行效率，為業務穩定、高效、安全、持續的運行提供保障。 最終達到提高服務管理效率，優化運維流程，提高高校運維服務部門的IT 綜合服務和維護管理水平。

將管理者設計理念與管理想法融入到流程與制度中，讓一線運維人員明確故障＆ 事件的分級、處理時間要求和處理流程，明確事件＆ 故障的處理職責和分工界面，提升故障的處理效率。

2.2.5 CMDB 模塊

隨著IT 技術的進步與發展，高校IT 基礎設施和信息系統越來越復雜。 數量龐大、品種繁多的IT設備及以這些IT 設備為基礎的各種技術服務很難被有效的管理。 系統通過配置管理數據庫（CMDB）對校園的IT 資源進行維護、檢查、識別和控制，從而高效控制與管理不斷變化的網絡基礎架構與信息技術服務。

同時，由于高校的IT 環境在不斷變化，為了更好的評估某個設備或服務發生的問題或變化對應用的影響，以及為其它流程提供當前系統準確的配置信息，需要準確及時的記錄設備數目和狀態的變更，精準記錄每個設備的狀態，必要時即時準備替補資源。

2.2.6 自助報修模塊

自助報修模塊采用圖形化流程定制功能模塊，通過簡單直觀的操作和配置，定義符合高校特色的應用流程活動與角色，實現圖形化流程定制功能，由用戶自行進行流程的重定義，以及流程的隨時調配。用戶可以通過PC 端／微信服務大廳根據故障類型提交故障報修，一線維修人員收到工單后，會在規定時間內受理工單。

自助報修模塊的總體架構如圖5 所示，為確保系統安全，采用單點登錄的方式。 可以方便的與第三方系統進行集成，流程生成和處理采用了自動化流轉的方式。 后端數據存貯使用了MySQL 數據庫，前端主要使用了H5 技術，如圖4 所示。

圖4 自助報修系統結構Fig. 4 Self－reporting system structure

圖5 大屏輪播Fig. 5 Large screen rotation

3 性能分析

性能分析可以快速識別系統運行時產生的異常狀況。 平臺實時采集納管設備的運行信息，資源管理包含了學校納管的所有設備的分類統計和運行狀態概覽。 以視圖的形式呈現核心設備鏈路出口的收發速率及帶寬占用率。 實時采集平臺納管設備的設備日志運行信息，過濾重復設備日志運行信息的同時比對閾值，若超出標準值立即觸發告警通知。 當前平臺監控網絡設備1 879 個節點，監控無線AP 設備23 126 個節點，實現對這些節點的實施監控，快速采集與精準分析都需要占用較大的系統資源，平臺資源占用情況見表1。

表1 平臺性能圖表Tab. 1 Table of platform performance

參照校園地圖所提供的位置搜索等功能，這種用戶體驗，平臺提供了折線圖、柱狀圖、餅圖、雷達圖、地圖等數十種圖表， D3.js 的JavaScript 庫，其利用現有的Web 標準，通過更簡單的（數據驅動）方式來展示可視化效果

監控大屏輪播展現3 個校區的樓宇地圖，當樓宇內設備出現告警，所對應樓宇開始閃爍，點擊樓宇亦可看到告警設備數量，并根據對應數值，查看告警詳情頁面。 采集到的告警信息，會同步推送到手機APP中，運維人員通過手機實時掌握設備的運行狀態和告警消息，發現異常指標及時響應，使設備快速恢復正常運行狀態。 如圖5 所示。

結合監控數據庫空間使用情況分析，可見項目試運行上線2020 年7 月至今數據庫空間占用總量為130 G，日志文件3 G。 設計空間800 G 滿足平臺5 年數據增長量。

為實現數據的通訊、傳輸、報警、查詢、趨勢圖分析等功能，需要對采集的數據進行長達一年期的無壓縮存儲，并對每類資源的數據單獨劃分獨立的庫存儲，同類資源數據存儲在同屬性的庫中。 并根據每一類監控資源節點數量，合理劃分每個庫的空間大小，自動進行數據庫系統運行狀態的監控。 由圖6 可見，圖形化呈現數據庫的空間利用率及日志空間占用情況，既能減輕平臺維護人員的工作壓力，也能更進一步增強平臺運行的穩定性。

圖6 數據庫空間Fig. 6 Database space

對于用戶來說，實現便捷的自助報修，平臺的設計十分重要。 考慮到目前大部分人手機的使用要遠多于其他終端，因此結合之前已存在的微信服務大廳，整合實現成了移動端的自助報修功能。用戶可以通過單獨設計的H5 頁面進行報修，該平臺與已經存在的ITSM 模塊進行對接結合，通過微信服務大廳進行的故障上報將會自動生成工單，并且發送給相關負責人員。

4 結束語

本文構建的網絡運維管理平臺已實現了IT 資源跨地域層次化的統一管理；實現了對高校各業務支撐系統的設備管理、性能管理、數據庫管理、應用管理、報表管理、資產管理等功能；實現了對各個應用子系統的運行狀況進行集中監控，實現聲音、短消息發送、釘釘，微信等報警手段；對各系統的運行性能進行監控、分析和統計；完成了數據庫及應用管理，能夠保證數據庫及應用服務管理滿足運行維護的需要。

一體化運維管理平臺的建設，大大地簡化了運維流程、提高了運維效率，同時使得面向全校各級部門的信息化服務質量和服務水平得到大幅度提升。

下一步正在有計劃的將其它軟硬件資源納入系統中，實施從傳統工作模式向信息化工作模式的全面轉變。 隨著平臺的深入使用，相關工作人員解決問題的效率得到了明顯的提升。 所構建的系統大大提高了工作效率，達到了預期目標。