信息安全事件管理程序

信息安全事件管理程序 目录 流程目的 流程主要内容 与其他流程的关系 关键角色、职责定义 服务台人员 一线支持人员 二线支持人员 三线支持人员 事件经理 事件管理流程负责人 实际岗位与 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 角色的映射 流程执行原则 常规原则 流程关联原则 所有权原则 再分派原则 重复事件原则 关闭原则 升级原则 人员岗位与角色落实原则 工单流转原则. 流程相关定义 事件信息项 事件性质 事件来源(非必填项) 事件所属系统类型 事件分类 1 事件优先级 事件响应时限和解决时限 事件影响度 事件状态 事件结束代码 事件解决人角色 处理是否超时 故障厂商 用户反馈 流程概要设计 流程详细设计 事件记录和分类 初始支持. 一线尝试解决 二线尝试解决 紧急事件再确认 三线尝试解决 记录解决方案细节 关闭事件. 事件处理的监控 紧急事件处理子流程 关键流程衡量指标 1 流程目的 事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性， 其目的包括: 在成本允许的范围内尽快恢复IT服务 快速响应服务请求(电话/Web/邮件等) 用户在线获得帮助 2 沟通事件解决的状态 和客户确认事件的解决 进行事件控制 按规范记录事件 就事件的优先级，影响度 进行分类 分析，诊断，必要时进行升级 监视并结束事件 进行定期服务流程回顾 提供IT管理信息 人力资源利用情况 故障处理情况 支持效率 2 流程主要内容 事件(Incidents)是中断业务流程和降低IT服务质量的错误。事件管理流程帮助迅速解决这些事件，并最小化对于业务的不利影响。流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容: 事件接收和记录 这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。 该环节的关键是信息的准确性和完整性。 分类和在线支持 事件可以是一个申告/故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。 该环节的关键是必要的问题库支持和正确的事件分派。 调查和诊断 若支持人员无法解决事件，可运用问题库、诊断工具等进行更加深入的分析以 3 找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。 解决和恢复 支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。 优先级为紧急的事件(紧急事件)和事件升级 对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。 当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。 结束事件 当用户确认事件解决后，此时可结束该事件，并在必要时更新问题库。 3 与其他流程的关系 和问题管理流程的关系 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。 和配置管理流程的关系 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。 和变更管理流程的关系 服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。 4 关键角色、职责定义 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满 4 足流程所需角色的基础上，为具体的实现提供足够的灵活性。 事件管理流程主要分为以下几个职责/角色，分别简述如下: 4.1 服务台人员 服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师。 职责: 在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告; 完整记录所有接收的事件信息，包括:记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等; 为事件进行适当的分类、为事件分配优先级等属性; 尝试使用知识库、初步诊断、分析相关信息等方式解决事件; 如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理; 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展; 在事件处理过程中，催办事件处理进度 与用户确认事件解决方案及用户满意度反馈，关闭事件。 技能要求: 熟悉技术平台和技术环境 较强的沟通能力 对简单的故障要有快速诊断和解决的能力 熟悉事件处理流程 人员按排建议: 建议总公司服务台设置3人，分别负责受理桌面支持、核心业务系统类、非核心业务系统(包括其他应用系统、网络接入等)三大类事件。各分公司服务台设置2-3人受理各类事件。结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加。 4.2 一线支持人员 在ITIL体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。 5 职责: 决定需要采取何种措施恢复服务并实施有效的行动 必要时提供现场支持 根据优先级提供有效的解决方案 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理 技能要求: 熟悉技术平台和技术环境 较强的沟通能力 快速诊断事件和解决事件的能力 熟悉事件处理流程 人员按排建议: 建议将分公司IT部门日常维护(包括硬件、软件、开发等)人员纳入一线支持中，按日常所管系统类型或设备类型划分到相应维护支持组中 分公司具有开发人员的，将开发人员纳入到应用系统支持组中 如分公司技术力量较强，可将一线支持各组根据技术能力划分为初级组、高级组 对于地市技术力量薄弱的，将地市人员按岗位技能纳入省级公司相应一线支持组中 对于地市技术力量较强的，可以考虑建立与省级公司平级的支持组 4.3 二线支持人员 二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。 职责: 进行事件的深入调查研究 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动 必要时引入供应商的支持 及时提供有效解决方案 与其他二线小组合作，确定解决方案 已解决的事件转回服务台，由服务台关闭事件 技能要求: 6 深厚的技术背景，对所维护范畴的技术深入掌握 熟悉事件处理流程 人员按排建议: 主要由总公司各类业务系统及基础设施维护专家组成，技术力量较强的分公司的资深维护人员组成虚拟团队 4.4 三线支持人员 职责: 从研发的角度进行事件的研究; 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等; 及时提供有效解决方案; 已解决的事件转回服务台，由服务台关闭事件。 技能要求: 具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握; 熟悉事件处理流程。 人员按排建议: 由总公司开发人员及厂商代维人员组成，以及分公司开发力量较强人员组成虚拟团队 4.5 事件经理 事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。 职责: 负责对重大、紧急事件的解决协调资源，保证故障的最终排除; 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进各类角色小组(如一线支持、二线支持)快速恢复正常服务; 确保和问题管理流程经理的有效合作; 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。 技能要求: 了解技术架构和技术环境; 较强的口头表达能力和与用户沟通技巧 7 处理纠纷的能力; 深刻了解事件管理流程; 较强的领导能力。 人员按排建议: 由分公司及总公司主管应用系统维护工作的领导担任 4.6 事件管理流程负责人 事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。 职责: 确定管理流程的衡量指标 确保事件流程能够取得管理层的参与和支持 确保事件流程符合cl实际状况和公司 IT发展战略 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行 分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高 技能要求: 深刻理解事件管理流程; 能够很好地理解业务对于事件管理的需求; 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行; 具有很好的沟通技能，获得所需资源。 人员按排建议: 由总公司IT部门领导担任 4.7 实际岗位与方案角色的映射 8 共 47 页 - 9 - 分公司服务台 职责:负责受理各类事件。 岗位建议:建议各分公司服务台设置2-3人，结 合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加，建议对应 岗位包括服务支持管理岗、应用管理岗、数据管理岗 一线支持 总公司一线支持 基础设施维护 支持组 职责:负责总公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的 基础维护工作 岗位建议:建议由总公司运行管理处、网络管理处负责各基础设施领域维护工作的 技术人员担 任 应用系统支持 组 职责:负责总公司各类应用系统的维护支持工作 9 岗位建议:建议由负责各类应用系统维护工作的 技术人员担任 桌面支持组 职责:负责总公司桌面支持工作 岗位建议:建议由代理服务处负责桌面维护工作的技术人员担任 分公司一线支持 (地市公司直接纳入 分公司一线支持) 应用系统支持 组 职责:负责分公司自有应用系统的支持工作以及对总公司应用系统的初始支持工作 岗位建议:建议由分公司负责各类应用系统维护工作的技术人员担任，建议对应岗 位包括应用管理岗、地市分公司应用管理岗、数据管理岗、应 用开发岗 基础设施维护 支持组 职责:负责分公司小型机、PC服务器、存储设备、 网络交换机、路由器、防火墙、网络链路等系统 硬件及操作系统、中间件、数据库等系统软件的基础维护工作 岗位建议:建议由分公司信息技术部门各基础设施领域维护工作的技术人员担任， 建议对应岗位 10 共 47 页 - 10 - 包括设备管理岗、系统管理岗、安全岗、网络管理岗、运行维护岗、地市分公司设备管理岗 桌面支持组 职责:负责分公司桌面维护支持工作 岗位建议:由负责分公司桌面维护支持工作人员的担任，建议对应岗位包括服务支持管理岗 二线支持 总公司二线支持 应用系统运维 专家组 职责:负责总公司应用系统包括核心应用系统及非核心应用系统的维护工作 岗位建议:由负责总公司各类应用系统资深技术 人员担任，可以借调分公司相关人员，形成虚拟团队 基础设施维护 专家组 职责:负责分公司小型机、PC服务器、存储设备、 网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的 维护工作 岗位建议:由总公司运行管理处、网络管理处负责各领域维护工作的资深技术人员 11 担任，可以借调分公司相关人员，形成虚拟团队 三线支持 总公司三线支持 应用系统开发 组 职责:负责总公司应用系统包括核心应用系统及非核心应用系统的开发、修改、优化工作 岗位建议:由总公司核心运营开发处、销售客服开发处、管理决策开发处、电子商务开发处开发 人员担任，可以借调分公司相关开发人员，形成虚拟团队 代维厂商组 总公司的厂家支持，可以细分为IBM、HP等 事件经理 总公司 职责:负责督导与监控总公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议:建议在总公司设置事件经理1人，由总公司应用管理处处长或副处长担任 12 共 47 页 - 11 - 分公司 职责:负责督导与监控分公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议:建议在各分公司设置事件经理1人，由分公司分管应用维护的领导担任 事件管理流 程负责人 职责:负责确定管理流程的衡量指标，从宏观上监控流程，当流程不能够适应cl发展需要时， 流程负责人必须及时的对此进行分析、找出缺 陷、进行改进，从而实现可持续提高 岗位建议:建议在总公司设置事件管理流程负责人1名，由总公司信息技术部相关领导担任 说明:一、二、三线分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置 5 流程执行原则 5.1 常规原则 所有IT和信息技术中心事件管理范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应 足够详细，包括事件处理交互过程，详细的解决方案和相应的附件 13 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有 优先处理级别 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会 议对这些事件进行评估 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性， 以改进事件管理流程 5.2 流程关联原则 和问题管理的关联 所有优先级为紧急的事件在恢复服务后，都应该创建问题单(问题单必须和事件单建立关联) 支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案 和变更管理的关联 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变 更请求单(变更单 必须和事件单建立关联)，变更完成后，继续事件单的处理 紧急事件(优先级为紧急的事件，下同)的处理过程中，如果需要对系统进行变更，必须按照变更 管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联 和配置管理的关联 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题 或变更，来帮助故障的定位 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联 14 5.3 所有权原则 所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。 由IT用户申报的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责 事件单的关闭 5.4 再分派原则 事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组(服务台、一线支持、二线支持、三线支持)，再由组内的支持人员处理。事件单的重分派次数不应该超过5次。 服务台将事件单分配给一线支持 一线支持可以将事件单重新分配给服务台，其他一线支持组(人员)，二线支持组(人员) 二线支持可以将事件单重新分配给服务台，一线支持组(人员)，其他二线支持组(人员)，三线支持组 (人员) 三线支持可以将事件单重新分配给服务台，二线支持组(人员)，其他三线支持组(人员) 5.5 重复事件原则 重复事件是指在一个较短时间段(通常30分钟内至1小时)，由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源(系统、应用)现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一线支持人员负责重复事件的处 理 15 5.6 关闭原则 由IT用户申报的事件单，关闭必须由服务台完成。 共 47 页 - 13 - 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时， 结束代码为"变通方法解决"。服务台负责和IT用户再次确认事件的解决 由IT用户认可获得关闭的事件单的结束代码为"成功解决"关闭 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为"不成功"，同时 创建一个新的事件单重新分配到原处理人员继续处理 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单 IT和信息技术中心的维护人员(一线、二线或三线)自行创建的事件单，本着"谁开单，谁负责关闭" 的原则 监控平台产生的事件发送到服务台，由服务台分派，处理人员解决并关单 5.7 升级原则 16 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。 优先级为紧急的事件，服务台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为 紧急，则立即升级到事件经理，并通知相应的管理层(通过IT服务管理平台)，由事件经理启动紧急事件处理流程 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务 台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理 服务台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责 协调升级处理 5.8 人员岗位与角色落实原则 分公司技术力量较强的一线各维护支持组根据实际情况可按能力划分初级维护支持组和高级维护支持 ，也可划分为一个组 组 如分公司具有开发人员，可将开发人员纳入到一线应用维护组 地市支持力量薄弱的，可将地市人员按岗位技能纳入省级公司相应支持组 地市支持力量较强的，可建立相对独立的支持维护组 目前流程中的各角色的分组可以进行扩充，由于此项目是全国性项目，在收集各分公司反馈后，由总公 司进行统一协调配置 5.9 工单流转原则 分公司事件管理流程负责处理分公司自有应用系统及基础设施产生的事件以及对总公司应用系统及基 础设施产生的事件进行尝试解决 总公司事件管理流程负责处理总公司应用系统及基础设施产生的事件 17 共 47 页 - 14 - 分公司服务台负责受理分公司服务对象提交的所有请求，分公司服务台首先对用户提交的请求进行尝试 解决，不能解决的通过服务目录自动提交到分公司一线相应支持组或人 总公司服务台负责受理总公司及成员公司提交的所有请求，总公司服务台首先对用户提交的请求进行尝 试解决，不能解决的通过服务目录自动提交到总公司一线相应支持组或人 分公司一线负责处理分公司服务台转派的工单，对于属于分公司自有应用系统及基础设施产生的事件在 一线内部处理解决，不能解决的将工单提交到分公司事件经理，由分公司事件经理协调资源处理;对于属于总公司应用系统及基础设施产生的事件首先在分公司一线内部尝试解决，不能解决的提交到二线相应支持组 总公司一线负责处理总公司服务台转派的工单，首先在一线内部尝试解决，不能解决的提交到二线相应 专家组 二线负责处理分公司一线及总公司一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三线 相应支持组 三线负责处理二线转派的工单，首先在三线内部尝试解决，对于三线不能解决的 18 将工单提交到总公司事 件经理，由总公司事件经理协调资源进行处理 对于公司信息技术部内部人员创建的工单，根据服务目录直接转派给本公司一线相应支持组组长，由组 长视情况手工分派给本组人员进行处理 对于公司信息技术部内容人员创建的工单，关闭原则是‘谁创建工单，谁关闭工单’ 6 流程相关定义 6.1 事件信息项 事件单必须包含如下事件信息项: 序号 信息项 是否必填 说明 事件记录和分类时填写: 1 请求人信息 是 事件申报人的信息，包括:登录名、姓名、分公司、部门、电子邮件、办公电话、手机(手工填写) 2 事件分类 是 参见“事件分类”定义 3 事件性质 是 参见“事件性质”定义 4 事件来源 是 参见“事件来源”定义 5 事件所属系统类型 是 参见“事件所属系统类型”定义 6 事件发生时间 是 针对故障:指的是业务中断的实际时间 (可能早于登记时间，需要手工填写) 针对 19 其他:缺省值等于登记时间 事件发生时间必须小于或等于登记时间 7 事件发生单位 是 树形目录(三级，总公司,省公司,地市) 共 47 页 - 15 - 序号 信息项 是否必填 说明 8 事件发生地点 否 事件发生的地点 (手工填写)描述性字段，不做为日后数据索引、统计，默认为事件 发生单位 9 20 事件简要简述 是 事件的简要描述(手工填写) 10 事件详细描述 是 对于整个事件内容的详细描述(手工填写) 11 分配对象 是 被分配的技术支持组(按服务目录自动分派) 12 事件优先级 是 参见“事件优先级”定义 13 事件影响度 是 参见“事件影响度”定义 14 重复事件标记 否 标记为重复事件(手工填写) 15 关联配置项 否 记录出现故障的配置项代码(系统自动关联) 16 附件 否 上传附件 提交事件工单时，系统自动产生 17 事件ID 是 事件单流水号(系统自动产生) 18 建单人(受理人) 是 创建事件请求工单的记录人 19 登记时间 是 在服务台生成事件记录的时间(系统自动产生) 20 事件状态 是 参见“事件状态”定义 21 事件完成期限 是 对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 (系统自动产生) 同14 关联配置项 否 记录出现故障的配置项代码(手工填写) 同15 附件 否 上传附件 一、二、三线尝试解决时填写: 22 业务恢复时间 是 针对故障的业务恢复实际时间(手工填写) 23 事件日志 是 反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信 21 息(系统自动产生) 24 解决方案 是 事件解决方案的描述(手工填写) 25 故障厂商 是 记录故障厂商或集 成商信息(手工选择) 26 重复事件标记 否 标记为重复事件(手工选择) 一、二、三线尝试解决时，系统自动产生 同19 事件状态 是 参见“事件状态”定义 共 47 页 - 16 - 序号 信息项 是否必填 说明 27 实际开始时间 是 记录事件状态到XX处理中的时间(系统自动产生) 28 事件解 决人 是 事件的最终解决人(系统填写) 22 29 处理是否超时 否 参见“处理是否超时”定义(系统自动产生) 30 实际完成时间 是 记录事件最后解决的时间(系统自动产生) 31 历时 是 实际完成时间”-““事件发生时间”(系统自动产生) 关闭工单时填写 32 用户反馈 是 参见“用户反馈”定义 33 事件结束代码 是 参见“事件结束代码”定义 34 事件解决人角色 是 参见“事件解决人角色”定义 35 事件关闭时间 是 的事件 记录事件被关闭 6.2 事件性质 根据clIT支撑系统的业务要求和管理要求，定义如下四类事件: 编号 代码 描述 1 故障 指因IT支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障; 2 申告 与IT支撑系统相关的用户投诉，如信息技术部各处室等业务受理部门转来的因支撑系统问题引发的投诉 3 告警 监控平台自动产生的没有影响到系统正常使用的告警 4 咨询 指对系统操作、业务流程等方面的求助和询问 23 24 共 47 页 - 20 - 系统 影响范围 全北京市或某一分公司 至少包括一个关键地区 多个非关键地区 一个非关键地区 块) 功能点C 高 高 6.7 事件响应时限和解决时限 在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。 响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间; 解决时限指的是事件状态从“已登记”到“已解决”经过的时间; 事件优先级对应的事件响应时限和解决时限参考下表(以下时间是24×7工作时间): 编号 优先级代码 响应时限要求 解决时限要求 25 1 紧急 30分钟 4小时 2 高 1小时 8小时 3 中 4小时 48小时 4 低 8小时 72小时 事件发生时的通告定义 通知人员列表的用途:当IT服务管理平台收到事件时，自动按照表中的人员列表发出 邮件或短信通知。 优先级别 通知人员列表 紧急 部门主管，相应事件经理，一、二、三线支持人 员 部门主管，高相应事件经理，一、二线支持人员 中 通知一、二线支持人员 低 通知一线支持人员 超出响应时间的通告定义 通知人员列表的用途:当IT服务管理平台判断到响应时限已经超出，则自动按照表中 的人员列表发出邮件或短信通知。 优先级别 通知人员列表 事件响应时限 紧急 部门主管，相应事件经理，一、二、三线支持 人员 30分钟 高 部门主管，相应事件经理，一、二线支持人员 1小时 26 共 47 页 - 21 - 中 部门主管，相应事件经理，一、二线支持人员 4小时 低 相应事件经理，服务台/一、二线支持人员 8小时 超出和即将超出解决时限的通告定义 通知人员列表的用途:当IT服务管理平台判断到解决时限已经或即将超出，则自动按 照表中的人员列表发出邮件或短信通知。 优先级别 通知时间 通知人员列表 事件解决时限 紧急 3小时 部门主管，相应事件经理，一、二、三线支持 人员 4小时 4小时 部门主管，相应事件经理，一、二线支持人员 高 7小时 部门主管，相应事件经理，一、二线支持人员 8小时 8小时 部门主管，相应事件经理，一、二线支持人员 中 27 47小时 部门主管，相应事件经理，一、二线支持人员 48小时 48小时 部门主管，相应事件经理，一、二线支持人员 低 71小时 相应事件经理，一、二线支持人员 72小时 72小时 相应事件经理，一、二线支持人员 6.8 事件影响度 事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。 定义事件影响度等级的因素有: 是否影响了核心业务 所影响的用户数 服务失效的影响范围和时长 例如，初始等级为严重的故障会随事件影响度在事件的生命周期中是可以改变的， 着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决(服务恢复)后重新确认。 事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。 编号 影响度代码 事件性质 描述 1 重大 故障 全国半数以上地区或关键地区的业务系统中断超过6小时; 全国半数以上地区或关键地区的营业、综合帐务、客服中任一业务中断超过3小时; 全国半数以上地区或关键地区的综合结算业务处理中断超过24小时; 28 共 47 页 - 22 - 编号 影响度代码 事件性质 描述 半数以下地区全业务中断超过6小时; 申告 对人寿公司造成巨大损失产生严重后果和不良影响的; 来自新闻媒体、消费者协会、国家行政机关的反映或申告; 2 严重 故障 全国半数以上地区或关键地区的业务系统中断大于10分钟、小于6小时; 全国半数以上地区或关键地区的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时; 29 全国半数以上地区或关键地区的综合结算业务处理中断大于2小时、小于24小时; 半数以下地区全业务中断大于10分钟、小于6小时。 申告 数据错误导致产生大量的错单; 涉及到高额问题的申告; 用户在营业现场反映激烈 3 一般 故障 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障 申告 不属于重大申告和严重申告的用户申述 告警 不影响系统的监控平台告警 4 无 咨询 一般数据查询或者使用指导 6.9 事件状态 事件状态代码表明事件所处的处理状态，事件状态如下: 编号 代码 描述 1 已登记 新开事件记录或事件已创建 2 分配到服务台 事件已分配给服务台人员 3 服务台处理中 服务台人员已接手处理事件 4 分配到一线 事件已分配到一线支持，一线还未响应 5 一线处理中 一线支持人员已接手处理事件 6 分配到二线 事件已分配到二线支持，二线还未响应 7 二线处理中 二线支持人员已接手处理事件 8 分配到三线 事件已分配到三线支持，三线还未响应 9 三线处理中 三线支持人员已接手处理事件 30 10 已解决 事件已解决，支持人员联系用户验证事件是否获得解决 11 关闭 事件已关闭 事件状态变迁图用来标明:当一个事件单处于某个状态时，它可以去到的下一个状态。 共 47 页 - 25 - 31 服务台处理中 否 分配到一线 否 一线处理中 否 分配到二线 是 二线支持人员无法处理该事件单，或者分配错误，将事件单重新分配给二线支持组或二线支持组内其他人员 二线处理中 否 分配到三线 是 二线支持人员将事件单分配给三线支持组或三线支持组内的其他人 三线处理中 否 已解决 是 二线支持找到解决方案或者变通方法，解决了分配的事件单 已关闭 否 当前状态为‘分配到三线’状态时，可迁移的状态 状态 合法 描述 已登记 否 分配到服务台 否 服务台处理中 否 分配到一线 否 一线处理中 否 分配到二线 否 二线处理中 否 分配到三线 是 三线支持人员将事件单分配给三线支持组或三线支持组内的其他人 三线处理中 是 三线支持人员，接受分配的事件单，并开始处理 已解决 否 已关闭 否 当前状态为‘三线处理中’状态时，可迁移的状态 状态 合法 描述 已登记 否 分配到服务台 否 服务台处理中 否 分配到一线 否 一线处理中 否 分配到二线 是 二线处理中 否 分配到三线 是 三线支持人员将事件单分配给三线支持组或三线支持组内的其他人 三线处理中 否 已解决 是 三线支持找到解决方案或者变通方法，解决了分配的事件单 已关闭 否 当前状态为‘已解决’状态时，可迁移的状态 状态 合法 描述 32 已登记 否 分配到服务台 否 服务台处理中 否 分配到一线 否 一线处理中 否 分配到二线 否 二线处理中 否 分配到三线 否 三线处理中 否 已解决 否 已关闭 是 服务台在关闭事件单的时候，需要填写客户反馈和结束代码 共 47 页 - 26 - 当前状态为‘已关闭’状态时，可迁移的状态 不迁移至任何状态。 6.10 事件结束代码 事件结束代码说明了事件是在何种情况下关闭的，结束代码如下: 编号 代码 描述 1 成功解决 事件获得成功解决 2 变通方法解决 事件已通过变通方法或者临时措施获得解决，但是需要进行更进一 步的根源分析 33 3 不成功 事件没有获得解决(用户没有认可解决时使用) 4 消失 事件自行消失 5 误报 不属于IT部门管理范围的事件 6 可忽略 如通过其他系统接口或监控系统提交的信息，经确认属于无效信息 6.11 事件解决人角色 事件解决人角色用来标明该事件单最终解决的角色是服务台还是一线、二线、三 线。 编号 代码 描述 1 服务台 服务台最终解决事件 2 一线 一线支持最终解决事件 3 二线 二线支持最终解决事件 , 三线 三线支持最终解决事件 , 其他 自动消失的事件等 6.12 处理是否超时 每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超 过了解决期限。 编号 代码 描述 1 未超时 未超时 2 超时 事件已超出规定的解决时限 6.13 故障厂商 用来在事件单中记录是哪个厂商的设备或系统发生故障。 编号 厂商名称 1 3COM 2 AVAYA 3 BEA 34 共 47 页 - 27 - 4 BMC 5 Borland 6 CA 7 Cisco 8 EMC 9 HDS 10 HP 11 IBM 12 McDATA 13 Mic rosoft 14 NCR 15 NETAPP 16 Oracle 17 Quantum ATL 18 STK 19 SUN 20 Sybase 21 TERADATA 22 北电 23 东方通 24 中兴 25 华为 26 SYMANTEC 27 QUEST 28 REDHAT 29 BROCADE 30 锐捷 31 迈普 32 联想 33 网神 34 天融信 6.14 用户反馈 用来在事件单中记录用户对事件处理的满意程度。 编号 代码 描述 1 满意 用户对事件处理结果表示满意 2 一般 用户对事件处理结果既非满意也非不满意，处于中间感受 3 不满意 用户对事件处理结果表示不满意 7 流程概要设计 事件管理概要设计流程图如下: 35 号 步骤名称 责任人 说明 100.1 事件记录和分类 服务台 服务台对来自本部门服务范围内的用户和系统自动产生的事件进行 详细记录，其中包括申告/咨询/告警/故障 服务台负责在接收到事件后进行分类转发 对于初步判断为紧急的事件马上升级到本公司一线人员处理 100.2 初始支持 服务台 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无 法解决需及时升级到本部门一线支持 通过变更流程实施解决 对于需要通过变更解决的事件提出变更申请， 方案 不属于服务台职责范围的事件，立即分派到相应的本部门一线支持 100.3 一线尝试解决 一线支持 一线支持人员在接受到由本公司服务台派发的事件后，进行调查诊 断，尝试解决 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决 方案 36 共 47 页 - 29 - 序号 步骤名称 责任人 说明 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决 方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 不能解决的事件，转100.4二线尝试解决 100.4 二线尝试解决 二线支持 二线支持人员接受到来自总公司或各分公司一线支持的事件后，进行 调查诊断，尝试解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决 方案 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决 方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 不能解决的事件，转100.6三线尝试解决 100.5 紧急事件再确认 一线支持 一线支持人员接受到来自本部门服务台的紧急事件后，根据事件优先 级别 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 再次确认事件是否为紧急事件 37 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理， 转101紧急事件处理子流程 如不是，转100.3一线尝试解决，开始正常事件解决流程 100.6 三线尝试解决 三线支持 三线支持人员接受来自总公司二线支持派发的事件后，根据实际情 况，尝试找出并实施解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决 方案 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决 方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 指定时限内未能解决的事件，通告事件经理，由事件经理负责协调资 源 100.7 记录解决方案细节 服务台 一、二、三线支持 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案 并更新事件信息 针对故障，一、二、三线支持必须记录业务恢复时间 100.8 关闭事件 服务台 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功 解决或变通方法解决而关闭;否则，事件以不成功关闭，重新开事件 记录，并与原记录做关联，分派到原处理人员继续处理 38 服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否 准确 100.9 事件处理的监控 事件经理 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时 关注，并负责协调资源，保证事件的最终解决 当事件优先级为紧急时，应按照紧急事件处理流程处理紧急事件 101 紧急事件处理流程 事件经理 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程 8 流程详细设计 8.1 (100.1)事件记录和分类 流程描述如下: 序号 步骤名称 责任人 输入 输出 说明 100.1.1 从任务队列中接受事件 服务台 事件队列 需要处理的事件 事件任务队列的来源: 1. 监控系统自动发送的告警 2. 业务部门通过其他接口转发的事件单 3. IT用户通过服务台自助系统提交的事件单 服务台负责检查事件任务队列中的新事件单，开始处 理 39 是否为本部门职责范围, 服务台 事件单 服务台判断是否属于本部门职责范围: 是，进行事件分类的处理; 否，转100.1.3回复和关闭 100.1.2 新建事件 服务台 电话 /OA/传真 新建的事件记录 属于本中心(科室)职责范围，服务台负责创建新的事件单，填写详细情况描述， 不属于本部门处理的，直接电话回复。 事件单填写的详细内容如下: 1. 报告人姓名、联系电话、邮件、分公司、部门 2. 事件标题和描述 3. 必要的附件 4. 事件发生时间和地点 5. 事件来源和事件性质 共 47 页 - 31 - 40 6. 进行事件分类 7. 设定事件状态为“新建” 100.1.3 回复和关闭 服务台 误报的 事件单 关闭的事 件单 联系申报用户，说明情况，将该事件单状态置为“关闭”，结束代码为“误报”，保存 关闭 是否为重复事件, 服务台 事件记录 相应的处理流程 服务台根据重复事件原则，判断该事件单是否属于重 复事件: 是，转100.1.4重复事件处理; 否，事件分类的判断 100.1.4 重复事件处理 服务台 重复事件 在重复事件单的“重复事件标记”中记录正在处理的 事件单的流水号，状态置为“XX处理中”，保存退出。 事件性质区分, 服务台 事件性质 相应的处理流程 根据事件性质区分不同的处理流程: 告警/申告/咨询/故障，走100.1.5事件影响度、优先级设定 100.1.5 事件影响度、优先级设定 服务台 41 事件记录 确定了影 响度和优先级的事件 根据上报的事件描述，判断对业务的影响程度，并对照优先级代码表，确定事件的 优先级，以及初始确定的影响度 优先级为紧急吗, 服务台 事件优先级 相应的处理流程 服务台根据业务的影响程度和事件优先级判定的条 件，初步判断优先级别: 优先级为紧急，转100.5紧急事件再确认; 其他优先级否，转100.2初始支持 8.2 (100.2)初始支持 服务台 服务台其它流程 其它流程服务台技能可以 处理吗, 100.2.1尝试处理 100.2.2 分配到一线支持 解决了吗,To100.7 From100.1To100.4 Yes NoNo 发起变更吗,变更管 理流程 YesYes No 42 流程描述如下: 序号 步骤名称 责任人 输入 输出 说明 服务台技能可以处理吗, 服务台 事件记录 处理方式 服务台根据事件分类和事件描述，判断处理职责 是否在服务台: 是，转100.2.1尝试处理; 共 47 页 - 32 - 否，转100.2.2分配到一线支持 43 100.2.1 尝试处理 服务台 事件记录 服务台运用知识库和自身技能在规定的时限内 尝试解决，将事件状态置为“分配到服务台”，如果不能处理应及时将事件单分配 到一线支持 100.2.2 分配到一线支持 服务台 事件记录 分配到一线的事件单 选择本部门相关的一线处理组和处理人员分派，并将事件状态置为“分配到一线” 解决了吗, 服务台 将解决方案和用户沟通，判断是否可以解决; 可以解决，转100.7记录解决方案细节 无法解决，转100.2.2分配到一线支持 发起变更吗, 服务台 解决方案 N/A 服务台根据解决方案的内容和变更管理流程对变更范围的定义，判断是否需要发起 变更, 需要发起变更，创建变更请求，提交到变更 管理流程，解决方案的实施由变更管理完成 不需要发起变更，转100.7 8.3 (100.3)一线尝试解决 流程描述如下: 序号 步骤名称 44 责任人 输入 输出 说明 100.3.1 接受事件 一线支持 事件记录 一线处理中 如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内 容、排除本部门原因等内 共 47 页 - 33 - 分配 的事件单 容告知责任岗位; 如接受，则将事件状态置为“一线处理中” 优先级为紧急吗, 一线支持 N/A N/A 根据预先定义的优先级判别标准(优先级映射表)， 再次确定事件优先级是否为紧急, 优先级为紧急，判断是否能够独立处理, 优先级不等于紧急，转100.3.3尝试 找出解决方 45 案 能独立处理吗, 一线支持 N/A N/A 根据业务影响的严重程度和自身技能，判断自己能否 独立处理或需要通知事件经理启动紧急处理流程, 能独立处理，转100.3.3尝试找出解决方案 不能独立处理，转101紧急事件处理 流程 是否为重复事件, 一线支持 事件记录 相应的处理流程 一线支持根据重复事件原则，判断该事件单是否属于 重复事件: 是，转100.3.7重复事件处理; 否，事件分类的判断 100.3.7 重复事件处理 一线支持 重复事件 在重复事件单的“重复事件标记”中记录正在处理的 事件单的流水号，状态置为“XX处理中”，保存退出。 100.3.2 通知事件 经理和管理层 一线支持 优先级紧急的事件 事件通知 将事件单的优先级别修改为“紧急”，IT服务管理平 台自动将优先级为紧急的事件通知事件经理和管理层，并上报总公司 100.3.3 46 尝试找出解决方案 一线支持 事件记录 解决方案 一线工程师借助工具或运用自己技能尝试找出解决 方案，在解决事件的过程中根据需要联系供应商或其他一线人员共同参与制定解决 方案 100.3.4 供应商提 供解决方案 事件记录 解决方案 供应商和一线支持共同研究解决方案，提供解决方案 有解决方案吗, 一线支持 N/A N/A 一线支持判断能否在规定的时限内找到解决方案, 找到解决方案，根据解决方案的内容判断是否需 要发起变更, 不能找到，转100.3.6二线尝试解决 发起变更吗, 一线支持 解决方案 N/A 一线支持根据解决方案的内容和变更管理流程对变 更范围的定义，判断是否需要发起变更, 需要发起变更，创建变更请求，提交到变更管理 流程，解决方案的实施由变更管理完成 不需要发起变更，转100.3.5应用解决方案 发起问题吗, 一线支持 解决方案 N/A 一线支持根据解决方案的内容和问题管理流程对变更范围的定义，判断是否需要发 47 起问题, 共 47 页 - 34 - 需要发起问题，创建问题请求，提交到问题管理 流程，解决方案的实施由问题管理完成 不需要发起问题，转100.3.5应用解决方案 100.3.5 应用解决方案 一线支持 解决方案 解决方案 一线支持实施解决方案，实施解决方案的过程，需要和相关申告方共同确认解决方 案是否有效 100.3.6 分配到二线 一线支持 事件记录 分配到二线的事件单 一线支持选择相应的二线支持人员分派事件单，状态置为“分配到二线” 8.4 (100.4)二线尝试解决 流程描述如下: 48 序号 步骤名称 责任人 输入 输出 说明 100.4.1 接受事件分配 二线支持 事件记录 二线处理中的事件单 如属于分派错误，则转派到负责该业务的岗位，在转 派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位; 如接受，则将事件状态置为“二线处理中” 是否为重复事件, 二线支持 事件记录 相应的处理流程 二线支持根据重复事件原则，判断该事件单是否属于 重复事件: 是，转100.4.6重复事件处理; 49 共 47 页 - 35 - 否，事件分类的判断 100.4.6 重复事件处理 二线支持 重复事件 在重复事件单的“重复事件标记”中记录正在处理的 事件单的流水号，状态置为“XX处理中”，保存退出。 100.4.2 尝试找出解决方案 二线支持 事件记录 解决方案 二线工程师借助工具或运用自己技能尝试找出解决 在解决事件的过程中根据需要联系或其他二线支持人员供应商共同参与制定方案， 解决方案 100.4.3 供应商提 供解决方案 事件记录 解决方案 供应商和二线支持共同研究解决方案，提供解决方案 有解决方案吗, 二线支持 N/A N/A 一线支持判断能否在规定的时限内找到解决方案, 找到解决方案，根据解决方案的内容判断是否需 要相关经理确认, 不能找到，转100.4.5三线尝试解决 50 发起变更吗, 二线支持 解决方案 N/A 二线支持根据解决方案的内容和变更管理流程对变 更范围的定义，判断是否需要发起变更, 需要发起变更，创建变更请求，提交到变更管理 流程，解决方案的实施由变更管理完成 不需要发起变更，转100.4.4应用解决方案 发起问题吗, 二线支持 解决方案 N/A 二线支持根据解决方案的内容和问题管理流程对变 更范围的定义，判断是否需要发起问题, 需要发起问题，创建问题请求，提交到问题管理 流程，解决方案的实施由问题管理完成 不需要发起问题，转100.4.4应用解决方案 100.4.4 应用解决方案 二线支持 解决方案 解决方案 二线支持实施解决方案，实施解决方案的过程，需要和相关申告方共同确认解决方 案是否有效 100.4.5 分配到三线 二线支持 事件记录 分配到三线的事件单 二线支持选择相应的三线支持人员分派事件单，状态置为“分配到三线” 8.5 (100.5)紧急事件再确认 流程描述如下: 序号 51 步骤名称 责任人 输入 输出 说明 100.5.1 确认优先级 一线支持 事件记录 确认紧急的事件 一线支持根据该事件相关的业务或IT系统/设备的实际故障情况，并结合其他相关因 素，再次确定事件优先级 优先级为紧急 吗, 一线支持 N/A N/A 判断优先级,紧急吗, 是，通知事件经理，由事件经理负责紧急事 件子处理的处理，转101紧急事件处理子流程 否，转100.3一线尝试解决 可以独立处理 吗, 一线支持 紧急事件 根据业务影响的严重程度和自身技能，判断自己能否独立处理或需要通知事件经理 启动紧急处 理流程, 能独立处理，转100.3一线尝试解决 不能独立处理，转100.5.2通知相关管理层 和事件经理 100.5.2 通知相关管理 52 层和事件经理 一线支持 紧急事件 事件通知 通过IT服务管理平台通知(邮件、短信等)事件经理和相应的管理人员 8.6 (100.6)三线尝试解决 流程描述如下: 序号 步骤名称 责任人 输入 输出 说明 100.6.1 接受事件分配 三线支持 事件记录 三线处理中的事件单 则转派到负责该业务的岗位，在转 如属于分派错误， 派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位; 如接受，则将事件状态置为“三线处理中” 是否为重复事件, 三线支持 事件记录 相应的处理流程 三线支持根据重复事件原则，判断该事件单是否属于 重复事件: 是，转100.6.6重复事件处理; 否，事件分类的判断 100.6.6 重复事件处理 三线支持 重复事件 53 在重复事件单的“重复事件标记”中记录正在处理的 事件单的流水号，状态置为“XX处理中”，保存退出。 100.6.2 尝试找出解决方案 三线支持 事件记录 解决方案 三线工程师借助工具或运用自己技能尝试找出解决 方案，在解决事件的过程中根据需要联系供应商或其他三线支持人员共同参与制定 解决方案 100.6.3 供应商提 事件记录 解决方案 供应商和三线支持共同研究解决方案，提供解决方案 共 47 页 - 38 - 54 供解决方案 有解决方案吗, 三线支持 N/A N/A 三线支持判断能否在规定的时限内找到解决方案, 找到解决方案，根据解决方案的内容判断是否需 要相关经理确认, 不能找到，转100.6.2尝试找出解决方案 发起变更吗, 三线支持 解决方案 N/A 二线支持根据解决方案的内容和变更管理流程对变 更范围的定义，判断是否需要发起变更, 需要发起变更，创建变更请求，提交到变更管理 流程，解决方案的实施由变更管理完成 不需要发起变更，转100.6.4应用解决方案 发起问题吗, 三线支持 解决方案 N/A 三线支持根据解决方案的内容和问题管理流程对变 更范围的定义，判断是否需要发起问题, 需要发起问题，创建问题请求，提交到问题管理 流程，解决方案的实施由问题管理完成 不需要发起问题，转100.6.4应用解决方案 100.6.4 应用解决方案 55 三线支持 解决方案 解决方案 二线支持实施解决方案，实施解决方案的过程，需要和相关申告方共同确认解决方 案是否有效 解决了吗, 三线支持 N/A N/A 判断事件是否得到解决, 是，转到100.7记录解决方案细节 否，判断是否需要协调处理, 需要协调处理吗, 三线支持 N/A N/A 根据事件的处理状况判断是否需要其它资源介入, 是，转到100.6.5事件经理协调解决 否，转到100.6.2尝试找出解决方案 100.6.5 事件经理协调解决 事件记录 解决方案 三线支持 事件经理负责将事件通报到管理层，通过高层寻求更多的资源介入，共同商讨和制 定解决方案 8.7 (100.7)记录解决方案细节 流程描述如下: 序号 步骤名称 责任人 输入 输出 说明 100.7.1 记录详细 56 的解决方案 服务台 一线支持 二线支持 三线支持 事件记录 更新的事件记录 根据事件的处理状况填写事件信息项 1(填写“解决方案” 2(确定“事件分类”和“事件所属系统类型”是否正确 3(填写“结束代码” 4(对于故障，应填写“业务恢复时间”以及确定“故障 厂商” 5(确定“事件影响度”的等级是否正确 6(根据自己所处岗位填写“事件解决人角色” 7(对于故障和告警，应该明确是哪个配置项发生的，关联正确的配置项 8(填写事件的“实际完成时间”并将状态改为“已解决” 9(如果有自己处理的重复事件单，则简单填写重复事件单的信息项，状态改为“已解决” 一线支持和二线支持接到的由服务台分配的事件单，应该转回服务台，由服务台和用户确认关闭 8.8 (100.8)关闭事件 流程描述如下: 序号 步骤名称 责任人 输入 输出 说明 监控系统自动告警, 服务台 事件记录 事件记录 服务台判断是否是监控系统自动产生的告警; 57 是，转100.8.1更新事件状态 否，转100.8.2与用户处确认事件解决 100.8.1 更新事件状态及 结束代码，关闭事 件 服务台 已解决的事件记录 关闭的事件 更新事件记录，状态为“已关闭”，结束代码 根据实际处理结果或用户反馈填写; 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束 代码和该事件保持一致 100.8.2 与用户处确认事件解决 服务台 用户反馈 反馈结果 从事件请求人处确认所提供的解决方案是否有 效 是否解决, 服务台 判断是否解决方案是否有效, 是，转100.8.1 否，转100.8.3重开单处理 100.8.3 重开单处理 服务台 未解决的事件记录 58 新的事件记录 服务台将该事件单的的结束代码置为“不成功”，关闭保存; 创建一个新的事件单，事件信息可以复制，分 配到原处理人员处理，新事件单状态“分配到一线” 注:服务台应该和原处理人员沟通事件的确认结果和后续的处理方式,并通过将事件 单关联到新的事件单中 是服务台分派 一、二、三 如果是服务台分派的事件单，需要返回到服务 共 47 页 - 41 - 吗, 线支持 台，否则直接到100.8.4 100.8.4 更新事件状态及 结束代码，关闭事 59 件 一、二、三线支持 已解决的事件记录 关闭的事件 更新事件记录，状态为“已关闭”，结束代码 根据实际处理结果填写; 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束 代码和该事件保持一致 8.9 (100.9)事件处理的监控 流程描述如下: 序号 步骤名称 责任人 输入 输出 说明 100.9.1 事件队列的监控 事件经理 当前打开的事 件单服务台的 超时告警 事件经理可以从以下途径获取事件处理的信息 服务台系统自动发送的告警通知 查询服务台系统的当前处理中的事件列表 需要介入吗, 事件经理 60 事件经理根据处理时限和该事件对业务的影响程度，判断是否需要及时介入，帮助 协调资源解 决 需要介入，转100.9.2 不需要，则继续监控 100.9.2 召集资源协商解决 事件经理 告警事件 支持人员的电 话通知 解决方案 由于处理不及时而可能导致用户满意度下降的事件或疑难事件，事件经理负责召集 相应二线专家，共同商讨并制定解决方案，并实施解决方案 可以解决吗, 事件经理 如果解决，转100.8关闭事件 无法解决，转100.9.3升级到管理层解决 100.9.3 升级到管理层解决 事件经理 升级的事件记 录 解决方案 事件经理负责将升级事件通报到管理层，通过高 层寻求更多的资源介入，共同商讨和制定解决方案 61 共 47 页 - 42 - 8.10 (,,,)紧急事件处理子流程 制定各系统应急处理预案 为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面: 应急预案启动条件 应急处理小组负责人和成员联系名单和联系方式 应急处理步骤 应急信息通报 应急善后处理 应急保障措施(人员、培训、演习、场地等) 紧急事件处理子流程说明如下: 序号 步骤名称 说明 101.1 召集应急小组，协调应急会议 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报分公司人寿IT信息中心相关领导或总公司 101.2 判断是否属于应急预案中的事件, 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相 应系统的应急预案, 如果没有应急预案，则进入101.4组织相关厂商共同分析紧急事件，制 62 定处理方案并处理; 共 47 页 - 43 - 如果有应急预案，则进入101.3按照应急预案处理 101.3 按照应急预案处理 根据各系统制定的应急预案中的实施步骤，处理紧急事件 101.4 组织相关厂商共同分 析，制定处理方案并处理 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案，如 果需要总公司介入处理，则向总公司申请介入; 处理方案在实施前应得到应急小组和相关领导的认可; 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求 101.5 紧急事件解除确认, 在紧急事件处理方案实施后，应急小组、相关厂商和相关部门对紧急事件是否解除进行确认 紧急事件如果没有解除，则重新进入101.4组织相关厂商共同分析紧急 63 事件，制定处理方案并处理; 如果解除，则进入101.6紧急事件善后处理和总结分析 101.6 善后处理和通报客户方 紧急事件解除后，应急小组向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况，并将该信息汇报到总 公司 对于影响度为重大的紧急事件，必须通过服务台提交《重大事件报告》 紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析 9 流程样例 9.1 总公司内部 总部人员财务部门小王，财务分析系统在总部内部执行，财务小王电话总公司服务台人员财务分析系统无法使用，服务台人员记录事件信息，与小王沟通后确认是“管理决策,财务分析系统,报送问题”的问题，首先根据服务目录查询知识库，如果有匹配的解决方案，则按照解决方案处理，如果需要发起变更，则由服务台人员根据解决方案创建变更工单。如果未在知识库中查询到匹配的解决方案，则进行重复事件判断，如是重复事件，则关联重复事件工单号，并置事件状态“XX处理中”，保存退出，同时服务台人员告知小王可以查询XX工单号可以了解决事件处理进度。如果不是重复事件，则判断事件性质、优先级、影响度等，如果此事件为紧急事件则转派给一线支持进行再确认，如果不是紧急事件则进行尝试解决，并更新事件状态为“服务台处理中”，如果服务台人员解决了此事件，则更新工单信息，并与小王确认解决方案及满意度。如果经尝试未能解决则转派一线支持，系统自动将事件状态置为“分派到一线” 通过系统对服务目录判断将此工单分派给一线应用支持组中的财务支持小组组长，此时财务支持小组有四人，分别为A，B，C，D，财务支持小组组长根据实际情况手工将此工单派发给B，B接到服务台派发的关于财务分析系统的事件工单后，经判断属于本人处理范围之内，将事件状态置为“一线处理中”，对于服务台人员派 64 发的事件进行优先级确认，此工单非紧急事件，根据服务目录查询知识库，未查到匹配的解决方案，且不是重复事件，B通过借助工具或运用自己技能尝试找出解决方案，如果未找到解决方案则点击按钮，系统会根据服务目录自动转派给二线支持人员。 通过系统对服务目录判断将此工单分派给二线应用支持组中的财务支持小组组长，此时财务支持小组有三人，分别为E,F,G，财务支持小组组长根据实际情况将此工单派发给G，G进行分析后手工选择分派对象为F将此工单派发给F，F对此工单做进一步分析，经分析后属于防火墙设置问题，将此工单分派给二线基础设施组中的防火墙小组。系统根据F填写的服务目录查找到二线基础设施组中的防火墙小组，目前此小组有三人，为H,I,J，防火墙小组组长根据实际情况将此工单派发给J，J进行分析确认，确是防火墙设置问题，需要修改防火墙设置，须走变更，J根据需要修改的防火墙设置创建变更工单，并关联此事件单，J将事件状态置为“已解决”并将工单转派给服务台人员，由服务台人员告知小王，此事件单正在变更流程中处理。 9.2 分公司内部 杭州市分公司柜面操作员小李，反映查询系统有问题，电话告知浙江省分公司服务台人员，分公司服务台人员记录事件信息，与小李沟通后确认是“分公司自有系统,浙江省,查询系统”的问题，首先根据服务目录查询知识库，如果有匹配的解决方案，则按照解决方案处理，如果需要发起变更，则由分公司服务台人员根据解决方案创建变更工单。如果未在知识库中查询到匹配的解决方案，则进行重复事件判断，如是重复事件，则关联重复事件工单号，并置事件状态“XX处理中”，保存退出，同时分公司服务台人员告知小李可以查询XX工单号可以了解决事件处理进度。如果不是重复事件，则判断事件性质、优先级、影响度等，如果此事件为紧急事件则转派给一线支持进行再确认，如果不是紧急事件则进行尝试解决，并更新事件状态为“服务台处理中”，如果服务台人员解决了此事件，则更新工单信息，并与小李确认解决方案及满意度。如果经尝试未能解决则转派一线支持，系统自动将事件状态置为“分派到一线” 通过系统对服务目录判断将此工单分派给分公司一线应用支持组中的查询支持小组组长，查询支持小组有两人，分别为A`，B`，查询支持小组组长根据实际情况将此工单派发给B`，B`经分析为数据库问题，填写分析过程后，将工单通过服务目录转派给 65 分公司一线基础设施支持组中的数据库小组组长，此小组有三人，为C`,D`,E`，数据库小组组长根据实际情况将此工单派发给D`，D`进行分析判断后通过借助工具或运用自己技能尝试找出解决方案，D`将事件状态置为“已解决”并将工单转派给服务台人员，由分公司服务台人员与小李确认解决方案及满意度，并更新事件状态及事件结束代码。 共 47 页 - 46 - 9.3 紧急事件 山东省分公司信息技术部小张反映CBPS8版系统不可用，小张直接创建事件工单，根据经验技能判断现象分类为“核心运营,CBPS8版系统,宕库”，并确认此事件为紧急事件，通过服务目录自动将此工单分派给分公司一线应用支持组中的CBPS8版支持小组组长，小组有成员3人分别为F1,F2,F3，CBPS8版支持小组组长根据实际情况手工选择将此工单派发给F2，经F2再次确认此事件确实为紧急事件，同时系统通过邮件或短信方式自动通知分公司事件经理，经分析F2无法独立处理，由F2联系分公司事件经理G1，G1通过其他方式联系总公司负责业务应用的事件经理W3，同时F2点击按钮，系统通过服务目录将此工单转派给总公司二线应用系统专家组中的CBPS8版系统小组组长(不派发给小组成员)L1，由W3召集应急小组进行应急会议， 66 根据之前制定的应急预案进行处理，同时W3与G1对事件处理过程进行沟通并确认紧急事件是否解决，L1发起对该紧急事件的问题请求。如果没有应用预案或已有应急预案无法解决此紧急事件，则由W3组织相关人员及厂商共同分析，制定解决方案并进行处理。事件处理结束后，将工单返回给山东省分公司信息技术部小张，由小张确认并关闭 9.4 分公司与总公司 贵阳市分公司业务处理人员小赵反映万能系统保全功能操作报错，联系贵州省分公司服务台人员，服务台人员记录事件信息并与小赵沟通确认是“核心运营,万能系统,保全模块”的问题，首先根据服务目录查询知识库，如果有匹配的解决方案，则按照解决方案处理，如果需要发起变更，则由服务台人员根据解决方案创建变更工单。如果未在知识库中查询到匹配的解决方案，则进行重复事件判断，如是重复事件，则关联重复事件工单号，并置事件状态“XX处理中”，保存退出，同时服务台人员告知小赵通过查询XX工单号可以了解决事件处理进度。如果不是重复事件，则判断事件性质、优先级、影响度等，如果此事件为紧急事件则转派给一线支持进行再确认，如果不是紧急事件则进行尝试解决，并更新事件状态为“服务台处理中 则更新工单信息，并与小赵确认解决方案及满‎‎”，如果服务台人员解决了此事件， 意度。如果经尝试未能解决则转派一线支持，系统自动将事件状态置为“分派到一线” 通过系统对服务目录判断将此工单分派给分公司一线应用支持组中的万能支持小组组长，此时万能支持小组有两人，分别为A，B，万能支持小组组长根据实际情况手工将此工单派发给B，经B分析分公司一线内部无法解决，需转派给总公司二线 通过系统对服务目录判断将此工单分派给总公司二线应用支持组中的万能支持小组组长，此时万能支持小组有三人，分别为C,D,E，万能支持小组组长根据实际情况手工将此工单派发给E，经E分析无法准确定位原因，需转派给总公司三线 通过系统对服务目录判断将此工单分派给总公司三线开发支持组中的万能支持小组，此时万能支持小组有五人，分别为F,G,H,I,J，其中F为本组中的组长，系统将此工单派发给F，经F分析了解此事件，H是最适合的人选，由F通过手工选择组内人员的方式将此工单派发给H，经H分析确认，此事件是由系统BUG引起，H填写临时解决方案，并将事件状态设置为“已解决”，同时由H发起一个针对此事件的问题工单 67 ，并与此事件工单进行关联，系统自动将事件工单转派给贵州省分公司服务台，由 服务台人员告知小赵针对此事件已经创建一问题工单。小赵可以通过此事件工单关 联的问题工单查看问题处理进度。 10 关键流程衡量指标 为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地 对流程的运行情况进行监控和改进。 序号 衡量指标 指标计算说明 1 事件总数 数量:在事件单中根据以下条件过滤 共 47 页 - 47 - 序号 衡量指标 指标计算说明 1. 【重复事件标记】为空 68 2. 【事件结束代码】不等于„消失?or„误报?or„可忽略? 3. 【事件发生时间】在统计周期内 2 服务台解决率 数量:在事件总数中过滤所有【事件解决人角色】,„服务台? 比率:数量 / 事件总数 × 100 % 3 服务台平台响应时间 响应时间:(【实际开始时间】,【登记时间】) 总响应时间:在事件总数中统计各(【实际开始时间】,【登记时间】) 平均响应时间:总响应时间/事件总数 4 一线解决率 数量:在事件总数中过滤所有【事件解决人角色】,„一线? 比率:数量 / 事件总数 × 100 % 69 事故事件控制程序 1 目的 为规范事故、事件管理，落实“四不放过”原则，制定本程序。 2 适用范围 本程序适用于公司一般事故和事件的管理。 特大、重大、较大事故，按国家有关规定执行。 3 术语 3.1事件:导致或可能导致事故的情况(可能导致事故的情况即“险肇事故”)。 3.2事故:指在企业活动过程中发生的，造成人身伤害、财产损失、环境污染或社会影响的事件。 3.3 险肇事故:可能导致事故的情况，即有可能造成事故、但因偶然性因素并未产生损失后果，但如果该情况重复发生，不排除造成事故的可能。 3.4 迟报:指报告事故的时间超过规定时限。 3.5 漏报:指因过失对应当上报的事故或部分内容遗漏未 报。 3.6 谎报:故意不如实报告事故或部分内容。 3.7 瞒报:指故意隐瞒已经发生的事故，并经有关部门查证属实。 3.8 系统停机:指单台套设备系统停机。 3.9 停产:指单台套设备系统停产。 3.10“四不放过”:事故、事件的原因未分析清楚不放过，防范措施未落实不放过，责任人未受到处理不放过，职工未受到教育不放过。 4 引用文件 GB/T19000-2008 质量管理体系 基础和术语 GB/T19001-2008 质量管理体系 要求 GB/T24001-2004 环境管理体系 要求及使用指南 GB/T28001-2001 职业健康安全管 70 理体系 规范 GB/T23331-2009 能源管理体系 要求 《生产安全事故报告和调查处理条例》(国务院令第493号) 《河北省生产安全事故报告和调查处理办法》(河北省人民政府令(2007)第13号) 《铁路交通事故调查处理规则》(铁道部令第30号) 《河北钢铁集团有限公司职工安全生产规则》(集团字(2010)29号) 5 职责 5.1企业管理部 5.1.1 负责组织制定、修订本程序。 5.1.2 负责工作事故的管理。 5.1.3 负责对各类事故(事件)的调查、分析、处理情况进行监督、考核。 5.2生产 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 部 5.2.1 负责各类事故(事件)的报告、登记。 5.2.2 负责核定各类事故停产时间、停减产损失。 5.2.3负责生产操作事故的管理。 5.2.4负责自然灾害类事故的管理。 5.3 钒钛技术工程研究中心负责工艺、质量事故(事件)的管理(政府部门监督检查发现的质量事故除外)。 5.4质量计量管控中心负责对政府部门监督检查发生的质量事故进行调查、分析、考核;督促、检查、考核有关部门对其它质量事故的调查、分析、考核。 5.5 安全生产监督管理部负责职业病、伤亡事故(事件)的管理，因其它类事故造成人员伤亡的(交通除外)，由安全生产监督部牵头处理。 5.6 设备管理部负责设备事故的管理。 5.7 环保部负责环境污染、辐射事故的管理。 5.8能源管控中心参与造成能源浪费的各类事故的调查、分析、处理。 5.9 武装保卫部负责交通事故、火灾事故、爆炸事故(可归类为设备事故、工艺事故的爆炸事故除外)的管理。 5.10 公司办公室负责泄密事故、群体性事件的管理。 5.11人力资源部负责落实助理级以上责任人员的经济处罚，落实或监督落实责任人员的行政处分。 5.12 公司工会负责维护职工合法权益，依法参加事故(事件)的调查、分析、处理。 71 5.13 监察部负责监督事故(事件)的调查、分析、处理工作。 5.14 自动化管控中心负责事故事件管理系统的开发与维护。 6 管理内容 6.1 事故分类。事故分为伤亡事故、设备事故、工艺事故、生产操作事故、质量事故、火灾事故、爆炸事故、交通事故、环境污染事故、辐射事故、自然灾害事故、工作事故、泄密事故及其它事故等。 6.1.1生产操作事故:因组织、协调、指挥不当或操作不当造成生产中断或财产损失，且不属于工艺事故等其它类别事故的事件。 6.1.2 伤亡事故:指职工在工作过程中发生的人身伤害、急性中毒事故。 6.1.3 设备事故:指投入试生产以后的设备，在生产过程中造成设备的零件损坏使生产突然中断，或由于设备原因直接造成能源动力供应中断而使生产突然中断的事件。 6.1.4 工艺事故:是指生产过程中因工艺技术条件变化、工艺参数、工艺件原因、工艺操作不当、或其它工艺原因造成的生产中断事件。 6.1.5 质量事故:指产品在成分、性能、尺寸、表面等方面不符合相应标准要求的事件以及产品未达到用户签订的 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 或技术协议要求，用户提出经济赔偿的事件。 6.1.6 火灾事故:是指在时间和空间上失去控制的燃烧所造成的事件。 6.1.7 爆炸事故:人们在生产生活中由于不认识物质的危险特性或违反正常生产操作而意外地发生了突发性大量能量的释放，这种由于人为环境或管理上的原因而发生和造成财产损失、或人身伤亡的事故，并伴有强烈的冲击波、高温高压和地震效应的事件。 6.1.8 交通事故:车辆在道路上因过错或意外造成的人身伤亡或财产损失的事件。 6.1.9 环境污染事故:指由于违反环境保护法规的经济、社会活动与行为，以及意外因素的影响或不可抗拒的自然灾害等原因使环境受到污染，国家重点保护的野生动植物、自然保护区受到破坏，人体健康受到危害，社会经济与人民财产受到损失，造成不良社会影响的突发性事件。 6.1.10 自然灾害事故:以自然变异为主因产生的灾害事件。 6.1.11 工作事故:是指管理岗、技术岗人员在工作中违反规定或未尽岗位职责，造成了经济损失或不良影响的事件。 72 6.1.12 泄密事故:指发生在所属部门、单位的政治、经济、技术等方面的泄漏机密、绝密级信息的泄密事件。 6.1.13 其它事故:指除上述事故外的其它事故。 6.2 事故管理 6.2.1 公司各职能部门按职责制订有关事故(事件)管理的三级文件，规定事故处理时限要求，由企业管理部、监察部、人力资源部、公司工会审定后，报请公司领导签发。 6.2.2公司各职能部门按职责牵头组织相应的事故(事件)的报告、调查、分析、处理，并及时将四级以上事故在事故事件管理系统发布。 6.2.3 公司各职能部门建立事故档案，对各类事故调查分析的资料，如现场勘察记录、照片、技术鉴定、化验分析、会议记录、旁证材料、综合调查材料及登记表、报告书等，应妥善保管。在事故事件管理系统发布实现之前，建立事故事件管理台帐(格式见附件1)，对事故(事件)进行登记，每月5日前报企业管理部。 6.3 事故分级 6.3.1根据后果的轻重不同，一般事故由重到轻分为四级，即一级事故、二级事故、三级事故、四级事故。 6.3.2 各专业管理部门根据本专业性质及国家、政府相关要求及停产时间，并对照本文件事故等级规定，在三级文件中明确事故等级标准。 6.4 事故报告 6.4.1 公司所属各单位生产科(调度室)、各部门办公室为事故报告的责任部门，各单位、部门主要负责人是报告的第一责任人。 6.4.2 凡发生事故，应立即采取必要措施，防止事故扩大。有现场应急处置要求的，在各类事故管理的三级文件中予以规 定。 6.4.3 发生各级事故，均应采用电话等快速方法进行快报，各级的报告时间不应超过5分钟。 6.4.4 事故快报:最先发现人向所在单位的调度室报告，所在单位调度室向本单位归口部门、有关领导、公司生产计划部调度室报告，公司生产计划部调度室向公司归口部门、公司分管领导报告，公司分管领导向公司总经理报告。 73 6.4.5 详细报告:由公司归口部门在事故调查、分析后提交文字的事故报告。报告时限、内容、格式等要求，在各类事故管理具体的三级文件中予以规定。 6.4.6 需要向集团、政府报告的，有关要求在各类事故管理的三级文件中予以规定。 6.4.7 发生事故后难以即时准确判断事故级别的，按可能的高级别报告。 6.4.8 各类事故报告的程序在专业事故管理的三级文件中予以规定。 6.4.9 事故报告流程(见附件2)。 6.5 事故分析及处理 6.5.1事故发生后，尚不能明确事故类别时，由生产部门牵头，组织有关部门进行调查、分析。 6.5.1.1经调查、分析，可以明确归于一类的，由该类事故主管部门接续调查、分析、处理。 6.5.1.2经调查、分析，可以归于两种或两种以上类别的，按损失合计、处理从重原则，由处理最重的事故类别的主管部门 牵头、相关事故类别主管部门参加，接续调查、分析，按处理最重的事故类别处理。 6.5.2各类、各级事故，都要按照“四不放过”原则，对事故进行调查分析，查明原因，分清责任，按规定对事故的责任者进行处理，采取事故通报、组织学习等方式对广大职工进行教育，制订并落实纠正措施，按举一反三原则制订并落实预防措施，防止发生重复事故。 6.5.3各类事故分析、处理内容在专业事故管理三级文件予以规定。 6.5.4事故处理分为行政处分、经济处罚及其他(待岗、下岗、解除合同)等处理方式，各种处理方式可单用或并用。 6.5.5行政处分包括:警告、记过、记大过、降级、撤职、留用察看、开除等七种。 6.5.6对事故指标的考核列入经济责任制执行，企业管理部负责制定公司职能部门考核办法，各职能部门负责制定专业管理考核办法。 6.5.7涉及政府罚款和赔偿客户损失的，在各专业事故管理 的三级文件中予以规定。 6.5.8每起事故对事故责任单位的处罚 6.5.8.1 一级事故:以发生事故造成的直接损失数额的1-3%进行扣罚，但扣罚金额下 74 限不低于单位人均400元，扣罚金额上限不超过绩效工资总额。 6.5.8.2 二级事故:每起扣罚5,10万元(含10万元)。 6.5.8.3 三级事故:每起扣罚3,5万元(含5万元)。 6.5.8.4 四级事故:每起扣罚1,3万元(含3万元)。 6.5.9 每起事故对事故责任人员的处罚 6.5.9.1对个人扣罚可逐月执行，每月应保留最低工资。 6.5.9.2 伤亡事故的处理，要遵守《河北钢铁集团有限公司职工安全生产规则》的规定。 6.5.9.3 各类、各级事故对责任人、有关领导的处理:对主要责任者、次要责任者应区别处理，对工段级主管领导、工段级主要领导、负有管理责任的分厂职能部门具体管理人员、负有管理责任的分厂职能部门领导、分厂级主管领导、分厂级主要领导、负有管理责任的公司职能部门具体管理人员、负有管理责任的公司职能部门领导应区别处理。具体在专业事故管理的三级文件中予 以规定。 6.5.10 其它处罚 6.5.10.1对于事故损失较大、情节严重、符合《劳动合同法》、《劳动合同法实施条例》中有关解除劳动合同条款规定的，可给予解除劳动合同处理。 6.5.10.2 因技术、标准、规程、制度等掌握不熟练、操作不当造成事故，可视情况给予责任人下岗1,12个月的处理。 6.5.11 须从重处理的情形:重复性事故;迟报、漏报、误报、瞒报;不配合事故调查;作伪证;事故发生后，不积极进行应急处置，致使事故损失扩大;由于严重违章、或严重不负责任造成事故;其他情形(在专业事故管理的三级文件中予以规定)。 6.6 事故预防 6.6.1 一级事故、二级事故在公司范围内通报，三级事故、 四级事故在本单位范围内通报。各单位要组织职工学习，以吸取教训。 6.6.2 对发现事故征兆并采取措施避免事故发生、报告险肇事故、举报事故的，均给予表彰和奖励。 6.6.3 险肇事故比照事故进行处理。 6.7 事故管理流程(见附件3)。 7 主要支持文件 75 《伤亡事故报告和调查处理制度》 《设备事故管理办法》 《工艺事故管理办法》 《质量管理办法》 《产品质量管理办法》 《生产操作事故管理办法》 《紧急情况重大事件报告管理办法》 《铁路交通事故管理办法》 《环境污染事故管理办法》 《交通事故管理办法》 《火灾事故管理办法》 《保密工作管理办法》 《工作事故管理办法》 8 记录 序号 记录名称 记录编号 保存地点 保存期限 1 事故事件管理台帐 C-Z/A/H/N/J-QG-043 各单位、部门 长期 9 附则 9.1 本程序文件自2010年7月1日起执行，原《事故管理办法(ZLQGZY》-07)和《事 故、事件和不符合管理程序》(AQAHCX4.5.2-06)废止。 9.2 本文件由企业管理部起草并负责解释。 起草人:王丽英 审核人:张玉玺 批准人:牟文恒 事件管理流程 编辑词条 76 B 添加义项 ? 事件管理流程是IT服务管理中的一个核心流程，提升事件管理时效性、回归事件管理本身属性，可以提高IT服务的质量，有效改变目前我国企业普遍存在的重开发、轻运维的现象，真正践行以服务为导向的ITIL理念，通过切实有效的IT服务管理为企业创造价值。 目录 1名词解释 2管理步骤 3相关软件 1 名 词 解 释 2 管 理 步 骤 3 相 关 软 件 回到顶部意见反馈 名词解释折叠编辑本段 事件管理流程是IT服务管理中的一个核心流程，提升事件管理时效性、回归事件管理本身属性，可以提高IT服务的质量，有效改变目前我国企业普遍存在的重开发、轻运维的现象，真正践行以服务为导向的ITIL理念，通过切实有效的IT服务管理为企业创造价值。 管理步骤折叠编辑本段 事件管理流程大概如下:当一个事件输入的时候，首先要对事件进行检查、定位。检查事件的时候要与它不断交互，明确它的影响范围和紧急程度，还要进行初步的归类评估。服务台(ServiceDesk)是事件的唯一入口，它接收事件后，操作人员通过查阅CMDB〔配置管理数据库)进行处理。 1.事件的查明和记录 服务台记录一些标识客户的基本信息，如姓名、工作地点、电话号码等，而事件管理记录详细的事件信息，如事件发生的时间、受事件影响的服务等。这样做的目的是便于确认事件的影响，问题管理可以根据这些信息查找事件原因，密切跟踪事件进展。 77 首先，当用户、服务台工作人员或其他IT部门人员发现或系统检测到某系统发生事件时，就将其报告给服务台，服务台将基本信息输入事件数据库并报告给事件管理人员。通常所有的事件都是先报告给服务台，再由服务台工作人员将其输入事件数据库，服务支持小组是不允许直接记录事件的。 其次，事件管理人员给事件一个唯一的编号(事件单号)，记录一些基本的事件分析信息(时间、症状、位置、用户、受影响服务、硬件等)，并补充其他的事件信息(与用户的交互信息和配置管理数据库等。 再次，事件管理人员根据服务台提供的信息和事件数据库信息判断此类事件是否与已有的事件相同或类似，如果有就更新事件信息或建立原事件的从属记录，并在必要时修改原事件的影响度和优先级，如果没有则创建新事件记录。最后，事件管理需要判断事件是否严重，如果严重就先向管理层报告并告知用户有关情况，再采取进一步行动，如果不严重就直接进入下一步的事件初步归类和支持。 2.初步归类和初步支持 经过第一步的事件查明和记录，可从用户处获取的事件信息基本上已得到，事件管理数据库已经根据这些信息进行更新，接下来就是事件的初步归类和初步支持。这里强调初步，就是为了能够尽可能快地恢复用户的正常工作，尽量避免或者减少事件对IT服务质量的影响。 归类的目的是发现事件原因以便采取相应行动。一般来说，许多事件是重复出现的，因此，当某个事件再次出现时，只需要根据已有的经验和措施采取行动即可:，当新的事件出现时，就有一个与其问题和知名错误(知识库)相匹配的过程，如果匹配成功就可直接用已有的方案将其解决，而不需要进一步调查，否则就要继续进行下面提到的其他几个步骤。 服务台如果没有成功解决事件，就将事件转交给二线、三线支持处理，然后负责记录事件并联系各支持小组，采取必要的措施以确保用户满意。如果碰到未出现过的事件或事件解决过程非常复杂，就必须对事件进行调查和分析。 3.事件调查和分析 事件在第一阶段和第二阶段没有圆满解决时，专家支持小组应介入处理过程，对其进行调查和分析。 一旦事件被分派给某个支持小组，他们应当完成以下工作:确认接收事件处理任务，同时指定有关日期和时间以保障正常更新事件状态和历史信息，经过服务台及时通知客户事件最新进展，说明事件当前所处的状态;尽可能快地把发现的权宜措施提供给服务台和客户;参考知名错误、问题、解决方案、计划的变更和知识库等对事件进行评审;必要时要求服务台根据协议的服务级别，重新 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 事件影响度和优先级，并在必要时对其进行调整;记录所有相关信息，包括解决方案、新增的或修改的分类;将所有相关事件的更新、花费的时间以及处理结果反馈给服务台以让其终止此类事件。 4.解决事件和恢复服务 在分析和调查事件后，支持小组根据更新的事件信息，提议的权益措施和解决方案以及有关的变更请求，解决事件并恢复服务，同时更新有关事件信息 5.事件终止 解决事件和恢复服务后，事件到达终止阶段。这个阶段输入的是上一阶段更新后的事件记录和已解决的事件，采取的行动主要是和客户一起确认事件解决是否成功，输出的结果为更新的事件信息和事件记录。在事件解决后，服务台应该确保以下内容:有关用于解决事件的行动的信息是准确的、易懂的;根据事件产生的根本原因对其归类;客户同意事件解决方案和方案的执行及最终结果;详细记录事件控制阶段的所有相关信息，如客户是否满意和满意度如何，处理事件所花费的时间，事件终止的日期和时间。 相关软件折叠编辑本段 78 对于不同规模的公司，所需要的事件管理流程也是不相同的。对于一个中小型的企业，IT人员只有几个人，这时候就不需要很复杂的事件处理流程，只需要实现“请求-指派-处理-确认”的基本过程即可。对于一个大型的企业或者专业的IT服务公司，则需要组建专门的IT服务受理和监督机构、多级IT技术支持团队，和与之适应的较为复杂完善的事件跟踪流程。 使用URTracker进行事件管理，您将可以: 根据您的组织规模、人员配置情况，设计和实现最适合自身情况的流程。 对用户提供了一个统一的IT部门联系接口。用户可以及时获知事件的处理进展和处理过程。 通过URTracker的“状态实现”和“定时器”功能，控制不同级别事件或问题在每个处理步骤的响应时限和处理时限要求等。在超过时限时自动进行通知或升级指派操作。 支持将事件提交给一个组(如IT支持人员组)，组中合适的人可以领取并处理事件。 将事件处理经验总结归纳成知识库文章，供用户学习，从而减少类似事件的发生和相应的服务请求数量。 统计分析各种问题出现的频率和分布，采取更有效的维护措施减少事故发生。 79