随着中山大学数字化校园建设的深入开展，其复杂性与日俱增，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最佳实践的方法，并结合各单位的实际情况，将运维管理工作流程化、可持续完善化。