内蒙古工业大学：以特征知识库打造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框架的管理系统支撑起来，规范了业务办理流程，减少了人为因素产生的疏漏、推诿，提升了业务办理的效率和用户的满意度。简化了运行维护工作的方式方法，降低了工作中一些关键环节的难度，使得许多并不具备扎实网络技术的人员也能参与其中，既缓解了校园网维护人员人力不足的问题，又提升了大家的工作积极性。平台下一步将向网络中心业务全支持、信息全公开和支持移动终端方向继续发展。