ITIL服务管理流程手册Word格式文档下载.docx
《ITIL服务管理流程手册Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《ITIL服务管理流程手册Word格式文档下载.docx（95页珍藏版）》请在冰豆网上搜索。
v快速响应系统监控产生的故障或用户的请求
v在线获得帮助
v沟通问题解决的状态
∙进展事件控制
v记录事件
v就事件的优先级、紧急性和重性进展分类
v分析、诊断，必要时进展升级
v监视，并完毕事件
∙支持业务运行
v对业务应用提供二级支持
v解答有关如使用的问题
v记录关于新效劳的需求
v记录关于改变的请求
∙提供一个与业务部门的日常接口
v提供关于效劳状态的信息更新
v新效劳的报告
v关于即将到来的新效劳或事件的通知
v进展事后回忆
∙提供IT管理信息
v人力利用情况
v效劳可用性
v产品质量
v支持效率
v供应商效劳情况
2.1.3事件管理围
在BOSS系统运维围所指的事件，包括所有与IT根底架构和业务相关的如下事件：
v申告
v故障
v咨询
v业务处理
v维护作业工科
事件的产生有两类：
v由监控管理平台自动发现并产生的告警事件
v由用户/IT维护人员报告的事件
但不包括：
v外部用户汇报的事件
v在开发和测试环境中的设备或系统产生的事件
“事件管理〞流程不一定必须找到问题发生的根本原因，其重点在于如在尽量短的时间，恢复已经中断的IT效劳，提高效劳的可用性。
2.1.4相关定义
∙重分配规那么
事件的及时、正确分配和接手处理是确保事件在解决时限解决的关键因素。
一线和二线技术人员可以拒绝并根据重分配原那么重新分配不属于自己运维围的事件。
∙事件性质
根据移动的业务要求和管理要求，按照事件性质定义如下六类事件：
性质
描述
申告
针对BOSS系统的IT用户投诉
故障
指因BOSS系统错误或非正常因素由监控管理平台发现的告警事件
咨询
指对系统操作、业务流程等面的求助和询问
业务处理
指需要运维人员进展后台数据处理的要求
维护作业
指运维人员的日常维护作业或临时进展的维护作业
其他
其他性质的事件。
∙事件来源
当接到一个问题时，帮助台人员需要记录事件来源的类型。
帮助台的事件来源可以包括以下：
来源
用户
来自IT用户的事件可以有以下几种记录式：
●//---来自用户/IT维护人员报告的事件
●自助开单---用户/支持人员发现问题，直接在效劳台系统客户端开单
●客服平台---来自客服平台的事件
●其他---其他式进入帮助台的事件
监控管理平台
监控管理平台发现的告警事件，通过与效劳管理平台接口发送告警信息到效劳管理系统中
∙事件优先级
优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级，如下表所示：
编号
优先级
1
紧急
2
高
3
中
4
低
事件的优先级分两个层面来定义和确认：
●帮助台
帮助台在接到来自监控管理平台的告警事件或IT用户报告的事件时，迅速根据事件相关的业务/子业务或IT系统/设备的关键级别及事件的性质，定义该事件的优先级别。
如果为紧急事件，立即升级到一线。
对于监控管理平台上传的报警事件，应包含该事件相关联的配置元素的搜索代码，帮助台人员据此确定配置元素及其关键级别。
帮助台人员可参考下表确定事件优先级：
事件优先级
本次事件所对应CI的关键级别
事件性质
咨询/业务处理/维护作业
●一线
一线人员在承受到帮助台升级上来的事件后，根据该事件相关的业务或IT系统/设备的实际故障情况，并结合其他相关因素，再次确定事件优先级，如确实为紧急事件，那么启动升级机制。
确定事件优先级后，即可以确定事件的处理时限，优先级对应的事件解决时限参考下表：
解决时限
（小时）
8
24
48
∙事件的升级
事件升级的目的是确保基于事件的优先级等级及时通知有关技术人员和领导，引起更多的重视，提供适宜的资源，从而快速找到解决事件的案。
可根据所要求的处理时间定义事件优先级升级规那么，包括不同等级的事件在不同的时间被升级到不同级别的人员：
时间
即时响应
+15分钟
处理时限30%
处理时限40%
处理时限
A
B
DEF
--
C
D
E
--
B
升级组群：
A帮助台
B一线支持人员
C二线支持人员
D事件经理
E管理层
F集团公司
各省可以根据业务的实际情况调整升级标准。
∙事件分类
根据移动目前的事件种类，事件的分类层次设计不超过三层，第一级分类，称之为“类别〞，第二级分类，称之为〞子类〞，第三级分类，称之为〞条目〞。
本规给出第一级、第二级分类。
各省市根据自己的情况决定是否要定义到第三层。
下表为事件分类表举例：
类别
子类
条目
根底架构
网络通讯系统
效劳器
存储系统
系统软件
操作系统
数据库
中间件
双机热备软件
系统监控软件
业务
采集
计费
结算
客服
业务管理
账务管理
账务处理
一级BOSS
拨测
配套设施
空调
UPS
机柜
照明
温湿度传感器
外设
∙事件状态代码
事件状态代码说明事件所处的处理状态，本规规定的事件状态如下：
事件状态代码
新建
新开事件记录
分配
事件在帮助台
一线处理
一线支持人员已接手处理事件
二线处理
二线支持人员已接手处理事件
供应商处理
由供应商处理
已解决
事件已找到解决案
关闭
确认解决案，事件得以关闭
∙事件完毕代码
事件完毕代码说明了事件是在种情况下关闭的，本规规定的完毕代码如下：
事件完毕代码
暂时解决
用变通方法暂时解决
已解决
帮助台
由帮助台人员成功解决
一线解决
由一线人员成功解决
二线解决
由二线人员成功解决
第三解决
由第三成功解决
包括消失,误操作,可忽略等
∙处理是否超时
事件超时代码
未超时
事件最后时限围完毕
超时
事件未能在最后时限围完毕
2.1.5流程职责/角色
事件管理流程主要分为以下几个职责/角色，分别简述如下：
Ø
事件经理
∙作为事件流程的负责人，负责制定流程的规那么、策略、步骤
∙调度资源，协调解决跨小组、部门的事件
∙指导日常操作，确保流程的执行符合预定的要求和规那么
∙建立流程的衡量指标和报表
∙与用户、效劳商和管理层交流流程的使用情况
∙确认和实施对流程的变更/改进方案
帮助台人员
∙在指定的响应时间响应所有帮助台热线、、等事件报告
∙完整记录所有接收的事件信息，包括：
记录事件报告人的详细联系式、事件特征表现、描述、发生时间等
∙为事件进展适当的分类、为事件分配优先级等属性
∙尝试使用工具、初步诊断、分析相关信息等式解决问题
∙如果帮助台不能解决这个事件，应当将事件分配给最适宜的一线支持小组/人员来处理
∙检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展
∙与用户确认事件解决案，关闭事件
一线支持人员
一线支持人员负责提供对帮助台无法解决的事件进展快速有效的分析并提出解决案以尽快恢复效劳，并在必要时提供现场支持。
∙验证事件的描述和信息，进一步收集相关信息
∙决定需要采取种措施恢复效劳并实施有效的行动
∙必要时提供现场支持
∙根据优先级提供有效的解决案
∙已解决的事件转回帮助台，由帮助台关闭事件
∙实施事件解决案
∙更新事件解决信息，已解决的事件转回帮助台，由帮助台关闭事件
∙如果一线不能解决这个事件，应当决定选择最适宜的二线支持小组/人员来处理
二线支持人员
二线支持人员是相关问题领域的专家。
负责提供对一线支持人员无法解决的问题进一步进展调研，找出解决案并尽快恢复效劳。
各省可以考虑按照所维护的应用、系统进展分组，如，网络组、主机组等。
∙进展事件的深入调查研究
∙根据经历和专业技能，决定需要采取种措施恢复效劳并实施有效的行动
∙必要时引入供应商的支持
∙在系统中更新事件根源和最终解决案
∙更新事件记录，确保事件状态代码真实反映事件状态。
∙及时提供有效解决案
∙与其他小组合作，确定解决案
∙如果二线不能在解决时限解决这个事件，应当将事件进展升级
2.1.6主要容
事件管理流程始于事件的探测和报告，完毕于事件的解决。
该流程包含下述主要容：
事件接收和记录
这个环节是事件管理流程的起点。
所有用户或系统报告的IT事件必须由此步骤开场。
此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。
在此步骤中将会收集创立事件记录所需的信息。
该环节的关键是信息的准确性和完整性。
分类和在线支持
事件可以是一个效劳请求、信息请求或效劳故障，对于每个事件，需要确立优先级、影响度、和分类。
假设没有现成的解决案或临时解决措施，该事件将分配给适宜的支持人员对此进展调查。
该环节的关键是需要知识库支持和正确的事件分派。
调查和诊断
假设在线支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进展更加深入的分析以找到恢复效劳的临时措施，必要时将使用多
升级会员 