ITIL-事件管理流程设计说明书.doc

目录目录 目录目录.4 4 1 1流程目的流程目的 .6 6 2 2流程主要内容流程主要内容 .6 6 3 3与其他流程的关系与其他流程的关系 .7 7 4 4关键角色、职责定义关键角色、职责定义 .7 7 4.1服务台人员 .9 4.2一线支持人员 .10 4.3二线支持人员 .11 4.4三线支持人员 .11 4.5事件经理 .12 4.6事件管理流程负责人 .12 4.7实际岗位与方案角色的映射 .13 5 5流程执行原则流程执行原则 .1414 5.1常规原则 .14 5.2流程关联原则 .15 5.3所有权原则 .15 5.4再分派原则 .15 5.5重复事件原则 .16 5.6关闭原则 .16 5.7升级原则 .16 5.8人员岗位与角色落实原则 .17 5.9工单流转原则 .17 6 6流程相关定义流程相关定义 .1717 6.1事件信息项 .17 6.2事件性质 .19 6.3事件来源（非必填项） .19 6.4事件所属系统类型 .20 6.5事件分类 .21 6.6事件优先级 .22 6.7事件响应时限和解决时限 .23 6.8事件影响度 .24 6.9事件状态 .25 6.10事件结束代码 .29 6.11事件解决人角色 .29 6.12处理是否超时 .29 6.13故障厂商 .30 6.14用户反馈 .30 。 精选资料，欢迎下载 7 7流程概要设计流程概要设计 .3131 8 8流程详细设计流程详细设计 .3333 8.1（100.1）事件记录和分类 .33 8.2（100.2）初始支持 .34 8.3（100.3）一线尝试解决 .35 8.4（100.4）二线尝试解决 .37 8.5（100.5）紧急事件再确认 .39 8.6（100.6）三线尝试解决 .40 8.7（100.7）记录解决方案细节 .42 8.8（100.8）关闭事件 .43 8.9（100.9）事件处理的监控 .44 8.10（）紧急事件处理子流程 .45 9 9关键流程衡量指标关键流程衡量指标 .4646 。 精选资料，欢迎下载 1流程目的流程目的 事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括： 在成本允许的范围内尽快恢复在成本允许的范围内尽快恢复 ITIT 服务服务 快速响应服务请求（电话/Web/邮件等） 用户在线获得帮助 沟通事件解决的状态 和客户确认事件的解决 进行事件控制进行事件控制 按规范记录事件 就事件的优先级，影响度 进行分类 分析，诊断，必要时进行升级 监视并结束事件 进行定期服务流程回顾 提供提供 ITIT 管理信息管理信息 人力资源利用情况 故障处理情况 支持效率 2流程主要内容流程主要内容 事件(Incidents)是中断业务流程和降低 IT 服务质量的错误。事件管理流程帮助迅速解决这些事件， 并最小化对于业务的不利影响。流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内 容： 事件接收和记录事件接收和记录 这个环节是事件管理流程的起点。所有用户或系统报告的 IT 事件必须由此步骤开始。此步骤的目的 是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事 件记录所需的信息。 该环节的关键是信息的准确性和完整性。 分类和在线支持分类和在线支持 。 精选资料，欢迎下载 事件可以是一个申告/故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决 方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。 该环节的关键是必要的问题库支持和正确的事件分派。 调查和诊断调查和诊断 若支持人员无法解决事件，可运用问题库、诊断工具等进行更加深入的分析以找到恢复服务的临时措 施，必要时可调用多名支持人员以寻求解决措施。 解决和恢复解决和恢复 支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并 得到用户的确认。 优先级为紧急的事件（紧急事件）和事件升级优先级为紧急的事件（紧急事件）和事件升级 对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层， 由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。 当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和 参与。 结束事件结束事件 当用户确认事件解决后，此时可结束该事件，并在必要时更新问题库。 3与其他流程的关系与其他流程的关系 和问题管理流程的关系和问题管理流程的关系 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以 及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。 和配置管理流程的关系和配置管理流程的关系 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。 和变更管理流程的关系和变更管理流程的关系 服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解 决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。 4关键角色、职责定义关键角色、职责定义 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一 。 精选资料，欢迎下载 系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同 时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满 足流程所需角色的基础上，为具体的实现提供足够的灵活性。 事件管理流程主要分为以下几个职责/角色，分别简述如下： 4.1 服务台人员服务台人员 服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支 持工程师。 职责：职责： 在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告； 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、 发生时间等； 为事件进行适当的分类、为事件分配优先级等属性； 尝试使用知识库、初步诊断、分析相关信息等方式解决事件； 如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理； 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展； 在事件处理过程中，催办事件处理进度 与用户确认事件解决方案及用户满意度反馈，关闭事件。 技能要求：技能要求： 熟悉技术平台和技术环境 较强的沟通能力 对简单的故障要有快速诊断和解决的能力 熟悉事件处理流程 人员按排建议：人员按排建议： 建议总公司服务台设置 3 人，分别负责受理桌面支持、核心业务系统类、非核心业务系统（包括 其他应用系统、网络接入等）三大类事件。各分公司服务台设置 2-3 人受理各类事件。结合分公 司实际情况，若事件单日常数量较多，服务台人数可以进行增加。 4.2 一线支持人员一线支持人员 在 ITIL 体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽 快恢复服务，并在必要时提供现场支持。 。 精选资料，欢迎下载 职责：职责： 决定需要采取何种措施恢复服务并实施有效的行动 必要时提供现场支持 根据优先级提供有效的解决方案 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理 技能要求：技能要求： 熟悉技术平台和技术环境 较强的沟通能力 快速诊断事件和解决事件的能力 熟悉事件处理流程 人员按排建议：人员按排建议： 建议将分公司 IT 部门日常维护（包括硬件、软件、开发等）人员纳入一线支持中，按日常所管 系统类型或设备类型划分到相应维护支持组中 分公司具有开发人员的，将开发人员纳入到应用系统支持组中 如分公司技术力量较强，可将一线支持各组根据技术能力划分为初级组、高级组 对于地市技术力量薄弱的，将地市人员按岗位技能纳入省级公司相应一线支持组中 对于地市技术力量较强的，可以考虑建立与省级公司平级的支持组 4.3 二线支持人员二线支持人员 二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出 解决方案并尽快恢复服务。 职责职责: : 进行事件的深入调查研究 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动 必要时引入供应商的支持 及时提供有效解决方案 与其他二线小组合作，确定解决方案 已解决的事件转回服务台，由服务台关闭事件 。 精选资料，欢迎下载 技能要求：技能要求： 深厚的技术背景，对所维护范畴的技术深入掌握 熟悉事件处理流程 人员按排建议：人员按排建议： 主要由总公司各类业务系统及基础设施维护专家组成，技术力量较强的分公司的资深维护人员组 成虚拟团队 4.4 三线支持人员三线支持人员 职责：职责： 从研发的角度进行事件的研究； 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等； 及时提供有效解决方案； 已解决的事件转回服务台，由服务台关闭事件。 技能要求：技能要求： 具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握； 熟悉事件处理流程。 人员按排建议：人员按排建议： 由总公司开发人员及厂商代维人员组成，以及分公司开发力量较强人员组成虚拟团队 4.5 事件经理事件经理 事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。 职责：职责： 负责对重大、紧急事件的解决协调资源，保证故障的最终排除； 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协 调资源，促进各类角色小组（如一线支持、二线支持）快速恢复正常服务； 确保和问题管理流程经理的有效合作； 确保正确和广泛地收集和分析事件数据，发现 IT 和业务相关的问题。 技能要求：技能要求： 了解技术架构和技术环境； 较强的口头表达能力和与用户沟通技巧； 。 精选资料，欢迎下载 处理纠纷的能力； 深刻了解事件管理流程； 较强的领导能力。 人员按排建议：人员按排建议： 由分公司及总公司主管应用系统维护工作的领导担任 4.6 事件管理流程负责人事件管理流程负责人 事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不 能够适应 cl 发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提 高。 职责：职责： 确定管理流程的衡量指标 确保事件流程能够取得管理层的参与和支持 确保事件流程符合 cl 实际状况和公司 IT 发展战略 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行 分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高 技能要求：技能要求： 深刻理解事件管理流程； 能够很好地理解业务对于事件管理的需求； 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行； 具有很好的沟通技能，获得所需资源。 人员按排建议：人员按排建议： 由总公司 IT 部门领导担任 4.7 实际岗位与方案角色的映射实际岗位与方案角色的映射 事件管理流程事件管理流程 角色角色角色细分角色细分说明说明成员成员 服务台总公司服务台 职责：负责受理办公管理、管理决策、核心运 营、销售客服、桌面支持五大类事件。 。 精选资料，欢迎下载 建议总公司服务台设置 3 人 分公司服务台 职责：负责受理各类事件。 岗位建议：建议各分公司服务台设置 2-3 人， 结合分公司实际情况，若事件单日常数量较多， 服务台人数可以进行增加，建议对应岗位包括 服务支持管理岗、应用管理岗、数据管理岗 基础设施维护 支持组 职责：负责总公司小型机、PC 服务器、存储设 备、网络交换机、路由器、防火墙、网络链路 等系统硬件及操作系统、中间件、数据库等系 统软件的基础维护工作 岗位建议：建议由总公司运行管理处、网络管 理处负责各基础设施领域维护工作的技术人员 担任 应用系统支持 组 职责：负责总公司各类应用系统的维护支持工 作 岗位建议：建议由负责各类应用系统维护工作 的技术人员担任 总公司一线支持 桌面支持组 职责：负责总公司桌面支持工作 岗位建议：建议由代理服务处负责桌面维护工 作的技术人员担任 应用系统支持 组 职责：负责分公司自有应用系统的支持工作以 及对总公司应用系统的初始支持工作 岗位建议：建议由分公司负责各类应用系统维 护工作的技术人员担任，建议对应岗位包括应 用管理岗、地市分公司应用管理岗、数据管理 岗、应用开发岗 一线支持 分公司一线支持 （地市公司直接纳入 分公司一线支持） 基础设施维护 支持组 职责：负责分公司小型机、PC 服务器、存储设 备、网络交换机、路由器、防火墙、网络链路 等系统硬件及操作系统、中间件、数据库等系 统软件的基础维护工作 。 精选资料，欢迎下载 岗位建议：建议由分公司信息技术部门各基础 设施领域维护工作的技术人员担任，建议对应 岗位包括设备管理岗、系统管理岗、安全岗、 网络管理岗、运行维护岗、地市分公司设备管 理岗 桌面支持组 职责：负责分公司桌面维护支持工作 岗位建议：由负责分公司桌面维护支持工作人 员的担任，建议对应岗位包括服务支持管理岗 应用系统运维 专家组 职责：负责总公司应用系统包括核心应用系统 及非核心应用系统的维护工作 岗位建议：由负责总公司各类应用系统资深技 术人员担任，可以借调分公司相关人员，形成 虚拟团队 二线支持总公司二线支持 基础设施维护 专家组 职责：负责分公司小型机、PC 服务器、存储设 备、网络交换机、路由器、防火墙、网络链路 等系统硬件及操作系统、中间件、数据库等系 统软件的维护工作 岗位建议：由总公司运行管理处、网络管理处 负责各领域维护工作的资深技术人员担任，可 以借调分公司相关人员，形成虚拟团队 应用系统开发 组 职责：负责总公司应用系统包括核心应用系统 及非核心应用系统的开发、修改、优化工作 岗位建议：由总公司核心运营开发处、销售客 服开发处、管理决策开发处、电子商务开发处 开发人员担任，可以借调分公司相关开发人员， 形成虚拟团队 三线支持总公司三线支持 代维厂商组 总公司的厂家支持，可以细分为 IBM、HP 等 事件经理总公司 职责：负责督导与监控总公司事件处理过程的 正常运转，接收事件的升级通知和处理超时通 。 精选资料，欢迎下载 知等 岗位建议：建议在总公司设置事件经理 1 人， 由总公司应用管理处处长或副处长担任 分公司 职责：负责督导与监控分公司事件处理过程的 正常运转，接收事件的升级通知和处理超时通 知等 岗位建议：建议在各分公司设置事件经理 1 人， 由分公司分管应用维护的领导担任 事件管理流 程负责人 职责：负责确定管理流程的衡量指标，从宏观 上监控流程，当流程不能够适应 cl 发展需要时， 流程负责人必须及时的对此进行分析、找出缺 陷、进行改进，从而实现可持续提高 岗位建议：建议在总公司设置事件管理流程负 责人 1 名，由总公司信息技术部相关领导担任 说明：说明：一、二、三线分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置 5流程执行原则流程执行原则 5.1 常规原则常规原则 所有 IT 和信息技术中心事件管理范围内发生的事件，都应该记录在 IT 服务管理平台中，记录的信息 应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件 所有 IT 支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有 优先处理级别 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理 会议对这些事件进行评估 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性， 以改进事件管理流程 5.2 流程关联原则流程关联原则 和问题管理的关联 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联） 支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案 。 精选资料，欢迎下载 和变更管理的关联 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更 单必须和事件单建立关联） ，变更完成后，继续事件单的处理 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变 更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联 和配置管理的关联 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问 题或变更，来帮助故障的定位 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联 5.3 所有权原则所有权原则 所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。 由 IT 用户申报的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责 事件单的关闭 5.4 再分派原则再分派原则 事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再 分派的几率。事件单可以分配到个人，或者分配到组（服务台、一线支持、二线支持、三线支持） ，再由组 内的支持人员处理。事件单的重分派次数不应该超过 5 次。 服务台将事件单分配给一线支持 一线支持可以将事件单重新分配给服务台，其他一线支持组（人员） ，二线支持组（人员） 二线支持可以将事件单重新分配给服务台，一线支持组（人员） ，其他二线支持组（人员） ，三线支持 组（人员） 三线支持可以将事件单重新分配给服务台，二线支持组（人员） ，其他三线支持组（人员） 5.5 重复事件原则重复事件原则 重复事件是指在一个较短时间段（通常 30 分钟内至 1 小时） ，由监控平台上报的同一个配置项上现象相 同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且 尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施 来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重 复事件单获得解决。 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标 。 精选资料，欢迎下载 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一线支持人员负责重复事件的 处理 5.6 关闭原则关闭原则 由 IT 用户申报的事件单，关闭必须由服务台完成。 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时， 结束代码为变通方法解决。服务台负责和 IT 用户再次确认事件的解决 由 IT 用户认可获得关闭的事件单的结束代码为成功解决关闭 已解决的事件单如果没有得到 IT 用户的认可，则首先关闭该事件单，结束代码修改为不成功，同时 创建一个新的事件单重新分配到原处理人员继续处理 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单 IT 和信息技术中心的维护人员（一线、二线或三线）自行创建的事件单，本着谁开单，谁负责关闭 的原则 监控平台产生的事件发送到服务台，由服务台分派，处理人员解决并关单 5.7 升级原则升级原则 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重 视，提供合适的资源，从而快速找到解决事件的方案。 优先级为紧急的事件，服务台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级 为紧急，则立即升级到事件经理，并通知相应的管理层（通过 IT 服务管理平台） ，由事件经理启动紧 急事件处理流程 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服 务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处 理 服务台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负 责协调升级处理 5.8 人员岗位与角色落实原则人员岗位与角色落实原则 分公司技术力量较强的一线各维护支持组根据实际情况可按能力划分初级维护支持组和高级维护支持 组，也可划分为一个组 如分公司具有开发人员，可将开发人员纳入到一线应用维护组 地市支持力量薄弱的，可将地市人员按岗位技能纳入省级公司相应支持组 地市支持力量较强的，可建立相对独立的支持维护组 目前流程中的各角色的分组可以进行扩充，由于此项目是全国性项目，在收集各分公司反馈后，由总 公司进行统一协调配置 。 精选资料，欢迎下载 5.9 工单流转原则工单流转原则 分公司事件管理流程负责处理分公司自有应用系统及基础设施产生的事件以及对总公司应用系统及基 础设施产生的事件进行尝试解决 总公司事件管理流程负责处理总公司应用系统及基础设施产生的事件 分公司服务台负责受理分公司服务对象提交的所有请求，分公司服务台首先对用户提交的请求进行尝 试解决，不能解决的通过服务目录自动提交到分公司一线相应支持组或人 总公司服务台负责受理总公司及成员公司提交的所有请求，总公司服务台首先对用户提交的请求进行 尝试解决，不能解决的通过服务目录自动提交到总公司一线相应支持组或人 分公司一线负责处理分公司服务台转派的工单，对于属于分公司自有应用系统及基础设施产生的事件 在一线内部处理解决，不能解决的将工单提交到分公司事件经理，由分公司事件经理协调资源处理； 对于属于总公司应用系统及基础设施产生的事件首先在分公司一线内部尝试解决，不能解决的提交到 二线相应支持组 总公司一线负责处理总公司服务台转派的工单，首先在一线内部尝试解决，不能解决的提交到二线相 应专家组 二线负责处理分公司一线及总公司一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三 线相应支持组 三线负责处理二线转派的工单，首先在三线内部尝试解决，对于三线不能解决的将工单提交到总公司 事件经理，由总公司事件经理协调资源进行处理 对于公司信息技术部内部人员创建的工单，根据服务目录直接转派给本公司一线相应支持组组长，由 组长视情况手工分派给本组人员进行处理 对于公司信息技术部内容人员创建的工单，关闭原则是谁创建工单，谁关闭工单 6流程相关定义流程相关定义 6.1 事件信息项事件信息项 事件单必须包含如下事件信息项： 序序 号号 信息项信息项 是否是否 必填必填 说明说明 事件记录和分类时填写： 1请求人信息 是事件申报人的信息，包括：登录名、姓名、分公司、部门、电子邮件、办公电话、 手机（手工填写） 2事件分类是参见“事件分类”定义 3事件性质是参见“事件性质”定义 4事件来源是参见“事件来源”定义 5事件所属系统类型是参见“事件所属系统类型”定义 。 精选资料，欢迎下载 序序 号号 信息项信息项 是否是否 必填必填 说明说明 6事件发生时间 是针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写） 针对其他：缺省值等于登记时间 事件发生时间必须小于或等于登记时间 7事件发生单位是树形目录（三级，总公司省公司地市） 8事件发生地点 否事件发生的地点 （手工填写）描述性字段，不做为日后数据索引、统计，默认为 事件发生单位 9事件简要简述是事件的简要描述（手工填写） 10事件详细描述是对于整个事件内容的详细描述（手工填写） 11分配对象是被分配的技术支持组（按服务目录自动分派） 12事件优先级是参见“事件优先级”定义 13事件影响度是参见“事件影响度”定义 14重复事件标记否标记为重复事件（手工填写） 15关联配置项否记录出现故障的配置项代码（系统自动关联） 16附件否上传附件 提交事件工单时，系统自动产生 17事件 ID是事件单流水号（系统自动产生） 18建单人（受理人）是创建事件请求工单的记录人 19登记时间是在服务台生成事件记录的时间（系统自动产生） 20事件状态是参见“事件状态”定义 21事件完成期限 是对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终 的完成期限 （系统自动产生） 同 14 关联配置项 否 记录出现故障的配置项代码（手工填写） 同 15 附件 否 上传附件 一、二、三线尝试解决时填写： 22业务恢复时间是针对故障的业务恢复实际时间（手工填写） 23事件日志 是反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等 信息（系统自动产生） 24解决方案是事件解决方案的描述（手工填写） 25故障厂商是记录故障厂商或集成商信息（手工选择） 。 精选资料，欢迎下载 序序 号号 信息项信息项 是否是否 必填必填 说明说明 26重复事件标记否标记为重复事件（手工选择） 一、二、三线尝试解决时，系统自动产生 同 19 事件状态 是 参见“事件状态”定义 27实际开始时间是记录事件状态到 XX 处理中的时间（系统自动产生） 28事件解决人是事件的最终解决人（系统填写） 29处理是否超时否参见“处理是否超时”定义（系统自动产生） 30实际完成时间是记录事件最后解决的时间（系统自动产生） 31历时是“实际完成时间”-“事件发生时间” （系统自动产生） 关闭工单时填写 32用户反馈是参见“用户反馈”定义 33事件结束代码是参见“事件结束代码”定义 34事件解决人角色是参见“事件解决人角色”定义 35事件关闭时间是记录事件被关闭的事件 6.2 事件性质事件性质 根据 clIT 支撑系统的业务要求和管理要求，定义如下四类事件： 编号编号代码代码描述描述 1故障 指因 IT 支撑系统错误或反映支撑系统部分或全部功能不能正常使用 的报障； 2申告 与 IT 支撑系统相关的用户投诉，如信息技术部各处室等业务受理部 门转来的因支撑系统问题引发的投诉 3告警监控平台自动产生的没有影响到系统正常使用的告警 4咨询指对系统操作、业务流程等方面的求助和询问 6.3 事件来源（非必填项）事件来源（非必填项） 事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种： 编号编号代码代码描述描述 1用户报告 用户或维护人员通过电话/邮件/传真报告的事件，服务台人员手 工创建事件单 2 内部 IT 人员开 单 IT 部门内部（一线/二线人员）提交的事件 。 精选资料，欢迎下载 编号编号代码代码描述描述 3监控系统 6.4 事件所属系统类型事件所属系统类型 根据目前信息技术中心支撑的应用系统和二级分类的划分定义事件所属系统类型，当事件发生时，应该 由服务台初步定位是哪个系统及二级分类出现问题，由一线进行进一步的明确。 业务系统分类业务系统分类子业务系统分类子业务系统分类简称简称 IT 服务管理系统ITSM 综合办公系统 办公管理 电子邮件系统请填写简称 电子商务网上招聘系统CORS 团体年金报表子系统GARS 财务计算机管理系统CLAF 集团财务计算机管理系统GCLAF cl 财务报表辅助系统EASY-REPORT 大中城市业绩考核分析系统CSIS 财务分析系统LIFA 基础率分析系统EAS 精算系统ATMS 每日业务快报系统ZHCX 统计信息系统TJXX 管理决策 审计系统AMS 综合业务处理系统 7 版CBPS7 集团综合业务处理系统 7 版NBPS 老业务处理系统OBPS 综合业务处理系统 8 版CBPS8 出单管理系统(七版)Printpro 档案影像管理系统CIMS 单证管理系统CVMS 打印管理系统CPMS 数据清理系统CLEANER 投连万能处理系统UBPS 团体年金核心业务处理系统GAPS 中介业务处理系统ABPS 统括业务处理系统UNITE 再保险系统RBPS 健康意外险系统HDPS 核心运营 互联网销售系统ISS 团体年金大客户支持子系统GACS 销售客服 团体年金报价子系统GAPS 。 精选资料，欢迎下载 团体年金销售支持系统GA3S 个人代理人管理信息系统AMIS 讲师管理系统TMIS 会员管理系统 2005 MMIS 个人代理人营销支持系统E-MSS 大客户支持系统anntsuport 网络查询系统netquery cl 呼叫中心系统CALL CENTER cl 短信系统SMS 其他其他系统类OTS 说明说明：第一层为”其它”的话，分公司可以对其子类可以扩充并提交到总公司，由总公司统一协调配置 6.5 事件分类事件分类 分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。 事件的分类层次设计不超过三层，第一级分类，称之为一级分类，第二级分类，称之为二级分类， 第三级分类，称之为三级分类。 一级分类一级分类二级分类二级分类三级分类三级分类 小型机（EPS） 服务器 SR PC 服务器（SPC） 磁盘阵列（RAD） 磁带库（TAP） 存储设备 RD 其他存储设备（OTR） 网络交换机（SWT） 交换机（SWT） 光纤交换机（FST） 路由器（RUT） 防火墙（FRW） VPN 网关（VPG） 安全网关（SEG） 链路（LNK） 网络 NW 其他网络设备（OTN） 台式机（COM） 笔记本（NTB） 字符终端（CTR） 终端 TR 图形终端（GTR） 打印机（PRT）外设及其他 PR 外设（DDV） 扫描仪（SCN） 。 精选资料，欢迎下载 绘图仪（DRW） 其他（SSO） 监控系统（） 机房（DCE） 消防系统 其他（OTR） 自主开发（SDV） 外包开发（ODV） 应用软件 APP 商业软件（FRD） 数据库（SDB） 操作系统（OPS） 中间件（SMD） 软件 SW 系统软件 SYS 其他（SYO） 管理文档（ADC） 技术文档（TDC） 维护文档（ODC） 工程文档（PDC） 产品购买合同（PUS） 文档 DC 合同 CRT 维护合同（MAN） 应用系统名称（API） 应用系