
信息技术服务管理体系控制程序.docx
10页事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第1页共10页1.1 目的事件管理过程提供日程支持服务的接口,以降低因 IT 事件带来的影响该过程关注 尽可能快的恢复服务以满足预定服务等级协议(SLA)的要求1.2 适用范围事件管理过程适用于记录、处理、关闭事件并监督整个过程的管理活动,事件管理 过程包括服务台和相应的支持组1.3 术语表a) 事件:指服务的任何异常,并将导致或可能导致服务的中断或服务质量下降的事态b) 服务请求:来自客户对 IT 服务的信息、建议、标准变更或访问请求例如要求增加内存、安装 某个软件、账号申请、变更请求等变更通常不认为是一个事件,而是一个变更请求 (RFC) 但两者的处理方式相近,因此在事件处理过程中也包括对服务请求的处理, 即事件包含服务请求c) 事件关闭:接到事件请求后,服务台不能当时解决问题,则将需要把事件分配给相应的支持组 为尽可能快地恢复业务,可利用解决方案(永久性的)或临时措施当事件得到了解决, 并且服务也恢复到正常状态后,事件关闭另外事件还包括系统自动产生或例行巡检所 发现的某些事态,如硬盘空间超出设定值、机房 UPS 报警等。
虽然这些事态不会对服务 的交付产生直接影响,但对这些事态的处理也包括在事件管理过程中d) 事件处理过程:事件发生后,通常综合部服务台接受和尝试处理,当服务台未能快速解决时,派单 给一线工程师作为一线支持处理;当一线工程师未能快速解决时,事件从一线返回服务 台重新分配到二线;调用二线支持,后续的二线支持应具有更高的技能和资源来解决事 件事件从一线支持转到二线支持线,通常称为“职能升级”为表述方便,在《事件 管理程序》中,把“职能升级”过程称为“事件处理过程”事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第2页共10页e) 事件升级过程:如果事件未能及时按照预定的时间得以解决或未能满足用户要求,需要管理层参与, 以提供更多资源,则进行“垂直升级”按照问题的解决时间进度设置自动升级的时间 段,如果在预定时间段,问题没有解决,则自动进行“垂直升级”在设定预定时间段 时,应考虑留有足够的时间以进行管理升级采取必要措施(如引入第三方支持)因为 技能或经验的缺乏,可以通过服务台或支持工程师进行人工要求进行“垂直升级”为 表述方便,在《事件管理程序》中,把“垂直升级”过程称为“事件升级过程”。
f) 事件分类由于用户提供信息的不完整或不正确,可能导致开始的分类与最终的分类有很大的 差别首先对事件按照事件类型进行分类,各类可以对应到相应的支持组,以便准确分 配任务编号一级分类二级分类描述1合同服务网络服务器计算机存储系统应用软件购买第三方软件基础设施电源、空调、门禁、监控2项目售后公司产品网络服务器存储系统应用软件基础设施3公司资产维护硬件送修PC机网络应用系统资源管理系统、配置变更系统g)事件分级给事件分配优先级,以保证对事件必要的重视分级应基于是事件的紧急程度和影 响面事件严重程度定义如下事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第3页共10页事件级别级别定义影响业务范围影响业务程度业务修复紧急程 度一级事件客户业务中断,无法工作80%以上客户业务受影响非常紧急二级事件客户业务性能严重下降50%以上客户业务受影响紧急三级事件客户业务性能下降20%以上客户业务受影响普通四级事件问题请求,业务性能无下降客户业务可能有潜在影响与客户协商确定h)事件状态为方便事件状态的跟踪和查询,对事件状态定义如下编号状态描述1待处理已在系统中记录,未派单给工程师2已派单已分配至工程师,工程师未处理3处理中工程师正在处理过程中,事件未关闭4挂起工程师正在处理,调用三线供方厂商支持或送外修,尚未完毕5暂停工程师正在处理,因客户原因暂时无法处理6待审核事件已关闭,等待项目经理审核7已归档服务台已审核归档,服务台回访客户结束。
1.4 引用文件【1】 《ISO/IEC 20000-1 :2011》【2】 《IT 服务管理手册》2.1 服务台受理事件请求,自行解决事件或调度相关支持组解决事件服务等级协议(SLA)约定的服务范围内的事件报告和服务请求,服务台都应纳入事件处理范围负责对相关数据进行统计分析2.2 一线(现场工程师)/二线(专项工程师)事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第4页共10页接收服务台的事件处理请求,解决系统运维相关事件 负责提供一线/二线支持,按照标准要求填写处理过程 负责联络和管理外部三线(供方厂商)支持2.3 外部资源接收一线/二线的事件处理请求,配合解决系统运维相关事件2.4 项目经理负责协调资源调度,保障业务尽快恢复 负责和客户确认事件解决并最终关闭事件 监控事件处理流程的效率和效果 管理一线/二线支持组的工作为改进工作提供建议事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第5页共10页3 流程图事件处理过程EMAIL/WEB巡检口头书面系统用户客户係统服务台一线支持解决和恢复二线支持三线支持事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第6页共10页具体内容4.1 接受/记录事件4.1.1 用户、IT维护人员、公司合作伙伴可以通过、或电子邮件 等方式向服务台报告事件,IT维护人员的日常检查等获得事件信息。
4.1.2 IT 维护人员应按《服务合同》的要求进行例行检查,并应在检查结 束后,填写相应的检查记录,对所发现的事件应告知服务台登记4.1.3 所有工程师(含服务组、技术组)接受的客户直接报修或工程师自 身主动发现的事件,告知服务台登记4.1.4 服务台接到事件报告和服务请求后,及时在事件管理系统内作好记录事件记录应包括以下要素:•事件编号•事件报告的日期、时间• 记录人• 事件报告人员、用户及其联系方式•事件发生的日期和时间,受影响的配置项(CI)信息• 症状描述和任何错误代码(如果是服务请求,则该项为所请求的服务的详细信息)• 已经产生的影响或可能导致的影响等级;• 事件处理状态4.1.5 服务台记录事件后,要分析事件是否在受理责任范围内如果不在 受理范围内,则由服务台告知事件报告人如客户仍需提供超出受理范围的支持服 务,则由服务台告知客户及研发部,由研发部决定是否进行服务4.2 分级/分类和初步支持4.2.1 在接受和记录事件之后,服务台首先根据1.3 的事件分级、分类准则对受理的事件 进行分级和分类以方便后续的监视和报告4.2.2 服务台要根据事件分类及性质确定应由哪个小组处理该事件,转到对应的一线或二 线支持组。
事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第7页共10页4.2.3 如果发现人员安排紧张时,应优先安排紧急程度高的事件必要时,可以召回低紧 急度事件的工程师,应对紧急程度较高的事件4.2.4对于重大事件,在按上述步骤进行处理的同时,还应按照第5节 “事件升级过程” 进行升级汇报4.3 调查和分析1.1 接到事件处理请求的小组应立即着手对事件进行调查诊断,提供事件、问题解决方 案判断事件的分级分类是否合理1.2 如果事件派单错误(如网络故障事件被派单到应用组),则立即返回服务台重新派单1.3 如果事件分级错误,则进行相应的调整,并告知服务台但原则上,原有分级不得 降低1.4 接到事件处理请求的小组收到转发过来的事件后,查看知识库,看以前是否有类似 事件发生1.5 如果类似事件发生过,查看知识库里是否已经有事件或类似事件的解决方案或是应 急措施等,如果有就参照这些方案组织实施以解决事件如没有发生过类似事件, 尝试解决1.6 如果接到事件处理请求的小组不能快速解决事件,或者事件处理要求已经超过他们 直接解决范围,则转入后续支持,如由一线通过服务台转到二线,或直接调用第三 方厂家支持,并告知服务台。
1.7 接到事件处理请求的小组不能快速解决事件时,应按事件的紧急程度,按照第 5 节 “事件升级过程”进行升级汇报1.8 如果事件无法得到解决,或事件虽然得到暂时解决,但没有找到事件发生的根本原 因,则由 IT 服务工程师汇报项目经理及部门经理,视其需要创建问题,进入问题管 理过程4.3 解决和恢复a. 接到事件处理请求的小组应着手解决事件和恢复服务b. 如果事件的处理需要在机房、或其他重要区域及系统进行操作,应遵照客户的规定事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第8页共10页执行c. 如事件的解决方案涉及 IT 基础设施、配置变更的,由负责事件处理的小组按《变更 管理程序》的要求向项目经理提交变更请求,项目经理制订相应的变更计划并监控 实施4.5 事件关闭4.5.1 工程师获得用户对事件解决的认可后,将事件转为“待审核”状态,关闭事件4.5.2 项目经理每天确认所对应的“待审核状态”的事件是否解决如果确认事件解决, 则终止该事件,将事件状态改为“已归档”;否则事件管理活动需要在未解决的地方重新 开始处理4.5.3 项目经理应对所发生事件进行分析,对于需要进行问题管理的事件,按照《问题 管理程序》的要求进行管理。
4.5.4 项目经理负责事件记录以及最终分类和分级的准确性4.6 过程的跟踪监控4.6.1 事件处理人员在实施过程中应按照 1.3 中的状态定义,随时更新事 件状态或向服务台报告事件状态当天未能解决的事件, 服务台应在每个工作日下班 前 1 小时告知项目经理事件的处理状态,以及预期的行动4.6.2 项目经理负责对事件进展进行跟踪和监控,根据服务等级协议(SLA) 来监控事件处理流程的效果和效率,在事件处理过程中要和客户保持良好沟通,及 时通报事件处理的进展情况,提高客户满意度当天未能解决的事件,应在当天下 班前半小时告知客户当前事件的处理状态,以及预期的行动4.6.3 服务台应每周对所有事件进行回访,并向项目经理通报回访结果5 事件升级过程【1】事件严重程度定义如果事件未能及时按照一定的时间得以解决或未能满足用户要求,需要管理层参与,事件管理程序文件编号ITSMS-02-13版号第A版第0次修改页码第9页共10页以提供更多资源,则负责处理事件的工程师和项目经理应按照事件的严重程度逐步 升级汇报事件严重程度定义按照 1.3 中的定义执行2】事件升级步骤当事件未能或预计未能按照服务等级协议(SLA)的要求,得以修复时,将按照预定 的时间表自动(或由服务台)发起事件升级。












