ITIL运维管理技术建议方案-非常不错的资料

XX客户ITIL运维系统实施建议方案
目录
1 XX客户ITIL运维系统背景 (3)
1.1XX客户信息化背景与现状 (3)
1.2服务运维未来目标 (4)
1.3实施范围 (4)
2 XX客户ITIL运维系统需求分析 (5)
2.1业务现状 (5)
2.2设计目标 (5)
2.3需求分析 (6)
3 XX客户ITIL运维系统实施建议方案概述 (7)
3.1ITIL与MIBP (7)
3.2面向不同角色的建设目标 (9)
3.3关联同类故障处理方式，规范事故处理阶段 (10)
3.4故障点关联裙带的展现 (10)
3.5度量运维效率，降低服务风险 (10)
3.6拓展IT服务途径 (11)
3.7建立分类统计报告机制 (11)
4 XX客户ITIL运维系统实施建议方案详述 (12)
4.1借以ITIL的运维阶段概述 (12)
4.2强化运维管理流程关键点详述 (13)
4.2.1 服务台&事故管理 (13)
4.2.2 问题管理 (16)
4.2.3 变更管理 (18)
4.2.4 发布管理 (20)
4.3提高运维效率关键点详述 (22)
4.3.1 关联同类故障处理方式，规范事故处理阶段 (22)
4.3.2 故障点关联裙带的展现 (22)
4.3.3 度量运维效率，降低服务风险 (23)
4.3.4 拓展IT服务途径 (24)
4.3.5 建立分类统计报告机制 (24)
4.4度量运维成效关键点详述 (25)
4.4.1 丰富的报表及KPI统计 (25)
4.4.2 便捷的报表定制 (27)
4.5增强运维灵活度关键点详述 (28)
4.5.1 CMDB设计工具 (28)
4.5.2 流程设计工具 (29)
4.5.3 表单设计工具 (30)
4.6提升运维品质关键点详述 (32)
4.6.1 服务台，快速恢复业务，减少企业损失 (32)
4.6.2 提供自助服务台，多种沟通渠道触发运维工单 (34)
4.6.3 以CMDB为运维核心，自动发现资源配置项 (35)
4.6.4 问题管理，找到根本原因，防止故障重复发生 (38)
4.6.5 变更管理，消除因为变更对业务造成的影响 (39)
4.6.6 发布管理，帮助变更有序的执行 (40)
4.6.7 SLM，度量运维效率，降低服务风险 (41)
4.6.8 知识库和FAQ的紧密结合，运维经验的积累 (42)
4.6.9 可定制的报表及KPI，度量流程执行绩效 (43)
4.7快速运维实施关键点详述 (45)
4.7.1 服务台配置向导 (45)
4.7.2 CMDB配置向导 (47)
4.7.3 系统管理配置向导 (48)
1XX客户ITIL运维系统背景
1.1 XX客户信息化背景与现状
目前，随着XX客户信息建设飞速发展，现今已形成**********************的规模。

为支撑不断发展的后续建设和发展，XX客户十分注重企业信息化的建设和应用，并投入了大量的资源，XX客户信息系统现有在建和已建成的应用系统超过XX个，注册用户数超过XX名，硬件设备数量达XX多台。

随着XX客户信息化工作的深入开展，IT服务运维管理的范围、数量难度呈指数级上升，信息系统服务运维主要体现在以下几方面特点：
地区范围广：我司办公区域分散，目前公司计算机网络覆盖5个办公区域；
应用用户数目庞大：目前终端用户数超4000个，各主要业务应用也有各自的账号和权限管理系统；
设备类型多样，信息系统服务器，其中有近数10台小型机、过百台服务器，超过300台网络设备和6000台电脑及外设；
信息系统环境复杂多样，操作系统平台有windows/UNIX/HPUX等，数据库平台有Oracle/SQL，此外还运行使用了个中高端交换机、路由器、互联网防火墙及负载均衡等网络设备。

