事件管理流程文件doc.docx

1、事件管理流程文件doc事件管理程序样式编号编制审核批准密级内部版本发布日期2009年1月5日信息技术有限责任公司变更履历序版本 更改处更改内容 更改人 / 日期 审核人 / 日期 批准人 / 日期号1 新建1.12345目录1简介 . .错误 ! 未定义书签。目的 .错误 ! 未定义书签。适用范围 . .错误 ! 未定义书签。术语表 . .错误 ! 未定义书签。引用文件 . .错误 ! 未定义书签。2职责 . .错误 ! 未定义书签。服务台 . .错误 ! 未定义书签。一线（现场工程师）/ 二线（专项工程师） . .错误 ! 未定义书签。外部资源 . .错误 ! 未定义书签。项目经理 . .错

2、误 ! 未定义书签。3流程图 . .错误 ! 未定义书签。4具体内容 . .错误 ! 未定义书签。接受 /记录事件 . .错误 ! 未定义书签。分级 /分类和初步支持. .错误 ! 未定义书签。调查和分析 . .错误 ! 未定义书签。解决和恢复 . .错误 ! 未定义书签。事件关闭 . .错误 ! 未定义书签。过程的跟踪监控 . .错误 ! 未定义书签。5事件升级过程. .错误 ! 未定义书签。事件严重程度定义 . .错误 ! 未定义书签。事件升级步骤 . .错误 ! 未定义书签。6事件管理过程与其他流程的关系. .错误 ! 未定义书签。事件管理过程与其他关系 . .错误 ! 未定义书签。7事

3、件管理过程的 KPI .错误 ! 未定义书签。KPI 定义 .错误 ! 未定义书签。8 输出的文件和记录 . . 错误 ! 未定义书签。1简介1.1目的事件管理过程提供日程支持服务的接口，以降低因IT事件带来的影响。该过程关注尽可能快的恢复服务以满足预定服务等级协议（SLA）的要求。1.2适用范围事件管理过程适用于记录、处理、关闭事件并监督整个过程的管理活动，事件管理过程包括服务台和相应的支持组。1.3术语表事件：指服务的任何异常，并将导致或可能导致服务的中断或服务质量下降的事态。服务请求：来自客户对 IT 服务的信息、建议、标准变更或访问请求。例如要求增加内存、安装某个软件、账号申请、变更请

4、求等。变更通常不认为是一个事件，而是一个变更请求（ RFC） 。但两者的处理方式相近， 因此在事件处理过程中也包括对服务请求的处理，即事件包含服务请求。事件关闭：接到事件请求后，服务台不能当时解决问题，则将需要把事件分配给相应的支持组。为尽可能快地恢复业务，可利用解决方案（永久性的）或临时措施。当事件得到了解决，并且服务也恢复到正常状态后，事件关闭。另外事件还包括系统自动产生或例行巡检所发现的某些事态，如硬盘空间超出设定值、机房UPS告警等。虽然这些事态不会对服务的交付产生直接影响，但对这些事态的处理也包括在事件管理过程中。事件处理过程：事件发生后，通常服务台接受和尝试处理，当服务台未能快速解

5、决时，派单给一线工程师作为一线支持处理；当一线工程师未能快速解决时，事件从一线返回服务台重新分配到二线；二线未能解决时，调用三线厂商支持，后续的二线或三线支持应具有更高的技能和资源来解决事件。事件从一线支持转到二线或后续支持线，通常称为“职能升级”。为表述方便，在事件管理程序中，把“职能升级”过程称为“事件处理过程”。事件升级过程：如果事件未能及时按照预定的时间得以解决或未能满足用户要求，需要管理层参与，以提供更多资源，则进行“垂直升级”。按照问题的解决时间进度设置自动升级的时间段，如果在预定时间段，问题没有解决，则自动进行“垂直升级”。在设定预定时间段时， 应考虑留有足够的时间以进行管理升级

6、采取必要措施 （如引入第三方支持） 。因为技能或经验的缺乏，可以通过服务台或支持工程师进行人工要求进行“垂直升级”。 为表述方便，在事件管理程序中，把“垂直升级”过程称为“事件升级过程”。事件分类由于用户提供信息的不完整或不正确， 可能导致开始的分类与最终的分类有很大的差别。首先对事件按照事件类型进行分类，各类可以对应到相应的支持组，以便准确分配任务。编号 一级分类 二级分类 描述包括视频会议、视频监控系统线路及外围设视讯系统备网络PC终端PC服务器1合同服务小型机存储系统公司自主开发软件或由公司提供服务的第三应用软件方软件基础设施 电源、空调、门禁、 KVM2 工程售后 视讯系统全球眼网络P

