內蒙古工業大學：以特征知識庫打造IT綜合運維服務系統

文/顏培志 王鋼 楊海東

編者按：本刊從本期開始連載中國高校信息化創新應用案例，這些案例來自于高教學會教育信息化分會組織編著的《高等教育信息化創新應用案例選編》一書。全書一共28篇，將分期刊載。這些案例內容涵蓋高校教育教學與科研支撐、校務管理與信息服務、基礎設施與運維服務、信息化建設與運營服務模式創新等諸多方面，旨在為當前高校信息化發展提供一些可以借鑒和參考的模式。本期刊載內蒙古工業大學、華東師范大學以及香港理工大學的案例。該案例集一書在近期由清華大學出版社出版發行。

建設背景

隨著計算機網絡技術的蓬勃發展，網絡的接入用戶數量在爆炸式增長,以學校實際情況為例，開通用戶數已近3萬人，白天平均在線人數多達1萬人。面對這樣一個龐大的用戶群體，網絡的管理維護人員所背負的工作壓力越來越大。這時再依靠個人經驗的傳統方式來進行基礎網絡服務工作將面臨巨大問題，這不僅浪費寶貴的人力資源，而且效率也是非常低下。因此需要一套規范高效的IT運維服務管理方法，再配合以準確全面的解決方案知識庫，才會大大降低運維人員的工作壓力，使工作變得從容有序。基于這樣的需求，我們組織并實施了基于ITIL和特征知識庫的校園IT綜合運維服務系統的研發工作。

建設目標

校園IT綜合運維服務系統的目標是建設一套符合ITIL管理理念的網絡中心業務服務管理信息系統，它能夠針對用戶遇到的網絡問題，與現有網絡管理系統相結合，實現網絡設備運行數據獲取，提供問題解決方案，以幫助運維管理人員快速準確地找到故障原因，并為用戶進行解答。系統要降低故障診斷的專業性和難度，使網絡運維工作人人能上手，人人愿出力。同時，通過事件流程的監督提醒機制，縮短事件處理的時間，促進網絡中心服務承諾制度的落實。

關鍵技術

最佳距離度量算法

在IT運維中，某個故障都有區別于其他故障的明顯特征，且有可能是多個特征。對于這些明顯特征，我們稱之為基本特征，是線性無關的。為了計算故障和解決方案的相似度，首先建立度量空間，將故障的每個基本特征定義為空間的一維，則整個空間的維數為我們日常歸納出的基本特征的個數，每個故障由其所表現的特征的坐標來表示。那么實際中的一個故障（即一個問題Problem）可定義為Pi，它由一些基本特征唯一確定，在度量空間中的坐標為（X1，X2， Xn）其中n為基本特征總數。同時，將解決方案（也即知識稱為Solution）定義為Sj，同理也由基本特征惟一確定。再將Pj定義為Sj對應的故障，且假定Pj與Sj之間的映射為雙射，即一一對應。將基本特征作為空間的基，將Sj、Pj用其坐標與空間基的乘積表示，那么求解可能解決問題的Pi解決方案的集合{Sj}的過程就可以歸結為求解問題空間中與點Pi比較接近的點的集合的過程，這些點可以是已有的解決方案或已經解決過的問題。

例如，校園網用戶電話報修，稱其網卡燈亮，但上不去網。窗口服務人員利用網絡故障特征檢測輔助程序對其所在的交換機進行檢測，檢測到交換機可以PING通，但用戶端口環路。這其中，網卡燈不亮、交換機可PING通、端口環路都是基本特征，那么這三個特征即可表達為空間三個基向量產生的點P（1， ，0，1， ，0，1），通過度量算法找到與P點距離最近的方案，就定位到了一個最佳的解決方案。在特征知識庫中，由網絡工程師事先定義了環路問題的解決方案，它與點P的距離最近，由此，不了解技術細節的服務人員就可以將這個最可能的解決方案提供給用戶。

圖1 系統架構

故障特征庫