应用环境复杂：已投入运行的应用系统多达30个以上，系统应用普及广泛，各系统实现技术类型多样，基础设施的运行要求各异。

目前承担服务运维工作人员不到40人，负责包括服务、应用、系统、网络及安全等运维业务，其中有15人为桌面维护外包代维人员，常驻各办公区负责桌面维护。

在运维工作量急剧增长同时，业务部门对信息中心提供的IT服务质量也提出了更高的要求，IT服务运维正面临着严峻挑战。

虽然XX客户信息系统服务运维体系建设投入了大量的资源，但是与未来大规模信息系统运维所提出的稳定、规范、高效的运维目标相比仍有较远距离，XX 客户信息中心有必要建立科学合理的IT服务运维管理体系，借助信息化手段实现以面向服务为主的、主动高效的、可重复优化的IT服务运维管理，以满足“数字化XX客户”可持续性发展的要求。

1.2 服务运维未来目标
XX客户服务运维未来工作目标是建立一个体系化、标准化的IT服务运维管理体系，构建起能支撑未来大规模信息化服务运维工作的全面实施有效信息化管理，降低信息系统服务运维人均成本，实现企业信息化效益最大化。

1.3 实施范围
XX客户信息系统服务运维平台的咨询、设计及实施将在充分调研的基础上，对所建设管理的服务管理、应用管理、系统管理、网络管理及安全管理等业务职能的服务运维管理功能进行建设或优化，以行业最佳实践为参照标准，在现有实现IT运维流程从受理到闭环的全流程统一管理。

系统建成后，系统用户面向公司所有计算机用户，用户可可以直接访问系统申请、跟踪、评价信息中心的运维服务，系统用户总包括信息中心服务运维人员，作为主要用户，服务运维人员可应用该系统对服务运维工作进行统一规范运作，通过该系统服务运维人员可以快速定位和获取复杂多样的服务运维配置信息，及时排除系统运行故障；通过该系统运维管理人员可以收集、统计和分析运维过程记录与信息，未将来运维工作改进实施提供数据支撑。

2XX客户ITIL运维系统需求分析
2.1 业务现状
2.2 设计目标
服务台作为受理用户服务申请或报障的服务窗口，设立运维支持级别一线、二线和三线支持。

一线人员主要由服务台人员及桌面服务人员组成，其中桌面服务采取外包方式进行，二线主要由系统及应用维护负责人组成，三线人员主要由信息中心系统研发人员、外部专家与合约期内的外部维护商组成。

这三线服务运维人员通过运维系统内的服务运维流程实施运维管理，各支持级别人员负责个级别的系统事件或故障，由服务台统一协调服务运维资源，跟踪督促实事件解决完成进度。

2.3 需求分析
综合来说，目前XX客户信息系统服务运维管理存在以下问题；
●XX客户现今和未来均处于公司信息化建设高峰期，未来两年很快许多新建成应用系
统上线后进入运维期，如何在有限的资源基础上支撑起庞大而复杂的信息系统服务运
维，达到稳定、规范及高效的服务运维管理目标，是信息部门亟待解决的重大问题。

●XX客户信息系统服务运维体系的建设是基于近年公司信息化战略规划及自身实施
经验总结的基础上逐步梳理的，虽然其中大部分内容引自IT行业最佳实践标准，期
间也主动与外部同行或厂商进行多方面的学习与交流，但由于实施经验、行业视角的
原因，难免在体系建设的科学性、系统性及完整性等方面存在缺陷，更缺乏从服务运
维运行生命周期的全局角度去审视思考的经验。

●目前使用的运维方式由于环境、业务及组织上的变化，管理平台的可进行功能调整的
灵活性较差或代价较高。

实际来说，平台与现今管理不相适应，有时甚至成为体系改
善改进的制约条件。

●服务运维除了负责信息系统日常系统维稳业务工作以外，还承担新信息化应用的系统
建设项目工作，接受战略规划的项目管控管理。

