【摘要】：本文基于ＩＴＩＬ框架，提出了一种ＩＴ运维中心模型，涉及人员、管理、流程、技术等方面，为大型企业的信息系统运维提供了一套全面完整的解决方案。该运维中心模型主要由前端的服务台和后端的运维技术平台构成。服务台是用户与运维中心的接口，负责接收来自用户和运维中心内部的服务请求，同时对整个运维活动进行监督管理；运维技术平台是运维中心所有技术工具的集合，用来对信息系统的软硬件进行监控与运维。

　　【关键词】：ＩＴＩＬ；ＩＴ运维；运维中心

　　（备注：因在前面的内容里已介绍了ITIL，因此“1. ITIL简介”不再重复）

2. 运维中心模型总体设计

　　ＩＴ运维中心用来对大型企业的整个ＩＴ基础设施及运行其上的应用系统进行运行维护，确保整个信息系统正常运行，以及对故障等异常情况进行及时响应和排除。模型的设计包括人员、流程、技术、管理等方面。

　　本运维中心模型由前端的服务台和后台的运维技术平台组成。结构如图１所示。

　　服务台是用户与运维中心的接口，负责接收来自用户和运维中心内部的服务请求，同时对整个运维活动进行监督管理；运维技术平台是运维中心各种软、硬件的运维技术工具的集合，对前端的服务台提供技术支持。通过此平台，技术人员可以监控全部ＩＴ系统的运行状况、故障情况等，还可以通过此平台进行远程运维，对系统进行管理、配置、故障排除等操作。

３．岗位人员设计

　　运维中心的岗位分为前台的服务管理岗和后台的技术支持岗。如图２所示。 

　前端服务台包括用户响应员、运维调度员和运维管理员。用户响应员主要负责接受来自用户和运维中心内部的服务请求，以及和用户进行沟通；运维调度员负责对运维任务和技术人员进行分配调度，合理利用现有资源；运维管理员对整个运维流程进行跟踪监督管理，保证运维质量。运维技术平台包括机房工程师、硬件工程师、网络工程师、安全工程师、应用工程师、桌面工程师等专业技术人员，各自负责相应的运维领域。

4. 服务台

　　服务台在用户支持方面扮演了重要的角色。对于用户，服务台为他们提供了联系ＩＴ运维中心的单一联系点，从而可以确保他们能找到合适的支持人员来帮助解决其问题或请求。同时，服务台也负责跟踪来自ＩＴ运维中心内部的呼叫，例如告警处理等。对整个运维工作的监督管理，也是通过服务台来体现。服务台从事与许多ＩＴＩＬ基本流程相关的活动，包括事件管理、发布管理、变更管理、配置管理和服务级别管理。

　　４．１ 事件管理

　　事件管理是一个被动性的任务，也就是减少或消除存在或可能存在于ＩＴ服务中的干扰因素给ＩＴ服务带来的影响，以确保用户可以尽快恢复自己的正常工作。因此，要将事件记录下来并分类，再分配给适当的专业人员去处理；也要监控事件的发展；并在事件得到解决之后将其终止。事件不仅包括了软件和硬件有关的错误，还包括服务请求。事件管理流程涉及服务的整个生命周期。

　　事件管理流程如图３所示。

　　４．２ 配置管理

　　配置管理流程的目标就是要提供有关ＩＴ基础设施的可靠和最新的信息，不仅包括基础设施中某个特定的配置项的详细资料，还包括这些配置项与其他配置项之间的相互关系。配置管理流程负责核实ＩＴ基础设施中实施的变更以及配置项之间的关系是否已被正确地记录下来；监控ＩＴ组件的运行状态，以确保配置管理数据库能够准确地反映现存配置项的实际版本情况。配置管理活动包括规划、识别、控制、状态记录、核实、报告等几部分。

　　４．３ 变更管理

　　服务台可能进行处理标准化请求的一些活动，在这种情况下，服务台将帮助进行变更评估，并参与到变更管理中来。变更管理旨在管理变更的过程，以及相应的减少错误和与变更有关的事件。变更管理活动包括记录、审查、归类、规划和批准、协调、评价等步骤。

　　４．４ 发布管理

　　发布管理采用一种项目规划的方法来实施ＩＴ服务中的变更，它负责处理变更项目所有技术和非技术方面的问题。一项发布就是一组新的或变更后的配置项，它们是经过测试后一起被导入实际运营环境的。发布管理包括下列活动，发布制定和发布规划，发布设计、构建和配置，测试和发布验收，试运行规划，沟通、准备和培训，发布分发和安装。

　　４．５ 服务级别管理

　　服务级别管理是对ＩＴ服务的供应进行谈判、定义、评价、管理以及可接受的成本改进ＩＴ服务的质量流程。服务级别管理确保客户需要的ＩＴ服务得到持续的维护和改进，这主要是通过针对ＩＴ运维中心的运作绩效进行协商、监控和报告，以及在ＩＴ运维中心及其客户之间建立有效的业务关系来实现的。服务级别管理包括识别、定义、签约、监控、报告、评审等活动。

