IT运维工作是自己工作的一个组成部分，这里就着一个项目的实施经验，谈谈ITIL是怎么和具体项目结合落地的。

一、项目介绍

这是一个跨地域的数据采集、传输与处理的运维项目，其特点为：

1、 1、跨地域广。覆盖全国16个省会城市的数据采集点（托管在当地IDC机房），北京城东、

西两个数据处理点，一个位于城中的业务处理与技术支持中心。

2、 2、业务要求的稳定性高，7*24服务，RTO与RPO要求高。

3、 3、设备种类多。有视频信号接入设备，机顶盒（由于属于民用设备，后期统计看该设备的

故障最高），由工控机承担的采集机，PC机做的预处理机，还有存储服务器，阵列柜，数据库服务器以及其他网络设备和传输线路等。

4、 4、牵扯人员多。包括IDC服务工程师，传输服务商，数据中心与业务中心的业务人员，技

术人员和管理人员等。

5、 5、沟通渠道复杂。每个环节都需要保证畅通的沟通渠道以保证和相关人员沟通信息。

二、二、项目目标

在这个项目中本人承担的角色，对内是IT服务角色，对内部的业务部门提供IT运维支持，对外承担管理服务商的角色，按与服务商签订的SLA进行跟踪管理。

项目的目标是：建立一个运维体系和信息化平台，把所有业务环节、服务流程与人员纳入到这个平台中，有效合理的调配资源，及时发现处理重要事件，提高运维效率，提高运维质量从而提高IT服务支持能力，提高用户满意度。

结合公司实际运维需求与能力，最终把项目的实施范围锁定在“服务支持”流程上，包括服务台功能，事件管理、问题管理、配置管理、变更管理和发布管理上。不求做的多，但求实用与质量。

三、技术设计

因为是跨地域的使用系统，因此采用B/S系统架构，尽管可能再速度上和表现界面上有些缺陷，但对我们这个应用来说这两点都不是核心需求。在开发语言上选择的是.NTE，数据库选择是SQL Server，这也是和我们目前产品采用一致的技术路线，方便日后的维护和对接。

服务台

上次在1中说了项目的背景介绍，在这里开始介绍这个项目是如何实施的。

ITIL从哪里下手？听到不少人是从“服务台”来做的。如果按我的理想规划来说，从“配置管理”做起比较合理，因为配置管理是所有其他模块的支持核心，它不但对其他模块的有效执行起到信息支持的功能，同时其他模块也要及时的变更配置库以保证配置库的最新有效状态。但这个实施的顺序是有潜在的适应要求的，对一个从无到有全新的系统，这个顺序无疑是正确的方式也容易操作，但具体到我这个项目，因为已经在运行当中，是边运营边建设的特点，假如这个时候再教条的从“配置管理”做起，那我将面对的是花费很大精力建立的“配置库”无流程可以配合使用，因此也会导致无流程维护其内容有效性的境地，这样的话，等到最后体系都建立完成，就会发现以前建立的配置库信息都失真无效，还要重新来过的情况。同时，在这个项目上，先做“服务台”也能立刻对外显示成果，这个成果确实也是领导需要的，当然也是我需要的。因此最后还是确定从“服务台”开始了这个运营体系的建设。

在ITIL中，服务台是有别于其他流程的，它被ITIL定义为“职能”而非“流程”，这也就说明了在我们实现该模块的时候，是要和其他模块的实现有区别有不同的。我知道不少人在实际落实上并没有注意到这点，而是把“服务台”当成一般流程一样看待，设计有专门的岗位，人员和流程，这点上我个人有些不同看法。”服务台”的核心职能是“单点受理用户事件，提供一般问题的处理支持和跟进事件处理的全过程，及时反馈给用户”等，这些事情如果照搬普通call center的模式，安排几个人在接通用户后，把问题再反馈给后续人员处理，那这个设置是没什么意义的，也许他是提高了快速响应，但并没有达到快速处理的目的。有价值的服务台是能在最短时间内提供有效的方案解决用户出现的问题，而这需要有专业的知识，这不是普通热线人员能达到的水平。但假如为达到这个水平而设置一群技术人员专职从事这个事物，那必将导致成本的上升，对我们这个公司来说是没法支持这个模式的。

因此，在我们这个系统体系下，服务台就是直接由技术维护人员和具有一定技术能力的业务骨干来充当的，他们各自分管设备和流程的一部分，这些分工信息对用户是公开的，因此当各自分管的工作出现问题时，用户直接可以联系到这些人员以得到及时的帮助，这些人对该事件负责，也负责其他服务台的职责。在这里可以看出，我并没有拉出一个团队组建一个“服务台”这么一个组织，而是规划出一个虚拟的“服务台”团队，既是一线支持人员也是事件的管理者，当这些人员遇到不能解决的问题时，由他们负责后续的协调组织工作，直到事件处理接触。