由于受到信息部门人力资源逐步收缩
的限制，如何平衡好、处理好系统建设与服务运维、应急处理与项目管控之间的关系，
往往成为长期困扰运维人的难题。

●信息中心服务运维团队依然常常扮演应急排障的救火者角色，往往缺乏对信息系统的
适用性、主动性运维。

如何做好主动式运维，把故障隐患排除爆发之前，而与此同时
又能平衡好服务运维资源的有效运用？
●各服务运维职能的IT系统功能、组织结构和流程分散，主要以业务为单位设立工作
组织，运维事故出现后团队成员之间沟通配合变得尤为重要，这种以功能为导向设置
的运维组织是否适合未来运维管理优化和发展？
●由于IT技术日新月异，信息系统日趋复杂。

以现有服务运维组织的能力难以独立完
成服务运维工作任务，因此有必要借助外部力量来解决工作中遇到的技术难题和紧急
问题。

而如何定位这种外力，以什么方式借助，怎样管理也是服务运维组织考虑的重
点问题。

3XX客户ITIL运维系统实施建议方案概述
3.1 ITIL与MIBP
Mocha ITOM所基于的ITIL（IT Infrastructure Library）理念，是CCTA（英国国家计算机和电信局）于20世纪80年代末开发的一套IT服务管理标准库，它把英国各个行业在IT管理方面的最佳实践归纳起来变成规范，旨在提高IT资源的利用率和服务质量。

ITIL把业务管理活动归纳为一项管理功能和十个核心流程：
摩卡ITIL最佳实践的英文名称为Mocha ITIL Best Practices，简称MIBP，它是摩卡软件有限公司（Mocha Software Co., Ltd.）提供的，基于摩卡软件多年来实施ITIL项目所积累经验的最佳实践。

它将ITIL项目实施经验抽象为知识、流程与模板，用专业的IT运维管理经验知识，帮助企业系统的规划与管理IT服务与运维，以提高企业的业务运作效率，降低业务流程的运作成本与风险。

摩卡最佳实践（MIBP）
现代企业需要建立完善而成熟的IT运维管理体制，通过流程管理，不断提高IT运维质量，实现高效运维，提升组织内IT服务满意度。

摩卡IT运维管理(Mocha IT Operations Management)帮助企业建立快速响应并适应企业业务环境及业务发展的IT运维模式，基于ITIL 的流程框架，实现运维管理的规范化、流程化、自动化。

在摩卡，我们提出了以下的公式：
ITIL执行= Mocha ITIL最佳实践方式+ Mocha ITOM产品
戴明持续改进循环，循序渐进的实现运维流程，将ITIL落地
⏹以CMDB为核心，拓展展现配置项关联关系，一目了然
⏹通过KPI指标，规范工作量，实现绩效考核
摩卡最佳实践更加强调运维流程间的关联，事故管理流程可以在需要的时候转为变更或者发布，来达到解决问题的目的，具体流程间的流转请参考下图。

3.2 面向不同角色的建设目标
最佳实践面向的用户群体包括企业IT高级管理者、IT部门经理、IT部门运维人员、使用企业IT资源的员工。