7、C终端PC服务器小型机存储系统应用软件基础设施硬件送修PC机3公司资产维护网络前端应用系统 公司协同办公、 MIS 系统服务4业务咨询5单次收费服务事件分级给事件分配优先级，以保证支持组对事件必要的重视。分级应基于是事件的紧急程度和影响面。事件严重程度定义如下。级别定义事件级别影响业务范围影响业务程度业务修复紧急程度一级事件客户业务中断，无法工作80%以上客户业务受影响非常紧急二级事件客户业务性能严重下降50%以上客户业务受影响紧急三级事件客户业务性能下降20%以上客户业务受影响普通四级事件问题请求，业务性能无下降客户业务可能有潜在影响与客户协商确定事件状态为方便事件状态的跟踪和查询，对事件状

8、态定义如下。编号 状态 描述编号 状态 描述1 待处理 已在系统中记录，未派单给工程师2 已派单 已分配至工程师，工程师未处理3 处理中 工程师正在处理过程中，事件未关闭4 挂起 工程师正在处理，调用三线厂商支持或送外修，尚未完毕5 暂停 工程师正在处理，因客户原因暂时无法处理6 待审核 事件已关闭，等待项目经理审核7 已归档 服务台已审核归档，服务台回访客户结束。2职责2.1服务台受理事件请求，自行解决事件或调度相关支持组解决事件。服务等级协议（ SLA）约定的服务范围内的事件报告和服务请求，服务台都应纳入事件处理范围。负责对相关数据进行统计分析。2.2一线（现场工程师） / 二线（专项工程

9、师）接收服务台的事件处理请求，解决系统运维相关事件。负责提供一线 / 二线支持，按照标准要求填写处理过程。负责联络和管理外部三线支持。2.3外部资源接收一线 / 二线的事件处理请求，配合解决系统运维相关事件。2.4项目经理负责协调资源调度，保障业务尽快恢复。负责和客户确认事件解决并最终关闭事件。监控事件处理流程的效率和效果。管理一线 / 二线支持组的工作。为改进工作提供建议。3流程图事件处理过程用户/电话EMAIL/WEB 巡检口头/书面系统客户/系统服务台监视、跟踪、沟通和管理一线支持 事件检测和记录分类和初步支持已解决解决和恢复事件关闭未解决二线调查和分析解决和恢复支持三线 调查和分析支持

10、4具体内容4.1 接受 / 记录事件4.1.1用户、 IT 维护人员、公司合作伙伴可以通过电话、传真或电子邮件等方式向服务台报告事件， IT 维护人员的日常检查等获得事件信息。4.1.2IT 维护人员应按服务合同的要求进行例行检查，并应在检查结束后，填写相应的检查记录，对所发现的事件应告知服务台登记。4.1.3所有工程师（含服务组、技术组）接受的客户直接报修或工程师自身主动发现的事件，告知服务台登记。4.1.4服务台接到事件报告和服务请求后，及时在事件管理系统内作好记录。事件记录应包括以下要素：4.1.4.1事件编号4.1.4.2事件报告的日期、时间4.1.4.3记录人4.1.4.4事件报告人

11、员、用户及其联系方式4.1.4.5事件发生的日期和时间，受影响的配置项(CI) 信息4.1.4.6症状描述和任何错误代码（如果是服务请求，则该项为所请求的服务的详细信息）4.1.4.7已经产生的影响或可能导致的影响等级；4.1.4.8事件处理状态4.1.5服务台记录事件后，要分析事件是否在受理责任范围内。如果不在受理范围内，则由服务台告知事件报告人。如客户仍需提供超出受理范围的支持服务，则由服务台告知客户及销售部门，由销售部门决定是否进行服务。4.2 分级 / 分类和初步支持4.2.1在接受和记录事件之后，服务台首先根据的事件分级、分类准则对受理的事件进行分级和分类以方便后续的监视和报告。4.

12、2.2服务台要根据事件分类及性质确定应由哪个小组处理该事件，转到对应的一线或二线支持组。4.2.3 如果发现人员安排紧张时，应优先安排紧急程度高的事件。必要时，可以召回低紧急度事件的工程师，应对紧急程度较高的事件。4.2.4 对于重大事件，在按上述步骤进行处理的同时，还应按照第 5 节 “事件升级过程”进行升级汇报。4.3调查和分析4.3.1接到事件处理请求的小组应立即着手对事件进行调查诊断，提供事件、问题解决方案。判断事件的分级分类是否合理。4.3.1.1如果事件派单错误（如网络故障事件被派单到应用组），则立即返回服务台重新派单。4.3.1.2如果事件分级错误，则进行相应的调整，并告知服务台

13、。但原则上，原有分级不得降低。4.3.2接到事件处理请求的小组收到转发过来的事件后，查看知识库，看以前是否有类似事件发生。4.3.3如果类似事件发生过，查看知识库里是否已经有事件或类似事件的解决方案或是应急措施等，如果有就参照这些方案组织实施以解决事件。如没有发生过类似事件，尝试解决。4.3.4如果接到事件处理请求的小组不能快速解决事件，或者事件处理要求已经超过他们直接解决范围，则转入后续支持，如由一线通过服务台转到二线，或直接调用第三方厂家支持，并告知服务台。4.3.5接到事件处理请求的小组不能快速解决事件时，应按事件的紧急程度，按照第5 节“事件升级过程”进行升级汇报。4.3.6如果事件无

