一个基于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，都需要在这个阶段确认。一个事件真正意 义的结束关闭不是简单的问题得到解决，一个完整的事件流程是所有对外问题，对内分类、 变更的相关流程都完成结束以后。 问题、变更&发布管理 问题管理 问题管理是事件管理的后续与推进，这个阶段核心目标是把未知名问题转变为知名问 题。 问题管理的管理内容很大程度上是来自于事件的统计分析，问题管理的“关注度”其 实就是继承了事件管理的“影响范围”和“严重程度”的结果。在规划问题管理的时候， 其“等级度”这个属性是要和事件管理的相呼应，这样也是便于由事件管理到问题管理的 平滑过度。不是所有的事件都要转化为问题来处理，到底该管理什么？一般关注的是“严 重程度高的事件”和经过统计后“重复出现的事件”，严重程度高意味着严重度*影响范围 的指标值就打，重复出现的事情的解决可以大大降低维护成本，减少资源，在这两类问题 上花费资源是事半功倍的，别纠结在那些影响不大，或者偶尔才发生的事情上。 问题的创建不象事件，它还需要有个“审批”的过程，这也是确保资源的有效使用， 避免过度反应。其次问题管理还和 SLA、配置库、知识库等相关联，这在设计问题管理流 程以及出入接口的时候应该注意的地方。总体来说问题管理不是 ITIL 的难点，关键要在实 际中按设计的流程来执行。 变更管理与发布管理 尽管在 ITIL 中这两个是分开的独立流程，但在我们的业务流程中这两个环节是由一 个部门先后顺序执行的，没有在部门这个角度上再区分。本来变更管理的核心并不是执行 变更，而是变更需要在一定的授权和控制直下执行。发布的核心也是在一定授权的情况下 实施的，以保证最新制定的变更能及时有效正确的部署到实际流程中，如果僵化的分开