ITIL事件管理.docx
《ITIL事件管理.docx》由会员分享，可在线阅读，更多相关《ITIL事件管理.docx（19页珍藏版）》请在冰豆网上搜索。
ITIL事件管理
ITIL事件管理
（一）
《事件管理流程》旨在介绍和描述事件管理流程，并将作为信息日常IT维护所涉及的事件管理流程的参考。
本文介绍了如何在事件发生、诊断、关闭的整个生命周期中实施事件管理，并定义支持、运作事件管理流程相关的人员职
责以及事件的升级策略。
一、流程概述
客服工业组、商业组和国家局组组员作为事件记录员，根据用户提出的服务请求，或在日常监控过程中发现的事
件，创建事件单，搜索知识库，根据级别为一二级的知识库条目以及通过常规恢复操作尝试进行事件的初步分析、解
决、跟踪和关闭，对于知识库中缺乏相关知识条目或知识条目级别为“三级”的事件向各自组长汇报并提交组长处理。
客服组长根据知识库判断该组员是否能够处理该事件，能够处理的返回该客服组员进行处理。
对于不能处理的事
件，客服组长判断是属于应用、系统还是设备方向的事件，提交支持相应组长处理。
支持组长受理客服组长转交的事件后，根据经验分派到相关组员处理。
支持组员作为事件分析员进行事件的分析处
理，事件恢复后汇报支持组长，支持组长将事件处理情况反馈该事件相关的客服组长，客服组长安排组员通知用户并关
闭事件单。
对于支持组员仍然无法恢复的事件，汇报支持组长后，由支持组长协调组织组内技术讨论会。
涉及需要支持
多组人员参与讨论的，在支持组长向支持经理汇报后，由支持经理协调组织技术讨论会。
在事件管理流程中，客服组长作为事件经理对整个事件的处理负责，受理事件并创建事件单的客服组员对整个事件
流程进行跟踪，并及时答复用户事件处理情况。
决策管理系统事件管理流程如下图所示：
（1）事件检测与记录
事件检测与记录步骤是事件管理流程的起点。
该步骤的目的是快速、准确地探测和捕捉所有在IT生产环境中发生的
错误，并在将来的问题管理流程中帮助确定问题和解决问题。
在本步骤中，将收集创建一个事件单所需要的信息，重点
是准确、完整地记录必要的信息。
（一）事件的检测
一线事件记录员在受理事件后检查是否已存在该事件单，若存在则将事件转由当前的受理人处理。
否则，创建新
事件单。
（二）事件的记录
事件的记录遵循《决策管理系统工单编制规范》进行填写。
（2）事件分类与初步支持
该步骤包括：
为了对用户的请求进行分析而进一步收集信息。
该步骤的目的是对每个事件进行正确的分类（依据
《决策管理系统分类规范》进行），随即在现存的知识库中查询与该事件相匹配的条目。
若没有找到合适的解决方案或变通方法，则该事件需要转派给一线组长，后者根据知识库判断该组员是否能够处理
该事件，能够处理的返回该客服组员进行处理。
对于不能处理的事件，客服组长判断是属于应用、系统还是设备方向的
事件，提交二线组长，由二线组长再根据实际情况分配给一个具有合适技能的事件分析员。
在处理过程中，事件记录员需要根据处理的情况详细记录整个处理过程和结果，记录信息应与实际情况一致。
若根
据当前已有知识库条目能够解决事件，则在解决完事件后，在事件单中记录和填写故障根源和解决方案。
若解决方案比
较复杂，还需附上附件。
（3）事件调查和诊断
这个步骤阶段的目标是进行深入的调查，以解决事件。
各个技术水平的事件分析员（二线人员）将会参与寻找一个
解决方案或变通方案。
若事件分析员（二线人员）认为该事件根据知识库条目或其他常规方式能够解决，则返回一线事
件记录员进行解决与恢复。
若通过调查和诊断还是不能解决事件，可能需要问题管理流程也参与进来进行更加深入的分
析研究。
一线事件记录员应及时跟踪事件的整个处理过程，并适时向用户说明处理情况。
（4）解决和恢复
这个步骤尝试使用解决方案和变通方法来解决事件。
某些情况下，需要引入变更管理来批准评估实施步骤。
事件解决完毕后，二线支持人员需要依据解决情况创建知识库条目，并进行等级划分，然后定期对一线人员进行新
知识库条目的培训。
（5）事件关闭
这个步骤确保客户对事件的处理情况感到满意。
这里分两种情况，若是用户提出的事件，则所有工单关闭前都需要
征得用户同意；若是监控发现的事件，则在解决后直接关闭。
（6）监控事件
这个步骤监控目前尚未解决或正在解决的事件，它由事件单创建时开始，在事件单关闭时结束。
这个步骤目前基本
上是由一线组长人工来执行，只有触发升级策略才会由后台工具发出邮件通知。
二、业务岗位和流程角色及职责
本部分描述有关人员在参与执行和管理事件管理方案时的角色和责任。
一个角色不等于对应一个人员，一个人员可
以担任多个角色。
结合运维流程岗位序列及岗位说明书，依据决策管理系统的运维业务的工作内容，明确各业务岗位工作内容：
部门
业务岗位名称
流程角色
工作内容
客
户
服
务
部
客服部经理
事件经理
管理客服部各业务组和部门日常事务，并承担部门间的协调工作。
协调日常的事件管理流程运作，保证事件管理流程的质量和完整性。
工业组组长
事件记录员
管理本组内事务，并负责与二线支持之间的业务流转。
受事件经理委托对本组行使事件经理的权限，协调日常的事件管理流程运作，保证事件管理流程的质量和完整性，遇到疑难事件时，负责召集专题会议。
商业组组长
事件记录员
国家局组组长
事件记录员
工业组客服专员
事件记录员
承担事件记录员的工作，受理用户的服务请求，创建事件单，根据知识库中的知识条目以及通过常规恢复操作尝试进行事件的初步分析、解决、跟踪和关闭，无法恢复的通过组长转交二线支持处理。
商业组客服专员
事件记录员
国家局组客服专员
事件记录员
技
术
支
持
部
应用组组长
事件分析员
对事件记录员转交的事件单进行判断，分派给合适的组员进行分析处理，并向一线组长反馈处理情况。
遇到疑难事件时，负责召集专题会议。
系统组组长
事件分析员
设备组组长
事件分析员
应用组组员
事件分析员
受理业务组长分派的事件单，对事件进行较为深入的分析，快速恢复中断或受到影响的服务，并向组织组长汇报处理情况。
系统组组员
事件分析员
设备组组员
事件分析员
以下为事件管理流程中必须具有的角色及其相应的职责：
（1）事件经理
事件经理负责协调日常的事件管理流程运作，保证流程的质量和完整性。
事件经理的责任包括：
序号
职责
工作任务
1
协调事件管理的日常操作，确保日常操作中所采集信息的完整性、准确性。
1）管理事件记录员和事件分析员的日常工作；
2）监控事件处理的流程和效率，向处理人提出改进建议；
3）传达流程的新要求，并执行流程的变更；
4）对于需要跨部门协调的事件进行分派。
2
负责流程中所需资源的协调与调度。
1）作为事件流程的集中联络点，保持与客户和公司管理层的沟通；
2）协调与事件流程相关的跨部门的资源。
3
定期组织召开事件分析和总结会议。
1）回顾解决及未解决的事件与事件统计报表；
2）对事件进行趋势分析，归类分析，并定期提交分析和总结报告；
3）组织事件流程相关人员学习新的知识条目。
4
管理事件流程相关的报表。
1）根据事件流程的要求，定期汇总统计，进行事件趋势、事件流程执行质量分析。
5
确保流程标准得到遵循，提出事件管理流程优化的建议。
1）监控事件流程环节，确保流程标准和规范落实；
2）对事件流程执行过程中的异常情况，向流程负责人汇报；
3）提出事件管理流程优化的建议。
（2）事件记录员
事件记录员负责创建事件单，跟踪、协调事件的解决情况，并关闭事件单。
事件记录员的责任包括：
序号
职责
工作任务
工作流程
1
受理并记录客户的请求，并确保客户资料准确有效。
1）验证客户信息，检查该客户是否属于服务的对象范围；
2）收集基本的联系信息，即时更新客户的资料；
3）所有客户的请求均应做记录，并保证记录准确、完整。
事
件
的
检
测
与
记
录
与
初
步
支
持
事
件
的
分
类
事
件
的
检
测
与
记
录
2
记录通过日常监控发现的事件。
1）记录通过系统监控或服务检测等发现的事件。
3
分析请求信息，创建或更新事件单。
1）调查客户所请求服务，是否属于服务目录的内容；
2）查找或者询问客户该事件是新增事件还是已存在的事件；
A新增事件，创建新事件单；
a在事件单中引入客户信息；
b在事件单中录入详细而准确的事件信息；
What－发生了什么；Which－影响了什么服务；When－发生的日期/时间；Where－发生在哪里或哪个环节；Who－谁提交的。
c必要时提供软件和硬件配置信息；
B已存在的事件，将新的信息更新到已存在事件单中（已发生，但尚未解决）。
3）查找有类似症状的事件单，并记录（重复事件或同一类原因引起的事件）。
4
鉴别请求的种类，初步判断请求的严重等级。
1）确认请求的类型（IC/RFC/RFI/RFS）；
2）询问客户该事件所产生的影响，依据事件严重等级政策，在事件单中记录严重等级；
3）对于严重等级为高以上的事件，需在服务管理平台发出公告；
4）对事件进行初步诊断。
5
确定适当的分派。
1）检查事件队列，依据事件分派原则将事件单分配给相关的事件分析员；
2）在适用的情况下，对现有的请求进行链接。
6
基于知识库，解决存在解决方案或变通方法的事件。
1）在知识库中查询已经存在的解决方案/变通方法，并执行解决方案或变通方法；
2）解决方案/变通方法如需要启动变更管理流程，创建变更单，通过变更流程实施；
3）对没有解决方案或变通方法的请求，分派给合适的事件分析员。
7
及时掌握事件的处理状况,并将事件的状态告知用户。
1）当事件单被分派给其他分析员，解决此事件需要一定周期时，须及时将事件的解决情况及所处状态告知客户，并与客户对处理情况进行必要的沟通。
8
了解客户对事件解决过程的意见及对处理结果的满意度。
1）确认客户所使用的服务是否已恢复正常，并将客户的意见记录在事件单中；
2）如果客户对事件处理不满意，需要调查客户不满意的原因，并调查事件的处理流程及处理现状，将相关的结果记入事件单中。
9
更新和关闭事件单。
1）确定关闭事件单的理由，选择正确的关闭代码，更新事件单；
2）与客户确认事件得到解决，移除公告信息或更新公告信息；
3）通知客户事件单已关闭。
10
鉴别已解决的事件可否作为录入知识库的候选条目，提交候选知识条目。
1）判断是否将该事件的解决方案或变通方法作为知识库的候选条目；
2）在事件单中说明是否将该事件记录作为进入知识库的解决方案/变通方法，提交候选条目。
（3）事件分析员
事件分析员受理事件记录员转交的事件单，对事件进行较为深入的分析，快速恢复中断或受到影响的服务。
事件
分析员的责任包括：
序号
职责
工作任务
工作流程
11
受理被分派的事件单，分析事件信息，确认事件的严重等级。
1）分析事件所涉及的领域、影响度、迫切性、优先级，确认事件等级；
2）分析事件收集的信息和数据，必要时对事件重新分类；
3）查找有相似症状的事件单，将同症状事件单进行关联；
4）若已存在与该事件相关的问题，将该事件与现有问题作出链接。
事
件
的
调
查
与
诊
断
事
件
的
解
决
与
恢
复
12
诊断并分析事件。
1）查找事件引起的直接原因，在最短时间内找到变通方法或解决方案。
2）必要时可请求其他资源或者第三方资源的支持，以确保快速恢复服务。
13
确定恰当的分派。
1）如果找不到变通方法或解决方案，依据事件分派原则将事件单分配给相关的事件分析员。
同时也希望查找事件的根本原因，可创建问题单，并将事件与问题进行关联。
14
提出有效的变通方法或解决方案。
1）确定执行变通方法或解决方案的标准，并判断变通方法或解决方案是否需要启动变更管理流程，如果需要，则创建变更单，通过变更流程实施。
2）与客户沟通即将实施的变通方法或解决方案。
15
记录变通方法或解决方案。
1）变通方法或解决方案记录在事件单中，确保文档的完整性。
2）变通方法或解决方案需要记录的信息：
①解决方案、测试报告②新增或修改的分类③对所有相关事件的更新④实施方案所需的时间
16
实施解决方案或变通方法，恢复服务。
1）根据变通方法或解决方案为客户恢复服务。
2）通过技术手段或者必要时直接联系客户，确认客户所使用的服务是否已恢复正常，并将客户的意见记录在事件单中。
17
创建问题单。
1）事件解决后，判断是否需要根源分析，如果需要，则创建问题单。
2）基于客户的反馈，判断是否需要一个更加永久的解决方案，如需要则创建新的问题记录。
18
反馈事件处理的信息。
1）将事件处理的最新进展及处理结果及时反馈至事件记录员。
19
鉴别已解决的事件可否成为知识库的案例。
1）判断是否将该事件解决方案或变通方法作为知识库的候选条目，
2）在事件单中说明是否推荐该问题记录作为进入知识库的解决方案/变通方法，提交候选知识条目。
三、常用政策
• 中烟信息所支持的操作环境中，所有对操作特性有影响的事件会通过事件管理流程处理；将通过流程中定义的标
准、政策和指导进行管理。
• 所有报告事件的部门或人员将会参与统一的事件管理流程，不应该有任何例外。
• 所有IT支持人员对严重等级1和2的事件所采取的恢复服务的行动，相比其他任务具有优先权。
• 应该定期产生和回顾事件管理报表。
• 应该定期对流程进行回顾，以改进事件管理流程。
（1）责任人政策
有效的管理事件的重要因素是定义一个责任人政策，以确保每个事件在任何时段都有适当的人员负责。
• 当一个事件被创建后，事件记录员负责这个事件单，直至事件单关闭。
• 当事件单被分派并接受后，事件分析员负责此事件单；但是作出分派的二线组长有责任通知被分派的事件分析员
并要求他接受或是拒绝此事件单。
该事件单的记录员有责任跟踪整个处理过程。
• 如果需要向客户通知处理情况，由事件记录员负责
（2）再分派政策
再分派又称转派，指第一次分派后被分派对象将事件单分派给其他部门或个人。
再分派政策是另一项关键的政策，
它确保事件单不被过于频繁的相互转派，以至于无法在规定时间内得到解决。
这里明确规定，事件单的再分派由当前业
务组的组长决定和负责。
（3）严重等级
事件的严重等级表明了该事件对服务所产生的业务影响。
它是中烟信息评定事件处理优先等级的一个重要指标。
事件的严重等级依据事件的紧急度和影响度综合评定，二者共同决定了一个事件的优先级次序。
紧急度用于衡量一个中断的服务等待恢复的迫切程度，即对时间的急迫性。
影响度用于衡量一个中断的服务的影响
范围，即对业务的影响程度。
下表定义了判断紧急度的参考时间值和影响度的参考范围以及严重等级的划分办法：
表一 紧急度的参考时间
紧急度
等级
紧迫要求
Level1
高
24小时内需要得到解决
Level2
中
在24-72小时内需要得到解决
Level3
低
72小时以上解决即可
表二 影响度的参考范围
影响度
等级
影响范围
Level1
高
企业关键业务或多个企业的业务受到影响
Level2
中
企业局部业务受到影响
Level3
低
服务请求、变更请求、咨询请求，及系统存在潜在风险的情况
表三 系统故障严重等级划分办法
严重等级
影响程度
紧急程度
高
中
低
高
1
2
3
中
2
3
4
低
3
4
5
紧急度和影响度基于受影响的业务情况来划分，事件紧急度和影响度可参考《事件单严重级别的划分及环节升级规
范》进行划分。
事件的严重等级划分需遵循以下要求：
（1）根据事件的紧急度和影响度的定义和指南准确划分紧急度和影响度；
（2）紧急度和影响度划分后将自动生成严重等级，不能人为修改严重等级而导致严重等级与紧急度和影响度划分
情况不符；
（3）严重等级在工单创建后不能再进行修改和调整。
（4）通知政策
目前的通知政策基于以下原则：
∙事件单被分派后，被分派人会接收到相关邮件通知；
∙事件单的严重等级为1（紧急）和2（高）时，将发送邮件通知事件经理。
（5）标准的通知内容
通过通知政策进行沟通的事件信息目前通过电子邮件方式发送，并将遵循标准的格式。
几个通知内容项描述如下：
∙事件的简要描述
∙事件的优先级
（6）事件单关闭政策
事件单的关闭必须由事件记录员得到用户确认后完成，但是事件经理可以超越（Override）此规则。
事件单的客户可以主动的关闭此事件单，例如：
误报、错报事件。
（7）事件单重开政策
已关闭的事件原则上不允许重新打开，但事件经理有权重新打开事件单。
升级会员 