　５. 运维技术平台

　　绝大多数网络都组成一堆相互叠加的层，每一层都建立在其下一层的基础之上，每一层的目的都是向上一层提供特定的服务，而把如何实现这些服务的细节对上一层加以屏蔽。这种层次结构有效的降低了网络设计的复杂性，使网络更加易用、高效［３］。如今最流行的就是ＴＣＰ／ＩＰ协议架构。ＩＴ运维技术平台，就参考了ＴＣＰ／ＩＰ架构的优点，进行了层次结构的划分，以便提高运维效率。运维技术平台由下自上依次可以分为机房运维、硬件运维、网络运维、安全运维、应用运维五个层次，依次对应ＴＣＰ／ＩＰ架构的各层。如图４所示。

５．１ 机房运维平台

　　机房作为一切ＩＴ系统的环境基础，在整个系统中处于最底层也是最基本的要素，它的重要性不言而喻，一旦机房环境出现异常，就会对整个ＩＴ系统的正常运行造成威胁。机房运维平台要通过各种前端传感器、控制器和后台的软件平台，实现对机房环境与环境设备的统一监控与管理、自动告警、自动应急处理、自动日志记录等，达到所谓“无人值守”的标准。机房运维平台包括配电监测、ＵＰＳ监测、精密空调监测、漏水监测、温湿度监测、消防监测、新风机监测、门禁监控、视频监控等九部分。

　　５．２ 硬件运维平台

　　各种数量庞大的计算机硬件设备（小型机、服务器、交换机、路由器等）是ＩＴ系统的基础，对硬件设备进行统一管理，保持其良好的运行状态，及时发现设备故障并给予排除，是硬件运维平台的功能与目标。ＩＴ基础设备的管理需要在一个集中的平台完成所有的工作，本平台采用ＫＶＭ（Ｋｅｙｂｏａｒｄ Ｖｉｄｅｏ Ｍｏｕｓｅ，多计算机切换器）技术，整合主机系统管理界面，通过少数几台管理控制服务器对主机系统进行集中控制，方便对主控的监控，缩短故障响应时间。

　　５．３ 网络运维平台

　　现在的大型ＩＴ系统都是基于局域网或者互联网的，网络运维是为了保障ＩＴ系统能有一个稳定、畅通的网络环境，主要包括网络拓扑管理、网络诊断、历史记录查看及分析、设备面板管理、设备端口状态分析、设备属性一览、故障告警与定位、网络流量监测分析、ＩＰ地址资源查询等。

　　５．４ 安全运维平台

　　安全需求对于大型企业的信息系统来说是非常重要的，安全运维就是采用各种手段，包括管理和技术等，来为信息系统创造一个安全的运行环境，防止安全隐患和安全威胁。平台主要包括防病毒、网络准入控制、自动化补丁管理和安全控制、入侵防范、负载均衡、网络设备与安全设备监控和日志收集分析、网络行为审计、数据安全防护等。

　　５．５ 应用运维平台

　　应用运维是应用系统层面上的运维，保障应用系统的正常运行。主要包括操作系统运维、存储运维、数据库运维、应用系统运维、中间件运维等方面。主要实现服务器资源的状况监控（ＣＰＵ、内存等）、应用服务器内部的应用性能变化状况监控、故障定位；业务行为审计等功能。

　　６ 结束语

　　本模型为ＩＴ运维中心的设计提供了一套全面完整的解决方案，从全局高度综合地考虑了ＩＴ运维所涉及的人员、软硬件、流程、管理、技术等各个方面，使整个模型具有很高的全面性和完整性。

　　由于ＩＴ服务的持续性，ＩＴ系统发展的多变性，以及客户对ＩＴ服务高期望的不确定性，使ＩＴ运维中心的建设不可能是一步到位的活动，而应是一个不断发展进步的过程。本模型应该在实践的基础上，根据需要不断地修改完善，以提供更优质的运维服务。

案例2：来自http://bbs.vsharing.com/Information/CIO/542391-1.html

读ITIL的书，我们都是一章一章地读。服务支持流程的介绍顺序基本上都是服务台、事件管理、问题管理、变更管理、发布管理、配置管理等。书，可以这么安排章节，但读书的人不可以按照这样的章节分配来分割自己的思维。

读完了服务台，有一句话印象深刻：“服务台的功能经常与突发事件管理功能紧密结合，用来连接其它的服务管理流程，逐渐被称为一线服务支持的代名词。”为什么 会对此印象深刻呢？因为这句话在实践中体会的最深，从实践中我体会到服务台和事件管理之间一种“点”与“面”的紧密关系。