所以，在我的这个运营体系中，“服务台”是被设计成嵌入在“事件管理”的流程中，成为了这个流程的一部分。对“服务台”的考核不是一天能受理多少客户电话，而是有多少客户需求被满足。只要流程、制度设计的完善，能完成“服务台”应该有的职责就可以了，而不必要一定建立一个专职的团队，尤其是在那些人力资源紧张的情况下。

事件管理

这个管理流程是整个系统最重要也是使用最多的，因此对它的严谨性，简洁性和标准性要求也就比较高。

结合实际项目的运营，我们把事件的起源分为两大类：主动事件和被动事件。主动事件是我们运维人员等通过内部的检查机制或者预警机制发现的问题或者发起的事件。被动事件是由系统使用的用户在使用过程中发现的问题事件和咨询等。这个分类主要是为了分析评估我们的检查机制和预警机制的功效。

事件类型被分为：“故障”、“咨询”、“新需求”和“维护通告”，基本上涵盖了所有重要的事件。而同时又从事件诊断角度对每个事件进行了分类，包括：电力、信号、网络传输、硬件设备、操作系统、应用软件、数据库和业务应用等，这样细分也是为了日后统计分析，有针对性的制定相关问题解决方案，充实知识库和CMDB。需要指出的是，这里的分类要考虑到与CMDB的同步，这样便于两种数据的互通。

不是所有的事件都要立马处理解决的，我们按照业务重要性（BIA）的特点和SLA的内容，根据事件的严重程度和紧急程度量化事件的严重等级。其中严重程度参考故障影响范围（频道数和流程数等），紧急程度参考RTO和RPO的需求。事件的严重等级最后确认为5级，并分别对每个级别做了行动预案，规定了流程、职责和批准关系等。

为了了解事件的实施进展，一个事件的全过程被区分为以下几个阶段：事件创建、事件等待、处理中、解决完毕，评审完毕，事件关闭。每个阶段都记录责任人，起止时间，用以评估每个环节和每个人的工作效率。各个阶段的切换必须由一定授权的人员完成，且受时间发起短的服务台人员的监控下。这里需要特点谈一下“评审完毕”的作用，有两个：一是确认项目当时的分类信息等是否正确，这样保证以后的统计正确性。二是确认事件是否引发“变更”流程，不论是知识库还是CMDB，都需要在这个阶段确认。一个事件真正意义的结束关闭不是简单的问题得到解决，一个完整的事件流程是所有对外问题，对内分类、变更的相关流程都完成结束以后。

问题、变更&发布管理 [问题管理]

问题管理是事件管理的后续与推进，这个阶段核心目标是把未知名问题转变为知名问题。 问题管理的管理内容很大程度上是来自于事件的统计分析，问题管理的“关注度”其实就是继承了事件管理的“影响范围”和“严重程度”的结果。在规划问题管理的时候，其“等级度”这个属性是要和事件管理的相呼应，这样也是便于由事件管理到问题管理的平滑过度。不是所有的事件都要转化为问题来处理，到底该管理什么？一般关注的是“严重程度高的事件”和经过统计后“重复出现的事件”，严重程度高意味着严重度*影响范围的指标值就打，重复出现的事情的解决可以大大降低维护成本，减少资源，在这两类问题上花费资源是事半功倍的，别纠结在那些影响不大，或者偶尔才发生的事情上。

问题的创建不象事件，它还需要有个“审批”的过程，这也是确保资源的有效使用，避免过度反应。其次问题管理还和SLA、配置库、知识库等相关联，这在设计问题管理流程以及出入接口的时候应该注意的地方。总体来说问题管理不是ITIL的难点，关键要在实际中按设计的流程来执行。

[变更管理与发布管理]

尽管在ITIL中这两个是分开的独立流程，但在我们的业务流程中这两个环节是由一个部门先后顺序执行的，没有在部门这个角度上再区分。本来变更管理的核心并不是执行变更，而是变更需要在一定的授权和控制直下执行。发布的核心也是在一定授权的情况下实施的，以保证最新制定的变更能及时有效正确的部署到实际流程中，如果僵化的分开执行，不但加长了流程部门间的沟通协调工作，还可能导流程事件的延长，导致标准没有及时下达到实际生产流程中，形成不一致。因此只要在授权上和控制上设计的合适就没必要一定要两个流程来分别处理。但所有的变更都要保留历史和痕迹，这样有利于跟踪和职责管理。

