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