随着中山大学数字化校园建设的深入开展，其复杂性与日俱增，IT运维管理的难度呈指数级上升，这主要由三个方面所致：规模大，中山大学校园网目前已覆盖4 个校区，跨越广州、珠海两座城市，网络节点、服务器节点合计约3000个；用户多，截止到2007年5月份，中山大学入网计算机数达35000台，预计 2010年将达到45000台；网络流量的多样性、异质性，除了正常的因特网应用流量（如Web、E-mail、FTP、P2P、Streaming 等）、中山大学私有应用流量（如校务管理系统、BlackBoard数字化教学、一卡通等），还有非正常的垃圾/攻击流量（如scan、probe、 flood、spam、worm等）。但是，用户对服务质量的要求却丝毫未有降低，IT运维管理正面临着严峻挑战。
    原先低效的、被动式的、面向网络/系统为主的运维管理必须要跃迁到高效并可重复优化的、主动式的、面向服务为主的运维管理，只有这样才能满足数字化校园可持续发展的要求。本文的主要目的就是研究如何建设这种新型的IT运维管理体系。
    定位

    如图1所示，数字化校园建设可分为“基本内容”和“支撑体系”两个部分，目前大多数高校建设的重点还停留在“基本内容”部分，如校园网扩容升级、数据中心、高性能计算、校务管理系统、一卡通等，而“支撑体系”部分建设容易被忽略或弱化。对于中山大学来说，数字化校园建设的“基本内容”部分已初具规模，建设重点已经转向“支撑体系”的建设，这是实现数字化校园建设5个转变（粗放式→精细式、硬为主→软为主、项目建设→服务建设、被动→主动、事后→事前）战略目标的关键步骤。可以看出，“支撑体系”部分主要分为IT运维管理体系、安全体系和用户服务体系三个部分，其中，IT运维管理体系又是其余两个体系的基础，其地位的重要性显而易见。
    体系设计
    中山大学的IT运维管理体系建设的基本思想是充分借鉴ITIL最佳实践的方法、流程，并结合自身情况给予剪裁、补充，决不盲目照搬，紧密融合组织、制度、流程、预案及演练等方面，走一条有中山大学特色的具体实践之路，其初步目标是实现日常运维有效管理，以保障IT系统的稳定与效率、从容应对各类紧急事件、以及合理的IT系统架构设计。
    中山大学的IT运维管理体系的总体设计如图2所示，它重点借鉴了ITIL最佳实践的配置管理、事故处理、问题处理、变更管理及发布管理流程，即“服务支持”部分，将传统的基于技术的IT管理与现代的基于流程的IT管理进行了有效结合。

全面的监测体系

    这是传统IT管理的重要内容，它也是整个IT运维管理体系的基础。在具体实现中，一方面，要利用成熟的监测工具对IT的基础环境（如机房的温度、湿度、 UPS等）进行监测，对网络系统、主机系统、存储系统、中间件及数据库系统、基本的因特网应用进行故障及性能监测，从值班人员的角度来说，主要是被动接收监测工具监测的信息；另一方面，由于应用的复杂性，尤其是一些私有应用，普通的监测工具只能监测到应用服务端口的可达性，其很难判断真实的“应用逻辑”的可用性，故值班人员应以普通使用者的身份去测试应用的可用性，主动地、定时地进行监测并记录使用情况。
    在建设监测体系时，特别要注意“工具”和“人”之间的协调关系，过于迷信工具的作用或者过于依赖人的操作对于整体的IT运维管理体系建设都是有害的。配置管理及CMDB。
    配置管理指识别和确认系统的配置项（CI），记录和报告配置项状态和变更请求，检验配置项的正确性和完整性等活动构成的服务管理流程。配置管理使得IT部门可以管理数字化校园中各个基础部件的整个生命周期，从采购、使用到报废，包括软硬件配置信息，它主要有三部分工作：登记组成服务的资产信息；登记这些资产之间的关系；确保配置管理信息库中的各类相关信息能够得以及时更新。
    CMDB（配置管理数据库）指包含每个配置项及配置项之间重要关系的详细资料的数据库。从业务角度来看，它不仅实现对数字化校园各个IT部件信息的跟踪，而且能够深入了解各个流程配置信息，并对配置信息进行共享。实际上，它就是一张IT部门的业务视图，反映数字化校园运行环境，当出现问题时，就可以到里面去找，会很清楚地知道这会影响什么，会关联什么，以及关联的原因。如果实际中有这个业务视图的话，会大大提高工作效率。从运营的发展目标来看，因为要强调精准性和效率，所以必须要建立CMDB。
    事故管理
    事故（Incident）是任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件。事故管理的作用是快速有效地响应最终用户，使它们能够迅速恢复工作，以减小对最终用户的影响，它包括故障管理，通过服务台接线员以及二线技术人员的工作，迅速解决客户的故障。主要包含以下活动：
    1.检测和记录事件通过系统管理软件检测出来或用户打电话进来，或通过Web，所有事件记录进系统中；
    2.判断并分派确定是事故，服务请求还是申述。如果是服务请求，依照服务请求流程；如果是申述，依照申述流程，如不是，进行事故的影响、收集信息等（定制checklist），尝试解决问题；
    3.判断是否已解决
  

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。