Changes for page 32 ITIL事件管理流程设计说明书

Last modified by superadmin on 2024/11/02, 13:28

From version < 19.1 >

edited by superadmin
on 2024/11/02, 13:27

To version < 20.1

edited by superadmin
on 2024/11/02, 13:28

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,0 +1,1 @@
	1	+32 ITIL事件管理流程设计说明书

Parent

...	...	@@ -1,0 +1,1 @@
	1	+G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome

Content

@@ -1,0
          +1,1018 @@
++= **1. 综述** =
++
++==  **1.1 文档简介** ==
++
++本文档是XX公司和XX客户（以下简称XX客户）共同制定的事件管理流程的设计文档。通过该文档,可以帮助XX客户快速的解决IT环境的事件，为XX客户业务的快速发展提供更优质的IT服务。
++
++本文档的内容是XX公司依据目前XX客户IT服务状况而制定的事件管理流程的说明，以后进一步的更新将由XX客户负责。
++
++
++==  **1.2 适用范围与对象** ==
++
++本文档作为本次项目的事件管理流程详细设计的交付物，读者对象为与事件管理流程相关的所有技术与管理人员。
++
++
++== ** 1.3 重要参考资料** ==
++
++ITIL（IT Infrastructure Library ）V3.0。
++
++《XX客户事件、变更级别说明》。
++
++
++== ** 1.4 相关术语** ==
++
++* ITIL（IT Infrastructure Library ）
++
++是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。
++
++* ISO20000
++
++国际标准组织ISO/IEC在2005年底发布的全球IT服务管理标准，包括服务实施、控制、发布、解决、关系管理5个域13个流程，强调持续改进过程。ISO20000可以提供针对企业或部门的国际标准认证。
++
++* 服务台（Service Desk）
++
++服务台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。
++
++* 事件管理（ Incident Management）
++
++ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
++
++* 问题管理（Problem Management）
++
++ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除根本原因从而使类似事件不再发生。同时问题管理流程也负责预防事件的发生。
++
++* 配置管理（Configuration Management）
++
++ITIL 流程之一，配置管理负责描述，跟踪和汇报IT基础架构中每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI)。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。
++
++* 配置管理数据库（CMDB - Configuration Management Database）
++
++是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。
++
++* 变更管理（Change Management）
++
++ITIL流程之一，变更管理通过控制和管理服务相关的变更， 使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。
++
++* 服务水平管理管理（Service Level Management）
++
++服务级别管理流程通过签订和维护服务水平协议（SLA）的方式,确保以协定的质量和成本向客户交付既定的服务。同时该流程维护、监控和持续改进协定的服务级别。
++
++* 日常运维管理（Operation and maintenance management）
++
++日常运维管理用来支持运行维护人员需要定期重复或临时发起的，需要人工参与执行或检查的日常任务，使日常运维工作规范化，并最大程度实现自动化。
++
++* 知识管理（Knowledge management）
++
++为日常使用、培训和丰富组织文化而设计的进行收集、组织、结构化和分发知识活动的集合，在整个服务生命周期中，通过提供充足、可信、可靠的知识，提升服务和组织决策的质量和效率。
++
++
++=   =
++
++=   =
++
++= **2. 事件管理流程介绍** =
++
++==  **2.1 流程目的** ==
++
++事件管理流程是负责解决IT服务的突发事件的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以事件管理的特点往往是以解决表征现象为目的，而不在于查找根本原因。
++
++
++==  **2.2 流程主要内容** ==
++
++事件管理流程着眼于快速解决IT环境中的突发事件，并降低其对业务的影响度，流程内容如下：
++
++**检测和记录**  事件的主要来源包括监控系统自动上报和用户电话生成,所有事件都需要被记录。
++
++
++**判断并分派**  确定是服务请求、事件、咨询还是投诉。如果是事件，收集信息, 确定事件影响，尝试解决问题。
++
++
++**服务台尝试解决**  确定是否能由服务台解决，如果无法解决则由服务台分派给后线支持人员进一步诊断处理。
++
++
++**调查和诊断**  一线、二线和三线（厂商、集成商、服务商等）支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决事件。
++
++
++**服务台确认**  对事件的解决方案进行确认，如未解决，根据情况重新分派。
++
++
++**结束**   如果确认已解决，关闭记录，更新文档。
++
++
++==  **2.3 业务价值** ==
++
++事件管理流程将在多方面对XX客户的IT服务产生积极作用，具体表现在：
++
++**提高服务可用性** –  不管什么原因，当用户不能使用IT提供的IT服务的时候(如设备宕机，网络过载等)，服务都是被认为不可用的，它影响了用户的生产率。事件管理流程通过保证事件的快速处理来达到服务可用性的最大化。
++
++**提高客户满意度 – **事件管理流程通过记录和管理事件的集成系统来提供有效服务。同时，也提供了服务供应者和使用者的沟通渠道，加强了技术运维中心和用户之间的双向认同。
++
++**集中化事件数据 –** 通过事件管理流程来统一收集事件数据，这些数据被其他流程所使用，如问题管理流程将分析这些数据以确定事件的根本原因，并确定纠正措施以消除再次发生的可能性。
++
++
++
++
++= **3. IT服务模式** =
++
++XX客户的IT服务支撑工作由所内运维人员和外部厂商、服务商共同承担，按照职责和技能划分为服务台、一线、二线、三线的层级支撑结构，服务台作为面向用户的统一入口，主要负责事件的受理和分派；一、二、三线支持由所内技术人员和外部支持人员组成，负责解决事件。IT服务模式如下图所示：
++
++(% style="text-align:center" %)
++[[image:1730524160214-385.png]]
++
++
++
++
++
++= **4. 事件管理的策略与原则** =
++
++==  **4.1 常规原则** ==
++
++1. 服务台是IT部门向IT用户提供的单一联系点，(通过电话、邮件等)对事件进行集中响应；
++1. 任何IT事件都必须执行事件管理流程。服务台提交事件单，所有事件或服务请求及其解决方案，都要记录在IT服务管理平台中；
++1. 服务台是事件处理过程的监督人，负责跟踪事件的处理，确保事件能按时解决；
++1. 定义服务台、一线支持、二线支持、三线支持人员，并落实到人员，使IT支持人员明确自己的角色和相关的责任，流程能够得到正确的执行，保证服务的质量，使IT人员变成服务人员。
++
++
++==  **4.2 沟通原则** ==
++
++1. 事件管理流程将就任何已知的或可能的事件的相关情况与受到影响的用户进行沟通。在事件解决过程中，服务台应及时向最终用户通报事件的处理情况，使用户了解事件的解决状态；
++1. 对于已知或计划内的服务中断要及时准确的提前通知所有受影响的部门和用户。
++
++
++== ** 4.3 事件升级原则** ==
++
++为了确保重要事件的及时解决，应严格执行定事件升级流程。制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到事件的解决方案。
++
++1. 服务台、一线、二线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理；
++1. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，系统应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时响应和处理。
++
++
++==  **4.4 事件关闭原则** ==
++
++1. 事件的关闭遵循谁开单谁关闭的原则；（由IT用户申报的事件单，关闭必须由服务台完成）
++1. 紧急程度较低的事件可设定自动关闭时间，在解决一段时间后由系统自动关闭。
++
++
++== ** 4.5 定期回顾原则** ==
++
++建立定期的服务回顾和检查制度。
++
++1. 回顾本周期内的故障记录，分析是否需要提出问题；
++1. 回顾正在进行中的故障（查看故障处理记录，工作日志、处理状态等等），分析是否存在优先级较高的待解决的故障，需要协调解决。
++
++
++==  **4.6 流程关联原则** ==
++
++* 和问题管理流程的关系
++
++事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。
++
++* 和配置管理流程的关系
++
++需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速恢复。
++
++* 和变更管理流程的关系
++
++服务台应了解变更管理流程中目前正在进行的变更信息。在事件的解决过程中，涉及变更都需要发起变更请求来解决事件。
++
++事件的处理涉及启动变更流程RFC。
++
++* 和知识管理流程的关系
++
++常见故障的解决方案可以升级为知识，或用户常用的服务呼叫和技术咨询类的流程规范和操作手册等都将是知识管理流程的入口。
++
++事件流程查询知识库知识信息，为事件处理提供支持。
++
++
++==  **4.7 紧急事件处理原则** ==
++
++当发生事件优先级为特大或者重大的事件后，服务台应立即通知事件经理，由事件经理通知相关领导共同协调相关资源，启动紧急事件流程（参见《大连商品交易所信息系统应急处置报告流程》），待事件处理完毕后再由事件处理人登陆系统补录事件信息。
++
++
++
++
++= **5. 事件管理的人员角色和职责** =
++
++XX客户事件管理流程设计的角色包含事件经理、服务台及一线、二线、三线支持。
++
++
++==  **5.1 事件管理流程负责人** ==
++
++事件管理流程负责人从宏观上监控流程，确保事件流程被正确执行。当流程不能够适应技术运维中心的维护要求时，流程负责人必须及时分析、找出缺陷、进行改进，从而实现流程的可持续提高。
++
++**职责：**
++
++1. 确保事件流程能够取得管理层的参与和支持；
++1. 总体上管理和监控流程，对事件管理流程的规划、实施、监督、改进负责；
++1. 保持与其他流程负责人的定期沟通；
++1. 定期召开部门级别的流程回顾会议（如每个季度1次）；
++1. 进行流程优化的发起，负责决定优化活动的负责人，并检查跟踪执行情况。
++
++**技能要求：**
++
++1. 深刻理解事件管理流程；
++1. 理解业务对于事件管理的需求；
++1. 良好的沟通技能，能够取得公司高层的支持，获得所需资源。
++
++
++==  **5.2 事件经理** ==
++
++事件经理负责事件解决过程中的协调和监控，事件升级的判断以及具体执行。
++
++**职责:**
++
++1. 负责协调资源，保证事件得到最终解决；
++1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题；
++1. 确保和问题管理流程经理的有效合作；
++1. 参与流程改进活动，提出流程改进建议。
++
++**技能要求:**
++
++1. 深刻了解事件管理流程；
++1. 较强的领导能力；
++1. 了解技术架构和技术环境；
++1. 了解维护支撑架构和人员岗位分工；
++1. 较强的口头表达能力和客户沟通技巧；
++1. 处理纠纷的能力。
++
++
++==  **5.3 服务台** ==
++
++服务台人员负责接收所有事件，对事件进行初步处理，不能处理的事件分派到合适的一线支持或者二线支持人员。
++
++**职责：**
++
++1. 受理不同来源的事件，包括电话、邮件等；
++1. 对事件进行分析和诊断，尝试提供解决方案；
++1. 事件解决后，在关闭事件前向用户进行确认事件已解决；
++1. 结束事件，更新信息。
++
++**技能要求：**
++
++1. 熟悉技术平台和技术环境；
++1. 熟悉事件管理流程；
++1. 熟悉维护支撑架构和人员岗位分工；
++1. 良好的工作素养和服务态度；
++1. 一定的技术能力；
++1. 较强的沟通能力。
++
++
++==  **5.4 一线支持** ==
++
++一线支持人员负责对服务台分派的事件进行分析，提出解决方案，并在必要时提供现场支持。
++
++**职责：**
++
++1. 验证事件的描述，进一步收集相关信息；
++1. 在规定的时间内解决事件；
++1. 在需要时及时利用其它资源(开发商, 厂家) 参与事件解决；
++1. 根据解决方案进行IT服务恢复；
++1. 向服务台人员提供必要的技术支持和协助；
++1. 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认。
++
++**技能要求：**
++
++1. 熟悉技术平台和技术环境；
++1. 较强的技术能力；
++1. 较强的分析能力。
++
++
++==  **5.5 二线支持** ==
++
++二线支持人员是技术领域的专家。处理一线支持人员无法解决的事件，实施解决方案。
++
++**职责：**
++
++1. 验证事件的描述，进一步收集相关信息；
++1. 在规定的时间内解决事件；
++1. 在需要时及时利用其它资源(开发商, 厂家) 参与事件解决；
++1. 根据解决方案进行IT服务恢复；
++1. 向服务台人员提供必要的技术支持和协助；
++1. 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认。
++
++**技能要求：**
++
++1. 某项技术领域的专家；
++1. 资深技术背景和技术能力；
++1. 较强的分析能力。
++
++
++==  **5.6 三线支持** ==
++
++对于XX客户运维中心来说，三线支持主要是外部厂商，在事件处理流程中，由一线或二线支持专家，来协调三线人员协助处理事件。
++
++**职责：**
++
++1. 验证事件的描述，进一步收集相关信息；
++1. 在规定的时间内解决事件；
++1. 负责协调厂商、开发商内部资源；
++
++
++**技能要求：**
++
++1. 熟悉术平台和技术环境；
++1. 相关技术领域专家；
++1. 较强的分析能力。
++
++
++
++
++= **6. 技术平台相关代码定义** =
++
++== ** 6.1 事件单信息项** ==
++
++|**编号**|**属性**|**说明**
++|1|事件ID|事件IM/服务请求SR/问题PM/变更CH例如：IM090224000001
++|2|状态|事件单当前状态，参见“事件状态”定义
++|3|事件分类|对事件的具体分类，参见“事件分类”定义
++|4|所属系统|事件所属系统，参见“所属系统”
++|5|优先级|参见“优先级”定义
++|6|简要描述|事件的简要描述（手工填写）
++|7|详细描述|对于整个事件内容的详细描述（手工填写）
++|8|活动日志|处理步骤的活动记录，包括类型、人员、日期、更新内容（系统自动产生）
++|9|登记人|创建此单的人，默认当前登录人
++|10|申请人|事件发起人
++|11|分派组|事件的当前处理组
++|12|分派人|事件的当前处理人
++|13|解决方案|包含事件的原因分析以及处理过程
++|14|事件结束代码|参见“事件结束代码”定义
++|15|创建时间|开单时间
++|16|更新时间|最后更新的时间
++|17|计划响应时间|由“优先级”决定
++|18|实际响应时间|事件实际开始处理时间（系统自动产生）
++|19|是否按时响应|由“计划响应时间”“实际响应时间”比较的结果决定
++|20|计划完成时间|由“优先级”决定
++|21|实际完成时间|状态更新为“已解决”的时间
++|22|事件支持满意度|参见“事件支持满意度”定义
++|23|是否需要三线厂商支持|标记该事件是否涉及第三方厂商
++|24|附件|相关附件
++|25|配置项|相关配置项
++|26|相关|事件、服务请求、问题、变更之间的关联
++|27|事件来源|参见“事件来源”定义
++|28|重复事件|标识重复事件
++
++==   ==
++
++== ** 6.2 任务单信息项** ==
++
++维护任务单包含如下信息项：
++
++|**编号**|**信息项**|**说明**
++|1|任务单ID|系统自动产生
++|2|创建时间|系统自动产生
++|3|类型|对任务的具体分类，参见“事件分类”定义
++|4|简要描述|任务的简要描述（手工填写）
++|5|执行内容|对于整个任务内容的详细描述（手工填写）
++|6|所属业务系统|任务所属系统，参见“所属系统”
++|7|状态|任务单当前状态，参见“事件状态”定义
++|8|活动日志|处理步骤的活动记录，包括类型、人员、日期、更新内容（系统自动产生）
++|9|执行人|任务的执行人
++|10|执行组|任务的执行人所属工作组
++|11|执行结果描述|任务的执行结果
++|12|响应时间|任务实际开始执行的时间，系统自动填写
++|13|实际完成时间|任务实际完成的时间，系统自动填写
++|14|任务结束代码|参见“事件结束代码”定义
++|15|附件|相关附件
++|16|配置项|相关配置项
++|17|相关|与事件、问题、变更之间的关联
++
++
++==  **6.3 所属系统** ==
++
++|**类别**|**子类别**|
++|(% rowspan="11" %)核心系统|六期交易系统|N/A
++|六期业务系统|N/A
++|会展灾备系统|N/A
++|新风控系统|N/A
++|统一开户系统|N/A
++|电子出入金系统|N/A
++|RTT系统|N/A
++|交易所网站系统|N/A
++|会员服务系统|N/A
++|邮件订阅系统|N/A
++|电子仓单系统|N/A
++|(% rowspan="20" %)非核心系统|模拟交易系统|N/A
++|期权模拟系统|N/A
++|会员测试系统|N/A
++|开发商测试系统|N/A
++|协作平台系统|N/A
++|所内日志系统|N/A
++|办公OA系统|N/A
++|办公内网邮件系统|N/A
++|办公外网邮件系统|N/A
++|车辆管理系统|N/A
++|黑莓管理系统|N/A
++|IT运行监控系统|N/A
++|办公防病毒系统|N/A
++|交易大厅|N/A
++|业务终端|N/A
++|KVM系统|N/A
++|GPS时间源系统|N/A
++|门禁系统|N/A
++|安防系统|N/A
++|集控系统|N/A
++|(% rowspan="2" %)核心网络|交易网|N/A
++|网站网|N/A
++|(% rowspan="4" %)非核心网络|办公内网|N/A
++|办公外网|N/A
++|开发测试网|N/A
++|证监会机密网|N/A
++
++
++==  **6.4 事件分类** ==
++
++对事件进行分类，主要目的在于方便各个事件处理组之间的信息沟通，为事件的诊断和处理提供信息，并产生相关的管理信息报表，从而达到优化提高IT服务质量，提高事件处理效率的目标。
++
++|**第一层**|**第二层**|**第三层**
++|(% rowspan="11" %)软件类|(% rowspan="7" %)系统软件类|操作系统
++|集群软件
++|中间件
++|备份软件
++|安全软件
++|数据库
++|监控软件
++|应用软件类|对应所属系统中的内容
++|(% rowspan="3" %)其他|集控系统
++|门禁系统
++|安防系统
++|(% rowspan="28" %)硬件类|(% rowspan="4" %)服务器类|小型机
++|刀片服务器
++|PC 服务器
++|其他
++|(% rowspan="8" %)网络设备类|路由器
++|交换机
++|网关
++|防火墙
++|VPN
++|负载均衡
++|链路
++|其他
++|(% rowspan="8" %)安全设备类|入侵检测
++|入侵防御
++|安全审计
++|防病毒网关
++|防病毒分析
++|安全管理平台
++|网闸
++|其他
++|(% rowspan="6" %)存储设备类|磁盘阵列
++|NAS
++|磁带库
++|光盘库
++|存储光纤交换机
++|其他
++|(% rowspan="2" %)其他|KVM设备
++|其他
++|(% rowspan="9" %)其他|(% rowspan="6" %)机房设备|配电柜
++|空调
++|机柜
++|UPS
++|ATS
++|其他
++|文档|
++|合同|
++|介质|
++|(% rowspan="12" %)交易大厅|(% rowspan="7" %)硬件类|主机
++|键盘
++|鼠标
++|电源
++|网络
++|其他
++|
++|(% rowspan="4" %)软件类|操作系统
++|交易软件
++|管理软件
++|其他
++|其他|
++|(% rowspan="4" %)业务终端|(% rowspan="2" %)硬件类|PC
++|网络
++|(% rowspan="2" %)软件类|业务软件
++|管理软件
++
++
++
++==  **6.5 影响度、优先级** ==
++
++通过事件的“影响程度”来评估每个事件的“优先级”。
++
++* **优先级**
++
++|**编号**|**代码**|**解释**
++|1|P1|特大事件
++|2|P2|重大事件
++|3|P3|较大事件
++|4|P4|普通事件
++|5|P5|次要事件
++
++
++* **影响程度**
++
++|**编号**|**事件级别**|**影响程度**
++|1|特大事件|(((
++因部门原因，导致重要业务系统出现异常，系统恢复时间（RTO-Recovery Time Objective）在30 分钟以上，影响所有客户：
++
++1. 交易主机因非应用软件原因宕机，导致核心交易中断。
++1. 交易核心网络故障，导致所有交易大厅或所有远程会员无法联通交易。
++1. 数据库故障导致交易、结算、行情数据发生严重错误，影响所有会员。
++1. 信息安全原因导致核心交易中断。
++1. 应用软件的日常维护、启停原因，导致核心交易中断。
++1. 因病毒、攻击、拥堵等使系统异常，给市场或客户造成可感知的影响，且交易时段2 个小时内没有恢复。
++1. 业务数据完整性被破坏，且在1 个交易日内没有修复。
++1.  通信线路发生故障，对业务造成严重影响，10%以上会员无法正常交易，且在1 个交易日系统没有恢复正常。
++1. 灾害事故（停电、水灾、火灾等）发生后，重要业务系统在一个交易日系统没有恢复正常。
++1. 网站上出现有害信息，且未能及时删除、屏蔽或未能保留审计线索的。
++1. 其他因部门原因，导致核心交易中断。
++)))
++|2|重大事件|(((
++因部门原因，导致重要业务系统出现异常，系统恢复时间（RTO-Recovery Time Objective）在30 分钟以内，影响所有客户：
++
++1. 因病毒、攻击、拥堵等使系统异常，给市场或客户造成可感知的影响，但交易时段2 个小时内恢复的。
++1. 系统数据完整性被破坏，但在1 个交易日内能够修复的。
++1. 灾害事故（停电、水灾、火灾等）发生后，重要业务系统能在1 个交易日恢复正常。
++1. 网站上出现有害信息，但能及时删除、屏蔽并保留审计线索的。
++1. 通信线路发生故障且对业务造成不良影响，10%以上会员无法正常交易，1 个交易日内系统恢复正常。
++1. 敏感业务数据泄漏。
++1. 机房空调无法正常运转导致部分核心主机运行故障，影响部分会员正常交易。
++1. 交易核心或交易所自身远程网络故障导致10%以上会员无法交易。
++1. 互联网系统出现非计划性网络中断，所有外部网络不可达，网站系统无法提供服务达2 小时以上。
++1. 全部或大部分会员或所有信息公司无法收到行情达2 小时以上。
++)))
++|3|较大事件|(((
++主要服务对少部分会员（5％~~10%）产生了一定影响。
++
++1. 由于系统、网络、数据库、应用运行、监控、信息安全等原因导致交易系统、结算系统、行情系统故障，致使个别
++1. 会员（5％~~10%）无法正常交易、接收行情2 小时内没有恢复。
++1. 因非行情软件和计划原因导致交易大厅大屏幕行情无法显示或显示错误，一个交易日以上没恢复。
++1. 互联网系统出现中断，所有外部网络不可达，达1～2 小时。
++1. 交易、交割、结算、监察业务终端出现非软件故障，导致某业务部门所有终端无法进行业务管理操作达1～2 小时。
++1. 办公网病毒大规模爆发或邮件系统故障，影响所有员工办公达2～4 小时。
++)))
++|4|普通事件|(((
++服务出现问题，但大部分功能仍然可用，影响个别会员（<5%）。
++
++1. 由于系统、网络、数据库、应用运行、监控、信息安全等原因导致交易系统、结算系统、行情系统故障，致使个别
++1. 会员无法正常交易、接收行情、收取结算数据延迟，但未超过30 分钟。
++1. 我所互联网和办公网系统出现故障：外部网络不可达，但时间小于1 小时；办公网络中断或者网络拥塞，但通过处理，2 小时内能够快速恢复。
++1. 客户端一般故障处理。
++1. 非交易系统技术故障，由于系统冗余、自动切换、非交易时间或系统重启可恢复，对客户的潜在影响较小，不会对客户产生可感知的影响。
++1. 局部办公网络短暂中断。
++1. 所领导办公电脑故障。
++)))
++|5|次要事件|(((
++技术请求和服务类事件，或者一般事件，对客户不产生负面影响
++
++1.  一般系统技术故障，由于系统冗余、自动切换、非交易时间或系统重启可恢复，对客户没有产生可感知的影响。
++1. 所内个别员工办公电脑故障、电子邮件故障。
++1. 开通行情、成交回报，交易大厅终端、业务系统终端安装。
++1. 数字证书处理。
++1. 服务请求。
++)))
++
++
++==  **6.6 优先级和解决时限** ==
++
++对于不同的事件优先级，事件处理的解决时限要求和响应时限要求不同。
++
++|**编号**|**优先级代码**|**解决时限（工作时间）**|**响应时限**
++|1|P1|1个小时|5分钟
++|2|P2|0.5个小时|10分钟
++|3|P3|3个小时|0.5小时
++|4|P4|24个小时|2小时
++|5|P5|48个小时|4小时
++
++
++**解决时限的定义**：事件单的实际完成时间（状态为已解决） － 事件单的分派时间（状态为处理中）。
++
++**响应时限的定义**：事件单的响应时间（状态处理中）－ 事件单的创建时间（状态为已分派）。
++
++==   ==
++
++== **6.7 事件通告路径** ==
++
++对于特大和重大的事件，需要及时通告事件经理。如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。具体定义如下表：
++
++**超出和即将超出时限的通告定义**
++
++|**事件级别**|**通告条件**
++|(% rowspan="3" %)特大事件|(((
++1. 特大事件登记后立即通知事件经理、技术负责人、相关主岗、中心领导
++)))
++|(((
++1. 特大事件超过5分钟未响应立即通知事件经理、技术负责人、相关主岗、中心领导
++)))
++|(((
++1. 特大事件超过1小时未解决立即通知事件经理、技术负责人、相关主岗、中心领导
++)))
++|(% rowspan="3" %)重大事件|(((
++1. 重大事件登记后立即通知事件经理、技术负责人、相关主岗、中心领导
++)))
++|(((
++1. 重大事件超过5分钟未响应立即通知事件经理、技术负责人、相关主岗、中心领导
++)))
++|(((
++1. 重大事件超过1小时未解决立即通知事件经理、技术负责人、相关主岗、中心领导
++)))
++|(% rowspan="2" %)较大事件|(((
++1. 较大事件超过30分钟未响应立即通知事件经理、技术负责人、相关主岗
++)))
++|(((
++1. 较大事件超过1小时未解决立即通知事件经理、技术负责人、相关主岗
++)))
++|(% rowspan="2" %)普通事件|(((
++1. 普通事件超过2小时未响应立即通知事件经理、技术负责人、相关主岗
++)))
++|(((
++1. 普通事件超过24小时未解决立即通知事件经理、技术负责人、相关主岗
++)))
++|(% rowspan="2" %)次要事件|(((
++1. 次要事件超过4小时未响应立即通知事件经理、技术负责人、相关主岗
++)))
++|(((
++1. 次要事件超过48小时未解决立即通知事件经理、技术负责人、相关主岗
++)))
++
++
++== ** 6.8 事件状态** ==
++
++|**编号**|**代码**|**描述**
++|1|已登记|新开事件记录或事件已创建
++|2|已分派|事件已经分配给支持人员，等待处理人处理
++|3|处理中|支持人员已接手处理事件
++|4|已解决|事件已解决
++|5|关闭|事件已关闭
++
++
++== ** 6.9 事件结束代码** ==
++
++|**编号**|**代码**|**描述**
++|1.|服务台解决|由服务台维护解决
++|2.|一线解决|由一线找到事件的根本原因或替代方法
++|3.|二线解决|由二线找到事件的根本原因或替代方法
++|4．|三线解决|由外部人员或外部厂商解决
++|5.|未解决|未解决
++|6.|自动恢复|系统自动恢复，事件无法再现
++|7.|误报|属于误报事件
++|8．|拒绝|事件被拒绝
++
++
++==  **6.10 事件来源** ==
++
++|**编号**|**代码**|**备注**
++|1.|电话|服务台通过客户电话创建的
++|2.|监控系统|监控系统通过接口自动创建的
++|3.|巡检自发现|日常检查过程中由工程师自发现
++|4.|EMAIL|服务台根据客户EMAIL创建的
++|5|短信|短信报警
++
++
++==  **6.11 事件支持满意度 ** ==
++
++|**编号**|**代码**|**备注**
++|1|非常好|用户非常满意
++|2|正常|用户接受处理结果
++|3|需要提高|用户认为对处理过程或结果不满意
++
++
++
++
++= **7. 事件管理流程概要设计** =
++
++(% style="text-align:center" %)
++[[image:图片2.jpg]]
++
++
++
++事件管理概要设计流程说明：
++
++|**序号**|**步骤名称**|**责任人**|**说明**
++|100.1|事件记录和分类|服务台|(((
++*   服务台对来自用户和系统自动产生的事件进行详细记录
++* 服务台负责在接收到事件后进行分类转发，对于初步判断为重大和特大的事件马上转102走紧急事件处理流程
++* 对于非支撑维护职责范围的事件转给其它相关责任部门
++)))
++|100.2|初始事件支持|服务台|(((
++* 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无法解决需及时升级到一/二线支持
++* 不属于服务台职责范围的事件，立即分派到相应的一/二线支持
++)))
++|(((
++100.3
++
++100.4
++)))|一线/二线尝试解决|一线支持/二线支持|(((
++* 一线/二线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决
++* 在必要时根据服务协议联系厂商帮助解决并负责核查
++* 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
++* 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
++* 不能解决的事件，转100.5三线尝试解决
++* 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
++)))
++|100.5|三线尝试解决|三线支持|(((
++* 三线支持人员接受事件，进行调查诊断，提出解决方案
++)))
++|100.6|记录解决方案细节|(((
++服务台
++
++一线支持
++
++二线支持
++)))|(((
++* 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
++)))
++|100.7|关闭事件|服务台|(((
++* 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决而关闭；否则，事件以不成功关闭，重新开事件记录，分派到原处理人员继续处理
++* 处理过程对后续工作有指导或参考的，录入知识库
++)))
++|100.8|事件处理的监控|(((
++服务台
++
++事件经理
++)))|(((
++* 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注
++* 事件经理负责协调资源，保证事件的最终解决
++)))
++|102|紧急事件处理流程|事件经理|(((
++* 事件经理负责协调紧急事件的处理，具体过程根据所内规定处理，参见《大连商品交易所信息系统应急处置报告流程》，处理完成后，由处理人负责补录事件信息
++)))
++
++
++
++
++= **8. 事件管理流程详细设计** =
++
++==  **8.1 (100.1)事件记录和分类** ==
++
++(% style="text-align:center" %)
++[[image:图片3.jpg]]
++
++
++
++流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|100.1.1|新建事件|一或二线支持|自行发现|完整的事件单|(((
++由一二线内部新建事件单，填写的详细内容如下：
++
++1. 事件标题和描述
++1. 必要的附件
++1. 事件来源和事件性质
++1. 进行事件分类
++)))
++|100.1.2|从非监控事件队列中接受事件|服务台|事件队列|需要处理的事件|(((
++事件任务队列的来源：非监控系统自动发送的事件
++
++服务台负责检查事件任务队列中的新事件单，开始处理
++)))
++|100.1.3|新建事件|服务台|电话、邮件|新建的事件记录|(((
++属于职责范围，服务台负责创建新的事件单，填写详细情况描述，不属于职责范围处理的，直接电话回复。
++
++事件单填写的详细内容如下：
++
++1. 报告人姓名、联系电话、邮件、部门
++1. 事件描述
++1. 必要的附件
++1. 事件来源和事件性质
++1. 进行事件分类
++)))
++|100.1.4|跟踪监控事件队列中的事件|服务台|事件队列|事件队列|(((
++事件任务队列的来源：监控系统自动发送的告警
++
++服务台负责检查、跟踪事件任务队列中的新事件单
++)))
++|100.1.5|标记重复事件|服务台|重复事件| |设置重复事件标识
++|100.1.6|事件信息项区分、确认|服务台|事件记录|确定了信息项的事件|根据上报的事件描述，审核信息项填写的规范性和准确性，判断对业务的影响程度，并对照优先级代码表，确定事件的优先级等相关属性。
++| |事件级别为重大、特大吗？|服务台|事件级别|相应的处理流程|(((
++服务台根据业务的影响程度和事件优先级判定的条件，初步判断优先级别：
++
++1. 事件级别为重大、特大，转102紧急事件流程；
++1. 其它优先级否，转100.2初始支持
++)))
++
++
++== ** 8.2 (100.2)初始事件支持** ==
++
++(% style="text-align:center" %)
++[[image:1730524637959-354.png]]
++
++
++ 流程描述如下：
++
++(% style="text-align:center" %)
++[[image:1730524713654-234.png]]
++
++
++== **8.3 (100.3)（100.4） 一、二线尝试解决**  ==
++
++(% style="text-align:center" %)
++[[image:图片4.jpg]]
++
++
++流程描述如下：
++
++(% style="text-align:center" %)
++[[image:1730524828187-986.png]]
++
++(% style="text-align:center" %)
++[[image:1730524846251-329.png]]
++
++
++
++== ** 8.4 (100.3.5) 子任务分派** ==
++
++=== **8.4.1 (100.3.5.1)分派任务子单** ===
++
++
++(% style="text-align:center" %)
++[[image:1730524881557-666.png]]
++
++
++具体描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**物理流程描述**
++|100.3.5.1.1|创建子任务单|一或二线支持|根据事件的信息描述，判断需要拆分成几个任务子单。
++|100.3.5.1.2|填写子单信息|一或二线支持|创建任务子单，补充或者填写子单信息，设置分派组和分派人信息。
++|100.3.5.1.3|保存子单|一或二线支持|保存子单信息。
++| |继续创建子任务？|一或二线支持|(((
++判断该是否需要继续添加子单，
++
++如果是转100.3.5.1.1继续创建任务子单；
++
++否则转100.3.5.1.4；
++)))
++|100.3.5.1.4|保存主单|一或二线支持|保存主单信息。
++
++
++=== **8.4.2 (100.3.5.2)任务处理** ===
++
++(% style="text-align:center" %)
++[[image:1730524913347-652.png]]
++
++
++具体描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**物理流程描述**
++|100.3.5.2.1|尝试找出解决方案|一或二线支持|根据事件的信息描述，分析事件的原因，并尝试找出解决方案，并做相关处理
++|100.3.5.2.2|记录解决方案|一或二线支持|将成功的解决方案和结束代码记录在系统中，并更改任务单状态为“已解决”。
++
++
++=== **8.4.3 (100.3.5.3)关闭任务单 ** ===
++
++
++(% style="text-align:center" %)
++[[image:1730524939675-902.png]]
++
++具体描述如下：
++
++
++|**序号**|**步骤名称**|**责任人**|**物理流程描述**
++|100.3.5.3.1|更新任务单|一或二线支持|更新任务单，包括解决方案，确认情况，用户反馈等。确保信息的完整性。
++|100.3.5.3.2|选择结束代码|一或二线支持|根据具体情况选择相应任务结束代码（同事件结束代码）
++|100.3.5.3.3|关闭子任务|一或二线支持|任务单关闭后，系统自动发送通知给主单处理人，告知任务单处理情况。
++| |所有任务单都完成？|一或二线支持|(((
++如果事件主单的分单人是自己，查看所有的子单是否都已经完成，并对任务完成情况进行填写。
++
++1. 如果是，则转到100.6，记录事件解决方案
++1. 如果否，则转到100.3.5.3.4等待其他任务完成
++)))
++|100.3.5.3.4|等待其他任务|一或二线支持|等待其他主单相同的子任务单完成
++
++
++== ** 8.5 (100.5)三线尝试解决** ==
++
++
++(% style="text-align:center" %)
++[[image:1730524973588-662.png]]
++
++
++ 流程描述如下：
++
++(% style="text-align:center" %)
++[[image:1730525028141-604.png]]
++
++(% style="text-align:center" %)
++[[image:1730525047226-162.png]]
++
++
++
++== **8.6 (100.6)记录解决方案细节** ==
++
++(% style="text-align:center" %)
++[[image:1730525082556-315.png]]
++
++流程描述如下：
++
++(% style="text-align:center" %)
++[[image:1730525124138-763.png]]
++
++
++== ** 8.7 (100.7)关闭事件** ==
++
++(% style="text-align:center" %)
++[[image:1730525151347-177.png]]
++
++流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++| |监控系统自动告警？|服务台|事件记录|事件记录|(((
++服务台判断是否是监控系统自动产生的告警；
++
++1. 是，转100.7.1更新事件状态
++1. 否，转100.7.2与用户处确认事件解决
++)))
++|100.7.1|更新事件状态及结束代码，关闭事件|服务台|已解决的事件记录|关闭的事件|更新事件记录，状态为“关闭”，结束代码根据实际处理结果或用户反馈确定；如果是由监控生成的事件，由系统自动关闭。
++|100.7.2|确认事件解决|服务台|用户反馈|反馈结果|从事件请求人处确认所提供的解决方案是否有效
++| |是否解决？|服务台| | |(((
++判断是否解决方案是否有效？
++
++1. 是，转100.7.1
++1. 否，转100.7.3重开单处理
++)))
++|100.7.3|重开单处理|服务台|未解决的事件记录|新的事件记录|(((
++服务台将该事件单的结束代码置为“未解决”，关闭保存；
++
++对事件进行重开单操作，分配到原处理人员处理，新事件单状态“已分派”
++
++注：服务台应该和原处理人员沟通事件的确认结果和后续的处理方式
++)))
++
++
++== **8.8 (100.8)事件处理监控** ==
++
++(% style="text-align:center" %)
++[[image:1730525194678-810.png]]
++
++流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|100.8.1|事件队列的监控|事件经理|(((
++当前打开的事件单
++
++服务管理平台的超时告警
++)))| |(((
++事件经理可以从以下途径获取事件处理的信息
++
++1. 服务台系统自动发送的告警通知
++1. 查询服务台系统的当前处理中的事件列表
++)))
++| |需要介入吗？|事件经理| | |(((
++事件经理根据处理时限和该事件对业务的影响程度，判断是否需要及时介入，帮助协调资源解决
++
++1. 需要介入，转100.8.2
++1. 不需要，则继续监控
++)))
++|100.8.2|召集资源协商解决|事件经理|(((
++告警事件
++
++支持人员的电话通知
++)))|解决方案|由于处理不及时而可能导致用户满意度下降的事件或疑难事件，事件经理负责召集相应二线专家，共同商讨并制定解决方案，并实施解决方案
++| |可以解决吗？|事件经理| | |(((
++1. 如果解决，转100.7关闭事件
++1. 无法解决，转100.8.3升级到管理层解决
++)))
++|100.8.3|升级到管理层解决|事件经理|升级的事件记录|解决方案|事件经理负责将升级事件通报到管理层，通过高层寻求更多的资源介入，共同商讨和制定解决方案
++
++
++
++
++= **9. 事件管理流程关键指标** =
++
++为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
++
++|**序号**|**衡量指标**|**作用**
++|1|服务台受理事件总数|考察统计周期内服务台受理的事件总量，用来衡量总工作量
++|2|事件成功关闭的数量/比率|考察统计周期内事件成功结束数量，衡量事件质量，如果比率过高需要事件经理重点关注
++|3|超时的事件数量/百分比|考察统计周期内事件超时结束数量，衡量事件质量，如果比率过高需要事件经理重点关注
++|4|平均解决时间|考察统计周期内事件平均解决时间，衡量事件质量，如果平均时间过高需要事件经理重点关注
++|5|服务台解决率|考察统计周期内服务台解决率，衡量事件质量，应当提高服务台解决率
++|6|重复事件数量|考察统计周期内重复事件数量，应当降低重复事件数量
++|7|超时未解决的事件数量|统计周期内超过预定解决时间未解决的事件数量，应当降低超时未解决事件数量
++|8|个人事件总数|考察周期内具体工程师处理事件的数量
++|9|个人超时未解决的事件数量|统计周期内具体工程师超过预定解决时间未解决的事件数量
++|10|具体类别事件发生总数|统计周期内具体类别事件的发生总数
++
++
++
++= **10. 流程持续改进机制**  =
++
++(% style="text-align:center" %)
++[[image:1730525249418-337.png]]
++
++运维流程必须经过持续地调整和优化，才能满足不断变化的业务及服务要求。流程的持续改进的具体方法，可以参考上述流程持续改进模型。
++
++* **评估及改进研讨**
++** 根据设定的ITSM基准线对流程的原则与目标、流程责任与授权、管理目标达成情况、与其他流程的关联及相关流程工具等方面进行评估；
++** 根据评估结果，通过研讨，发现已在或潜在的差距和风险，并针对这些差距和风险提出改进建议。根据改进建议的实施成本、风险和耗时等因素，对改进建议进行优先级别排序；
++** 改进原因还可能来自于日常服务管理工作中发现的不足；
++** 生成评估结果及改进建议方案。
++* **制定流程改进计划**
++** 分析改进建议的相关性，并进行有效合理的分类和组合；
++** 针对不同的改进建议组制定具体的改进计划，将具体的改进计划分解成更详细的改进任务和动作，定义改进时间点、责任人、改进成功条件等；
++* **实施具体的改进活动**
++** 根据改进计划的要求，实施具体的流程改进活动；
++** 跟踪改进活动，及时更新改进计划，并上报改进活动进展及成果；
++* **根据业务及服务变化，进行定期评估**
++** 根据业务及服务的变化，对事件管理流程进行相关性评估，以满足业务和服务需求；
++** 除业务及服务变化可触发流程评估外，流程负责人还应定期组织对管理流程的评估和改进；
++
++定期生成流程改进报告（如季度或半年度）。
++
++

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司