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