IT运维事件管理实践事件响应时限和解决时限
4）事件响应时限和解决时限在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。
响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间；
解决时限指的是事件状态从“已登记”到“已解决”经过的时间；
表：事件优先级对应的事件响应时限和解决时限参考下表（时间是24×7工作时间）
编号优先级代码响应时限要求解决时限要求
1紧急30分钟4小时
2高1小时8小时
3中4小时48小时
4低8小时72小时
通知人员列表的用途：当IT服务管理平台收到事件时，自动按照表中的人员列表发出邮件或短信通知。
表：事件发生时的通告定义
优先级别通知人员列表
紧急部门主管，相应事件经理，一、二支持人员
高部门主管，相应事件经理，一、二线支持人员
中通知一、二线支持人员
低通知一线支持人员
通知人员列表的用途：当IT服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。
表：超出响应时间的通告定义
优先级别通知人员列表事件响应时限
紧急部门主管，相应事件经理，一、二支持人员30分钟
高部门主管，相应事件经理，一、二线支持人员1小时
中部门主管，相应事件经理，一、二线支持人员4小时
低相应事件经理，服务台/一、二线支持人员8小时
通知人员列表的用途：当IT服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。
表：超出和即将超出解决时限的通告定义
优先级别通知时间通知人员列表事件解决时限
紧急3小时部门主管，相应事件经理，一、二、三线支持人员4小时
4小时部门主管，相应事件经理，一、二线支持人员
高7小时部门主管，相应事件经理，一、二线支持人员8小时
8小时部门主管，相应事件经理，一、二线支持人员
中47小时部门主管，相应事件经理，一、二线支持人员48小时
48小时部门主管，相应事件经理，一、二线支持人员
低71小时相应事件经理，一、二线支持人员72小时
72小时相应事件经理，一、二线支持人员
5）事件影响度定义
事件影响度是指衡量事件对业务影响程度的指标。该程度的严重性通常依据受影响的人数、关键系统数量以及服务故障导致的经济损失来确定。
事件影响度等级的划分依据包括：
·是否波及核心业务（核心业务系统的定义详见《监控和事态管理流程》）
·受影响的用户数量
·服务失效的范围及持续时间
事件影响度在事件生命周期内具有动态变化性。例如，初始评估为严重的故障，随着服务失效时间的延长，可能升级为重大故障。因此，事件影响度应在事件解决（服务恢复）后重新评估确认。
事件的响应时间、解决时限以及处理事件所需资源的配置，主要取决于事件的优先级。
表：事件影响度定义
编号影响度代码事件性质描述
重大故障全国半数以上地区或关键地区的业务系统中断超过6小时；
1全国半数以上地区或关键地区的营业、综合账务、客服中任一业务中断超过3小时；
1全国半数以上地区或关键地区的综合结算业务处理中断超过24小时；
1半数以下地区全业务中断超过6小时；
申告1对公司造成巨大损失产生严重后果和不良影响的；
1来自新闻媒体、消费者协会、国家行政机关的反映或申告；
2严重故障1全国半数以上地区或关键地区的业务系统中断大于10分钟、小于6小时；
1全国半数以上地区或关键地区的营业、综合账务、客服等业务中断均大于10分钟、小于3小时；
1全国半数以上地区或关键地区的综合结算业务处理中断大于2小时、小于24小时；
1半数以下地区全业务中断大于10分钟、小于6小时。
申告1数据错误导致产生大量的错单；
1涉及高额问题的申告；
1用户在营业现场反应激烈
故障系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障
申告1不属于重大申告和严重申告的用户申述
告警1不影响系统的监控平台告警
4无咨询1一般数据查询或者使用指导
6）事件模型定义
事件模型：管理某一特定类型事件的可重复的方法。其作用是：
·一些系统和服务的事件处置过程可以作为“典型事件的操作范例”。这些可能与已知的错误相关，例如缺乏兼容性或不正确的用户行为方式。服务提供者通过定义事件模型以优化处理和解决重复事件或类似事件，这些事件模型有助于快速、高效地解决事件，由于采用了经过验证和测试的解决方案，通常会产生更好的结果；
·事件模型通常是自动化的前提，通过事件模型的构建为自动化提供标准的操作过程。
事件模型通常需要根据不同的事件分类、不同的故障现象来具体描述，方便事件处理工程师能够正确使用加速事件处理和解决的过程。
表：事件模型示例
事件标题
事件分类
事件/故障现象描述
故障原因说明
解决方案
是否变通方案【】是；【】否
事件关闭条件与用户电话回访/某个自动化的参考标记/
7）事件起因定义事件起因定义主要是为完成对事件回顾分析时的统计标签设置，以便于后续事件回顾分析使用，根据不同的起因事件的数量采取有针对性的优化措施。
表：事件起因定义
事件起因描述
用户操作不当事件由用户的误操作导致
硬件故障事件由硬件故障导致
系统软件BUG事件由系统软件本身的缺陷（Bug）导致
应用程序BUG事件由应用程序本身的缺陷（Bug）导致
续表
事件起因描述
网络故障事件由网络故障导致
桌面环境事件由用户桌面环境导致
系统故障事件由系统故障导致
其他不属于以上原因的事件起因应备注说明
8）事件状态定义事件状态用于一方面用于通知用户能够随时了解事件处理的进展，另一方面便于做工单的转交现状和统计分析。
表：事件状态定义
事件状态描述
已受理事件已被服务台受理
已派单一个事件已被分派给二线支持人员或事件经理
已接单任何一个二线支持人员接受了事件并开始受理事件
解决中任何一个二线支持人员接受了事件并开始受理事件
挂起服务请求信息不完整，或在某些情况下阻止服务请求处理人员对服务请求进行受理，等待的原因为：
1、需要用户提供更详细的信息
2、不能联系到用户
3、升级到供应商受理
4、提交采购
5、其他不可抗拒力原因
已解决为一个事件找到解决方案或变通方法
已关闭事件经客户确认已关闭
注：挂起须填写挂起原因
9）事件关闭代码定义
事件关闭代码用于分析统计事件被解决的状态，便于事件回顾流程中对事件模型的评审与更新。
表：事件关闭代码
关闭状态描述
成功解决事件被正常解决。
变通方案解决事件已通过变通方法解决掉，但是需要进行更进一步的根源分析。用户认可可以作为一种特殊的变通方法。
事件消失没有找到错误或不能重现故障
无法解决现有情况下无法解决
关闭方式描述
用户确认关闭经用户确认后，服务台关闭
默认关闭如果累计两次与用户确认，用户未能配合确认的，并且事件解决已超过48小时的，可由服务台选择自动关闭
注：事件只有在解决后才能关闭，暂时无法解决的不能关闭。
10）用户反馈用来在事件单中记录用户对事件处理的满意程度。参考数字化IT运维管理体系建设指南等书籍资料
表：用户反馈定义
编号代码描述
1
满意用户对事件处理结果表示满意
2一般用户对事件处理结果既非满意也非不满意，处于中间感受
3
不满意用户对事件处理结果表示不满意
页:
[1]