基于ITIL的IT服务事件管理手册Word文档下载推荐.docx
- 文档编号:21815856
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:24
- 大小:87.30KB
基于ITIL的IT服务事件管理手册Word文档下载推荐.docx
《基于ITIL的IT服务事件管理手册Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《基于ITIL的IT服务事件管理手册Word文档下载推荐.docx(24页珍藏版)》请在冰豆网上搜索。
3.3.2事件流程经理16
3.3.3一线支持人员(IT协调员)17
3.3.4服务台支持人员18
3.3.5二线支持人员19
3.3.6三线支持人员20
3.3.7四线支持人员20
3.4流程设计20
3.5流程衡量指标22
1.术语
❑服务台
在ITIL中,服务台从根本上来说提供了用户和IT部门的唯一接口。
此项功能常常通过集中的服务台进行体现。
服务台的根本目的是提供一线支持,并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。
❑事件管理
ITIL流程,是负责解决所有的IT事件、问题和用户请求等的管理流程。
它的目的是尽快恢复被中断或受到影响的IT服务,所以它的特点往往是以解决表征现象为目的,而不在于查找根本原因。
2.事件管理流程简介
2.1流程基本概念
事件管理流程通过提供服务台作为日常IT支持接口,由IT支持人员根据流程定义,快速响应和解决IT用户的服务请求、突发事件、投诉反馈等,最大化地减少突发事件对用户业务活动的影响,最终确保SLA目标的实现。
事件管理流程相关的几个关键词汇解释如下:
“日常支持接口”:
即服务台,该接口将采用集中服务方式,向所有IT用户提供唯一服务窗口,按照业务需求,提供相应级别的支持服务。
“IT用户”:
指的是指IT服务的使用者,他们使用IT组提供的IT服务来支持相关日常业务。
“IT支持人员”:
指的是IT服务团队中IT运维和支持人员的统称,包括一线人员和二线人员、服务台等,可能涉及IT管理体系中的相关的开发、支持和运维等团队。
“一线支持”:
指各分支机构IT协调员(桌面支持人员),向IT用户提供一线支持服务,主要负责
“二线支持”:
指总部IT组工程师(系统管理员、网络管理员),在复杂度较高事件或一线支持无法解决事件时负责协调分支机构IT协调员员进行事件处理。
二线支持同时承担服务台的角色。
“服务台”:
负责记录来自一线支持和直接用户的请求并进行任务分派与事件跟踪。
服务台角色可设置专职岗位,也可由一线支持或二线支持人员兼任。
“三线支持”:
指IT组负责人(IT主管)在复杂度较高事件二线支持无法解决事件时或事件需要授权时负责协调IT组工程师或IT(服务)供应商进行事件处理。
三线支持更多的强调管理协调职能。
“四线支持”:
指IT开发团队和IT(服务)供应商等。
“事件”:
指IT组在用户IT环境中发现的所有非正常事件,对现有的服务造成影响或中断。
例如:
服务器宕机、网络中断、应用不可用等。
从来源上来分,主要包括由信息技术总部内部人员发起的事件以及有用户报告的事件等。
“事件经理”对IT事件执行监督与控制,保障事件处理的进度与质量,以及事件的统计与分析。
“服务请求”:
指用户提出的关于标准服务、培训、文档、信息等方面的请求,以及针对IT服务使用的咨询等,通常并没有发生IT组方面的故障。
请求培训、寻求咨询等。
服务请求是一种特殊类型的事件。
“投诉反馈”:
指由用户提出的对于IT服务质量或服务方式的抱怨或改进建议,通过服务台统一接受,并进行相应处理。
2.2流程目的
事件管理流程的主要功能是尽快解决出现的事件,保持业务支撑系统的稳定性,其目的包括:
❑在成本允许的范围内尽快恢复IT服务
-快速响应故障及服务请求
-用户在线获得帮助
-沟通事件解决的状态
-和用户确认事件的解决
❑进行事件控制
-按规范记录事件
-就事件的优先级,影响度进行分类
-分析,诊断,必要时进行升级
-监视并结束事件
-进行定期服务流程回顾
❑提供IT管理信息
-人力资源利用情况
-故障处理情况
-支持效率
2.3流程范围
IT事件流程管理范围包括所有用户与IT组信息技术总部内部的事件、服务请求和投诉反馈等。
其中:
❑不包括现有应用系统新增功能需求
❑不包括用户对于信息类设备和应用系统的新需求
❑不包括新系统开发需求
2.4流程主要内容
事件管理流程始于事件的接收和报告,结束于事件的解决。
该流程包含下述主要内容:
❑事件接收和记录
这个环节是事件管理流程的起点。
所有监控系统或用户报告的IT事件必须由此步骤开始。
此步骤的目的是在事件发生时快速准确地发现,以协助事件的诊断和解决并通知相关人员。
在此步骤中将会收集创建事件记录所需的信息。
该环节的关键是信息的准确性和完整性。
❑分类和初步支持
对于每个事件,需要确立优先级和分类。
若没有现成的解决方案或变通方法,该事件将分配给合适的支持人员对此进行调查。
❑调查和诊断
若支持人员无法利用现成方案解决事件,可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施,必要时可调用多名支持人员以寻求解决措施。
❑解决和恢复
支持人员实施事件的解决方案,并将解决完毕的事件转回服务台,由服务台通知用户解决的结果,并得到用户的确认。
❑事件升级
对于高优先级的事件,服务台应立即上报给事件经理和相关的管理层,由事件经理决定事件的处理方式,确保其得到最快速的解决。
当事件处理超过预期解决时限,应通知相关处理人员和管理层,以引起处理人员和管理人员的重视和参与。
❑结束事件
当用户确认事件解决后,可结束该事件。
2.5流程业务价值
IT事件管理流程将在多个方面对“IT服务”业务产生积极作用,具体表现在以下几个方面:
单一联系点–通过在团队内部建立服务台,作为与用户沟通联系的单一联系点。
对用户方发生的故障及用户上报的服务请求进行快速响应和统一管理,对内部服务支持资源进行合理协调和调配。
同时,服务台作为IT服务窗口,也进一步维护和加强了与用户的关系,为提高用户体验和满意度起到了重要作用。
用户业务尽快恢复–通过合理调配资源,使用知识库等相关支持工具,对不同级别事件选择各自的解决时限,对用户被中断或受影响的业务进行快速响应和恢复。
内部团队协作加强–为服务支持团队成员分配角色,并清晰界定职责。
通过事件管理流程将团队成员进行有效的连接,加强内部团队协作和沟通的有效性和工作效率。
服务质量控制和改进–通过定期提交流程相关指标和报表至管理层,以实现对流程的监控和管理,同时为服务质量的改进奠定基础。
3.事件管理流程设计
3.1流程执行原则
3.1.1流程常规原则
❑所有在流程范围内发生的事件,都应该被完整准确的记录下来,记录的信息应足够详细,包括事件处理交互过程,详细的解决方案和相关的附件等。
❑事件处理过程中,在需要寻求第三方的情况下,遵循下述原则:
-根据事件实际处理情况,各二线或三线支持寻找相应供应商
-在供应商参与解决事件的过程中,事件当前处理责任仍保留在二线或三线人员处
❑IT服务支持体系是由信息技术总部全体人员共同组成的,事件的处理过程中必须加强一线和二线的沟通,沟通的方式优先使用工具(服务管理平台),在需要的时候必须辅助电话、短信、邮件、现场沟通等手段。
❑所有支持人员优先处理优先级较高的事件。
❑对于来自于服务台转入的事件(包括故障/服务请求/新需求/咨询/投诉建议),首次接听电话并进行支持的服务台人员负责在系统中进行登记,并由该员工成为该事件在IT组范围内的责任人,确保事件在在IT组内部得到有效跟踪、解决,并将解决结果反馈给服务台。
❑每月定期产生事件管理报表,分析服务质量,对重大事件、重复发生的事件或者利用变通方法解决的事件,应提交问题管理流程进行问题定义分析和解决,并定期对这些事件进行评估跟踪。
❑建议每三个月对流程进行回顾,包括流程执行效率和流程支持工具的有效性,以改进和优化事件管理流程。
3.1.2责任制原则
责任制原则用来确保每个事件在任何时段都有适当的人员负责。
❑由监控系统上报的事件,对故障进行识别并在系统中记录的服务台人员是该事件的责任人,确保事件得到有效跟踪与解决,并负责事件单的关闭
❑由用户电话上报的事件,首次接听电话并进行支持的服务台人员负责在系统中进行登记,并由该员工成为该事件的责任人,确保事件得到有效跟踪与解决,并负责事件单的关闭
❑服务台员工更换时,由服务台负责人进行事件重新分派,事件责任人也由此转移
❑事件被服务台人员转至二线人员或第三方后,二线人员/第三方成为该事件的当前责任人,但服务台人员仍然是事件的整体负责人,有义务对事件处理状态按相应策略进行监控,并及时反馈给用户,保证事件的处理过程对用户充分透明。
3.1.3事件分派原则
事件分派原则是确保事件在服务目标时段内处理和解决的重要因素。
❑服务台(二线支持)人员在规定的一线处理时限内,可按情况选择转给其他一线支持人员或二线支持人员进行处理
❑一线支持人员在规定的一线处理时限内不能解决事件时,原则上根据事件分类分派到相应二线支持人员,并由服务台登记变更。
❑在特定情况下,比如一线支持人员的非工作时间内,服务台(二线支持)人员在派单后利用电话方式通知一线人员相关事宜。
❑桌面类故障导致事件直接由一线支持(IT协调员)进行处理.
❑关键系统故障,直接由二线支持(系统管理员、网络管理员)处理。
❑服务台(二线支持)人员在判断事件为关键系统故障后,应第一时间按策略通报相应工程师处理。
3.1.4事件重分派原则
❑二线支持接受服务台分派事件后,如果该事件不属于本人支持范围或者自身能力无法处理,二线人员需首先注明原因,然后将事件返回到服务台,由服务台重新分配。
❑为提高事件解决效率,应当尽量减少事件单重分派的几率。
事件单的重分派次数不应该超过2次。
❑同组的事件单再分派不被监控;
❑任何跨组的事件单再分派将会报告给事件经理(IT组负责人);
❑事件再分派超过2次,事件单将升级给事件经理(IT组负责人);
3.1.5重复/复发事件原则
❑重复事件
如果被报告的事件与某个已经创建且尚未解决的事件单症状相同,则该事件被认为是重复的。
将会为此重复的事创建新的事件单,并标注此单为“重复”并与原始事件单相关联。
原始事件将被标注为“主事件”复发事件(3天内同一用户,同一件事)如果报告的事件与已经关闭的事件相同,该事件被认为是“复发”的事件单。
这意味着为了解决事件而采取的解决措施失败了(或失败或误再报)。
此时,应当创建一个新的事件单,复制原始事件单的内容,并说明这是复发的事件。
3.1.6事件关闭原则
❑事件单的关闭必须由服务台对应2线支持人员完成,但是事件经理可以超越此规则。
其他人无权关闭事件单。
二线支持人员确定解决方案并解决事件后,必须把事件返回到服务台。
❑事件单的用户可以要求关闭此事件单,例如:
误报、错报事件。
关闭事件单由事件单对应二线支持人员负责。
❑服务台人员关闭事件前,需获得客户对解决方案的确认和反馈。
❑关闭事件时,根据实际解决情况填写事件的结束代码。
❑已关闭的事件单不允许重开。
如果事件重复发生,则创建一个新的事件单,并标识为复发事件。
❑对于以“变通方法解决”或“不能重现”结束代码关闭的事件,需通知问题经理对此类事件进行分析并在必要时生成问题,通过问题流程对问题进行根源分析并提供解决方案。
❑所有优先级为最高的事件在关闭后,需通知问题经理对此类事件进行分析并在必要时生成问题,通过问题流程对问题进行根源分析并提供解决方案。
❑对于未及时取得用户反馈的已解决事件,系统将对其保留3日。
3日内服务台人员应至少每天主动与用户联系1次。
若3日后仍未得到用户有效反馈,系统将自动关闭事件,并标识结束代码为“自动关闭”字样。
3.1.7事件通报原则
对于监控系统自动发现的告警信息,服务台人员有责任对其进行识别。
如确认为一条事件,则应首先在第一时间通报相应用户和事件经理,然后在服务管理平台中进行记录。
通报策略具体如下:
通报方式
❑用户工作时间内采用正式的通知方式进行通报
❑用户非工作时间采用即时通讯工具或邮件方式进行通报
❑与用户通报相关的其他方式参考与用户签订的SLA中的具体定义
❑采用邮件的方式通知事件经理;
❑如果由于用户原因第一时间无法完成通报,应首先在服务管理平台中登记一条事件,并置于“挂起”状态,相关服务台人员有责任在开单后每隔1小时主动尝试联系用户1次。
若3次后仍无法取得联系,则应在事件工作日志中注明“无法联系到用户”的字样,并进行后续处理;
若3次内取得联系,则在与用户确认故障后,取消事件“挂起”状态并进行后续处理。
通报对象
❑依照事件分类表中定义,向用户部门相关人员通报
❑最后通报事件经理
通报内容
❑事件简要描述
❑可能受到影响的用户方业务(或范围)
❑确认是否为用户方运维操作导致
❑可能导致事件的原因
❑预计解决事件的时间点
3.1.8事件升级原则
制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和管理人员,引起足够的重视,协助提供合适的资源,从而快速找到解决事件的方案。
❑优先级为最高的事件,需要立即事件升级,同时,事件继续按事件管理流程进行快速处理
❑超出规定的响应或者解决时限之后,需要立即升级事件,同时,事件继续按流程进行快速处理
❑事件重复派单超过三次直接升级给事件经理
具体事件升级机制如下表所示:
表3-1事件升级机制
事件升级机制
IT管理员
IT主管
部门负责人
公司高层
优先级1
30分钟
60分钟
1小时
2小时
优先级2
3小时
优先级3
优先级4
4小时
3.1.9流程关联原则
与配置管理的关联
-事件处理过程中,可以通过配置管理查询相关的配置项信息(尤其是关系信息)以及该配置项历史上发生的事件,来帮助故障的定位
-事件处理过程中,如果可以将故障定位到某个配置项,则必须将事件单与该配置项关联
3.2流程相关定义
3.2.1事件信息项
事件单必须包含如下事件信息项,IT服务团队可以在此基础上进行扩充:
表32事件信息项
序号
信息项
说明
1
事件ID
事件单流水号(系统自动产生)
2
事件请求人
事件申报人的信息,包括:
姓名、公司、部门、电子邮件、办公电话、手机
3
事件登记时间
在服务台生成事件记录的时间(系统自动产生)
4
受理人
事件受理人的信息,包括员工姓名、员工ID、联系方式等(系统自动产生)
5
事件发生地点
事件发生的位置信息
6
受理方式
参见“受理方式”定义
7
事件标题
事件的简要描述
8
事件描述
对于整个事件内容的详细描述
9
服务需求类型
参见“服务需求类型”定义
10
事件类型
参见“事件类型”定义
11
事件状态
参见“事件状态”定义
12
事件优先级
参见“事件优先级”定义
13
事件完成期限
对应每一个事件优先级,系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限(系统自动产生)
14
事件分配人员
被分配的支持小组内成员
15
事件解决时间
记录事件状态为“已解决”的时间(系统自动产生)
16
关联配置项
记录出现故障的线路编号或者设备编号
17
附件信息
事件相关附件信息
3.2.2受理方式
受理方式代码用来标明事件的提出方式,受理方式可以包括以下几种:
表33受理方式
描述
电子邮件
服务台通过电子邮件收到一个请求。
电话
服务台通过电话收到一个请求。
服务台
服务台通过Web系统(流程管理平台)收到一个请求。
现场指派
用户直接到电脑部工作间找相关工程师报障
主动监控
服务台通过系统网络管理工具主动监控得到的请求。
3.2.3服务需求类型
服务需求类型用来表明事件的概要类型,具体可以包含以下几种:
表34服务需求类型
服务需求类型
故障
设备或系统出现无法正常工作的现象
请求
对外宣布的服务(不含新业务需求)
咨询
对与业务或IT相关杂项信息(联系人、电话号码,状态查询、技术问题等)的请求
新需求
再现对在现有系统、服务、资产基础上添加基本内容的请求,如新增加员工帐号或电脑采购
投诉
出现对服务或业务流程不满意的反馈
3.2.4事件类型
事件类型代码用于标识故障或申告的具体原因,由支持人员在处理过程中填写。
当事件发生时,应该由服务台初步分析和定位事件的分类,一方面便于与历史事件/问题或者知识库的匹配,另一方面也便于选择合适的二线或者第三方进行分配。
事件最终分类可由后续支持人员作进一步的确认,并在事件关闭前进行调整。
事件的分类层次设计不超过三层,第一级分类,称之为“类别”,第二级分类,称之为“子类”,第三级分类,称之为“条目”。
事件分类一级称之为“类别”分为四大类:
桌面类、网络类、系统类、基础设施类
事件分类二级称之为“子类”分为三大类:
硬件、软件、系统、网络、基础设施、信息安全、IT管理、其它
事件分类三级分为具体条目,例如:
办公软件-Office2010,HRM管理系统、交换机
3.2.5事件优先级
优先级是事件管理的一个关键要素,优先级决定处理事件的顺序及所需的资源。
在IT服务中,事件优先级可分为四级:
0(紧急)、1(高)、2(中)、3(低)、4(计划中)。
为方便服务支持对于事件优先级的判断,IT组建议从事件影响程度和事件紧急程度两维来进行优先级定位。
事件的影响程度主要是对事件发生的关键程度以及事件发生后的影响范围综合考虑得出。
在IT技术服务业务中,要考虑以下几个方面:
❑用户身份
❑受影响用户数量和范围
❑受影响设备
❑受影响系统
具体影响程度判定可直参考附件中的影响度判读资料。
事件的紧急程度主要由事件本身是否涉及关键业务系统来进行判定,如事件涉及关键业务系统,则认为紧急程度较高,需要尽快恢复;
如事件不涉及关键业务系统,则认为紧急程度较低,可优先处理紧急程度较高的事件。
3.2.6事件时限
在事件处理过程中,对于事件应有响应时间限制、分派时间限制和解决时间限制,以保证事件处理过程的高效执行。
如果该事件的响应、一线分派、解决超过了时限,需要通告事件经理,同时也要根据具体情况通告给其他相关管理人员。
响应时限指的是事件发生到在系统中登记所经过的时间;
一线分派时限指事件登记时间到转给二线/第三方所经过的时间;
解决时限指的是事件登记时间到事件状态变为“已解决”所经过的时间。
在IT技术支持服务业务中,不同的事件优先级对应了不同的响应时限、一线分派时限及解决时限,具体如下:
表35IT服务优先级定义
3.2.7事件状态
事件状态代码表明事件所处的处理状态,事件状态如下:
表36事件状态
状态代码
描述
未启动
一个事件被记录或创建但还在未处理
进行中
任何一个支持人员或第三方(供应商、开发部)接受了事件并开始处理事件
等待中
事件信息不完整,或在某些情况下阻止事件受理员对事件进行处理,等待的原因为:
∙需要客户提供更详细的信息
∙优先级为1、2必须由事件经理挂起
∙不能联系到用户人员
∙升级到供应商处理
∙采购定单的批准
∙不可抗拒力原因
已完成
事件经用户确认已关闭
已推迟
事件因用户原因无法按计划进行
已取消
事件因用户或上级指示停止执行或取消的
3.3流程角色和职责定义
3.3.1事件流程负责人
事件管理流程负责人(IT小组组长/负责人)从宏观上监控流程,确保事件流程IT服务团队范围内被正确的执行。
随着业务需求和IT环境的改变,流程负责人必须定期或不定期进行流程分析、找出缺陷、进行改进,从而实现服务能力的可持续提升。
职责定义:
❑确定管理流程的衡量指标
❑确保事件流程能够取得管理层的参与和支持
❑确保事件流程符合业务实际状况和业务发展战略
❑总体上管理和监控流程,建立事件流程运行机制
❑确保事件流程实用、有效、正确地执行
❑保持与其他流程负责人的定期沟通
专业技能:
❑理解内部和外部业务环境
❑理解业务规划及发展战略
❑理解用户需求
❑充分理解业务相关IT政策、操作过程和标准
❑流程的评估和设计能力
❑良好的分析和规划能力
❑理解事件管理流程
❑理解服务水平承诺
处事技能:
❑良好的矛盾管理技巧
❑确定问题和趋势发现的能力
❑良好的口头和书面表达能力
❑工作主动性和领导能力
❑决策能力
3.3.2事件流程经理
事件流程经理(IT小组组长/负责人)负责事件解决过程中的协调和监控,以及事件升级的判断以及升级过程中的具体执行或协调。
职责定义:
❑监控事件流程运行状况
❑负责对事件解决过程的资源协调,跟踪事件的解决进展
❑当事件超时升级或重大事件升级时,负责或参与资源协调,解决事件
❑确保和问题管理流程的有效合作
❑基于事件处理状况,发现IT或业务相关的问题
❑基本了解业务系统环境
❑具有流程的知识
❑了解用户需求
❑分析技能
❑用户关系技能
❑矛盾管理技巧
❑监控和管理流程的能力
❑谈判技巧
❑管理经验
❑良好的团队工作能力
3.3.3一线支持人员(IT协调员)
用户的最开始的直接联系人,负责为用户提供初步支持。
❑为事件进行适当的分类、为事件分配优先级等属性
❑使用知识库等手段对事件进行初步诊断和分析,尝试解决问题,如果无法解决上报服务台/二线支持
❑必要时联系供应商和现场服务人员,参与事件处理
❑与用户确认事件解决方案,关闭事件
❑了解用户和供应商信息
❑基本理解业务相关IT政策、操作过程和标准
❑用户关系技巧
❑服务的基本知识和技能
❑沟通技巧
❑分析诊断能力
❑电话响应技能
❑专业的口头和书面沟通能力
❑客户至上的理念
❑责任心
❑积极进取之心
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 ITIL IT 服务 事件 管理 手册
![提示](https://static.bdocx.com/images/bang_tan.gif)