一个基于ITIL的运维项目介绍总结

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，都需要在这个阶段确认。一个事件真正意义的结束关闭不是简单的问题得到解决，一个完整的事件流程是所有对外问题，对内分类、变更的相关流程都完成结束以后。