变更管理中最重要的是配置库相关的变更，同时还有就是发布的版本控制问题，变更发布的时间点控制问题，目的是要避免影响正常业务环境。

 

第二篇：中国ITIL运维市场需求总结

20xx年中国ITIL运维市场需求总结

随着中国企业信息化建设的深入推进，信息系统的规模不断扩大，业务对IT系统的依赖性越来越大，同时IT系统日趋复杂、系统维护要求越来越高。尤其是金融、电信、电力等重点行业对IT运维管理的要求越来越高。ITIL作为运维IT管理的新理论、方法和工具，正在发挥着越来越重要的作用。

ITIL作为管理IT的一种方法和理念，从初期有人提出它的概念到成为行业标准在世界范围内得以广泛应用，以ITIL作为规范的IT服务管理也成为一个受到重视的领域。那在即将过去的20xx年，中国企业用户是日常网络运维管理中又遇到了怎样的难题，他们究竟需要哪方面的解决方案，以下进行详尽分析。

ITIL运维需求分析

一.基础设施监控需求

20xx年，企业对IT基础设施仍然保持着高投入，随着也产生了对基础设施运营维护需求。而对这些基础设备的监控不仅要求实时的，而且要求具有一定的颗粒度，能保证网络环境的正常运行。一般来说，需要用网络设备、服务器、用户上网行为以及安全方面进行充分地管理，才能确保一个企业内网的安全、稳定。

基础设施作为网络正常运作的基石，是IT运维人员关注和关心的重点。如何保障快速查看网络中所有的网络信息、网络全局、运作

情况，如何及时预防发现网络设备故障和隐患，如何快速操作控制不同厂商、型号的网络设备，都是IT运维人员的管理需求。

企业许多核心业务都运转在服务器上，而一些公司的web服务、网站等都需要服务器的支持，因为系统管理员需求维护这些服务器。网络管理人员需要配置管理服务、安装管理DNS服务器、为终端用户颁发许可证，管理本地和远程式终端等。通过以上操作，服务器才能真正为企业服务，而服务器正常运转后，服务器的网络环境、运行状态、参数设置等情况又是需要管理员时刻关注的。

二.业务服务管理需求

企业在在实施良好的基础设施管理后，网络运维需求就提升到新的层面，需要进行精细化的业务服务管理，这也是企业ITIL运维管理的精华之所在，满足IT服务于企业业务的管理层次。企业的IT运维管理在某种程度上说是重复性的工作，既然有处理IT故障的经验，就希望这些经验能积累成知识，成为企业IT管理的智能库，进而更好地为流程化的企业IT管理服务。

1、服务流程管理需求

在以服务制胜的今天，IT部门非常需要有一套好的管理理念和管理工具来支撑服务体系。信息中心需要为IT运维人员与服务的用户之间提供唯一的接口(SPOC，Single Point of Contact)。用户对不同专业部分的咨询、问题和投诉都通过该接口进行，避免用户与各级支持人员直接联系带来的种种弊病，如出现不同问题找不同支持人

员、找不到人、问题得不到及时反馈和解决等等现象。通过应用IT服务流程管理体系和平台，用户可以很好地将一系列的服务以体系化的形式来进行前台、后台的有效关联，更好地提供IT服务。如广通推出的基于ITIL规范的Broadview COSS 解决方案，就很好地应用和推广了ITIL服务台管理、事件管理流程、问题管理、配置管理等服务流程。

2、知识库管理需求

调查显示知识库管理是企业ITIL运维系统建设中的一个重点需求。在ITIL运维知识库管理中，所有可以为处理事件和问题、排查日常工作中遇到的潜在隐患提供有效帮助的信息，及与运行维护及服务台、二线和三线支持人员日常工作相关的有效信息，都应该提交到知识库中。

信息中心以往经常会出现这种情况：网络出现故障，一个人去解决花掉一个小时；过段时间，同样的问题再出现，另一个人处理，又另外再花费1个小时。这样导致知识没有得到及时的沉淀和积累，而基于ITIL的广通Broadview解决方案可以通过知识库管理来解决这些问题。

ITIL运维市场分析

20xx年的国内ITIL运维市场格局可以大致分为以前几种情况：国际知名厂商的ITIL运维服务在高端行业如电信、金融等占据了较

多份额，相比国内厂家更具有技术实力和服务优势；中端市场如省级运维项目，国产ITIL运维厂商开始彰显实力，因为本土化的优势使得软件更符合用户的使用习惯，同时也能满足绝大多数企业用户的需求；对于一些信息化刚起步的初级用户市场，ITIL运维工具更多的起到指建设导向作用，需为实现ITIL的服务流程打下前期基础，国内厂商在此领域竞争也较为激烈。