IT高级管理者：
IT从规划到实施到运维更加有效，降低成本的同时获得更高的IT服务水平
确保IT流程支持业务流程，提高企业整体业务运营的质量
推进IT部门和业务部门的沟通，降低沟通成本
减少冗余和重复的工作，提高IT运维人员和业务人员的生产效率
IT部门经理：
了解业界领先的IT服务管理模式，熟悉业界领先的IT管理最佳实践
通过自动化IT运维模式，使IT部门的管理更加有效、方便
使用知识库与FAQ等方法，全面记录规范化的解决方案，为IT部门快速解决问题提供坚实基础
通过明确的角色定义与职责划分，提高IT部门人员的生产效率、士气和工作满意度
加强个人的IT服务管理工作技能，成为IT界的MBA，向管理型的IT人才发展
IT部门的运维操作人员：
了解业界领先的IT服务管理模式，熟悉业界领先的IT管理最佳实践
通过知识库与FAQ等，加强个人的工作技能，提高工作表现，获得更多的专业知识
通过自动化与可视化流程大大提高个人工作效率
加强个人的IT服务管理工作技能，成为IT界的MBA从而获得更好的发展机会
企业的IT资源用户：
使用IT资源时遇到的故障与问题将被快速解决
通过满意度评估等手段，切实推进IT服务水平，从而获得更佳的用户体验
3.3 关联同类故障处理方式，规范事故处理阶段
在IT资源越来越多的前提下，很可能存在多个IT资源同时出现故障的情况，近年来XX 客户的IT部门也在不断的增加技术人员，原因就在于在以往的运维模式中是将IT部门的人员作为解决问题的核心，事故的解决效果完全依赖于个人的能力和水平，因此，本阶段的建设重点在于，建立一种以事故处理经验为核心的事故分析模式，减少对个人能力的依赖，同时可以帮助技术人员快速的进行问题定位和问题分析。

3.4 故障点关联裙带的展现
影响运维效果的最重要一个原因还可能在于，当解决了一个故障后，引起了另外一个新的故障出现，这种被称之为拆东墙补西墙的故障处理方式是比较常见的，也就造成了IT部门人员在不断的解决问题的状况，所以，本阶段的建设重点就是，建立一种故障点关联裙带的展现机制，最大程度的帮助技术人员进行故障关联裙带的分析，避免这种解决老问题带来新问题的现象。

3.5 度量运维效率，降低服务风险
作为运维整体的掌控上来讲，运维效率是一定需要保证的，而这就要求需要有一套保障及时快速的响应用户请求的机制，比如可以通过设定硬件类的故障一线解决时间在2小时以内，同时对VIP用户提出的问题需要醒目的标示等等，因此，在本阶段的建设重点就是，通过SLM 的设定来对运维效率进行约束，同时可以评审报告的形式对周期内的运维效率进行有效的统计
和计算，用来辅助管理决策。

3.6 拓展IT服务途径
以往XX客户接受用户请求的方式只是通过电话，这种方式用户已经很习惯，但经过统计之后会发现，IT技术人员每天的工作量有至少30%会放在帮助用户解决一些简单问题上，比如打印机不能打印之类，如果可以有一个用户自助式的服务台，可以把这些简单问题的处理方式直接呈现给用户，用户自己根据这样的方式解决的话，对IT部门来说，也就意味着，对用户的服务渠道又多了一个，而内部技术人员的工作量也会相应减少，因此，本阶段的建设重点在于，通过拓展IT服务途径的方式，来同步降低IT部门的工作量，实现一箭双雕的效果。

3.7 建立分类统计报告机制
对运维情况的了解，比如如何可以得到IT部门一段时间内支持了多少个用户的请求，其中多少是硬件类的，多少是简易问题等等，都需要反映的报表或对应的KPI中，提供给IT部门决策者，因此，在本阶段的建设重点在于，完善且全面的报表和KPI建设。

4XX客户ITIL运维系统实施建议方案详述
4.1 借以ITIL的运维阶段概述
摩卡软件将ITIL先进的设计理念加以十年运维管理经验，形成一套完整的切实可行的ITIL 实施依据，在摩卡ITOM中将整个的ITIL分为四大实施阶段，各个阶段的特点如下：✓计划
✓实施
✓检查
✓
改进
4.2 强化运维管理流程关键点详述
将整个运维流程分为事故管理、问题管理、变更管理、发布管理四大阶段，可实现事故或问题或故障在不同流程阶段中的切换，方便进行跟踪管理。

4.2.1服务台&事故管理
事故管理的目的是记录、解决及跟踪IT服务运作过程中发生的事故，并使用户可以尽快恢复自己的正常工作，避免业务中断，将事故对业务运营的影响降至最低。

服务台即连接用户与IT部门以处理上述事故的连接点。