ITIL对事件管理这样描述：“事件管理的目标是尽可能快地解决突发事件或意外事件，使之恢复到正常的服务操作，并且使突发事件或意外事件对业务操作的负面影响减到最小。”简而言之，事件管理就是“确保高质量的服务水平得以维持，并使服务满足客户的需求”。

图1－服务台与事件管理关系简图  

从图1的描述中，我们看到事件管理的启动触发是服务台的服务请求。当服务请求经服务台进入事件管理流程后，事件管理围绕这个服务请求，依次按识别事件、分类支持、调查分析、解决事件、跟踪过程等流程进行操作，最终实现最短时间内恢复IT服务，将客户损害降至最小。这样，一个事件管理流程启动的触发点就将服务台和事件管理紧紧地捆绑在一起。没有这个触发点，服务请求无处可去；没有这个触发点，事件管理无用武之地。

根据客户服务中心的业务需求，服务请求被细分为：问题报修、新机开通、设备保养和业务咨询四类。按照ITIL对 事件管理目标的定义，在四个服务请求中似乎只有问题报修才符合事件管理的要求。但细想之下，其实不然。问题报修很明显属于异常或意外的事件，我们必须尽可 能快地给予解决；新机开通和设备保养，表面上看起来好像和异常或意外无关，但开通和保养的质量会间接地影响到客户的业务运行。试想，开通时刚安装完毕的POS机第一次开机突然黑屏；导入的门店信息出现异常等等，那么原本正常的开通此时就会转变为异常或意外事件；保养是一种预防性的措施，通过例行的设备维护来发现潜在的问题。当潜在问题被发现时，意味着异常或意外的事件即将被有效的措施控制在未来可能发生之前。

图2－事件管理控制图

客户服务中心的实施管理部主要由服务台和服务支持两部分构成。服务请求经过服务台时，会产生两种结果：一是服务台自行解决；一是服务台无法解决，转到服务支持再进行解决。无论是哪一种结果，最终都是要求实现客户满意的输出。但是，我们在图2中发现服务支持的处理过程其实就是“尽可能快地解决突发事件或意外事件，使之恢复到正常的服务操作，并且使突发事件或意外事件对业务操作的负面影响减到最小”。而这不正是事件管理的目标吗？图2实施管理部的上方为什么还有一个事件管理呢？

这还要先从客户服务中心的ITIL框架谈起。我在《面壁ITSM之框架搭建》中提到个人对客户服务中心ITIL框架的理解：为了IT服务支持和保障的及时、可靠和有效，由于服务支持部门的服务管理部，以第三方的客观立场对以IT服 务支持为核心的实施管理部进行综合的检查和评价，向客户服务中心或实施管理部的最高领导，提出问题与建议的一连串的活动。从这个角度来理解就可以很明确地 将服务管理部的事件管理和实施管理部的服务支持区别开来。前者负责服务过程的检查和评价；后者强调服务支持的快速、有效。虽然在名称有所差异，但是二者的 分立并不违背ITIL对事件管理的定义，因为最终的目的都是“确保高质量的服务水平得以维持，并使服务满足客户的需求”。

服务台通过服务请求与服务支持建立了启动触发点，并对服务请求的受理、调派、维护、跟踪、反馈等进行跟踪，同时对每一个服务节点的把握，每一个服务环节的了 解也使得服务台由点及面地建立起对服务支持流程的全程监控，实现服务台成为事件主人的主动服务，以更好地为客户服务。“面”在此即表现为服务台通过关注服 务节点和服务环节形成的与服务支持大面积的紧密联接。

在研究实施管理部服务台与服务支持之间“面”的关系时，我发现同样“面”的关系也存在于服务管理部的事件管理与实施管理部的服务台之间。为什么呢？我们再来看看图2， 服务台对服务支持所做的跟踪都是“平面”的，跟踪到了问题但限于岗位职责无法对发现的问题作进一步的处理。而服务支持又会因为忙于快速处理，而缺乏足够的 时间来评估已经发生的问题。此时，于实施管理部的事件管理应运而生。初看上去，服务管理部的事件管理和服务台有着相似的功能，即检查和监督服务支持过 程。但实际上，服务管理部的事件管理更多的是根据服务支持流程的环节和节点来设置监控指标，如图2所示的：事件总量、服务立处理比例、解决事件平均耗用时间等等。通过这些观察指标的变化来发现服务支持过程中的异常，“进行综合的检查和评价，向客户服务中心或实施管理部的最高领导，提出问题与建议……”，弥补服务支持无暇顾及问题评估的缺陷。在实践中，客户服务中心服务管理部的权限不仅仅是提出问题和建议，而是可以直接向实施管理部下发工作改进要求并对改进后的工作作出评估。

这样，服务管理部的事件管理通过对服务支持过程的服务环节和服务节点的设点监控，不仅监督了服务支持过程，检查了服务台的工作质量，而且也实现了事件管理对实施管理部整体上的服务支持监控，用事件管理的“点”做到实施管理部“面”上的管理。