事件管理流程设计样例.ppt

XX银行IT服务管理事件管理流程概要设计,XX2015.1,文件控制记录,更新记录：,去向记录：,报告内容,流程目的、基本概念、范围和指导原则事件管理角色和流程事件管理政策事件管理KPI,事件管理目标,事件管理的宗旨是在对用户提供的服务受到一些计划外的违反时，采取快速、成功的行动来恢复受到影响的IT服务。目标：事件管理的目标是确保影响到用户服务的事件能够快速得到解决。事件管理关注于快速确定解决方案或变通方法。对于那些无法立即解决的事件，事件管理同时也是问题管理流程的关键驱动者。要达到这个目标的重点在于：在第一次接到用户报告事件时，尝试解决准确的将故障单分派给后台技术支持人员确保用户对于事件的解决方案是满意的为用户提供礼貌的服务，确保客户满意度,事件管理基本概念,事件(Incident)本项目中的事件主要是指XX银行科技部维护范围内的所有不属于标准服务运作的一部分，并且导致或可能导致服务中断或服务质量降低的任何事件。如：软/硬件故障、检测到病毒等。事件管理事件管理包括事件管理流程、相关的一系列事件处理政策以及对角色职责的明确定义。事件管理旨在确保检测并记录事件，跟踪事件的解决过程，使事件能在最短的时间内得到解决，并为问题管理等其它服务管理流程提供相关信息。,事件管理的范围,任何违背XX银行IT正常运作、影响或可能影响XX银行科技部提供IT服务的偏离，包括所有IT生产环境的基础设施系统或组成部分发生的异常，而不论它们影响大小或者它们影响到具体的IT组件内容。,在XX银行具体事件将包括：终端故障营业厅运营设备故障操作类故障服务器故障网络故障机房设备故障软件故障（注：不含桌面办公系统）,IT基础设施包括：软件与应用网上银行系统、反洗钱系统、办公系统等业务系统数据库、其他应用软件网络软件硬件服务器、个人终端运营设备、网络硬件机房、通讯设备手册、文档,本项目事件管理范围不包括：服务请求(如数据提取、密码重置、政策信息查寻等)需求管理(各类系统的需求管理、审批等)其他在事件管理范围外的请求将通过变更或者其他服务流程处理，但它们可能一开始寻求的是服务台的支持，服务台将会把这些请求转到相应处理流程,事件管理指导原则,XX银行科技部需要建立统一的事件管理流程，生产环境中发生的事件都由统一的事件管理流程进行管理。XX银行科技部的员工都应遵守事件管理的流程、政策和步骤。必须首先恢复受到影响的服务，之后再进行问题根源分析；特别是批量故障发生后，将优先恢复服务。对所有的事件问题必须清晰记录，并通过知识库详细记录故障特征与解决方法。优先等级将在科技部内定义、记录和发布。需要定期产生事件报表，并不断优化。事件的责任人（不是指“引起事件的责任归咎”，而是指负责某一个事件处理解决的人员）必须是XX银行科技部内的员工，负责解决或协调供应商解决事件，并填写事件单处理信息。如果服务提供商参与事件处理解决，须确保向事件责任人提供事件处理的信息。,报告内容,流程目的、基本概念、范围和指导原则事件管理角色和流程事件管理政策事件管理KPI,XX银行事件管理的支持架构,服务台（前台服务岗）,网络维护岗,数据库管理岗,第三方厂商支持,基础设施及硬件维护岗,系统管理岗,安全维护岗,服务台（一线）：作为服务台，响应客户的任何请求，需要IT部门所提供的服务都有所了解，不仅仅包括服务器、网络，还要包括应用系统；但是以常见问题为主。需要定期接受二线人员的培训。,二线支持：是各个领域的专家，由各服务的负责部门人员组成,第三方厂商：第三方的服务商、集成商、原厂商协助二线支持响应客户的服务请求,流程负责人，事件经理,事件流程负责人：由IT部门负责建立和推广制度的人员担任负责制定和推行事件管理制度和流程负责确保事件管理流程达到事件管理的目标事件经理：由具有较强沟通协调能力的同事担任负责推动事件管理流程的日常执行,事件管理角色定义,事件管理总体流程,事件管理总体流程,本步骤的目的是快速、准确地在故障发生的时候识别出事件，并收集创建一个事件单所需要的信息。本步骤定义事件的严重性等级和分类，并尝试通过匹配可用的解决方案或变通方法来尽快恢复服务。如果没有可用的解决方案或变通方法。则将该事件分派给适当的事件分析员进行调查。事件的初步解决不成功，需要进行更深入的调查和诊断，以找出恢复服务的变通方法。如需要，可以请一个或者多个事件分析员来寻求变通方法。如果无法找出变通方法，将引入问题管理流程。如果解决方案需要变更请求，将引入变更管理流程。如果不需要变更，将与用户进行沟通，执行解决方案/变通方法。如果解决方案无法引出正确的结果，需要进行进一步诊断。如果需要进行问题根源分析，则创建一个问题单。如果事件得到解决，或者与事件相关联的问题得到解决，并且用户验证并接受结果，该事件即可准备关闭，如果需要的话，知识库也可以随之更新。最终，该事件单将被关闭。如果用户不接受解决结果，事件将被报告给事件经理。,检测与记录,事件分类和初步支持,调查与诊断,解决与恢复,事件关闭,事件管理总体流程,对于事件的生命周期都可进行监控。监控始于事件的开始，结束于事件的关闭，包括人工和自动两种方式：人工方式：帮助台与用户验证事件的解决结果时，用户表示对结果不满意或认为事件未被解决，则应通知相关人员（事件分析员或事件经理），必要时对事件进行升级。自动方式：设定事件处理的一系列阀值（如处理时间、转派次数等），通过自动化工具进行监控，当阀值被超出时，自动对事件进行升级处理，相关人员得到通知。,事件监控与跟踪,步骤1：事件检测与记录,步骤1：事件检测与记录流程要点,事件单的产生：运维中心外部发现并报告的事件单，由服务台开单、派单和跟踪。运维中心内部发现的事件单，发现者开单，发现者或服务台派单，服务台跟踪。监控告警时，由监控平台或统一事件管理平台完成过滤后，符合条件的自动开单；另外，服务台或者监控人员发现了未符合自动开单条件的告警，也可开单，服务台负责派单和跟踪。客户信息记录：XX银行暂时未有LDAP来记录所有行内人员的信息。建议：在ITSM系统中维护行内人员信息。,步骤2：事件分类和初步支持,步骤2：事件分类和初步支持流程要点,分派事件：派单：按照事件类别（CTI）来判断分派给哪个组、哪个人。既可分派到具体的人，也可分派到组，由组内人员主动接单。重新派单：（1）组内转派，允许事件分析员直接转派。（2）当事件分析员判断不属于本组处理范围，需退回服务台，由服务台重新分派。重大事件：如果发生特别重大突发事件或重大突发事件，或者事件特征符合应急方案或者灾难恢复计划的决策条件，须考虑启动应急方案或灾难恢复计划。服务台尽快向管理层报告重大事件，然后继续开单和派单，事件处理人员在实施应急方案或灾难恢复计划后，继续填单和关闭单，以作未来统计分析之用。重复事件：当服务台或者事件分析员判断是重复事件（同一故障引发多人报障）时，直接把重复的事件单关联到已经有的事件单（主事件单），不必继续处理重复的事件单。,步骤3：事件调查与诊断,步骤3：事件调查与诊断流程要点,事件单转派策略：同上一流程步骤的重新派单要点。诊断事件：如果事件特征符合应急预案的启动条件，须确定合适的应急预案并加以执行。如果事件特征不符合应急预案的启动条件，则事件分析员分析诊断事件，并检查可行的解决方案，如果没有发现可行的解决方案，则需要启动问题管理流程来寻找临时措施和解决方案。,步骤4：事件解决和恢复,步骤4：事件解决和恢复流程要点,流程关联：如果事件的解决涉及变更，需要通过变更管理来执行。如果事件严重等级较高，应该通过紧急变更来执行解决。如果事件存在深层未知原因，需要通过问题管理来根除故障。（待第2期实现）,步骤5：事件关闭,步骤5：事件关闭流程要点,事件复发：如果事件由事件分析员标记为“已解决”（但服务台未关闭事件）时，同样的用户报告故障未解决或故障再次发生，则须返回事件分析员继续处理。事件关闭：在关闭事件前，三个角色要进行如下工作：服务台：由用户报告的故障，联系用户确认同意关闭，并获取满意度信息。（由科技部内部发起的故障，则不必进行此步骤）事件分析员：负责处理该事件的事件分析员，填写事件处理总结。事件经理：进行事件处理总结的复核，并对事件判定属于“特别重大突发事件”、“重大突发事件”、“较大突发事件”、“一般事件”。如果事件处理总结适合用于知识积累，可提交知识库（该功能待第3期时实现）。关闭事件单。,事件管理状态定义,报告内容,流程目的、基本概念、范围和指导原则事件管理角色和流程事件管理政策事件管理KPI,事件分类政策,对事件的分类，按发生故障的对象进行分类。采用类别（Category）、子类（Type）、条目（Item）三级分类。分类的作用：有助于服务台快速判断分派给谁；有助于进行事件按分类的统计分析。分类的要求：一个事件，只能属于一个分类。,Sample,信息系统等级政策,注1：信息系统等级按照XX银行信息系统灾难应急处理管理规范中定义的信息系统等级。信息系统等级可用于判断处理事件的优先级别。注2：系统实现时，把信息系统等级与事件CTI分类进行对应，即只要在事件单中选择了CTI，通过后台设置的对应关系，自动选择信息系统等级。,事件影响度,事件影响度：用于判断事件发生时，造成的影响范围和影响对象。事件影响度分为3级：高中低事件影响度的具体定义见下表：,事件优先级,事件优先级：用于判断处理一个事件的优先级。事件优先级分三级：高中低事件优先级由两个因素共同决定：信息系统等级，事件影响度，对应关系如下表。,目标时间政策,设定目标时间的目的：有助于对事件处理进行时间控制，使管理层能够及时关注超时事件。有助于事件管理进行统计分析，获得事件处理及时情况的报表。XX银行使用目标时间政策的限制：要充分利用目标时间，XX银行科技部需要建立一个规则：先在系统中接单，再进行故障处理；故障处理完毕，立刻进入系统登记事件解决。由于在流程讨论中已经谈到，当事件（故障）发生时，一旦事件紧急，事件处理人员必须先去处理故障，处理完后再进行接单、填单等，因此仅凭系统自动记录的接单时间和解决时间，是不符合真实的响应和解决的时间，这种情况就无法利用系统设定的目标时间来进行事件的跟踪告警。建议：系统保留对事件响应、事件解决、事件关闭的超时告警功能。现阶段，XX银行只使用“事件解决”的超时告警。,目标时间政策（续）,注：第一、二级的信息系统，可能需要重点回顾一下，所以关闭时间相对较长一些。,事件通知政策,下表表示不同优先级的事件所需要通知到的人员和相应的通知方式。,事件重复政策,重复事件：如果被报告的时间与某个已经创建且尚未解决的时间单症状相同，则该事件被认为是重复的。而已经创建尚未解决的那个事件，则是主事件。将会为此重复事件创建新的事件单，并将此单标注为“重复”，并与原始事件单相关联。原始事件单将会被标注为“主事件”。主事件解决时，从事件自动解决（自动变为“已解决”状态。）,事件分级政策,注：事件分级参考XX银行信息系统灾难应急处理管理规范中定义的突发事件分级。考虑到非应急情况的需要，增加一个“一般事件”的级别。,事件分级政策要点,事件分级政策，用于对事件的定性评价。在事件发生时，服务台进行初始选择。随着事态的发展，可以随时修改此事件分级的选择，以引起事件处理人员的关注。在事件处理完成后，进行最后的定性，由事件分析员进行事件总结时填写，并由事件经理复核。,事件关闭政策,事件关闭：在关闭事件前，三个角色要进行如下工作：服务