于是，服务台与事故管理相结合就构成了从事故发生到得到解决的首要流程，同时，服务台记录下事故以及事故解决方案的有效信息，以备其他流程（例如问题管理）参考。

4.2.1.1 输入和输出
服务台&事故管理的输入主要有以下三个方面：
1、监控系统自动发现的请求；
2、用户热线电话反馈的请求；
3、用户通过自动服务台反馈的请求。

服务台&事故管理的输出主要有以下：
请求的应急措施或最终解决方案。

4.2.1.2 受理请求
1、请求按照三类不同的来源流入请求池中，进入请求的“未受理”状态。

2、请求池中的请求会按照设置的请求分发策略分派请求：
✓自动分发：请求池中的请求按照已定义好的资源类型对应关系自动分派给相应的一线支持人员；服务台值班长也可以手动分派一些未自动分派出去的请求；
✓手动分派：由服务台值班长分派给相应的一线支持人员，进入请求的“已受理”状态；
✓主动获取：一线支持人员主动获取能够处理的请求，服务台值班长也可以手动分派一些未自动分派出去的请求；
4.2.1.3 处理请求
1、一线支持人员直接关闭请求，处理结果为：①彻底解决请求；②确定无法解决，直接关闭；③错误的请求时，将请求转为“已关闭”状态。

2、一线支持人员由于工作量超负荷时可升级给服务台值班长，申请重新分派请求给其他的一线支持人员。

3、一线支持人员升级至对应的二线支持人员处理请求。

4、二线支持人员处理路径有三种：
✓提供处理意见，置请求状态为“待验证”，提交一线支持人员进行请求处理方案验证，验证通过，一线人员提供最终解决方案并置“已关闭”状态。

✓可以提供应急措施，但不能彻底解决请求，需要申请变更流程或转入问题流程以解决请求，同时发出邮件通知请求提出人，请求进入“转入问题”或“变更中”状态。

✓无法解决请求，需升级三线支持人员处理请求。

5、三线支持人员处理请求路径与二线支持人员大致相同。

有如下三种处理路径：
✓提供处理意见，置请求状态为“待验证”，提交一线支持人员进行请求处理方案验证，验证通过，一线支持人员提供最终解决方案置“已关闭”状态。

✓可以提供应急措施，但不能彻底解决请求，申请变更流程或问题流程以解决请求，同时发出邮件通知请求提出人，请求进入“转入问题”或“变更中”状态。

✓根据服务台实际N线流程，无法解决请求，需升级N线支持人员处理请求。

4.2.2问题管理
问题管理是负责解决IT 服务管理中遇到的所有潜在的和已经发生的问题的流程，目的是找到这些问题的根本原因，并提供临时措施与根本解决方案，防止问题再次发生或减少问题的数量。

问题管理调查基础设施和所有可用信息，例如监控系统事件记录等，以确定引起事件发生的真正的潜在原因以及提供的服务中可能存在的问题。

在定位问题的根本原因后，产生相应的应急措施以及最终解决方案。

对于那些由于成本、技术等原因，暂时不予消除的问题，可以置为已知错误，留待日后解决。

4.2.2.1 输入和输出
问题管理的输入主要有以下两个方面：
1、由服务台&事故管理转入的问题；
2、问题管理员主动发现并新起草的问题；
问题管理的输出：
1、已知错误；
2、问题的应急措施或最终解决方案；
4.2.2.2 处理问题
对于不同来源的问题，处理问题权限如下：
✓对于由服务台&事故转入的问题，则任意问题管理员均可抢先处理。

✓对于问题管理员自己起草的问题，只有起草人有权限处理问题。

4.2.2.3 关闭问题
如果问题不需要解决，问题管理员可以直接处理，则可以点击“关闭”按钮直接结束文档的处理，问题进入“已关闭”状态。

4.2.2.4 申请变更
如果需要申请变更以消除问题，问题管理员可以点击“提交”按钮申请变更，问题进入“变更中”状态。