根據學校校園網的實際組成結構和運行狀況，常見故障問題一般都有相對固定的現象。在本次項目中，運維管理人員對這些現象特征做了詳細的總結和分類，形成了故障基本特征分類統計表。在表中又對不同分類級別的特征規定了一個數據庫內的特征編號，由此形成特征分類數據庫。應用程序采用樹形結構展現特征分類數據庫，供窗口服務人員選擇相應的故障特征。當分類級別最低的特征被選定時，其特征編號以及父分類的特征編號同時被取出，這些編號組合在一起就產生了本次選擇的特征向量值，進而在知識庫中選出與本向量值相匹配的知識庫條目。

當知識庫中未找到與特征向量相匹配的內容條目時，就說明知識庫中缺少針對這種特征的解決方案，此時事件將轉交到后臺工程師來處理。后臺工程師對事件進行跟進解決時，必須對缺少的知識庫內容進行填寫，后臺程序把填寫的內容與本事件的特征向量值對應起來并保存到知識庫中，這樣就形成了知識庫的積累、更新功能。

建設過程

系統的建設過程大致分為需求調研分析、系統設計、編碼實現、測試等幾個階段，總共歷時1年。系統建設工作由網絡中心主任牽頭，工作團隊包括網絡中心的信息系統管理部、網絡運行服務部、校園卡服務中心等科室的多名一、二線技術人員。在建設過程前期的需求調研分析階段，多次召開項目實施協調會，集中討論系統建設的目標、使用需求、技術路線等重要問題。在系統設計工作完成后，所有參與人員共同討論，論證系統的各部分流程、各種模型的可行性，為編碼實現工作奠定了良好的基礎。

架構設計

如圖1所示，本系統先從原有用戶認證計費系統和網絡監控管理系統中抽取原始數據，結合eService系統數據如解決方案知識庫等，來完成服務臺流程。同時，服務臺還可以延伸為自助服務模式，通過網站、自助終端、短信及語音網關等方式通過eService系統的WebService接口來獲取用戶所需要的信息。

知識庫建設

系統初期的知識庫建設工作主要由網絡中心各科室的主要技術負責人來完成。他們先后查閱了兩年所積累的近1000份紙質工單記錄，歸納出70多項現象特征，并有針對性地撰寫出圖文并茂的解決方案。

實施效果

系統于2013年初上線至今，經過幾次優化調整，現已平穩運行，全面支撐起了網絡中心的網絡運維業務。

工作中前臺工程師為一線支持服務人員，在固定時間、固定地點接待用戶上門或電話求助，受理用戶申請辦理的業務，對網絡故障的求助提供初步的技術支持。當問題無法在前臺解決時，可轉交至后臺工程師。前臺工程師僅可以看到本人提交添加的事件，包括轉交給其他角色的事件，并可以看到此事件的狀態。當轉交出去的事件長時間沒有關閉時，需催促轉交的后臺工程師盡快處理事件。

后臺工程師為二線支持管理人員，擁有較深的專業技術知識和處理問題的能力，熟悉信息系統和校園網，處理由前臺工程師轉交過來的事件，對大面積網絡或系統故障進行調查處理，并根據需要生成片區故障信息。接到前臺工程師轉交的事件，應該立即對問題進行診斷，當無法在遠程調試解決或診斷為現場硬件故障時，需把事件進一步生成工單，安排現場工程師赴現場處理。

現場工程師為現場服務支持人員，熟練掌握現場維修服務需要的各項技能，完成后臺工程師指派的維修工單，并在工單成功處理完成以后關閉工單。

清晰的一線、二線、現場工程師工作角色及工作流程，配合故障自動分析判斷功能，使系統在網絡中心面向用戶的服務中發揮了重要的作用。在受理的事件中，由前臺工程師受理直接解決的簡單重復性問題超過50%，不必再轉交給后臺工程師，很大程度上緩解了后臺工程師的工作壓力，也提高了用戶服務體驗度。

校園IT綜合運維服務系統將傳統方式的校園IT綜合運維服務用遵循ITIL框架的管理系統支撐起來，規范了業務辦理流程，減少了人為因素產生的疏漏、推諉，提升了業務辦理的效率和用戶的滿意度。簡化了運行維護工作的方式方法，降低了工作中一些關鍵環節的難度，使得許多并不具備扎實網絡技術的人員也能參與其中，既緩解了校園網維護人員人力不足的問題，又提升了大家的工作積極性。平臺下一步將向網絡中心業務全支持、信息全公開和支持移動終端方向繼續發展。