信息安全事件管理程序2.doc

【精品文档】如有侵权，请联系网站删除，仅供学习与交流信息安全事件管理程序2.精品文档.目录流程目的流程主要内容与其他流程的关系 关键角色、职责定义 服务台人员一线支持人员二线支持人员三线支持人员事件经理事件管理流程负责人 实际岗位与方案角色的映射流程执行原则常规原则流程关联原则所有权原则 再分派原则重复事件原则关闭原则升级原则人员岗位与角色落实原则工单流转原则.流程相关定义事件信息项事件性质事件来源（非必填项）事件所属系统类型事件分类事件优先级 事件响应时限和解决时限事件影响度事件状态事件结束代码事件解决人角色处理是否超时故障厂商用户反馈流程概要设计流程详细设计事件记录和分类 初始支持.一线尝试解决二线尝试解决紧急事件再确认 三线尝试解决记录解决方案细节 关闭事件.事件处理的监控紧急事件处理子流程 关键流程衡量指标1  流程目的 事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：q  在成本允许的范围内尽快恢复IT服务 Ø  快速响应服务请求（电话/Web/邮件等） Ø 用户在线获得帮助 Ø 沟通事件解决的状态 Ø 和客户确认事件的解决 进行事件控制 Ø  按规范记录事件 Ø  就事件的优先级，影响度 进行分类 Ø 分析，诊断，必要时进行升级 Ø  监视并结束事件 Ø 进行定期服务流程回顾 提供IT管理信息 Ø  人力资源利用情况 Ø 故障处理情况 Ø 支持效率 2 流程主要内容 事件(Incidents)是中断业务流程和降低IT服务质量的错误。事件管理流程帮助迅速解决这些事件，并最小化对于业务的不利影响。流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容： q  事件接收和记录 这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。 该环节的关键是信息的准确性和完整性。 q 分类和在线支持事件可以是一个申告/故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。 该环节的关键是必要的问题库支持和正确的事件分派。 q 调查和诊断 若支持人员无法解决事件，可运用问题库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。 q 解决和恢复 支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。 q  优先级为紧急的事件（紧急事件）和事件升级 对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。 当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。 q 结束事件 当用户确认事件解决后，此时可结束该事件，并在必要时更新问题库。 3  与其他流程的关系 q  和问题管理流程的关系 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。 q 和配置管理流程的关系 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。 q 和变更管理流程的关系 服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。 4  关键角色、职责定义 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。 事件管理流程主要分为以下几个职责/角色，分别简述如下： 4.1 服务台人员 服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师。 职责： q  在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告； q  完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等； q  为事件进行适当的分类、为事件分配优先级等属性； q  尝试使用知识库、初步诊断、分析相关信息等方式解决事件； q  如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理； q 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展； q 在事件处理过程中，催办事件处理进度 q  与用户确认事件解决方案及用户满意度反馈，关闭事件。 技能要求： q  熟悉技术平台和技术环境 q 较强的沟通能力 q 对简单的故障要有快速诊断和解决的能力 q 熟悉事件处理流程 人员按排建议： q  建议总公司服务台设置3人，分别负责受理桌面支持、核心业务系统类、非核心业务系统（包括其他应用系统、网络接入等）三大类事件。各分公司服务台设置2-3人受理各类事件。结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加。 4.2 一线支持人员 在ITIL体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。职责： q  决定需要采取何种措施恢复服务并实施有效的行动 q 必要时提供现场支持 q  根据优先级提供有效的解决方案 q  更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件 q  如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理 技能要求： q  熟悉技术平台和技术环境 q 较强的沟通能力 q  快速诊断事件和解决事件的能力 q 熟悉事件处理流程 人员按排建议： q  建议将分公司IT部门日常维护（包括硬件、软件、开发等）人员纳入一线支持中，按日常所管系统类型或设备类型划分到相应维护支持组中 q 分公司具有开发人员的，将开发人员纳入到应用系统支持组中 q 如分公司技术力量较强，可将一线支持各组根据技术能力划分为初级组、高级组 q 对于地市技术力量薄弱的，将地市人员按岗位技能纳入省级公司相应一线支持组中 q 对于地市技术力量较强的，可以考虑建立与省级公司平级的支持组 4.3 二线支持人员 二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。 职责:  q  进行事件的深入调查研究 q  根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动 q 必要时引入供应商的支持 q 及时提供有效解决方案 q  与其他二线小组合作，确定解决方案 q 已解决的事件转回服务台，由服务台关闭事件 技能要求： q  深厚的技术背景，对所维护范畴的技术深入掌握 q 熟悉事件处理流程 人员按排建议： q  主要由总公司各类业务系统及基础设施维护专家组成，技术力量较强的分公司的资深维护人员组成虚拟团队 4.4 三线支持人员 职责： q  从研发的角度进行事件的研究； q  根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等； q 及时提供有效解决方案； q  已解决的事件转回服务台，由服务台关闭事件。 技能要求： q  具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握； q 熟悉事件处理流程。 人员按排建议： q  由总公司开发人员及厂商代维人员组成，以及分公司开发力量较强人员组成虚拟团队 4.5 事件经理 事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。 职责： q  负责对重大、紧急事件的解决协调资源，保证故障的最终排除； q  当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进各类角色小组（如一线支持、二线支持）快速恢复正常服务； q  确保和问题管理流程经理的有效合作； q  确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。 技能要求： q  了解技术架构和技术环境； q  较强的口头表达能力和与用户沟通技巧q  处理纠纷的能力； q 深刻了解事件管理流程； q 较强的领导能力。 人员按排建议： q  由分公司及总公司主管应用系统维护工作的领导担任 4.6 事件管理流程负责人 事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。 职责： q  确定管理流程的衡量指标 q  确保事件流程能够取得管理层的参与和支持 q 确保事件流程符合cl实际状况和公司 IT发展战略 q  总体上管理和监控流程，建立事件流程实施、评估和持续优化机制 q 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高 技能要求： q 深刻理解事件管理流程； q 能够很好地理解业务对于事件管理的需求；  q 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行； q 具有很好的沟通技能，获得所需资源。 人员按排建议： q 由总公司IT部门领导担任 4.7 实际岗位与方案角色的映射共 47 页 - 9 - 分公司服务台 职责：负责受理各类事件。 岗位建议：建议各分公司服务台设置2-3人，结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加，建议对应岗位包括服务支持管理岗、应用管理岗、数据管理岗  一线支持 总公司一线支持 基础设施维护支持组 职责：负责总公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的基础维护工作 岗位建议：建议由总公司运行管理处、网络管理处负责各基础设施领域维护工作的技术人员担任 应用系统支持组 职责：负责总公司各类应用系统的维护支持工作 岗位建议：建议由负责各类应用系统维护工作的技术人员担任 桌面支持组 职责：负责总公司桌面支持工作 岗位建议：建议由代理服务处负责桌面维护工作的技术人员担任 分公司一线支持 （地市公司直接纳入分公司一线支持） 应用系统支持组 职责：负责分公司自有应用系统的支持工作以及对总公司应用系统的初始支持工作 岗位建议：建议由分公司负责各类应用系统维护工作的技术人员担任，建议对应岗位包括应用管理岗、地市分公司应用管理岗、数据管理岗、应用开发岗 基础设施维护支持组 职责：负责分公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的基础维护工作 岗位建议：建议由分公司信息技术部门各基础设施领域维护工作的技术人员担任，建议对应岗位共 47 页 - 10 - 包括设备管理岗、系统管理岗、安全岗、网络管理岗、运行维护岗、地市分公司设备管理岗 桌面支持组 职责：负责分公司桌面维护支持工作 岗位建议：由负责分公司桌面维护支持工作人员的担任，建议对应岗位包括服务支持管理岗  二线支持 总公司二线支持 应用系统运维专家组 职责：负责总公司应用系统包括核心应用系统及非核心应用系统的维护工作 岗位建议：由负责总公司各类应用系统资深技术人员担任，可以借调分公司相关人员，形成虚拟团队 基础设施维护专家组 职责：负责分公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的维护工作 岗位建议：由总公司运行管理处、网络管理处负责各领域维护工作的资深技术人员担任，可以借调分公司相关人员，形成虚拟团队 三线支持 总公司三线支持 应用系统开发组 职责：负责总公司应用系统包括核心应用系统及非核心应用系统的开发、修改、优化工作 岗位建议：由总公司核心运营开发处、销售客服开发处、管理决策开发处、电子商务开发处开发人员担任，可以借调分公司相关开发人员，形成虚拟团队 代维厂商组 总公司的厂家支持，可以细分为IBM、HP等 事件经理 总公司 职责：负责督导与监控总公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议：建议在总公司设置事件经理1人，由总公司应用管理处处长或副处长担任 共 47 页 - 11 - 分公司 职责：负责督导与监控分公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议：建议在各分公司设置事件经理1人，由分公司分管应用维护的领导担任 事件管理流程负责人 职责：负责确定管理流程的衡量指标，从宏观上监控流程，当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高 岗位建议：建议在总公司设置事件管理流程负责人1名，由总公司信息技术部相关领导担任 说明：一、二、三线分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置 5 流程执行原则 5.1 常规原则 q 所有IT和信息技术中心事件管理范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件 q 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别 q 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估 q 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程 5.2 流程关联原则 q 和问题管理的关联 Ø 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联） Ø 支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案 q 和变更管理的关联 Ø 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理 Ø 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联 q 和配置管理的关联 Ø 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位 Ø 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联 5.3 所有权原则 所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。 q 由IT用户申报的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭 5.4 再分派原则 事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组（服务台、一线支持、二线支持、三线支持），再由组内的支持人员处理。事件单的重分派次数不应该超过5次。 q 服务台将事件单分配给一线支持  q 一线支持可以将事件单重新分配给服务台，其他一线支持组（人员），二线支持组（人员） q 二线支持可以将事件单重新分配给服务台，一线支持组（人员），其他二线支持组（人员），三线支持组（人员） q 三线支持可以将事件单重新分配给服务台，二线支持组（人员），其他三线支持组（人员） 5.5 重复事件原则 重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。 q 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标 q 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一线支持人员负责重复事件的处理 5.6 关闭原则 由IT用户申报的事件单，关闭必须由服务台完成。 共 47 页 - 13 - q 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为"变通方法解决"。服务台负责和IT用户再次确认事件的解决 q 由IT用户认可获得关闭的事件单的结束代码为"成功解决"关闭 q 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为"不成功"，同时创建一个新的事件单重新分配到原处理人员继续处理  q 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单 q IT和信息技术中心的维护人员（一线、二线或三线）自行创建的事件单，本着"谁开单，谁负责关闭"的原则 q 监控平台产生的事件发送到服务台，由服务台分派，处理人员解决并关单 5.7 升级原则 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。 q 优先级为紧急的事件，服务台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过IT服务管理平台），由事件经理启动紧急事件处理流程 q 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理 q 服务台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理 5.8 人员岗位与角色落实原则 q 分公司技术力量较强的一线各维护支持组根据实际情况可按能力划分初级维护支持组和高级维护支持组，也可划分为一个组 q 如分公司具有开发人员，可将开发人员纳入到一线应用维护组 q 地市支持力量薄弱的，可将地市人员按岗位技能纳入省级公司相应支持组 q 地市支持力量较强的，可建立相对独立的支持维护组 q 目前流程中的各角色的分组可以进行扩充，由于此项目是全国性项目，在收集各分公司反馈后，由总公司进行统一协调配置 5.9 工单流转原则 q 分公司事件管理流程负责处理分公司自有应用系统及基础设施产生的事件以及对总公司应用系统及基础设施产生的事件进行尝试解决 q 总公司事件管理流程负责处理总公司应用系统及基础设施产生的事件 共 47 页 - 14 - q 分公司服务台负责受理分公司服务对象提交的所有请求，分公司服务台首先对用户提交的请求进行尝试解决，不能解决的通过服务目录自动提交到分公司一线相应支持组或人 q 总公司服务台负责受理总公司及成员公司提交的所有请求，总公司服务台首先对用户提交的请求进行尝试解决，不能解决的通过服务目录自动提交到总公司一线相应支持组或人 q 分公司一线负责处理分公司服务台转派的工单，对于属于分公司自有应用系统及基础设施产生的事件在一线内部处理解决，不能解决的将工单提交到分公司事件经理，由分公司事件经理协调资源处理；对于属于总公司应用系统及基础设施产生的事件首先在分公司一线内部尝试解决，不能解决的提交到二线相应支持组 q 总公司一线负责处理总公司服务台转派的工单，首先在一线内部尝试解决，不能解决的提交到二线相应专家组 q 二线负责处理分公司一线及总公司一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三线相应支持组 q 三线负责处理二线转派的工单，首先在三线内部尝试解决，对于三线不能解决的将工单提交到总公司事件经理，由总公司事件经理协调资源进行处理 q 对于公司信息技术部内部人员创建的工单，根据服务目录直接转派给本公司一线相应支持组组长，由组长视情况手工分派给本组人员进行处理 q 对于公司信息技术部内容人员创建的工单，关闭原则是谁创建工单，谁关闭工单6 流程相关定义 6.1 事件信息项 事件单必须包含如下事件信息项： 序号 信息项 是否必填 说明 事件记录和分类时填写： 1  请求人信息 是 事件申报人的信息，包括：登录名、姓名、分公司、部门、电子邮件、办公电话、手机（手工填写） 2  事件分类 是 参见“事件分类”定义 3  事件性质 是 参见“事件性质”定义 4  事件来源 是 参见“事件来源”定义 5 事件所属系统类型 是 参见“事件所属系统类型”定义 6 事件发生时间 是 针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写） 针对其他：缺省值等于登记时间 事件发生时间必须小于或等于登记时间 7 事件发生单位 是 树形目录（三级，总公司省公司地市） 共 47 页 - 15 - 序号 信息项 是否必填 说明 8  事件发生地点 否 事件发生的地点 （手工填写）描述性字段，不做为日后数据索引、统计，默认为事件发生单位 9 事件简要简述 是 事件的简要描述（手工填写） 10  事件详细描述 是 对于整个事件内容的详细描述（手工填写） 11  分配对象 是 被分配的技术支持组（按服务目录自动分派） 12  事件优先级 是 参见“事件优先级”定义 13  事件影响度 是 参见“事件影响度”定义 14  重复事件标记 否 标记为重复事件（手工填写） 15  关联配置项 否 记录出现故障的配置项代码（系统自动关联） 16  附件 否 上传附件 提交事件工单时，系统自动产生 17  事件ID 是 事件单流水号（系统自动产生） 18  建单人（受理人） 是 创建事件请求工单的记录人 19  登记时间 是 在服务台生成事件记录的时间（系统自动产生） 20  事件状态 是 参见“事件状态”定义 21  事件完成期限 是 对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生） 同14 关联配置项 否 记录出现故障的配置项代码（手工填写） 同15 附件 否 上传附件 一、二、三线尝试解决时填写： 22  业务恢复时间 是 针对故障的业务恢复实际时间（手工填写） 23  事件日志 是 反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生） 24  解决方案 是 事件解决方案的描述（手工填写） 25  故障厂商 是 记录故障厂商或集成商信息（手工选择） 26  重复事件标记 否 标记为重复事件（手工选择） 一、二、三线尝试解决时，系统自动产生 同19 事件状态 是 参见“事件状态”定义 共 47 页 - 16 - 序号 信息项 是否必填 说明 27  实际开始时间 是 记录事件状态到XX处理中的时间（系统自动产生） 28  事件解决人 是 事件的最终解决人（系统填写） 29  处理是否超时 否 参见“处理是否超时”定义（系统自动产生） 30  实际完成时间 是 记录事件最后解决的时间（系统自动产生） 31  历时 是 “实际完成时间”-“事件发生时间”（系统自动产生） 关闭工单时填写 32  用户反馈 是 参见“用户反馈”定义 33  事件结束代码 是 参见“事件结束代码”定义 34  事件解决人角色 是 参见“事件解决人角色”定义 35  事件关闭时间 是 记录事件被关闭的事件 6.2 事件性质 根据clIT支撑系统的业务要求和管理要求，定义如下四类事件： 编号 代码 描述 1 故障 指因IT支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障； 2 申告 与IT支撑系统相关的用户投诉，如信息技术部各处室等业务受理部门转来的因支撑系统问题引发的投诉 3 告警 监控平台自动产生的没有影响到系统正常使用的告警 4 咨询 指对系统操作、业务流程等方面的求助和询问共 47 页 - 20 - 系统        影响范围 全北京市或某一分公司 至少包括一个关键地区 多个非关键地区 一个非关键地区 块） 功能点C 高 高 6.7 事件响应时限和解决时限 在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。 响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间； 解决时限指的是事件状态从“已登记”到“已解决”经过的时间； 事件优先级对应的事件响应时限和解决时限参考下表（以下时间是24×7工作时间）： 编号 优先级代码 响应时限要求 解决时限要求 1 紧急 30分钟 4小时 2 高 1小时 8小时 3 中 4小时 48小时 4 低 8小时 72小时 事件发生时的通告定义 通知人员列表的用途：当IT服务管理平台收到事件时，自动按照表中的人员列表发出邮件或短信通知。 优先级别 通知人员列表 紧急 部门主管，相应事件经理，一、二、三线支持人员 高 部门主管，相应事件经理，一、二线支持人员 中 通知一、二线支持人员 低 通知一线支持人员 超出响应时间的通告定义 通知人员列表的用途：当IT服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。 优先级别 通知人员列表 事件响应时限 紧急 部门主管，相应事件经理，一、二、三线支持人员 30分钟 高 部门主管，相应事件经理，一、二线支持人员 1小时 共 47 页 - 21 - 中 部门主管，相应事件经理，一、二线支持人员 4小时 低 相应事件经理，服务台/一、二线支持人员 8小时 超出和即将超出解决时限的通告定义 通知人员列表的用途：当IT服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。 优先级别 通知时间 通知人员列表 事件解决时限 紧急 3小时 部门主管，相应事件经理，一、二、三线支持人员 4小时 4小时 部门主管，相应事件经理，一、二线支持人员 高 7小时 部门主管，相应事件经理，一、二线支持人员 8小时 8小时 部门主管，相应事件经理，一、二线支持人员 中 47小时 部门主管，相应事件经理，一、二线支持人员 48小时 48小时 部门主管，相应事件经理，一、二线支持人员 低 71小时 相应事件经理，一、二线支持人员 72小时 72小时 相应事件经理，一、二线支持人员 6.8 事件影响度 事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。 定义事件影响度等级的因素有： q 是否影响了核心业务 q 所影响的用户数 q 服务失效的影响范围和时长 事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。 事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。 编号 影响度代码 事件性质 描述 1 重大 故障 l 全国半数以上地区或关键地区的业务系统中断超过6小时； l 全国半数以上地区或关键地区的营业、综合帐务、客服中任一业务中断超过3小时； 全国半数以上地区或关键地区的综合结算业务处理中断超过24小时； 共 47 页 - 22 - 编号 影响度代码 事件性质 描述 半数以下地区全业务中断超过6小时； 申告 对人寿公司造成巨大损失产生严重后果和不良影响的； l 来自新闻媒体、消费者协会、国家行政机关的反映或申告； 2 严重 故障 全国半数以上地区或关键地区的业务系统中断大于10分钟、小于6小时； 全国半数以上地区或关键地区的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时； 全国半数以上地区或关键地区的综合结算业务处理中断大于2小时、小于24小时； l 半数以下地区全业务中断大于10分钟、小于6小时。 申告 数据错误导致产生大量的错单； l 涉及到高额问题的申告； l 用户在营业现场反映激烈 3 一般 故障 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障 申告 l 不属于重大申告和严重申告的用户申述 告警 不影响系统的监控平台告警 4 无 咨询  一般数据查询或者使用指导 6.9 事件状态 事件状态代码表明事件所处的处理状态，事件状态如下： 编号 代码 描述 1 已登记 新开事件记录或事件已创建 2 分配到服务台 事件已分配给服务台人员 3 服务台处理中 服务台人员已接手处理事件 4 分配到一线 事件已分配到一线支持，一线还未响应 5 一线处理中 一线支持人员已接手处理事件 6 分配到二线 事件已分配到二线支持，二线还未响应 7 二线处理中 二线支持人员已接手处理事件 8 分配到三线 事件已分配到三线支持，三线还未响应 9 三线处理中 三线支持人员已接手处理事件 10 已解决 事件已解决，支持人员联系用户验证事件是否获得解决 11 关闭 事件已关闭 事件状态变迁图用来标明：当一个事件单处于某个状态时，它可以去到的下一个状态。共 47 页 - 25 - 服务台处理中 否  分配到一线 否  一线处理中 否  分配到二线 是 二线支持人员无法处理该事件单，或者分配错误，将事件单重新分配给二线支持组或二线支持组内其他人员 二线处理中 否  分配到三线 是 二线支持人员将事件单分配给三线支持组或三线支持组内的其他人 三线处理中 否  已解决 是 二线支持找到解决方案或者变通方法，解决了分配的事件单 已关闭 否 q 当前状态为分配到三线状态时，可迁移的状态 状态 合法 描述 已登记 否  分配到服务台 否  服务台处理中 否  分配到一线 否  一线处理中 否  分配到二线 否  二线处理中 否  分配到三线 是 三线支持人员将事件单分配给三线支持组或三线支持组内的其他人 三线处理中 是 三线支持人员，接受分配的事件单，并开始处理 已解决  否  已关闭 否 q 当前状态为三线处理中状态时，可迁移的状态 状态 合法 描述 已登记 否  分配到服务台 否  服务台处理中 否  分配到一线 否  一线处理中 否  分配到二线 是  二线处理中 否  分配到三线 是 三线支持人员将事件单分配给三线支持组或三线支持组内的其他人 三线处理中 否  已解决 是 三线支持找到解决方案或者变通方法，解决了分配的事件单 已关闭 否 q 当前状态为已解决状态时，可迁移的状态 状态 合法 描述 已登记 否  分配到服务台 否  服务台处理中 否  分配到一线 否  一线处理中 否  分配到二线 否  二线处理中 否  分配到三线 否  三线处理中 否  已解决 否  已关闭 是 服务台在关闭事件单的时候，需要填写客户反馈和结束代码 共 47 页 - 26 - q 当前状态为已关闭状态时，可迁移的状态 不迁移至任何状态。 6.10 事件结束代码 事件结束代码说明了事件是在何种情况下关闭的，结束代码如下： 编号 代码 描述 1 成功解决 事件获得成功解决 2 变通方法解决 事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析 3 不成功 事件没有获得解决（用户没有认可解决时使用） 4 消失 事件自行消失 5 误报 不属于IT部门管理范围的事件 6 可忽略 如通过其他系统接口或监控系统提交的信息，经确认属于无效信息 6.11 事件解决人角色 事件解决人角色用来标明该事件单最终解决的角色是服务台还是一线、二线、三线。 编号 代码 描述 1 服务台 服务台最终解决事件 2 一线 一线支持最终解决事件 3 二线 二线支持最终解决事件  三线 三线支持最终解决事件  其他 自动消失的事件等 6.12 处理是否超时 每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。 编号 代码 描述 1 未超时 未超时 2 超时 事件已超出规定的解决时限 6.13 故障厂商 用来在事件单中记录是哪个厂商的设备或系统发生故障。 编号 厂商名称 1  3COM 2  AVAYA 3  BEA 共 47 页 - 27 - 4  BMC 5  Borland 6  CA 7  Cisco 8  EMC 9  HDS 10  HP 11  IBM 12  McDATA 13  Microsoft 14  NCR 15  NETAPP 16  Oracle 17  Quantum ATL 18  STK 19  SUN 20  Sybase 21  TERADATA 22  北电 23  东方通