4.2.2.5 已知错误
如果暂时还没有找到问题的最终解决方案或由于成本、技术等原因暂时不解决当前问题，则问题管理员提供一个可接受的应急措施后，将问题转为已知错误。

一旦找到了最终解决方案或成本、技术已允许解决该问题，就可以通过对已知错误继续处理来消除这些已知错误。

点击“提交”按钮，选择“已知错误”路径，问题进入“已知错误”状态。

若要消除已知错误，在页面“已知错误”模块找到当前错误，并重新启动流程。

4.2.2.6 重复问题
如果问题是一个重复问题，问题管理员可以直接在表单中输入重复问题编号，再点击“提交”按钮选择“重复问题”路径，问题进入“已关闭”状态。

4.2.2.7 确认变更结果
如果问题触发了变更，当变更处理后，会给问题管理员一个反馈，问题管理员可以对变更后的效果进行审核，如果问题已解决，则可以点击“关闭”按钮直接结束文档的处理，问题进入“已关闭”状态。

如果问题没解决，则问题管理员可以点击“关闭”按钮直接结束文档的处
理，也可以点击“提交”按钮，再一次申请变更。

4.2.3变更管理
业务需要通过变更改善自己的服务，但是，经验显示影响业务的IT事件往往与变更有关。

造成这些事件的原因很多：可能是由于一时疏忽，资源匮乏，准备不充分，较差的影响度分析，测试不够或者一些暂时的问题。

如果与变更有关的事件无法控制，IT服务提供者，甚至于整个行业本身也会因此逐渐失去控制。

事件的数量还在增加，而每一个事件出现时都需要“救火”，它可能极易催生导致新的事件发生的新错误，影响到IT服务日常事务的运作和维护。

变更管理是要确保在IT 服务变动的过程中能够有标准的方法，以有效的控制变更，降低或消除因为变更对业务运营所造成的影响与问题。

它的目的并不是限制变更的发生，而是为了确保变更的有序进行。

4.2.3.1 输入和输出
变更管理的输入主要有以下四个方面：
1、服务台&事故管理触发的变更请求
2、问题管理触发的变更请求
3、变更管理员新起草的变更请求
4、处理监控系统事件起草的变更请求
变更管理的输出：
变更方案与变更计划
4.2.3.2 受理变更
对于不同来源的变更，受理变更的权限如下：
✓对于变更管理员自己起草的问题，只有起草人有权限处理变更。

✓对于由服务台&事故、问题、监控系统事件触发的变更，则任意变更管理员均可抢先处理。

变更管理员提交时，需要填写结论性意见，如果结论性意见为“批准”，提交时自动提交给CAB审核；如果结论性意见为“拒绝”，提交时则直接关闭文档的处理，变更进入“已撤消”状态。

4.2.3.3 变更咨询委员会审核
CAB（变更咨询委员会）审核是一个会签环节。

所有的变更都需要经过CAB（变更咨询委员会）的审核，每个成员进行CAB审核时，都需要填写结论性意见，最后一个成员提交给变更管理员处理，其他成员提交时直接结束处理。

4.2.3.4 处理变更
当CAB会签的所有结论性意见都为“批准”时，提交时自动触发发布子流程，变更进入“已审核”状态；CAB会签只要有一个结论性意见“拒绝”，提交时就只能结束文档的处理，变更进入“已撤消”状态；CAB会签只要有一个结论性意见为“重新填写”时，提交时可以重新提交给CAB审核，也可以直接结束文档的处理。

4.2.3.5 变更实施后评审
变更实施后评审（PIR）是一个会签环节，每个人员进行PIR时，都需要填写结论性意见，最后一个人员进行PIR时，如果所有的PIR审核结论都是“通过”，提交时会自动结束文档的处理，变更进入“已完成”状态；PIR审核结论只要有一个是“未通过”，提交时会自动返回给变更管理员，由变更管理员重新对此变更进行处理，变更进入“待审核”状态。