數字校園亟需建立IT運維管理體系
隨著中山大學數字化校園建設的深入開展，其復雜性與日俱增，IT運維管理的難度呈指數級上升，這主要由三個方面所致：規模大，中山大學校園網目前已覆蓋4個校區，跨越廣州、珠海兩座城市，網絡節點、服務器節點合計約3000個；用戶多，截止到2007年5月份，中山大學入網計算機數達35000臺，預計2010年將達到45000臺；網絡流量的多樣性、異質性，除了正常的因特網應用流量(如Web、E-mail、FTP、P2P、Streaming等)、中山大學私有應用流量(如校務管理系統、BlackBoard數字化教學、一卡通等)，還有非正常的垃圾/攻擊流量(如scan、probe、flood、spam、worm等)。但是，用戶對服務質量的要求卻絲毫未有降低，IT運維管理正面臨著嚴峻挑戰。
原先低效的、被動式的、面向網絡/系統為主的運維管理必須要躍遷到高效并可重復優化的、主動式的、面向服務為主的運維管理，只有這樣才能滿足數字化校園可持續發展的要求。本文的主要目的就是研究如何建設這種新型的IT運維管理體系。
定位
數字化校園建設可分為“基本內容”和“支撐體系”兩個部分，目前大多數高校建設的重點還停留在“基本內容”部分，如校園網擴容升級、數據中心、高性能計算、校務管理系統、一卡通等，而“支撐體系”部分建設容易被忽略或弱化。對于中山大學來說，數字化校園建設的“基本內容”部分已初具規模，建設重點已經轉向“支撐體系”的建設，這是實現數字化校園建設5個轉變(粗放式→精細式、硬為主→軟為主、項目建設→服務建設、被動→主動、事后→事前)戰略目標的關鍵步驟。可以看出，“支撐體系”部分主要分為IT運維管理體系、安全體系和用戶服務體系三個部分，其中，IT運維管理體系又是其余兩個體系的基礎，其地位的重要性顯而易見。
體系設計
中山大學的IT運維管理體系建設的基本思想是充分借鑒ITIL最佳實踐的方法、流程，并結合自身情況給予剪裁、補充，決不盲目照搬，緊密融合組織、制度、流程、預案及演練等方面，走一條有中山大學特色的具體實踐之路，其初步目標是實現日常運維有效管理，以保障IT系統的穩定與效率、從容應對各類緊急事件、以及合理的IT系統架構設計。
中山大學的IT運維管理體系的總體設計，它重點借鑒了ITIL最佳實踐的配置管理、事故處理、問題處理、變更管理及發布管理流程，即“服務支持”部分，將傳統的基于技術的IT管理與現代的基于流程的IT管理進行了有效結合。
全面的監測體系
這是傳統IT管理的重要內容，它也是整個IT運維管理體系的基礎。在具體實現中，一方面，要利用成熟的監測工具對IT的基礎環境(如機房的溫度、濕度、UPS等)進行監測，對網絡系統、主機系統、存儲系統、中間件及數據庫系統、基本的因特網應用進行故障及性能監測，從值班人員的角度來說，主要是被動接收監測工具監測的信息；另一方面，由于應用的復雜性，尤其是一些私有應用，普通的監測工具只能監測到應用服務端口的可達性，其很難判斷真實的“應用邏輯”的可用性，故值班人員應以普通使用者的身份去測試應用的可用性，主動地、定時地進行監測并記錄使用情況。
在建設監測體系時，特別要注意“工具”和“人”之間的協調關系，過于迷信工具的作用或者過于依賴人的操作對于整體的IT運維管理體系建設都是有害的。
配置管理及CMDB
配置管理指識別和確認系統的配置項(CI)，記錄和報告配置項狀態和變更請求，檢驗配置項的正確性和完整性等活動構成的服務管理流程。配置管理使得IT部門可以管理數字化校園中各個基礎部件的整個生命周期，從采購、使用到報廢，包括軟硬件配置信息，它主要有三部分工作：登記組成服務的資產信息；登記這些資產之間的關系；確保配置管理信息庫中的各類相關信息能夠得以及時更新。
CMDB(配置管理數據庫)指包含每個配置項及配置項之間重要關系的詳細資料的數據庫。從業務角度來看，它不僅實現對數字化校園各個IT部件信息的跟蹤，而且能夠深入了解各個流程配置信息，并對配置信息進行共享。實際上，它就是一張IT部門的業務視圖，反映數字化校園運行環境，當出現問題時，就可以到里面去找，會很清楚地知道這會影響什么，會關聯什么，以及關聯的原因。如果實際中有這個業務視圖的話，會大大提高工作效率。從運營的發展目標來看，因為要強調精準性和效率，所以必須要建立CMDB。
事故管理
事故(Incident)是任何不符合標準操作且已經引起或可能引起服務中斷和服務質量下降的事件。事故管理的作用是快速有效地響應最終用戶，使它們能夠迅速恢復工作，以減小對最終用戶的影響，它包括故障管理，通過服務臺接線員以及二線技術人員的工作，迅速解決客戶的故障。主要包含以下活動：
1.檢測和記錄
事件通過系統管理軟件檢測出來或用戶打電話進來,或通過Web，所有事件記錄進系統中；
2.判斷并分派
確定是事故,服務請求還是申述。如果是服務請求，依照服務請求流程; 如果是申述,依照申述流程,如不是,進行事故的影響、收集信息等(定制checklist)，嘗試解決問題；
3.判斷是否已解決
確定問題是否已解決,如解決,由服務臺確認,如非,繼續診斷,必要時轉由二線進行支持解決等；
4.調查和診斷
二線支持人員利用自身技能和相關工具，力圖在規定的時間內提出解決方案,嘗試解決事件；
5.服務臺確認
對事件的解決方案進行確認,如未解決,根據情況采取相應動作；
6.結束
如果確認已解決，關閉記錄，更新文檔; 必要時進行回顧；
7.定期產生報表
事故支持人員將根據管理要求定期產生相關報表。
問題管理
問題(Problem)是指存在某個未知的潛在原因的一種情形、這種原因會(或可能會)導致一起或多起事故發生。問題經常是分析多個呈現相同癥狀的事故后發現的某種情形。
主要包括三方面的工作：一是確認問題，從大量的故障報告中找出問題；二是找到導致問題的根源并解決；三是為解決某個問題，需要提出變化請求。主要包含以下活動：
1.接受升級事故
當事故滿足升級條件時，問題管理流程接受該事故；
2.分析事故
定期分析事故，找出潛在問題；
3.生成問題記錄
問題記錄在幫助臺中生成，并把所有相關事故與此記錄關聯起來；
4.分派
問題記錄將根據問題內容分派給適當的技術小組；
5.根本原因分析
被分派的小組人員將調查問題以期找出其原因，制定解決方案或變通方法或提出預防性措施以消除產生原因或在重發時使其影響力最小化；
6.更新已知錯誤
這是流程中的關鍵一步, 記錄必須被更新以反映它是已知錯誤狀態,并且把任何變通方法、避免或最小化負面影響的動作行為也記錄下來；
7.提出變更請求
對問題的解決方案進行評估，通過變更請求(RFC)進行測試和實施。根據RFC對業務的影響和成本進行評估并決定繼續進行與否。并非所有問題需要解決，例如, 如果一個新的應用系統將要實施，那么老應用系統里的一個錯誤可能不需要解決；
8.關閉
一旦找出問題根本原因,并實施了解決方案,當確認已解決了問題,問題記錄可以關閉；
9.事后回顧
問題必須進行回顧以發現流程和服務得以改進的機會或總結預防性措施。包括改進事件監測、找出技能差距和文檔資料改進等。這對于回顧解決方案的成功與否也很關鍵。
變更管理
變更(Change)是指在維護過程中對系統或服務所做的各種改變，包括增補、移除和其他修改。變更管理指為了在最短的時間內完成基礎架構或服務的任一方面的變更而對其進行控制的過程，可分為被動變更，目的是再事故發生后要實施變更以消除事故產生的根本原因；主動變更，是指為適應信息科技技術的快速發展和數字化校園建設的內部需求所做的更新，如校園網升級等。
它包括三個不同的流程：
1.對要采取的變更作風險和影響分析；
2.將風險和影響分析以及變更計劃交給變更審批部門，由他們根據這些信息決定下一步要采取得行動，是批準，還是延遲或拒絕該變化申請；
3.實施該變更，指定相關人員實現每一步變化，并對變化的流程進行記錄，通知配置管理更新配置數據庫。
發布管理
發布管理(Release Management)是指對經測試后導入實際應用的新增或修改的配置項進行分發和宣傳的管理流程，它涉及已定義的IT服務的變更，這些變更通過對一些新應用軟件與升級硬件和新硬件的結合使用來完成的。主要包含以下活動：
1.發布規劃
2.發布的準備
3.培訓
4.生產環境的測試
5.用戶接受測試(User Acceptance Test)
6.系統推廣
本文詳細探討了IT運維管理體系的具體實踐，其主要由全面的監測體系、配置管理、事故處理、問題處理、變更管理及發布管理流程構成。
通過分析，我們了解到數字化校園可持續發展所面臨的新挑戰，即必須要重視支撐體系的建設，而IT運維管理體系又是支撐體系的基礎，尤為重要。其建設之路應充分借鑒ITIL最佳實踐的方法，并結合各單位的實際情況，將運維管理工作流程化、可持續完善化。
【編輯推薦】
