it服务管理项目-事件管理流程设计手册（46页）

IT服务管理项目事件管理流程设计手册来自资料搜索网WWW3722CN海量资料下载目录1文档介绍511文档简介512文档用途513文档结构514术语62事件管理流程简介721流程基本概念722流程目的823流程范围924流程主要内容925流程业务价值103事件管理流程设计1031流程执行原则10311流程常规原则10312责任制原则11313事件分派原则11314事件重分派原则12315重复/复发事件原则12316事件关闭原则12317事件通报原则13318事件升级原则14319流程关联原则1432流程相关定义15321事件信息项15322事件来源18323事件性质19324事件分类19325事件优先级20326事件时限21327事件状态22328事件结束代码2233流程角色和职责定义23331事件流程负责人23332事件流程经理24333服务台支持人员（含1线、15线）25334二线支持人员26335三线支持人员26336四线支持人员2634流程概要设计2735流程详细设计29351事件检测与记录29352事件分类和初步支持30353事件调查和诊断32354事件解决和恢复33355事件关闭3436与其他流程的关系3637流程衡量指标及报表374附录3841事件管理流程相关表格38图目录图31XXX事件管理流程概览3图32事件检测和记录3图33事件分类和初步支持3图34事件调查和诊断3图35事件解决和恢复3图36事件关闭3图37XXX服务管理流程关系图3表目录表31事件升级机制3表32事件信息项3表33事件来源3表34事件性质3表35事件分类3表36事件紧急程度3表37事件优先级矩阵3表38事件时限3表39事件状态3表310事件结束代码3表311事件管理KPI列表31文档介绍11文档简介本文档XXX事件管理流程设计手册,是XXX信息技术总部（以下简称XXX）团队制定的事件管理流程文档。通过制定该流程，可以帮助XXX信息技术总部团队对主动监控发现以及用户上报的故障和服务请求进行快速响应和快速处理,尽快恢复中断或受影响的用户业务。通过该流程的规范，可进一步改进XXXIT服务向用户提供的服务水平和服务质量,确保用户对服务价值的认同和肯定。本文档是依据目前XXX的IT服务状况而制定的事件管理流程,进一步的流程更新将移交由XXX服务团队负责。12文档用途本文档既是本次IT服务管理项目事件管理流程的交付物,也可作为XXX服务团队进一步改进事件管理流程的蓝本,读者对象为与事件管理流程相关的所有管理与技术人员本文档所描述的流程在IT服务管理中有许多作用,列举如下减小突发事件对业务的影响；最优化支持资源，提高工作效率；屏蔽错误事件和服务请求；根据影响业务轻重缓急安排资源解决事件，保障有效IT运营；加强有形监控和及时反馈；提升用户对服务的认知度和满意度；提供管理信息；13文档结构本文档作为XXX事件管理流程设计手册，主要包含针对XXX服务运营中对用户故障及用户请求处理等相关人员及活动的定义和描述。各章节中内容概要如下文档介绍主要对文档的目的、用途及结构进行简要描述，并就文档当中出现的术语进行了说明。事件管理流程简介主要对事件管理流程的基本概念、目的和范围进行了介绍。同时简单梳理了事件管理流程中包含的主要活动内容，最后对事件管理流程对组织及用户的业务价值进行了相关阐述。事件管理流程设计该部分为本文档的重点章节。在该章节中，首先对事件管理流程的相关执行原则和代码进行了描述；其次，对事件流程相关角色的职责和技能要求进行了说明；基于流程原则和角色定义，进而对事件管理的概要设计流程及详细设计流程进行了充分定义，并给出了事件管理流程的关键衡量指标，以保证对流程运行的监控、管理和改进。附录与事件管理流程相关的附属内容，都将在附录中进行补充说明。14术语服务台在ITIL中，服务台从根本上来说提供了用户和IT部门的唯一接口。此项功能常常通过集中的服务台进行体现。服务台的根本目的是提供一线支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。事件管理ITIL流程，是负责解决所有的IT事件、问题和用户请求等的管理流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。问题管理ITIL流程，是负责对事件进行深入分析，找出根本原因并提供解决方案的管理流程。它的目的是主动防御，找出根本原因并对其根除，所以它与事件管理流程有显著的不同，以“治本”为最终目标。变更管理ITIL流程，是负责对生产环境中支持IT服务的各种基础架构设备和应用系统的变更操作进行记录、分类、评估、计划和协调的流程。它的目的是在权衡“风险”和“效率”的前提下，对变更操作进行有效的控制，以保证任何变更对IT环境和其所支撑的IT服务的影响最小。发布管理ITIL流程，是负责对应用系统上线过程的全局管理和控制。管理范围涉及测试环境、预发布环境和生产环境等，旨在通过对发布单元的生命周期各个阶段的控制保证其安全稳妥的进入生产环境，而不引入新的缺陷或故障。配置管理ITIL流程，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置元素（CI）。每一个CI必须有效管理，跟踪和控制以支持IT服务和基础设施成功运行。配置管理数据库（CMDB）是在配置管理流程中用于记录企业所有IT相关配置元素信息及其相互关系而建立的数据库。ITILITINFRASTRUCTURELIBRARY，是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。2事件管理流程简介21流程基本概念事件管理流程通过提供服务台作为日常IT支持接口，由IT支持人员根据流程定义，快速响应和解决IT用户的服务请求、突发事件、投诉反馈等，最大化地减少突发事件对用户业务活动的影响，最终确保SLA目标的实现。事件管理流程相关的几个关键词汇解释如下“日常支持接口”即服务台，该接口将采用集中服务方式，向所有IT用户提供唯一服务窗口，按照业务需求，提供相应级别的支持服务。“IT用户”指的是指XXX服务的使用者，他们使用XXX提供的IT服务来支持相关日常业务。“IT支持人员”指的是XXX服务团队中IT运维和支持人员的统称，包括一线人员和二线人员等，可能涉及XXX体系中的相关的开发、支持和运维等团队。“一线支持”指服务台的通用座席，向IT用户提供一线支持服务，以下提到的服务台人员即一线支持人员。“15线支持”指机房值班人员（交易系统故障时）和桌面维护人员（桌面故障时，在桌面类和机房交易系统相关事件处理过程中实施IT支持服务；“二线支持”主要由各职能小组运维工程师组成，协助服务台一线人员参与事件处理，相对一线支持人员，二线支持具有更高更专业的技能。“三线支持”指各职能小组组长，在复杂度较高事件或二线支持无法解决事件时负责协调小组内部人员进行事件处理，三线支持更多的强调管理协调职能。“四线支持”指XXX开发团队和供应商等。“事件”指XXX在用户IT环境中发现的所有非正常事件，对现有的服务造成影响或中断。例如服务器宕机、网络中断、应用不可用等。从来源上来分，主要包括由信息技术总部内部人员发起的事件以及有用户报告的事件等。“服务请求”指用户提出的关于标准服务、培训、文档、信息等方面的请求，以及针对IT服务使用的咨询等，通常并没有发生IT组件方面的故障。例如请求培训、寻求咨询等。服务请求是一种特殊类型的事件。“投诉反馈”指由用户提出的对于IT服务质量或服务方式的抱怨或改进建议，通过服务台统一接受，并进行相应处理。22流程目的事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括在成本允许的范围内尽快恢复IT服务快速响应故障及服务请求用户在线获得帮助沟通事件解决的状态和用户确认事件的解决进行事件控制按规范记录事件就事件的优先级，影响度进行分类分析，诊断，必要时进行升级监视并结束事件进行定期服务流程回顾提供IT管理信息人力资源利用情况故障处理情况支持效率23流程范围XXX事件流程管理范围包括所有用户与XXX信息技术总部内部的事件、服务请求和投诉反馈等。其中不包括现有应用系统新增功能需求不包括用户对于信息类设备和应用系统的新需求不包括新系统开发需求24流程主要内容事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容事件接收和记录这个环节是事件管理流程的起点。所有监控系统或用户报告的IT事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。该环节的关键是信息的准确性和完整性。分类和初步支持对于每个事件，需要确立优先级和分类。若没有现成的解决方案（SOLUTION）或变通方法（WORKAROUND），该事件将分配给合适的支持人员对此进行调查。调查和诊断若支持人员无法利用现成方案解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。解决和恢复支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。事件升级对于高优先级的事件，服务台应立即上报给事件经理和相关的管理层，由事件经理决定事件的处理方式，确保其得到最快速的解决。当事件处理超过预期解决时限，应通知相关处理人员和管理层，以引起处理人员和管理人员的重视和参与。结束事件当用户确认事件解决后，可结束该事件。25流程业务价值XXX事件管理流程将在多个方面对“XXX服务”业务产生积极作用，具体表现在以下几个方面单一联系点通过在团队内部建立服务台，作为与用户沟通联系的单一联系点。对用户方发生的故障及用户上报的服务请求进行快速响应和统一管理，对内部服务支持资源进行合理协调和调配。同时，服务台作为IT服务窗口，也进一步维护和加强了与用户的关系，为提高用户体验和满意度起到了重要作用。用户业务尽快恢复通过合理调配资源，使用知识库等相关支持工具，对不同级别事件选择各自的解决时限，对用户被中断或受影响的业务进行快速响应和恢复。内部团队协作加强为服务支持团队成员分配角色，并清晰界定职责。通过事件管理流程将团队成员进行有效的连接，加强内部团队协作和沟通的有效性和工作效率。服务质量控制和改进通过定期提交流程相关指标和报表至管理层，以实现对流程的监控和管理，同时为服务质量的改进奠定基础。3事件管理流程设计31流程执行原则311流程常规原则所有在流程范围内发生的事件，都应该被完整准确的记录下来，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相关的附件等。事件处理过程中，在需要寻求第三方的情况下，遵循下述原则根据事件实际处理情况，各二线或三线支持寻找相应供应商在供应商参与解决事件的过程中，事件当前处理责任仍保留在二线或三线人员处XXX服务支持体系是由信息技术总部全体人员共同组成的，事件的处理过程中必须加强一线和二线的沟通，沟通的方式优先使用工具（服务管理平台），在需要的时候必须辅助电话、短信、邮件等手段。所有支持人员优先处理优先级较高的事件。对于来自于服务台转入的事件（包括故障/服务请求/咨询/投诉建议），首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件在XXX范围内的责任人，确保事件在在XXX内部得到有效跟踪、解决，并将解决结果反馈给服务台。每月定期产生事件管理报表，分析服务质量，对重大事件、重复发生的事件或者利用变通方法解决的事件，应提交问题管理流程进行问题定义分析和解决，并定期对这些事件进行评估跟踪。建议每三个月对流程进行回顾，包括流程执行效率和流程支持工具的有效性，以改进和优化事件管理流程。312责任制原则责任制原则用来确保每个事件在任何时段都有适当的人员负责。由监控系统上报的事件，对故障进行识别并在系统中记录的服务台人员是该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭由用户电话上报的事件，首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭服务台员工换班时，由服务台值班经理进行事件重新分派，事件责任人也由此转移事件被服务台人员转至二线人员或第三方后，二线人员/第三方成为该事件的当前责任人，但服务台人员仍然是事件的整体负责人，有义务对事件处理状态按相应策略进行监控，并及时反馈给用户，保证事件的处理过程对用户充分透明。313事件分派原则事件分派原则是确保事件在服务目标时段内处理和解决的重要因素。服务台一线支持人员在规定的一线处理时限内，可按情况选择转给其他在值服务台一线支持人员进行处理服务台一线支持人员在规定的一线处理时限内不能解决事件时，原则上根据事件分类分派到相应二线支持人员。在特定情况下，比如二线支持人员的非工作时间内，服务台一线支持人员在派单后利用电话方式通知二线人员相关事宜。桌面类故障导致事件直接由15线桌面运维小组进行处理开市期间交易系统故障，直接由15线机房座席接听处理。服务台一线支持人员在判断事件为交易系统故障后，应第一时间按策略通报机房处理，不能明确界定是否是交易系统故障，亦应交机房处理。314事件重分派原则二线支持接受服务台分派事件后，如果该事件不属于本人支持范围或者自身能力无法处理，二线人员需首先注明原因，然后将事件返回到服务台，由服务台重新分配。为提高事件解决效率，应当尽量减少事件单重分派的几率。事件单的重分派次数不应该超过2次。同组的事件单再分派不被监控；任何跨组的事件单再分派将会报告给事件经理；事件再分派超过2次，事件单将升级给事件经理；315重复/复发事件原则重复事件如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。将会为此重复的事创建新的事件单，并标注此单为“重复”并与原始事件单相关联。原始事件将被标注为“主事件”复发事件（3天内同一用户，同一件事）如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了（或失败或误再报）。此时，应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。316事件关闭原则事件单的关闭必须由服务台对应15/1线支持人员完成，但是事件经理可以超越此规则。其他人无权关闭事件单。二线支持人员确定解决方案并解决事件后，必须把事件返回到服务台。事件单的用户可以要求关闭此事件单，例如误报、错报事件。关闭事件单由事件单对应一线支持人员负责。服务台人员关闭事件前，需获得客户对解决方案的确认和反馈。关闭事件时，根据实际解决情况填写事件的结束代码。已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单，并标识为复发事件。对于以“变通方法解决”或“不能重现”结束代码关闭的事件，需通知问题经理对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。所有优先级为最高的事件在关闭后，需通知问题经理对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。对于未及时取得用户反馈的已解决事件，系统将对其保留3日。3日内服务台人员应至少每天主动与用户联系1次。若3日后仍未得到用户有效反馈，系统将自动关闭事件，并标识结束代码为“自动关闭”字样。317事件通报原则对于监控系统自动发现的告警信息，服务台人员有责任对其进行识别。如确认为一条事件，则应首先在第一时间通报相应用户和事件经理，然后在服务管理平台中进行记录。通报策略具体如下通报方式用户工作时间内采用正式的通知方式进行通报用户非工作时间采用邮件方式进行通报与用户通报相关的其他方式参考与用户签订的SLA中的具体定义采用邮件的方式通知事件经理；如果由于用户原因第一时间无法完成通报，应首先在服务管理平台中登记一条事件，并置于“挂起”状态，相关服务台人员有责任在开单后每隔5分钟主动尝试联系用户3次。若3次后仍无法取得联系，则应在事件工作日志中注明“无法联系到用户”的字样，并进行后续处理；若3次内取得联系，则在与用户确认故障后，取消事件“挂起”状态并进行后续处理。通报对象依照事件分类表中定义，向用户部门相关人员通报最后通报事件经理通报内容事件简要描述可能受到影响的用户方业务（或范围）确认是否为用户方运维操作导致可能导致事件的原因预计解决事件的时间点318事件升级原则制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和管理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。优先级为最高的事件，需要立即事件升级，同时，事件继续按事件管理流程进行快速处理超出规定的响应或者解决时限之后，需要立即升级事件，同时，事件继续按流程进行快速处理事件重复派单超过三次直接升级给事件经理具体事件升级机制如下表所示表31事件升级机制事件升级机制小组技术经理事件经理运维经理技术总部领导公司领导优先级15分钟5分钟10分钟10分钟15分钟优先级21小时1小时1小时15小时优先级32小时2小时优先级44小时4小时319流程关联原则和问题管理的关联一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案通过分析事件记录，形成问题，并使该问题与相关事件建立关联通过事件单和问题单的关联，服务台人员对问题的解决状况进行跟踪并和用户保持沟通对高优先级事件或者“变通方法解决”或“无法重现”关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。和变更发布管理的关联事件处理过程中，如果需要对相关IT组件进行变更（不在标准变更清单内的变更），必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理。高优先级事件的处理过程中，如果需要对相关IT组件进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和事件单建立关联。和配置管理的关联事件处理过程中，可以通过配置管理查询相关的配置项信息（尤其是关系信息）以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联32流程相关定义321事件信息项事件单必须包含如下事件信息项，XXX服务团队可以在此基础上进行扩充表32事件信息项序号信息项说明1事件ID事件单流水号（系统自动产生）2事件请求人事件申报人的信息，包括姓名、公司、部门、电子邮件、办公电话、手机3事件登记时间在服务台生成事件记录的时间（系统自动产生）4事件登记人事件开单人的信息，包括员工姓名、员工ID、联系方式等（系统自动产生）5事件发生时间针对故障指的是业务中断的实际时间（可能早于登记时间，自动设置或者手工填写）；针对用户请求缺省值等于登记时间。事件发生时间必须早于或等于登记时间。6事件发生地点事件发生的位置信息7事件来源参见“事件来源”定义8事件标题事件的简要描述9事件描述对于整个事件内容的详细描述10事件性质参见“事件性质”定义11事件分类参见“事件分类”定义12事件状态参见“事件状态”定义13事件影响范围参见“事件影响范围”定义14事件紧急程度参见“事件紧急程度”定义序号信息项说明15事件优先级参见“事件优先级”定义16事件完成期限对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限（系统自动产生）17事件分配工作组被分配的支持小组18事件分配人员被分配的支持小组内成员19事件工作日志反映事件处理过程的信息20解决方案/变通方法事件解决方案/变通方法的描述21事件解决人事件的最终解决人22事件解决人角色参见“事件解决人角色”定义23事件解决时间记录事件状态为“已解决”的时间（系统自动产生）24处理是否超时参见“处理是否超时”定义（系统自动产生）25涉及第三方支持XXX和第三方集成商名称26关联配置项记录出现故障的线路编号或者CPE设备编号27关联的问题单号记录由事件引发问题时，关联的问题单号28关联的变更单号记录由事件引发变更时，关联的变更单号29事件结束代码参见“事件结束代码”定义30事件关闭时间记录事件状态为“结束”的时间（系统自动产生）31重复事件标记标记为重复事件32对应告警ID事件如来自于监控系统告警，则填写对应告警的ID；若为用户自动上报，此处为空不填33用户满意度用户对事件处理的满意程度。分值从5分至1分，分别对应非常满意、比较满意、一般，不太满意及很不满意序号信息项说明34用户反馈信息用户对事件处理过程及结果的意见或建议35附件信息事件相关附件信息IT运维事件单（含事件、信息咨询、服务请求）事件单编号（示例200708220001）受理事件基本信息受理时间2007年月日时分受理人用户所属部门申报人申报人电话申报人EMAIL申报方式电话邮件工作台现场其他受理人根据事件形成事件信息服务分类故障问题改进咨询业务需求投拆其他桌面终端类PC机故障局域网故障软件故障外设故障基础设施类硬件故障操作系统/DB/系统软件故障网络故障机房环境故障空调、UPS等事件分类应用系统类可用性响应速度功能性易用性（应用系统列表选择）影响度报障人员分类VIP1VIP2普通影响度单内部客户单部门2个部门以上影响度人员分类受影响人员分类单外部客户单营业部24个营业部4个营业部以上影响度序号信息项说明关键设备关键设备列表选择非关键设备未知影响度典型事件分类典型事件（列表选择）无对应典型事件事件描述事件影响度事件紧急度1危急5分钟2紧急高,30分钟）3紧急中,2小时4紧急低,4小时5普通4小时以上事件处理优先级事件完成计划时间受派人员处理人员记录响应时间月日时分处理人员服务方式电话EMAIL现场远程终端送修其它原因及故障分析解决办法是否需要发起技术问题处理是否去除）完成时间日时分用户反馈（用户填写）处理结果全部解决部分解决未解决满意度评价非常满意较满意满意不满意用户意见可选事件优先级升级记录序号信息项说明事件结束方式自动结束客户确认结束转为其它事件经理结束事件对应其它流程编号转为其它时填写）转为同工具其它流程（对应编号）转为NOTES其它流程（流程名称列表对应编号）最终事件分类（服务台填报）故障类型问题类型咨询类型需求类型投拆其他知识库评价有对应完善知识库知识库需完善无对应知识库322事件来源事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种表33事件来源事例来源描述电子邮件服务台通过电子邮件收到一个请求。电话服务台通过电话收到一个请求。服务台工具（HELPDESK）服务台通过WEB系统（流程管理平台）收到一个请求。来访用户直接到电脑部工作间找相关工程师报障主动监控服务台通过系统网络管理工具主动监控得到的请求。323事件性质事件性质用来表明事件的概要类型，具体可以包含以下几种表34事件性质请求类型描述事件出现对服务造成影响的不正常现象信息咨询对与业务或IT相关杂项信息（联系人、电话号码，状态查询等）的请求服务请求对外宣布的服务（不含新业务需求）324事件分类事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。当事件发生时，应该由服务台初步分析和定位事件的分类，一方面便于与历史事件/问题或者知识库的匹配，另一方面也便于选择合适的二线或者第三方进行分配。事件最终分类可由后续支持人员作进一步的确认，并在事件关闭前进行调整。事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为“子类”，第三级分类，称之为“条目”。XXX事件分类表分为三大类桌面类、网络类、系统类表35事件分类流程系统/类别模块/子类模块/子类说明使用部门典型事件二线责任人三线责任人四线责任人备注各应用系统名称填写基本原则客户化语言描诉处理该事件的工程师或职能小组应用系统的模块名称模块业务功能说明使用该模块的业务部门325事件优先级优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源。在XXX服务中，事件优先级可分为四级P1（最高）、P2（高）、P3（中）、P4（低）。为方便服务支持对于事件优先级的判断，XXX建议从事件影响程度和事件紧急程度两维来进行优先级定位。事件的影响程度主要是对事件发生的关键程度以及事件发生后的影响范围综合考虑得出。在XXX业务中，要考虑以下几个方面用户身份受影响用户数量和范围受影响设备受影响系统具体影响程度判定可直参考附件中的影响度判读资料。事件的紧急程度主要由事件本身是否涉及关键业务系统来进行判定，如事件涉及关键业务系统，则认为紧急程度较高，需要尽快恢复；如事件不涉及关键业务系统，则认为紧急程度较低，可优先处理紧急程度较高的事件。在XXX业务中，事件紧急程度定义具体如下表36事件紧急程度紧急度紧急度时间标准备注1危急30分钟2紧急（高）2小时3紧急（中）4小时4紧急（低）8小时5普通8小时以上结合事件发生时的影响程度和紧急程度，可以通过下表确定事件的优先级表37事件优先级矩阵影响度事件优先级高中低1危急123紧急度2紧急（高）2333紧急（中）3444紧急（低）3445普通444注对于用户上报的服务请求，一般建议按优先级为P4（低）进行处理。326事件时限在事件处理过程中，对于事件应有响应时间限制、分派时间限制和解决时间限制，以保证事件处理过程的高效执行。如果该事件的响应、一线分派、解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。响应时限指的是事件发生到在系统中登记所经过的时间；一线分派时限指事件登记时间到转给二线/第三方所经过的时间；解决时限指的是事件登记时间到事件状态变为“已解决”所经过的时间。在XXX业务中，不同的事件优先级对应了不同的响应时限、一线分派时限及解决时限，具体如下表38事件时限事件目标时间一线响应时间事件被分派并得到接受事件得到解决的时间备注优先级13分钟5分钟30分钟优先级25分钟10分钟2小时优先级310分钟20分钟4小时优先级410分钟30分钟8小时327事件状态事件状态代码表明事件所处的处理状态，事件状态如下表39事件状态状态代码描述待处理一个事件被记录或创建已分派一个事件已被分派给一线支持人员、二线支持人员或事件经理；受理中1线受理中15线受理中2线受理中3线受理中4线任何一个服务台1/15/2线支持人员或第三方（供应商、开发部）接受了事件并开始处理事件挂起事件信息不完整，或在某些情况下阻止事件受理员对事件进行处理，等待的原因为需要客户提供更详细的信息优先级为1、2必须由事件经理挂起不能联系到用户人员升级到供应商处理采购定单的批准不可抗拒力原因已解决为一个事件找到解决方案或变通方法已关闭事件经用户确认已关闭328事件结束代码事件结束代码说明了事件是在何种情况下关闭的，结束代码如下表310事件结束代码事件关闭代码描述成功事件被正常解决成功但有问题事件已通过变通方法解决掉，但是需要进行更进一步的根源分析。不能重现没有找到错误或不能重现故障操作错误用户错误（如操作错误、理解存在误差等）失败已知的错误、变通方法或已实施的变更失败，不能解决这个事件或问题33流程角色和职责定义331事件流程负责人事件管理流程负责人从宏观上监控流程，确保事件流程XXX服务团队范围内被正确的执行。随着业务需求和IT环境的改变，流程负责人必须定期或不定期进行流程分析、找出缺陷、进行改进，从而实现服务能力的可持续提升。职责定义确定管理流程的衡量指标确保事件流程能够取得管理层的参与和支持确保事件流程符合业务实际状况和业务发展战略总体上管理和监控流程，建立事件流程运行机制确保事件流程实用、有效、正确地执行保持与其他流程负责人的定期沟通专业技能理解内部和外部业务环境理解业务规划及发展战略理解用户需求充分理解业务相关IT政策、操作过程和标准流程的评估和设计能力良好的分析和规划能力理解事件管理流程理解服务水平承诺处事技能良好的矛盾管理技巧确定问题和趋势发现的能力良好的口头和书面表达能力工作主动性和领导能力决策能力332事件流程经理事件流程经理负责事件解决过程中的协调和监控，以及事件升级的判断以及升级过程中的具体执行或协调。职责定义监控事件流程运行状况负责对事件解决过程的资源协调，跟踪事件的解决进展当事件超时升级或重大事件升级时，负责或参与资源协调，解决事件确保和问题管理流程的有效合作基于事件处理状况，发现IT或业务相关的问题专业技能充分理解业务相关IT政策、操作过程和标准基本了解业务系统环境具有流程的知识了解用户需求分析技能理解服务水平承诺用户关系技能处事技能良好的口头和书面表达能力矛盾管理技巧监控和管理流程的能力谈判技巧确定问题和趋势发现的能力管理经验良好的团队工作能力333服务台支持人员（含1线、15线）用户的主要联系人，作为用户组织和服务团队之间的纽带。作为事件的整体负责人，负责创建事件单，并跟踪、协调事件的解决。职责定义按监控流程和规范进行主动监控工作，并对告警进行筛选和识别响应所有用户事件，包括通过电话、邮件、WEB等渠道的事件完整记录所有接收的事件信息，包括IT用户信息、事件描述、发生时间和地点等负责处理事先确定的服务请求为事件进行适当的分类、为事件分配优先级等属性使用知识库等手段对事件进行初步诊断和分析，尝试解决问题必要时联系供应商和现场服务人员，参与事件处理如果不能解决事件，应当将事件分配给合适的二线支持检查事件记录的处理进度，保持与用户的联系，适时通知事件处理状况与用户确认事件解决方案，关闭事件专业技能了解用户和供应商信息基本理解业务相关IT政策、操作过程和标准用户关系技巧服务的基本知识和技能沟通技巧分析诊断能力电话响应技能处事技能出色的口头和书面沟通能力（必要时多语种支持）客户至上的理念责任心承受压力的能力334二线支持人员二线支持人员具有某个领域的技术技能，负责对服务台无法解决的事件进行进一步快速有效的分析，提出解决方案以尽快恢复服务。职责定义验证事件的描述和处理状况，进一步收集相关信息根据专业技能和知识库等，确定并实施有效解决方案或临时变通方法必要时联系供应商和现场服务人员参与事件处理更新事件记录和解决方案，确保事件状态代码真实反映事件状态必要时与其他二线支持人员合作，确定解决方案或临时变通方法已解决的事件转回服务台，由服务台进行用户确认并关闭事件专业技能基本理解业务相关IT政策、操作过程和标准理解相关的操作过程和工作指导IT基础架构和操作环境中某一方面的较高的技术知识用户关系技能分析技能处事技能良好的口头和书面沟通能力基本的决策能力客户至上的理念承受压力的能力335三线支持人员在XXX的的三线为各职能小组组长，其主要职责是调度和安排复杂度较高的事件处理。鉴于其管理职能偏重，且各小组的技能要求出入很大，此处不再做具体要求。336四线支持人员四线支持人员是指除运维团队外的技术层面XXX可以调集的事件处理人员，包括开发人员业务单位对口人员供应商34流程概要设计流程概要设计是从逻辑层面对事件管理流程进行的描述总结，结合XXX具体情况，给出如下流程设计子流程判断结束或节点其他流程文档图31事件流程角色与流程总体对应流程图图32XXX事件管理流程概览事件管理概要设计流程说明序号步骤名称责任人说明1事件识别和记录服务台服务台人员通过监控系统进行主动监控，发现告警后对告警进行监控和跟踪，如识别确为故障，则通报相应用户，并同时在服务管理平台上登记一条事件记录进行跟踪和处理。服务台人员除主动发现事件外，也接受来自用户上报的故障以及各类服务请求。在充分搜集事件信息后，服务台人员在服务管理平台上登记一条事件记录进行跟踪和处理序号步骤名称责任人说明如果是一条重复事件，则新建该事件记录后，更新原有事件为“主事件”，并建立重复事件与原有事件的关联关系。2分类与初步支持服务台服务台人员对事件进行分类，并分配优先级。服务台应尝试解决事件，如果无法解决需及时升级到二线支持服务台人员找到解决方案或变通方法后，转313调查与诊断二线支持二线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决，必要时可联系第三方供应商协助处理。对于无法找到解决方案或者变通方法的事件，二线人员可转回服务台请求重新分派二线支持人员找到解决方案或者变通方法后，转314解决与恢复服务台/二线支持服务台或二线支持人员详细记录解决方案或变通方法如解决方案或变通方法涉及变更，则由服务台或二线支持人员发起变更请求（RFC），并对变更管理流程进行监控和跟踪5事件关闭服务台服务台人员对已解决的事件与用户进行确认如用户业务确认被恢复，则关闭事件事件必要时可由服务台人员提交至知识管理重大事件/变通方法解决事件/不成功解决的事件可由交由问题流程成为问题记录，进行深入分析35流程详细设计351事件检测与记录图33事件检测和记录详细流程说明如下序号步骤名称责任人说明11能否自行解决用户这里的用户包含业务用户和XXX内部IT人员自行处理解决后直接在服务管理平台关闭事件12识别和验证客户信息服务台服务台接受来自用户和监控系统上报的事件服务台对于用户的信息进行识别和记录服务台对用户上报事件进行相关信息收集13用户信息是否正确服务台确认用户身份，并核实相关信息在配置信息列表中修正相关用户和设备信息14新事件还是重复事件服务台判断事件是新事件还是重复事件若是新事件，则进入16若是重复事件，进入1515更新原有事件记录服务台更新原有事件记录为“主事件”，并设置原有事件与重复事件的关联关系完成设置后，进入1616记录事件服务台无论是用户还是监控系统上报的事件，经信息收集和核实后，应由服务台人员创建相应事件记录记录事件时，应对用户信息、故障描述进行填写，同时，应在配置管理数据库中查找并关联发生故障的配置项记录完毕后进入17352事件分类和初步支持图31事件分类和初步支持详细流程说明如下序号步骤名称责任人说明17确认事件类型服务台服务台在创建事件后，对事件性质即事件的类型进行划分故障/服务请求/咨询/投诉等服务请求性质的事件对应优先级建议设置为“低”18确定事件分类和优先级服务台服务台人员对事件的分类进行设置服务台人员基于事件影响程度和紧急程度设置事件的优先级具体确认参照事件优先级判读标准不同优先级事件对应其响应和解决时限不同19查找解决方案服务台服务台在事件或问题历史记录或知识库中查找是否有与当前事件匹配的解决方案或变通方法110是否有现成的解决方案/变通方法服务台是否找到现成的解决方案或变通方法。如找到，则转31如未找到，则转111进一步尝试解决111分派事件服务台服务台人员根据事件分类和二线人员的忙闲状态，合理选择一名二线支持人员进行事件单的转派分派事件前建议首先电话沟通，缩短二线人员对事件单的响应时间，提高事件的分派成功率112是否接受事件单二线支持二线支持人员在了解事件情况后，可依据自身能力和资源情况对是否接受事件单进行选择。如接受，则进入31如不接受，则进入113113写明原因二线支持二线支持人员如不接受事件单，应在事件单上注明原因，并提供下次分派的建议，供服务台人员参考。114重派单服务台、在接受二线支持人员拒绝派单原因后进行事件单的再序号步骤名称责任人说明事件经理次分派重派单超过3次的由事件经理参与进行分派353事件调查和诊断图32事件调查和诊断详细流程说明如下序号步骤名称责任人说明21信息收集和诊断服务台、二线支持二线支持人员接受来自112服务台分派的事件单二线支持人员基于事件单信息在事件、问题历史数据记录或知识记录中进行匹配二线支持人员在必要时对事件信息作进一步的收集。二线支持人员对事件进行分析诊断，可借助配置管理数据库中的线路或设备信息进行辅助分析诊断过程中如发生解决时间超时，系统应升级通报到事件经理处请求资源支持22找到解决方案/变通方法服务台、二线支持若找到解决方案或变通方法，则进入31进行实施若为找到解决方案或变通方法，则进入23判断是否重新派单23是否重新派单服务台二线支持服务台与二线人员一起判定是否需要请求重新派单如二线支持人员自身能力无法提供方案，且事件尚未超时，则应选择进入114请求重派单。否则，由该二线人员继续对事件进行标记失败提请服务台关闭。序号步骤名称责任人说明24标记失败服务台确认此次事件失败354事件解决和恢复图33事件解决和恢复详细流程说明如下序号步骤名称责任人说明31是否需要审批服务台/二线支持服务台人员找到解决方案或变通方法后，在事件单上应详细记录解决方案或变通方法信息二线支持人员找到解决方案或变通方法后，在事件单上应详细记录解决方案或变通方法信息服务台或二线支持依据解决方案或变通方法判断是否需要进行变更如需要进行表更，则进入32填写变更请求单（RFC），并将变更请求单转至变更管理流程进行计划和实施如无需进行变更，则进入33对方案进行实施32审批通过事件经理、服务台服务台与事件经理提交RFC给变更管理变更管理通过进入33，如审批未通过则进入110再次查找其他解决方案或进入21重新收集事件信息补充变更请求记录服务台或事件经理对变更过程进行监控和跟踪33沟通和实施解决方案/变通方法服务台/二线支持服务台或二线人员对事件的解决方案或变通方法进行实施如实施过程中事件超时，则应升级至事件经理处对资源进行协调和支持序号步骤名称责任人说明34方案得到客户认可用户判断此解决方案实施结果是否能接受，能则进行35记录、否则进入111重新派单进行处理35记录解决方案服务台/二线支持对经客户认可的事件处理结果进行记录36需要通知事件经理服务台/二线支持根据事件优先级判断是否需要将结果告知事件经理，原则上优先级1、2的事件都应该告知，不需告知直接进入41，告知进入3737通知事件经理服务台/二线支持将事件处理结果告知事件经理355事件关闭图34事件关闭详细流程说明如下序号步骤名称责任人说明41验证分类的正确性服务台服务台基于二线人员的反馈或历史记录，对事件的分类的正确性进行验证，必要时对分类进行调整42是否需要请用户关闭事件服务台服务台来判断此事件是否需要得到用户认可方能关闭，是进入43，否进入4643请求关闭事件服务台服务台在确认事件解决方案和变通方法等信息填写完整后，并确认方案已得到实施后，与用户联系，确认是否可以关闭事件44接受关闭请求用户与用