事件管理流程手册 事件件管理流流程设计计手册 文档信息项目名称：：项目编号：：项目经理：：项目阶段：：文档名称：：文档编号：：文档起草人人：起草日期：：当前版本编编号：版本日期：：相关文档：：分发名单来自 Frrom日 期/真/Emmaill给 To行 动*截止日期/真/Emmaill*：行动类类别：批批准，复复审，通通知，存存档，修修改，其其它（请请指明）版本记录版本号版本日期修改者说 明文件名 目 录1. 文档档介绍 51.1 文文档简介介 51.22 文档用用途 51.3 文文档结构构 51.4 术术语 62. 事件件管理流流程简介介 72.1 流流程基本本概念 72.2 流流程目的的 82.3 流流程范围围 92.4 流流程主要要内容 92.5 流流程业务务价值 103. 事件件管理流流程设计计 103.11 流程执执行原则则 103.1.11. 流程常常规原则则 103.1.22. 责任制制原则 113.1.33. 事件分分派原则则 113.1.44. 事件重重分派原原则 123.1.55. 重复/复发事事件原则则 123.1.66. 事件关关闭原则则 123.1.77. 事件通通报原则则 133.1.88. 事件升升级原则则 143.1.99. 流程关关联原则则 143.2 流流程相关关定义 153.2.11. 事件信信息项 153.2.22. 事件来来源 183.2.33. 事件性性质 193.2.44. 事件分分类 193.2.55. 事件优优先级 203.22.6.. 事件时时限 213.2.77. 事件状状态 223.2.88. 事件结结束代码码 223.3 流流程角色色和职责责定义 233.3.11. 事件流流程负责责人 233.3.22. 事件流流程经理理 243.3.33. 服务台台支持人人员（含含1线、1..5线） 253.3.44. 二线支支持人员员 263.3.55. 三线支支持人员员 263.3.66. 四线支支持人员员 263.4 流流程概要要设计 273.5 流流程详细细设计 293.5.11. 事件检检测与记记录 293.5.22. 事件分分类和初初步支持持 303.5.33. 事件调调查和诊诊断 323.5.44. 事件解解决和恢恢复 333.5.55. 事件关关闭 343.6 与与其他流流程的关关系 363.7 流流程衡量量指标及及报表 374. 附录录 384.1 事事件管理理流程相相关表格格 38图目录图 3 11 XXXX事件件管理流流程概览览 3图 3 22 事件件检测和和记录 3图 3 33 事件件分类和和初步支支持 3图 3 44 事件件调查和和诊断 3图 3 55 事件件解决和和恢复 3图 3 66 事件件关闭 3图 3 77 XXXX服务务管理流流程关系系图 3表目录表 3 11 事件升升级机制制 3表 3 22 事件信信息项 3表 3 33 事件来来源 3表 3 44 事件性性质 3表 3 55 事件分分类 3表 3 66 事件紧紧急程度度 3表 3 77 事件优优先级矩矩阵 3表 3 88 事件时时限 3表 3 99 事件状状态 3表 3 110 事件结结束代码码 3表 3 111 事件管管理KPPI列表表 3701. 文档介绍1.1 文档简介本文档『XXXX事事件管理理流程设设计手册册』,是XXXX信息技技术总部部（以下下简称XXXX）团团队制定定的事件件管理流流程文档档。
通过过制定该该流程，可可以帮助助XXXX信息技技术总部部团队对对主动监监控发现现以及用用户上报报的故障障和服务务请求进进行快速速响应和和快速处处理, 尽快恢恢复中断断或受影影响的用用户业务务通过过该流程程的规范范，可进进一步改改进XXXXITT服务向向用户提提供的服服务水平平和服务务质量,,确保用用户对服服务价值值的认同同和肯定定本文档是依依据目前前XXXX的IT服务务状况而而制定的的事件管理理流程,,进一步步的流程程更新将将移交由由XXXX服务团团队负责责1.2 文档用途本文档既是是本次ITT服务管管理项目目事件管管理流程程的交付付物,也可作为XXXX服务团团队进一一步改进进事件管管理流程程的蓝本本,读者对对象为与与事件管理理流程相相关的所所有管理理与技术人员员.本文档所描描述的流流程在IIT服务务管理中中有许多多作用,,列举如下下:q 减小突发事事件对业业务的影影响；q 最优化支持持资源，提提高工作作效率；；q 屏蔽错误事事件和服服务请求求；q 根据影响业业务轻重重缓急安安排资源源解决事事件，保保障有效效IT运营营；q 加强有形监监控和及及时反馈馈；q 提升用户对对服务的的认知度度和满意意度；q 提供管理信信息；1.3 文档结构本文档作为为XXXX事件管管理流程程设计手手册，主主要包含含针对XXXX服服务运营营中对用用户故障障及用户户请求处处理等相相关人员员及活动动的定义义和描述述。
各章章节中内内容概要要如下：：q 文档介绍主要对文档档的目的的、用途途及结构构进行简简要描述述，并就就文档当当中出现现的术语语进行了了说明q 事件管理流流程简介介主要对事件件管理流流程的基基本概念念、目的的和范围围进行了了介绍同同时简单单梳理了了事件管管理流程程中包含含的主要要活动内内容，最最后对事事件管理理流程对对组织及及用户的的业务价价值进行行了相关关阐述q 事件管理流流程设计计该部分为本本文档的的重点章章节在在该章节节中，首首先对事事件管理理流程的的相关执执行原则则和代码码进行了了描述；；其次，对对事件流流程相关关角色的的职责和和技能要要求进行行了说明明；基于于流程原原则和角角色定义义，进而而对事件件管理的的概要设设计流程程及详细细设计流流程进行行了充分分定义，并并给出了了事件管管理流程程的关键键衡量指指标，以以保证对对流程运运行的监监控、管管理和改改进q 附录与事件管理理流程相相关的附附属内容容，都将将在附录录中进行行补充说说明1.4 术语q 服务台在ITILL中， 服务台台从根本本上来说说提供了了用户和和IT部门门的唯一一接口此此项功能能常常通通过集中中的服务务台进行行体现服服务台的的根本目目的是提提供一线线支持，并并通过变变通方法法、解决决方案或或升级到到二线支支持等手手段帮助助用户恢恢复到正正常工作作状态。
q 事件管理ITIL流流程，是是负责解解决所有有的ITT事件、问问题和用用户请求求等的管管理流程程它的的目的是是尽快恢恢复被中中断或受受到影响响的ITT服务，所所以它的的特点往往往是以以解决表表征现象象为目的的，而不不在于查查找根本本原因q 问题管理ITIL流流程，是是负责对对事件进进行深入入分析，找找出根本本原因并并提供解解决方案案的管理理流程它的目的是主动防御，找出根本原因并对其根除，所以它与事件管理流程有显著的不同，以“治本”为最终目标q 变更管理ITIL流流程，是是负责对对生产环环境中支支持ITT服务的的各种基基础架构构设备和和应用系系统的变变更操作作进行记记录、分分类、评评估、计计划和协协调的流流程它它的目的的是在权权衡“风险”和“效率”的前提提下，对对变更操操作进行行有效的的控制，以以保证任任何变更更对ITT环境和和其所支支撑的IIT服务务的影响响最小q 发布管理ITIL流流程，是是负责对对应用系系统上线线过程的的全局管管理和控控制管管理范围围涉及测测试环境境、预发发布环境境和生产产环境等等，旨在在通过对对发布单单元的生生命周期期各个阶阶段的控控制保证证其安全全稳妥的的进入生生产环境境，而不不引入新新的缺陷陷或故障障。
q 配置管理ITIL流流程，配配置管理理负责描描述，跟跟踪和汇汇报所有有IT基础础架构中中的每一一个设备备或系统统的管理理流程这这些设备备和系统统被称为为配置元元素（CCI）每一一个CII必须有有效管理理，跟踪踪和控制制以支持持IT服务务和基础础设施成成功运行行q 配置管理数数据库（CMDB）是在配置管管理流程程中用于于记录企企业所有有IT相关关配置元元素信息息及其相相互关系系而建立立的数据据库q ITIL IT Innfraastrructturee Liibraary，是是英国政政府在119877年制定定的有关关IT服务务管理的的方法论论，现已已成为事事实上的的IT管理理标准2. 事件管理流流程简介介2.1 流程基本概概念事件管理流流程通过过提供服服务台作作为日常常IT支持持接口，由由IT支持持人员根根据流程程定义，快快速响应应和解决决IT用户户的服务务请求、突突发事件件、投诉诉反馈等等，最大大化地减减少突发发事件对对用户业业务活动动的影响响，最终终确保SSLA目目标的实实现事件管理流流程相关关的几个个关键词词汇解释释如下：：“日常支持持接口”：即服服务台，该该接口将将采用集集中服务务方式，向向所有IIT用户户提供唯唯一服务务窗口，按按照业务务需求，提提供相应应级别的的支持服服务。
IT用户户”：指的的是指XXXX服服务的使使用者，他他们使用用XXXX提供的的IT服务务来支持持相关日日常业务务IT支持持人员”：指的的是XXXX 服务团团队中IIT运维维和支持持人员的的统称，包包括一线线人员和和二线人人员等，可可能涉及及XXXX体系中中的相关关的开发发、支持持和运维维等团队队 “一线支支持”：指服服务台的的通用座座席，向向IT用户户提供一一线支持持服务，以以下提到到的服务务台人员员即一线线支持人人员1.5线线支持”：指机机房值班班人员（交交易系统统故障时时）和桌桌面维护护人员（桌桌面故障障时)，在桌桌面类和和机房交交易系统统相关事事件处理理过程中中实施IIT支持持服务；； “二线支支持”：主要要由各职职能小组组运维工工程师组组成，协协助服务务台一线线人员参参与事件件处理，相相对一线线支持人人员，二二线支持持具有更更高更专专业的技技能三线支持持”：指各各职能小小组组长长，在复复杂度较较高事件件或二线线支持无无法解决决事件时时负责协协调小组组内部人人员进行行事件处处理，三三线支持持更多的的强调管管理协调调职能四线支持持”：指XXXX开发发团队和和供应商商等事件”：：指XXXX在用用户ITT环境中中发现的的所有非非正常事事件，对对现有的的服务造造成影响响或中断断。
例如如：服务务器宕机机、网络络中断、应应用不可可用等从从来源上上来分，主主要包括括由信息息技术总总部内部部人员发发起的事事件以及及有用户户报告的的事件等等 “服务请请求”：指用用户提出出的关于于标准服服务、培培训、文文档、信信息等方方面的请请求，以以及针对对IT服务务使用的的咨询等等，通常常并没有有发生IIT组件件方面的的故障例例如：请请求培训训、寻求求咨询等等服务务请求是是一种特特殊类型型的事件件 “投诉反反馈”：指由由用户提提出的对对于ITT服务质质量或服服务方式式的抱怨怨或改进进建议，通通过服务务台统一一接受，并并进行相相应处理理2.2 流程目的事件管理流流程的主主要功能能是尽快快解决出出现的事事件，保保持业务务支撑系系统的稳稳定性，其其目的包包括： q 在成本允许许的范围围内尽快快恢复IIT服务务- 快速响应故故障及服服务请求求- 用户获获得帮助助- 沟通事件解解决的状状态 - 和用户确认认事件的的解决q 进行事件控控制- 按规范记录录事件- 就事件的优优先级，影影响度 进行分分类- 分析，诊断断，必要要时进行行升级- 监视并结束束事件- 进行定期服服务流程程回顾q 提供IT管管理信息息- 人力资源利利用情况况- 故障处理情情况- 支持效率2.3 流程范围XXX事件件流程管管理范围围包括所所有用户户与XXXX信息息技术总总部内部部的事件件、服务务请求和和投诉反反馈等。
其中：q 不包括现有有应用系系统新增增功能需需求q 不包括用户户对于信信息类设设备和应应用系统统的新需需求q 不包括新系系统开发发需求2.4 流程主要内内容事件管理流流程始于于事件的的接收和和报告，结结束于事事件的解解决该该流程包包含下述述主要内内容：q 事件接收和和记录 这个环节节是事件件管理流流程的起起点所所有监控控系统或或用户报报告的IIT 事事件必须须由此步步骤开始始此步步骤的目目的是在在事件发发生时快快速准确确地发现现，以协协助事件件的诊断断和解决决并通知知相关人人员在在此步骤骤中将会会收集创创建事件件记录所所需的信信息该该环节的的关键是是信息的的准确性性和完整整性q 分类和初步步支持对于每个事事件，需需要确立立优先级级和分类类若没没有现成成的解决决方案（Solution）或变通方法（Workaround），该事件将分配给合适的支持人员对此进行调查q 调查和诊断断 若支持人员员无法利利用现成成方案解解决事件件，可运运用自身身技能、知知识库、诊诊断工具具等进行行更加深深入的分分析以找找到恢复复服务的的临时措措施，必必要时可可调用多多名支持持人员以以寻求解解决措施施q 解决和恢复复支持人员实实施事件件的解决决方案，并并将解决决完毕的的事件转转回服务务台，由由服务台通通知用户户解决的的结果，并并得到用用户的确确认。
q 事件升级对于高优先先级的事事件，服服务台应应立即上上报给事事件经理理和相关关的管理理层，由由事件经经理决定定事件的的处理方方式，确确保其得得到最快快速的解解决当事件处理理超过预预期解决决时限，应应通知相相关处理理人员和和管理层层，以引引起处理理人员和和管理人人员的重重视和参参与q 结束事件当用户确认认事件解解决后，可可结束该该事件2.5 流程业务价价值XXX事件件管理流流程将在在多个方方面对“XXXX服务”业务产产生积极极作用，具具体表现现在以下下几个方方面：单一联系点点 – 通过在在团队内内部建立立服务台台，作为为与用户户沟通联联系的单单一联系系点对对用户方方发生的的故障及及用户上上报的服服务请求求进行快快速响应应和统一一管理，对对内部服服务支持持资源进进行合理理协调和和调配同同时，服服务台作作为ITT服务窗窗口，也也进一步步维护和和加强了了与用户户的关系系，为提提高用户户体验和和满意度度起到了了重要作作用用户业务尽尽快恢复复 – 通过合合理调配配资源，使使用知识识库等相相关支持持工具，对对不同级级别事件件选择各各自的解解决时限限，对用用户被中中断或受受影响的的业务进进行快速速响应和和恢复。
内部团队协协作加强强 – 为服务务支持团团队成员员分配角角色，并并清晰界界定职责责通过过事件管管理流程程将团队队成员进进行有效效的连接接，加强强内部团团队协作作和沟通通的有效效性和工工作效率率服务质量控控制和改改进 –– 通过过定期提提交流程程相关指指标和报报表至管管理层，以以实现对对流程的的监控和和管理，同同时为服服务质量量的改进进奠定基基础3. 事件管理流流程设计计3.1 流程执行原原则3.1.1. 流程常规原原则q 所有在流程程范围内内发生的的事件，都都应该被被完整准准确的记记录下来来，记录的的信息应应足够详详细，包包括事件件处理交交互过程程，详细细的解决决方案和和相关的的附件等等q 事件处理过过程中，在在需要寻寻求第三三方的情情况下，遵遵循下述述原则：：- 根据事件实实际处理理情况，各各二线或或三线支支持寻找找相应供供应商- 在供应商参参与解决决事件的的过程中中，事件当当前处理理责任仍保保留在二二线或三三线人员员处q XXX服务务支持体体系是由由信息技技术总部部全体人人员共同同组成的的，事件件的处理理过程中中必须加加强一线线和二线线的沟通通，沟通通的方式式优先使使用工具具（服务务管理平平台），在在需要的的时候必必须辅助助、短短信、邮邮件等手手段。
q 所有支持人人员优先先处理优优先级较较高的事事件q 对于来自于于服务台台转入的的事件（包包括故障障/服务请请求/咨询/投诉建建议），首首次接听听并并进行支支持的服服务台人人员负责责在系统统中进行行登记，并并由该员员工成为为该事件件在XXXX范围围内的责责任人，确确保事件件在在XXXX内内部得到到有效跟跟踪、解解决，并并将解决决结果反反馈给服服务台q 每月定期产产生事件件管理报报表，分分析服务务质量，对重大事件、重复发生的事件或者利用变通方法解决的事件，应提交问题管理流程进行问题定义分析和解决，并定期对这些事件进行评估跟踪q 建议每三个个月对流流程进行行回顾，包括流程执行效率和流程支持工具的有效性，以改进和优化事件管理流程3.1.2. 责任制原则则责任制原则则用来确确保每个个事件在在任何时时段都有有适当的的人员负负责q 由监控系统统上报的的事件，对对故障进进行识别别并在系系统中记记录的服服务台人人员是该该事件的的责任人人，确保保事件得得到有效效跟踪与与解决，并并负责事事件单的的关闭q 由用户话上报的的事件，首首次接听听并并进行支支持的服服务台人人员负责责在系统统中进行行登记，并并由该员员工成为为该事件件的责任任人，确确保事件件得到有有效跟踪踪与解决决，并负负责事件件单的关关闭q 服务台员工工换班时时，由服服务台值值班经理理进行事事件重新新分派，事事件责任任人也由由此转移移q 事件被服务务台人员员转至二二线人员员或第三三方后，二二线人员员/第三方方成为该该事件的的当前责责任人，但但服务台台人员仍仍然是事事件的整整体负责责人，有有义务对对事件处处理状态态按相应应策略进进行监控控，并及及时反馈馈给用户户，保证证事件的的处理过过程对用用户充分分透明。
3.1.3. 事件分派原原则事件分派原原则是确确保事件件在服务务目标时时段内处处理和解解决的重重要因素素q 服务台一线线支持人人员在规规定的一一线处理理时限内内，可按按情况选选择转给给其他在在值服务务台一线线支持人人员进行行处理q 服务台一线线支持人人员在规规定的一一线处理理时限内内不能解解决事件件时，原原则上根根据事件件分类分分派到相相应二线线支持人人员q 在特定情况况下，比比如二线线支持人人员的非非工作时时间内，服服务台一一线支持持人员在在派单后后利用电方式式通知二二线人员员相关事事宜q 桌面类故障障导致事事件直接接由1..5线桌桌面运维维小组进进行处理理q 开市期间交交易系统统故障，直直接由11.5线线机房座座席接听听处理q 服务台一线线支持人人员在判判断事件件为交易易系统故故障后，应应第一时时间按策策略通报报机房处处理，不不能明确确界定是是否是交交易系统统故障，亦亦应交机机房处理理3.1.4. 事件重分派派原则q 二线支持接接受服务务台分派派事件后后，如果果该事件件不属于于本人支支持范围围或者自自身能力力无法处处理，二二线人员员需首先先注明原原因，然然后将事事件返回回到服务务台，由服务务台重新新分配。
q 为提高事件件解决效效率，应应当尽量量减少事事件单重重分派的的几率事事件单的的重分派派次数不不应该超超过2次q 同组的事件件单再分分派不被被监控；；q 任何跨组的的事件单单再分派派将会报报告给事事件经理理；q 事件再分派派超过22次，事事件单将将升级给给事件经经理；3.1.5. 重复/复发发事件原原则重复事件 如果被报告告的事件件与某个个已经创创建且尚尚未解决决的事件件单症状状相同，则则该事件件被认为为是重复复的将会为此重重复的事事创建新新的事件件单，并并标注此此单为“重复”并与原原始事件件单相关关联原原始事件件将被标标注为“主事件件”复发事件（3天内同一用户，同一件事）如果报告的的事件与与已经关关闭的事事件相同同，该事事件被认认为是“复发”的事件件单这这意味着着为了解解决事件件而采取取的解决决措施失失败了（或或失败或或误再报报）此此时，应应当创建建一个新新的事件件单，复复制原始始事件单单的内容容，并说说明这是是复发的的事件3.1.6. 事件关闭原原则q 事件单的关关闭必须须由服务务台对应应1.55/1线线支持人人员完成成，但是是事件经经理可以以超越此此规则其其他人无无权关闭闭事件单单。
二线线支持人人员确定定解决方方案并解解决事件件后，必必须把事事件返回回到服务务台q 事件单的用用户可以以要求关关闭此事事件单，例例如：误误报、错错报事件件关闭闭事件单单由事件件单对应应一线支支持人员员负责q 服务台人员员关闭事事件前，需需获得客客户对解解决方案案的确认认和反馈馈q 关闭事件时时，根据据实际解解决情况况填写事事件的结结束代码码q 已关闭的事事件单不不允许重重开如如果事件件重复发发生，则则创建一一个新的的事件单单，并标标识为复复发事件件q 对于以“变变通方法法解决”或 “不能重重现”结束代代码关闭闭的事件件，需通通知问题题经理对对此类事事件进行行分析并并在必要要时生成成问题，通通过问题题流程对对问题进进行根源源分析并并提供解解决方案案 q 所有优先级级为最高高的事件件在关闭闭后，需需通知问问题经理理对此类类事件进进行分析析并在必必要时生生成问题题，通过过问题流流程对问问题进行行根源分分析并提提供解决决方案q 对于未及时时取得用用户反馈馈的已解解决事件件，系统统将对其其保留33日3日内服服务台人人员应至至少每天天主动与与用户联联系1次若若3日后仍仍未得到到用户有有效反馈馈，系统统将自动动关闭事事件，并并标识结结束代码码为“自动关关闭”字样。
3.1.7. 事件通报原原则对于监控系系统自动动发现的的告警信信息，服服务台人人员有责责任对其其进行识识别如如确认为为一条事事件，则则应首先先在第一一时间通通报相应应用户和和事件经经理，然然后在服服务管理理平台中中进行记记录通通报策略略具体如如下：通报方式q 用户工作时时间内采采用正式式的通知知方式进进行通报报q 用户非工作作时间采采用邮件件方式进进行通报报q 与用户通报报相关的的其他方方式参考考与用户户签订的的SLAA中的具具体定义义q 采用邮件的的方式通通知事件件经理；； q 如果由于用用户原因因第一时时间无法法完成通通报，应应首先在在服务管管理平台台中登记记一条事事件，并并置于“挂起”状态，相相关服务务台人员员有责任任在开单单后每隔隔5分钟主主动尝试试联系用用户3次若若3次后仍仍无法取取得联系系，则应应在事件件工作日日志中注注明“无法联联系到用用户”的字样样，并进进行后续续处理；；若3次内取取得联系系，则在在与用户户确认故故障后，取取消事件件“挂起”状态并并进行后后续处理理通报对象q 依照事件分分类表中中定义，向向用户部部门相关关人员通通报q 最后通报事事件经理理通报内容q 事件简要描描述q 可能受到影影响的用用户方业业务（或或范围）q 确认是否为为用户方方运维操操作导致致q 可能导致事事件的原原因q 预计解决事事件的时时间点3.1.8. 事件升级原原则制定升级原原则的目目的是确确保事件件在规定定的解决决时限内内能够及及时通知知相关技技术人员员和管理理人员，引引起足够够的重视视，协助助提供合合适的资资源，从从而快速速找到解解决事件件的方案案。
q 优先级为最最高的事事件，需需要立即即事件升升级，同同时，事事件继续续按事件件管理流流程进行行快速处处理q 超出规定的的响应或或者解决决时限之之后，需要立立即升级级事件，同同时，事事件继续续按流程程进行快快速处理理q 事件重复派派单超过过三次直直接升级级给事件件经理具体事件升升级机制制如下表表所示：：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件升升级机制制事件升级机机制小组技术经经理事件经理运维经理技术总部领领导公司领导优先级15分钟5分钟10分钟10分钟15分钟优先级21小时1小时1小时1.5小时时 优先级32小时2小时 优先级44小时4小时 3.1.9. 流程关联原原则q 和问题管理理的关联联- 一线支持在在解决事事件的过过程中，可可以通过过问题记记录查找找相应的的解决方方案- 通过分析事事件记录录，形成成问题，并并使该问问题与相相关事件件建立关关联- 通过事件单单和问题题单的关关联，服服务台人人员对问问题的解解决状况况进行跟跟踪并和和用户保保持沟通通- 对高优先级级事件或或者“变通方方法解决决”或“无法重重现”关闭的的事件，由由问题管管理流程程生成问问题进行行进一步步分析，直直到确定定根本原原因，得得到根本本解决。
事事件单和和问题应应建立关关联q 和变更发布布管理的的关联- 事件处理过过程中，如如果需要要对相关关IT组件件进行变变更（不不在标准准变更清清单内的的变更），必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理 高优先级事事件的处处理过程程中，如如果需要要对相关关IT组件件进行变变更，必必须按照照变更管管理的定定义，提提出紧急急变更请请求，变变更完成成后，补补录紧急急变更单单，并和和事件单单建立关关联q 和配置管理理的关联联- 事件处理过过程中，可可以通过过配置管管理查询询相关的的配置项项信息（尤尤其是关关系信息息）以及及该配置置项历史史上发生生的事件件、问题题或变更更，来帮帮助故障障的定位位- 事件处理过过程中，如如果可以以将故障障定位到到某个配配置项，则则必须将将事件单单与该配配置项关关联3.2 流程相关定定义3.2.1. 事件信息项项事件单必须须包含如如下事件件信息项项，XXXX服务务团队可可以在此此基础上上进行扩扩充：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件信信息项序号信息项说明1事件ID事件单流水水号（系系统自动动产生）2事件请求人人事件申报人人的信息息，包括括：姓名名、公司司、部门门、电子子邮件、办办公话、机3事件登记时时间在服务台生生成事件件记录的的时间（系系统自动动产生）4事件登记人人事件开单人人的信息息，包括括员工姓姓名、员员工IDD、联系系方式等等（系统统自动产产生）5事件发生时时间针对故障：：指的是是业务中中断的实实际时间间 （可能能早于登登记时间间，自动动设置或或者手工工填写）；；针对用用户请求求：缺省省值等于于登记时时间。
事件发生时时间必须须早于或或等于登登记时间间6事件发生地地点事件发生的的位置信信息7事件来源参见“事件件来源”定义8事件标题事件的简要要描述9事件描述对于整个事事件内容容的详细细描述10事件性质参见“事件件性质”定义11事件分类参见“事件件分类”定义12事件状态参见“事件件状态”定义13事件影响范范围参见“事件件影响范范围”定义14事件紧急程程度参见“事件件紧急程程度”定义15事件优先级级参见“事件件优先级级”定义16事件完成期期限对应每一个个事件优优先级，系系统根据据流程相相关定义义中“事件解解决时限限”自动设设定最终终的完成成期限 （系统统自动产产生）17事件分配工工作组被分配的支支持小组组18事件分配人人员被分配的支支持小组组内成员员19事件工作日日志反映事件处处理过程程的信息息 20解决方案//变通方方法事件解决方方案/变通方方法的描描述21事件解决人人事件的最终终解决人人22事件解决人人角色参见“事件件解决人人角色”定义23事件解决时时间记录事件状状态为“已解决决”的时间间（系统统自动产产生）24处理是否超超时参见“处理理是否超超时”定义（系系统自动动产生）25涉及第三方方支持XXX和第第三方集集成商名名称26关联配置项项记录出现故故障的线线路编号号或者CCPE设设备编号号27关联的问题题单号记录由事件件引发问问题时，关关联的问问题单号号28关联的变更更单号记录由事件件引发变变更时，关关联的变变更单号号29事件结束代代码参见“事件件结束代代码”定义30事件关闭时时间记录事件状状态为“结束”的时间间（系统统自动产产生）31重复事件标标记标记为重复复事件32对应告警IID事件如来自自于监控控系统告告警，则则填写对对应告警警的IDD；若为为用户自自动上报报，此处处为空不不填33 用户满意意度用户对事件件处理的的满意程程度。
分分值从55分至1分，分分别对应应非常满满意、比比较满意意、一般般，不太太满意及及很不满满意34用户反馈信信息用户对事件件处理过过程及结结果的意意见或建建议35附件信息事件相关附附件信息息IT运维事事件单（含事件、信信息咨询询、服务务请求）事件单编号号： （示示例：2200770822200001）受理事件基基本信息息■ 受理时时间2007年年 月 日 时 分■受理人 用户所属部部门 申报人 申报人话 申报人EMMAILL 申报方式□ □□邮件 □工作台台 □现场 □其他 受理人根据据事件形形成事件件信息服务分类□故障 □□问题 □改进 □咨询 □业务需需求 □投拆 □其他 事件分类桌面终端类类：□PC机故故障 □局域网网故障 □软件故故障 □外设故故障 基础设施类类：□硬件故故障 □操作系系统/DDB/系系统软件件故障 □网络故故障 □机房环环境故障障(空调、UUPS等等) 应用系统类类：□可用性性 □响应速速度 □功能性性 □易用性性 （应应用系统统列表选选择）影响度： 人员分类报障人员分分类□VIP11 □VIPP2 □□普通影响度： 受影响人员员分类□单内部客客户 □单部门门 □2个部门门以上影响度： □单外部客客户 □单营业业部 □2－4个营业业部 □4个营业业部以上上影响度： 关键设备□关键设备备(列表选选择) □非关键键设备 □未知影响度： 典型事件分分类□典型事件件（列表表选择） □无对应典型事件事件描述 事件影响度度 事件紧急度度□1-危急急(5分钟钟) □2-紧急急(高,300分钟）□□3-紧急急(中,2小时时) □4-紧急急(低,4小时时) □5-普通通(4小时时以上))事件处理优优先级 事件完成计计划时间间 受派人员 处理人员记记录响应时间 月 日日 时 分处理人员 服务方式□ □□Emaail □现场 □远程终终端 □送修 □其它原因及故障障分析：：解决办法：：是否需要发发起技术术问题处处理 □是 □□否 (去除除？）完成时间 日日 时 分用户反馈（用用户填写写） 处理结果 □全部解决决 □部分解解决 □未解决决满意度评价价 □非常满意意 □较满意意 □满意 □不满意意用户意见((可选) 事件优先级级升级记记录 事件结束方方式 □自动结束束 □客户确确认结束束 □转为其其它 □事件经经理结束束事件对应其其它流程程编号((转为其其它时填填写） □转为同工工具其它它流程（对对应编号号） □转为NOOTESS其它流流程（流流程名称称(列表)＋对应应编号）最终事件分分类（服服务台填填报） □故障类型型 □问题类型型 □咨询类型型 □需求类型型 □投拆 □其他 知识库评价价□有对应完完善知识识库 □知识库库需完善善 □无对应应知识库库 3.2.2. 事件来源事件来源代代码用来来标明事事件的提提出方式式，事件件来源可可以包括括以下几几种：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件来来源事例来源 描 述 电子邮件 服务台通过过电子邮邮件收到到一个请请求。
服务台通过过收收到一个个请求 服务台工具具（Helpp Deesk） 服务台通过过Webb系统（流流程管理理平台）收收到一个个请求 来访用户直接到到电脑部部工作间间找相关关工程师师报障主动监控服务台通过过系统网网络管理理工具主主动监控控得到的的请求 3.2.3. 事件性质事件性质用用来表明明事件的的概要类类型，具具体可以以包含以以下几种种：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件性性质请求类型 描 述 事件 出现对服务务造成影影响的不不正常现现象 信息咨询 对与业务或或IT相关关杂项信信息（联联系人、电号码码，状态态查询等等）的请请求 服务请求 对外宣布的的服务（不不含新业业务需求求） 3.2.4. 事件分类事件分类代代码用于于标识故故障或申申告的具具体原因因，由支支持人员员在处理理过程中中填写当当事件发发生时，应应该由服服务台初初步分析析和定位位事件的的分类，一一方面便便于与历历史事件件/问题或或者知识识库的匹匹配，另另一方面面也便于于选择合合适的二二线或者者第三方方进行分分配。
事事件最终终分类可可由后续续支持人人员作进进一步的的确认，并并在事件件关闭前前进行调调整事件的分类类层次设设计不超超过三层层，第一一级分类类，称之之为“类别”，第二二级分类类，称之之为“子类”，第三三级分类类，称之之为“条目”XXX事件件分类表表分为三三大类：：桌面类类、网络络类、系系统类表 Error! No text of specified style in document. Error! Bookmark not defined. 事件分分类流 程系统/类别别模块/子类类模块/子类类说明使用部门典型事件二线责任人人三线责任人人四线责任人人备 注 各应用系统统名称应用系统的的模块名名称模块业务功功能说明明使用该模块块的业务务部门填写基本原原则：客客户化语语言描诉诉处理该事件件的工程程师或职职能小组组 3.2.5. 事件优先级级优先级是事事件管理理的一个个关键要要素，优优先级决决定处理理事件的的顺序及及所需的的资源在在XXXX服务中中，事件件优先级级可分为为四级：：P1（最最高）、P2（高）、P3（中）、P4（低）。
为方便服务支持对于事件优先级的判断，XXX建议从事件影响程度和事件紧急程度两维来进行优先级定位事件的影响响程度主主要是对对事件发发生的关关键程度度以及事事件发生生后的影影响范围围综合考考虑得出出在XXXX业业务中，要考虑以下几个方面：q 用户身份q 受影响用户户数量和和范围q 受影响设备备q 受影响系统统具体影响程程度判定定可直参参考附件件中的影影响度判判读资料料事件的紧急急程度主主要由事件本本身是否否涉及关关键业务务系统来来进行判判定，如如事件涉涉及关键键业务系系统，则则认为紧紧急程度度较高，需需要尽快快恢复；；如事件件不涉及及关键业业务系统统，则认认为紧急急程度较较低，可可优先处处理紧急急程度较较高的事事件在在XXXX业务中中，事件件紧急程程度定义义具体如如下：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件紧紧急程度度紧急度紧急度时间间标准备注1-危急30分钟 2-紧急（高高）2小时 3-紧急（中中）4小时 4-紧急（低低）8小时 5-普通8小时以上上 结合事件发发生时的的影响程程度和紧紧急程度度，可以以通过下下表确定定事件的的优先级级：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件优优先级矩矩阵事件优先级级影响度高中低紧急度1-危急1232-紧急（高高）2333-紧急（中中）3444-紧急（低低）3445-普通444注：对于用用户上报报的服务务请求，一一般建议议按优先先级为PP4（低低）进行行处理。
3.2.6. 事件时限在事件处理理过程中中，对于于事件应应有响应应时间限限制、分分派时间间限制和和解决时时间限制制，以保证证事件处处理过程程的高效效执行如果该事件的响应、一线分派、解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员响应时限指指的是事事件发生生到在系系统中登登记所经经过的时时间；一线分派时时限指事事件登记记时间到到转给二二线/第三方方所经过过的时间间；解决时限指指的是事事件登记记时间到到事件状状态变为为“已解决决”所经过过的时间间在XXX业业务中，不不同的事事件优先先级对应应了不同同的响应应时限、一一线分派派时限及及解决时时限，具具体如下下：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件时时限事件目标时时间一线响应时时间事件被分派派并得到到接受事件得到解解决的时时间备注优先级13分钟5分钟30分钟 优先级25分钟10分钟2小时 优先级310分钟20分钟4小时 优先级410分钟30分钟8小时 3.2.7. 事件状态事件状态代代码表明明事件所所处的处处理状态态，事件件状态如如下：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件状状态状态代码 描述 待处理一个事件被被记录或或创建已分派一个事件已已被分派派给一线线支持人人员、二二线支持持人员或或事件经经理； 受理中-11线受理中-11.5线线受理中-22线受理中-33线受理中-44线任何一个服服务台11/1..5/22线支持持人员或或第三方方（供应应商、开开发部）接接受了事事件并开开始处理理事件挂起事件信息不不完整，或或在某些些情况下下阻止事事件受理理员对事事件进行行处理，等等待的原原因为：： · 需要客户提提供更详详细的信信息· 优先级为11、2必须由由事件经经理挂起起· 不能联系到到用户人人员· 升级到供应应商处理理· 采购定单的的批准· 不可抗拒力力原因 已解决为一个事件件找到解解决方案案或变通通方法已关闭事件经用户户确认已已关闭 3.2.8. 事件结束代代码事件结束代代码说明明了事件件是在何何种情况况下关闭闭的，结结束代码码如下：：表 Error! No text of specified style in document. Error! Bookmark not defined. 事件结结束代码码事件关闭代代码 描 述 成功事件被正常常解决成功但有问问题事件已通过过变通方方法解决决掉，但但是需要要进行更更进一步步的根源源分析。
不能重现没有找到错错误或不不能重现现故障操作错误用户错误（如如操作错错误、理理解存在在误差等等）失败已知的错误误、变通通方法或或已实施施的变更更失败，不不能解决决这个事事件或问问题3.3 流程角色和和职责定定义3.3.1. 事件流程负负责人事件管理流流程负责责人从宏宏观上监监控流程程，确保保事件流流程XXXX服务务团队范范围内被被正确的的执行随随着业务务需求和和IT环境境的改变变，流程程负责人人必须定定期或不不定期进进行流程程分析、找找出缺陷陷、进行行改进，从从而实现现服务能能力的可可持续提提升职责定义::q 确定管理流流程的衡衡量指标标q 确保事件流流程能够够取得管管理层的的参与和和支持q 确保事件流流程符合合业务实际际状况和和业务发展展战略q 总体上管理理和监控控流程，建建立事件件流程运运行机制制q 确保事件流流程实用用、有效效、正确确地执行行q 保持与其他他流程负负责人的的定期沟沟通专业技能：：q 理解内部和和外部业业务环境境q 理解业务规规划及发发展战略略q 理解用户需需求q 充分理解业业务相关关IT政策策、操作作过程和和标准q 流程的评估估和设计计能力q 良好的分析析和规划划能力q 理解事件管管理流程程q 理解服务水水平承诺诺处事技能：：q 良好的矛盾盾管理技技巧q 确定问题和和趋势发发现的能能力q 良好的口头头和书面面表达能能力q 工作主动性性和领导导能力q 决策能力 3.3.2. 事件流程经经理事件流程经经理负责责事件解解决过程程中的协协调和监监控，以以及事件件升级的的判断以以及升级级过程中中的具体体执行或或协调。
职责定义：：q 监控事件流流程运行行状况q 负责对事件件解决过过程的资资源协调调，跟踪踪事件的解决进进展q 当事件超时时升级或或重大事事件升级级时，负负责或参参与资源源协调，解解决事件件q 确保和问题题管理流流程的有有效合作作q 基于事件处处理状况况，发现现IT或业业务相关关的问题题专业技能：：q 充分理解业业务相关关IT政策策、操作作过程和和标准q 基本了解业业务系统统环境q 具有流程的的知识q 了解用户需需求q 分析技能 q 理解服务水水平承诺诺q 用户关系技技能处事技能：：q 良好的口头头和书面面表达能能力q 矛盾管理技技巧q 监控和管理理流程的的能力q 谈判技巧q 确定问题和和趋势发发现的能能力q 管理经验q 良好的团队队工作能能力3.3.3. 服务台支持持人员（含含1线、1..5线）用户的主要要联系人人，作为为用户组组织和服服务团队队之间的的纽带作作为事件件的整体体负责人人，负责责创建事事件单，并并跟踪、协协调事件件的解决决 职责定义：：q 按监控流程程和规范范进行主主动监控控工作，并并对告警警进行筛筛选和识识别q 响应所有用用户事件件，包括括通过电、邮邮件、WWEB等等渠道的的事件q 完整记录所所有接收收的事件件信息，包包括：IIT用户户信息、事事件描述述、发生生时间和和地点等等q 负责处理事事先确定定的服务务请求q 为事件进行行适当的的分类、为为事件分分配优先先级等属属性q 使用知识库库等手段段对事件件进行初初步诊断断和分析析，尝试试解决问问题q 必要时联系系供应商商和现场场服务人人员，参参与事件件处理q 如果不能解解决事件件，应当当将事件件分配给给合适的的二线支支持q 检查事件记记录的处处理进度度，保持持与用户户的联系系，适时时通知事事件处理理状况q 与用户确认认事件解解决方案案，关闭闭事件专业技能：：q 了解用户和和供应商商信息q 基本理解业业务相关关IT政策策、操作作过程和和标准q 用户关系技技巧q 服务的基本本知识和和技能q 沟通技巧q 分析诊断能能力q 响应技技能处事技能：：q 出色的口头头和书面面沟通能能力（必必要时多多语种支支持）q 客户至上的的理念q 责任心q 承受压力的的能力3.3.4. 二线支持人人员二线支持人人员具有有某个领领域的技技术技能能，负责责对服务务台无法法解决的的事件进进行进一一步快速速有效的的分析，提提出解决决方案以以尽快恢恢复服务务。
职责定义：：q 验证事件的的描述和和处理状状况，进进一步收收集相关关信息q 根据专业技技能和知知识库等等，确定定并实施施有效解解决方案案或临时时变通方方法q 必要时联系系供应商商和现场场服务人人员参与与事件处处理q 更新事件记记录和解解决方案案，确保保事件状状态代码码真实反反映事件件状态q 必要时与其其他二线线支持人人员合作作，确定定解决方方案或临临时变通通方法q 已解决的事事件转回回服务台台，由服服务台进进行用户户确认并并关闭事事件专业技能：：q 基本理解业业务相关关IT政策策、操作作过程和和标准q 理解相关的的操作过过程和工工作指导导q IT基础架架构和操操作。