14、法得到解决，或事件虽然得到暂时解决，但没有找到事件发生的根本原因，则由 IT 服务工程师汇报项目经理及部门经理，视其需要创建问题，进入问题管理过程。4.4解决和恢复4.4.1接到事件处理请求的小组应着手解决事件和恢复服务。4.4.2 如果事件的处理需要在中心机房、或其他重要区域及系统进行操作，应遵照客户的规定执行。4.4.3 如事件的解决方案涉及 IT 基础设施、配置变更的， 由负责事件处理的小组按 变更管理程序的要求向项目经理提交变更请求，项目经理制订相应的变更计划并监控实施。4.5事件关闭4.5.1工程师获得用户对事件解决的认可后，将事件转为“待审核”状态, 关闭事件。4.5.2项目经理每

15、天确认所对应的“待审核状态”的事件是否解决。如果确认事件解决，则终止该事件，将事件状态改为“已归档”；否则事件管理活动需要在未解决的地方重新开始处理。4.5.3项目经理应对所发生事件进行分析，对于需要进行问题管理的事件，按照问题管理程序的要求进行管理。4.5.4项目经理负责事件记录以及最终分类和分级的准确性。4.6过程的跟踪监控4.6.1事件处理人员在实施过程中应按照中的状态定义，随时更新事件状态或向服务台报告事件状态。当天未能解决的事件, 服务台应在每个工作日下班前1 小时告知项目经理事件的处理状态，以及预期的行动。4.6.2项目经理负责对事件进展进行跟踪和监控，根据服务等级协议 （ SLA

16、）来监控事件处理流程的效果和效率，在事件处理过程中要和客户保持良好沟通，及时通报事件处理的进展情况，提高客户满意度。当天未能解决的事件，应在当天下班前半小时告知客户当前事件的处理状态，以及预期的行动。4.6.3服务台应每周对所有事件进行回访，并向项目经理通报回访结果。5事件升级过程5.1 事件严重程度定义5.1.1如果事件未能及时按照一定的时间得以解决或未能满足用户要求，需要管理层参与，以提供更多资源，则负责处理事件的工程师和项目经理应按照事件的严重程度逐步升级汇报。事件严重程度定义按照中的定义执行。5.2事件升级步骤5.2.1当事件未能或预计未能按照服务等级协议（SLA）的要求，得以修复时，

17、将按照预定的时间表自动（或由服务台）发起事件升级。另当，用户或支持队伍认为有必要时，可以要求发起事件升级。5.2.2事件升级时间表汇报人工程师项目经理事业部总监一级事件立即立即立即二级事件4小时内6小时内8小时内三级事件6小时内8小时内12小时内四级事件12小时内24小时内48小时内升级至项目经理事业部总监公司管理层（时间表按照客户合同重新调整）6事件管理过程与其他流程的关系6.1 事件管理过程与其他关系6.1.1 图 2 为事件管理过程与其他过程的之间关联关系。在事件管理过程中，可能需要直接触发其他管理过程， 或直接向某些过程获取必要数据。 对于在事件管理过程没有直接影响的其他管理过程，则不

18、在本过程中进行描述。查询配置管理更新事件信息事件管理过程 问题管理解决方案接受和记录分级 /分类和初步支持调查和分析解决和恢复RFC事件关闭变更管理解决方案事件跟踪、监控和沟通SLA 要求服务水平管理报告6.1.2 配置管理指服务台 / 一线 / 二线 / 三线支持在处理问题过程中， 可能需要从配置数据库中获取必要的配置项相关的信息，并在处理过程中对配置项的变更及时更新。6.1.3 问题管理指事件没有得到解决，需要升级为问题进行进一步分析处理时，应创建问题；事件虽然得到解决，但可能存在未知错误时，应创建问题；重大事件，无论是否得到解决，为防止再次出现，应创建问题；在事件分析报告中提出的存在趋势

19、或潜在隐患的可能问题，例如事件类型或数量的趋势分析存在问题。创建问题后，启动问题管理过程。6.1.4 变更管理过程指服务台 / 一线 / 二线 / 三线支持在处理问题过程中， 可能需要提交变更请求，以解决问题。6.1.5 服务等级管理指为服务台在接受 / 跟踪时，提供必要的服务等级协议（ SLA）信息。7事件管理过程的 KPI7.1 KPI 定义7.1.1 为保证事件管理过程的快速有效，发现潜在的问题，被加以改善是非常必要的。为此，定义以下关键指标：7.1.1.1 事件的总数7.1.1.2 对业务的影响7.1.1.3 未能满足服务等级协议（ SLA）要求的比例7.1.1.4 平均花费的时间（按事件分类进行统计）7.1.1.5 一线解决问题的比例7.1.1.6 事件趋势分析7.1.1.7 重大事件分析。8 输出的文件和记录文件和记录文件属性拟制部门事件记录表D服务部服务月报D服务部客户服务工作单D服务部