12 某市商品交易所ITIL事件管理流程设计说明书

= 1. 综述 =

== 1.1 适用范围与对象 ==

本文档作为本次项目的事件管理流程详细设计的交付物，读者对象为与事件管理流程相关的所有技术与管理人员。

== 1.2 重要参考资料 ==

ITIL（IT Infrastructure Library ）V3.0。

《大XX事件、变更级别说明》。

== 1.3 相关术语 ==

* ITIL（IT Infrastructure Library ）

19

20

是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。

* ISO20000

国际标准组织ISO/IEC在2005年底发布的全球IT服务管理标准，包括服务实施、控制、发布、解决、关系管理5个域13个流程，强调持续改进过程。ISO20000可以提供针对企业或部门的国际标准认证。

* 服务台（Service Desk）

服务台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。

29

30

* 事件管理（ Incident Management）

31

32

ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

33

34

* 问题管理（Problem Management）

35

36

ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除根本原因从而使类似事件不再发生。同时问题管理流程也负责预防事件的发生。

37

38

* 配置管理（Configuration Management）

39

40

ITIL 流程之一，配置管理负责描述，跟踪和汇报IT基础架构中每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI)。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。

41

42

* 配置管理数据库（CMDB - Configuration Management Database）

43

44

是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。

45

46

* 变更管理（Change Management）

47

48

ITIL流程之一，变更管理通过控制和管理服务相关的变更，使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。

49

50

* 服务级别管理（Service Level Management）

51

52

服务级别管理流程通过签订和维护服务水平协议（SLA）的方式,确保以协定的质量和成本向客户交付既定的服务。同时该流程维护、监控和持续改进协定的服务级别。

53

54

* 日常运维管理（Operation and maintenance management）

55

56

日常运维管理用来支持运行维护人员需要定期重复或临时发起的，需要人工参与执行或检查的日常任务，使日常运维工作规范化，并最大程度实现自动化。

57

58

* 知识管理（Knowledge management）

59

60

为日常使用、培训和丰富组织文化而设计的进行收集、组织、结构化和分发知识活动的集合，在整个服务生命周期中，通过提供充足、可信、可靠的知识，提升服务和组织决策的质量和效率。

= 2. 事件管理流程介绍 =

== 2.1 流程目的 ==

事件管理流程是负责解决IT服务的突发事件的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以事件管理的特点往往是以解决表征现象为目的，而不在于查找根本原因。

== 2.2 流程主要内容 ==

事件管理流程着眼于快速解决IT环境中的突发事件，并降低其对业务的影响度，流程内容如下：

75

76

检测和记录事件的主要来源包括监控系统自动上报和用户电话生成,所有事件都需要被记录。

77

78

79

判断并分派确定是服务请求、事件、咨询还是投诉。如果是事件，收集信息, 确定事件影响，尝试解决问题。

80

81

82

服务台尝试解决确定是否能由服务台解决，如果无法解决则由服务台分派给后线支持人员进一步诊断处理。

83

84

85

调查和诊断一线、二线和三线（飞创公司、厂商、集成商、服务商等）支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决事件。

86

87

88

服务台确认对事件的解决方案进行确认，如未解决，根据情况重新分派。

结束如果确认已解决，关闭记录，更新文档。

== 2.3 业务价值 ==

事件管理流程将在多方面对XX所技术运维中心的IT服务产生积极作用，具体表现在：

97

98

* 提高服务可用性 – 不管什么原因，当用户不能使用IT提供的IT服务的时候(如设备宕机，网络过载等)，服务都是被认为不可用的，它影响了用户的生产率。事件管理流程通过保证事件的快速处理来达到服务可用性的最大化。

99

* 提高客户满意度 – 事件管理流程通过记录和管理事件的集成系统来提供有效服务。同时，也提供了服务供应者和使用者的沟通渠道，加强了技术运维中心和用户之间的双向认同。

100

* 集中化事件数据 – 通过事件管理流程来统一收集事件数据，这些数据被其他流程所使用，如问题管理流程将分析这些数据以确定事件的根本原因，并确定纠正措施以消除再次发生的可能性。

= 3. IT服务模式 =

XX所的IT服务支撑工作由所内运维人员、XX公司和外部厂商、服务商共同承担，按照职责和技能划分为服务台、一线、二线、三线的层级支撑结构，服务台作为面向用户的统一入口，主要负责事件的受理和分派；一、二、三线支持由所内技术人员和外部支持人员组成，负责解决事件。IT服务模式如下图所示：

106

107

(% style="text-align:center" %)

108

[[image:1730084819894-163.png]]

= 4. 事件管理的策略与原则 =

== 4.1 常规原则 ==

1. 服务台是IT部门向IT用户提供的单一联系点，(通过电话、邮件等)对事件进行集中响应；

117

1. 任何IT事件都必须执行事件管理流程。服务台提交事件单，所有事件或服务请求及其解决方案，都要记录在IT服务管理平台中；

118

1. 服务台是事件处理过程的监督人，负责跟踪事件的处理，确保事件能按时解决；

119

1. 定义服务台、一线支持、二线支持、三线支持人员，并落实到人员，使IT支持人员明确自己的角色和相关的责任，流程能够得到正确的执行，保证服务的质量，使IT人员变成服务人员。

== 4.2 沟通原则 ==

1. 事件管理流程将就任何已知的或可能的事件的相关情况与受到影响的用户进行沟通。在事件解决过程中，服务台应及时向最终用户通报事件的处理情况，使用户了解事件的解决状态；

125

1. 对于已知或计划内的服务中断要及时准确的提前通知所有受影响的部门和用户。

== 4.3 事件升级原则 ==

为了确保重要事件的及时解决，应严格执行定事件升级流程。制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到事件的解决方案。

131

132

1. 服务台、一线、二线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理；

133

1. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，系统应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时响应和处理。

== 4.4 事件关闭原则 ==

1. 事件的关闭遵循谁开单谁关闭的原则；（由IT用户申报的事件单，关闭必须由服务台完成）

139

1. 紧急程度较低的事件可设定自动关闭时间，在解决一段时间后由系统自动关闭。

== 4.5 定期回顾原则 ==

建立定期的服务回顾和检查制度。

1. 回顾本周期内的故障记录，分析是否需要提出问题；

147

1. 回顾正在进行中的故障（查看故障处理记录，工作日志、处理状态等等），分析是否存在优先级较高的待解决的故障，需要协调解决。

== 4.6 流程关联原则 ==

* 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。

* 和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速恢复。

* 和变更管理流程的关系

服务台应了解变更管理流程中目前正在进行的变更信息。在事件的解决过程中，涉及变更都需要发起变更请求来解决事件。

事件的处理涉及启动变更流程RFC。

* 和知识管理流程的关系

常见故障的解决方案可以升级为知识，或用户常用的服务呼叫和技术咨询类的流程规范和操作手册等都将是知识管理流程的入口。

169

170

事件流程查询知识库知识信息，为事件处理提供支持。

== 4.7 紧急事件处理原则 ==

当发生事件优先级为特大或者重大的事件后，服务台应立即通知事件经理，由事件经理通知相关领导共同协调相关资源，启动紧急事件流程（参见《XX商品交易所信息系统应急处置报告流程》），待事件处理完毕后再由事件处理人登陆系统补录事件信息。

= 5. 事件管理的人员角色和职责 =

XX所事件管理流程设计的角色包含事件经理、服务台及一线、二线、三线支持。

== ==

== 5.1 事件管理流程负责人 ==

事件管理流程负责人从宏观上监控流程，确保事件流程被正确执行。当流程不能够适应技术运维中心的维护要求时，流程负责人必须及时分析、找出缺陷、进行改进，从而实现流程的可持续提高。

职责：

1. 确保事件流程能够取得管理层的参与和支持；

193

1. 总体上管理和监控流程，对事件管理流程的规划、实施、监督、改进负责；

194

1. 保持与其他流程负责人的定期沟通；

195

1. 定期召开部门级别的流程回顾会议（如每个季度1次）；

196

1. 进行流程优化的发起，负责决定优化活动的负责人，并检查跟踪执行情况。

技能要求：

1. 深刻理解事件管理流程；

1. 理解业务对于事件管理的需求；

1. 良好的沟通技能，能够取得公司高层的支持，获得所需资源。

== 5.2 事件经理 ==

事件经理负责事件解决过程中的协调和监控，事件升级的判断以及具体执行。

职责:

1. 负责协调资源，保证事件得到最终解决；

212

1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题；

213

1. 确保和问题管理流程经理的有效合作；

214

1. 参与流程改进活动，提出流程改进建议。

技能要求:

1. 深刻了解事件管理流程；

1. 较强的领导能力；

1. 了解技术架构和技术环境；

1. 了解维护支撑架构和人员岗位分工；

1. 较强的口头表达能力和客户沟通技巧；

1. 处理纠纷的能力。

== 5.3 服务台 ==

服务台人员负责接收所有事件，对事件进行初步处理，不能处理的事件分派到合适的一线支持或者二线支持人员。

职责：

1. 受理不同来源的事件，包括电话、邮件等；

233

1. 对事件进行分析和诊断，尝试提供解决方案；

234

1. 事件解决后，在关闭事件前向用户进行确认事件已解决；

1. 结束事件，更新信息。

技能要求：

1. 熟悉技术平台和技术环境；

1. 熟悉事件管理流程；

1. 熟悉维护支撑架构和人员岗位分工；

1. 良好的工作素养和服务态度；

1. 一定的技术能力；

1. 较强的沟通能力。

== 5.4 一线支持 ==

一线支持人员负责对服务台分派的事件进行分析，提出解决方案，并在必要时提供现场支持。

职责：

1. 验证事件的描述，进一步收集相关信息；

254

1. 在规定的时间内解决事件；

255

1. 在需要时及时利用其它资源(开发商, 厂家) 参与事件解决；

256

1. 根据解决方案进行IT服务恢复；

257

1. 向服务台人员提供必要的技术支持和协助；

258

1. 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认。

技能要求：

1. 熟悉技术平台和技术环境；

1. 较强的技术能力；

1. 较强的分析能力。

== 5.5 二线支持 ==

二线支持人员是技术领域的专家。处理一线支持人员无法解决的事件，实施解决方案。

职责：

1. 验证事件的描述，进一步收集相关信息；

274

1. 在规定的时间内解决事件；

275

1. 在需要时及时利用其它资源(开发商, 厂家) 参与事件解决；

276

1. 根据解决方案进行IT服务恢复；

277

1. 向服务台人员提供必要的技术支持和协助；

278

1. 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认。

技能要求：

1. 某项技术领域的专家；

1. 资深技术背景和技术能力；

1. 较强的分析能力。

== 5.6 三线支持 ==

对于XX所运维中心来说，三线支持主要是XX公司和外部厂商，在事件处理流程中，由一线或二线支持专家，来协调三线人员协助处理事件。

职责：

1. 验证事件的描述，进一步收集相关信息；

1. 在规定的时间内解决事件；

1. 负责协调厂商、开发商内部资源；

技能要求：

1. 熟悉术平台和技术环境；

1. 相关技术领域专家；

1. 较强的分析能力。

= 6. 技术平台相关代码定义 =

== 6.1 事件单信息项 ==

|**编号**|**属性**|**说明**

313

|1|突发事件ID|事件IM/服务请求SR/问题PM/变更CH例如：IM090224000001

314

|2|状态|事件单当前状态，参见“事件状态”定义

|3|联系人|事件的联系人

|4|位置|事件发生的位置

|5|受影响的配置项|相关配置项

|6|事件来源|参见“事件来源”定义

|7|类别|对事件的具体分类，参见“事件分类”定义

320

|8|子类别|对事件的具体分类，参见“事件分类”定义

|9|服务|事件相关服务

|10|优先级|参见“优先级”定义

|11|厂商|事件相关厂商

|12|是否需要XX公司参与|

|13|是否为重复事件|标识重复事件

|14|独立处理分配组|

|15|独立处理分配人|

|16|是否协作处理|

|17|标题|事件的标题

|18|描述|对于整个事件内容的详细描述

|19|是否为问题候选项|

|20|是否为知识库候选项|

|21|新更新类型|

|22|新更新|

|23|日记更新|

|24|活动类型|

|25|活动日志|处理步骤的活动记录，包括类型、人员、日期、更新内容

|26|是否对客户显示|

|27|相关记录|事件相关记录

|28|添加附件|相关附件

|29|响应时间目标|

== 6.2 任务单信息项 ==

维护任务单包含如下信息项：

|**编号**|**信息项**|**说明**

350

|1|任务单ID|系统自动产生

351

|2|创建时间|系统自动产生

352

|3|类型|对任务的具体分类，参见“事件分类”定义

353

|4|简要描述|任务的简要描述（手工填写）

354

|5|执行内容|对于整个任务内容的详细描述（手工填写）

355

|6|所属业务系统|任务所属系统，参见“所属系统”

356

|7|状态|任务单当前状态，参见“事件状态”定义

357

|8|活动日志|处理步骤的活动记录，包括类型、人员、日期、更新内容（系统自动产生）

|9|执行人|任务的执行人

|10|执行组|任务的执行人所属工作组

|11|执行结果描述|任务的执行结果

|12|响应时间|任务实际开始执行的时间，系统自动填写

362

|13|实际完成时间|任务实际完成的时间，系统自动填写

363

|14|任务结束代码|参见“事件结束代码”定义

364

|15|附件|相关附件

365

|16|配置项|相关配置项

366

|17|相关|与事件、问题、变更之间的关联

== 6.3 事件分类 ==

对事件进行分类，主要目的在于方便各个事件处理组之间的信息沟通，为事件的诊断和处理提供信息，并产生相关的管理信息报表，从而达到优化提高IT服务质量，提高事件处理效率的目标。

372

373

374

|**第一层**|**第二层**|**第三层**

375

|(% rowspan="18" %)软件类|(% rowspan="2" %)系统软件|操作系统

376

|系统管理软件

377

|监控软件|

378

|(% rowspan="6" %)安全软件|终端管理与审计

|安全运营管理平台

|终端准入系统

|漏洞扫描器

|身份认证和帐号管理

|其它

|数据库软件|

|备份软件|

|中间件软件|

|应用软件|

|(% rowspan="4" %)机房软件|集控系统

|门禁系统

|安防系统

|其它

|其它|

|(% rowspan="31" %)硬件类|(% rowspan="3" %)服务器类|小型机

394

|刀片服务器

395

|PC 服务器

396

|(% rowspan="8" %)网络设备类|路由器

|交换机

|流量监控探针

|负载均衡设备

|统一通信设备

|传输设备

|链路

|其它

|(% rowspan="11" %)安全设备类|IDS入侵检测

|IPS入侵防御

|TDS入侵分析

|防病毒网关

|防病毒系统

|防DoS攻击

|安全审计

|数据摆渡

|病毒分析

|签名

|SSL加速

| |其它

|(% rowspan="5" %)存储设备类|存储

|磁带库

|光盘库

|存储光纤交换机

|其它

|(% rowspan="3" %)其他|KVM设备

422

|UPS

423

|ATS

424

|(% rowspan="12" %)交易大厅|(% rowspan="7" %)硬件类|主机

|键盘

|鼠标

|电源

|网络

|(% rowspan="2" %)其它

|

|(% rowspan="4" %)软件类|操作系统

|交易软件

|管理软件

|其它

|其他|

|(% rowspan="4" %)业务终端|(% rowspan="2" %)硬件类|PC

437

|网络

438

|(% rowspan="2" %)软件类|业务软件

|管理软件

== 6.4 影响度、优先级 ==

通过事件的“影响程度”来评估每个事件的“优先级”。

1. **优先级**

|**编号**|**代码**|**解释**

|1|P1|特大事件

|2|P2|重大事件

|3|P3|较大事件

|4|P4|普通事件

|5|P5|次要事件

* **影响程度**

|**编号**|**事件级别**|**影响程度**

460

|1|特大事件|(((

461

因部门原因，导致重要业务系统出现异常，系统恢复时间（RTO-Recovery Time Objective）在30 分钟以上，影响所有客户：

462

463

* 交易主机因非应用软件原因宕机，导致核心交易中断。

464

* 交易核心网络故障，导致所有交易大厅或所有远程会员无法联通交易。

465

* 数据库故障导致交易、结算、行情数据发生严重错误，影响所有会员。

466

* 信息安全原因导致核心交易中断。

467

* 应用软件的日常维护、启停原因，导致核心交易中断。

468

* 因病毒、攻击、拥堵等使系统异常，给市场或客户造成可感知的影响，且交易时段2 个小时内没有恢复。

469

* 业务数据完整性被破坏，且在1 个交易日内没有修复。

470

* 通信线路发生故障，对业务造成严重影响，10%以上会员无法正常交易，且在1 个交易日系统没有恢复正常。

471

* 灾害事故（停电、水灾、火灾等）发生后，重要业务系统在一个交易日系统没有恢复正常。

472

* 网站上出现有害信息，且未能及时删除、屏蔽或未能保留审计线索的。

* 其他因部门原因，导致核心交易中断。

)))

|2|重大事件|(((

因部门原因，导致重要业务系统出现异常，系统恢复时间（RTO-Recovery Time Objective）在30 分钟以内，影响所有客户：

477

478

* 因病毒、攻击、拥堵等使系统异常，给市场或客户造成可感知的影响，但交易时段2 个小时内恢复的。

479

* 系统数据完整性被破坏，但在1 个交易日内能够修复的。

480

* 灾害事故（停电、水灾、火灾等）发生后，重要业务系统能在1 个交易日恢复正常。

481

* 网站上出现有害信息，但能及时删除、屏蔽并保留审计线索的。

482

* 通信线路发生故障且对业务造成不良影响，10%以上会员无法正常交易，1 个交易日内系统恢复正常。

483

* 敏感业务数据泄漏。

484

* 机房空调无法正常运转导致部分核心主机运行故障，影响部分会员正常交易。

485

* 交易核心或交易所自身远程网络故障导致10%以上会员无法交易。

486

* 互联网系统出现非计划性网络中断，所有外部网络不可达，网站系统无法提供服务达2 小时以上。

487

* 全部或大部分会员或所有信息公司无法收到行情达2 小时以上。

488

)))

489

|3|较大事件|(((

490

主要服务对少部分会员（5％~~10%）产生了一定影响。

491

492

* 由于系统、网络、数据库、应用运行、监控、信息安全等原因导致交易系统、结算系统、行情系统故障，致使个别

493

* 会员（5％~~10%）无法正常交易、接收行情2 小时内没有恢复。

494

* 因非行情软件和计划原因导致交易大厅大屏幕行情无法显示或显示错误，一个交易日以上没恢复。

495

* 互联网系统出现中断，所有外部网络不可达，达1～2 小时。

496

* 交易、交割、结算、监察业务终端出现非软件故障，导致某业务部门所有终端无法进行业务管理操作达1～2 小时。

497

* 办公网病毒大规模爆发或邮件系统故障，影响所有员工办公达2～4 小时。

498

)))

499

|4|普通事件|(((

500

服务出现问题，但大部分功能仍然可用，影响个别会员（<5%）。

501

502

* 由于系统、网络、数据库、应用运行、监控、信息安全等原因导致交易系统、结算系统、行情系统故障，致使个别

503

* 会员无法正常交易、接收行情、收取结算数据延迟，但未超过30 分钟。

504

* 我所互联网和办公网系统出现故障：外部网络不可达，但时间小于1 小时；办公网络中断或者网络拥塞，但通过处理，2 小时内能够快速恢复。

505

* 客户端一般故障处理。

506

* 非交易系统技术故障，由于系统冗余、自动切换、非交易时间或系统重启可恢复，对客户的潜在影响较小，不会对客户产生可感知的影响。

* 局部办公网络短暂中断。

* 所领导办公电脑故障。

)))

|5|次要事件|(((

技术请求和服务类事件，或者一般事件，对客户不产生负面影响

512

513

* 一般系统技术故障，由于系统冗余、自动切换、非交易时间或系统重启可恢复，对客户没有产生可感知的影响。

514

* 所内个别员工办公电脑故障、电子邮件故障。

515

* 开通行情、成交回报，交易大厅终端、业务系统终端安装。

* 数字证书处理。

* 服务请求。

)))

== 6.5 优先级和解决时限 ==

对于不同的事件优先级，事件处理的解决时限要求和响应时限要求不同。

524

525

|**编号**|**优先级代码**|**解决时限（工作时间）**|**响应时限**

|1|P1|1个小时|5分钟

|2|P2|0.5个小时|10分钟

|3|P3|3个小时|0.5小时

|4|P4|24个小时|2小时

|5|P5|48个小时|4小时

**解决时限的定义**：事件单的实际完成时间（状态为已解决）－事件单的分派时间（状态为处理中）。

534

535

**响应时限的定义**：事件单的响应时间（状态处理中）－事件单的创建时间（状态为已分派）。

== ==

== 6.6 事件通告路径 ==

对于特大和重大的事件，需要及时通告事件经理。如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。具体定义如下表：

**超出和即将超出时限的通告定义**

|**事件级别**|**通告条件**

|(% rowspan="3" %)特大事件|(((

547

* 特大事件登记后立即通知事件经理、技术负责人、相关主岗、中心领导

548

)))

549

|(((

550

* 特大事件超过5分钟未响应立即通知事件经理、技术负责人、相关主岗、中心领导

551

)))

552

|(((

553

* 特大事件超过1小时未解决立即通知事件经理、技术负责人、相关主岗、中心领导

554

)))

555

|(% rowspan="3" %)重大事件|(((

556

* 重大事件登记后立即通知事件经理、技术负责人、相关主岗、中心领导

557

)))

558

|(((

559

* 重大事件超过5分钟未响应立即通知事件经理、技术负责人、相关主岗、中心领导

560

)))

561

|(((

562

* 重大事件超过1小时未解决立即通知事件经理、技术负责人、相关主岗、中心领导

563

)))

564

|(% rowspan="2" %)较大事件|(((

565

* 较大事件超过30分钟未响应立即通知事件经理、技术负责人、相关主岗

566

)))

567

|(((

568

* 较大事件超过1小时未解决立即通知事件经理、技术负责人、相关主岗

569

)))

570

|(% rowspan="2" %)普通事件|(((

571

* 普通事件超过2小时未响应立即通知事件经理、技术负责人、相关主岗

572

)))

573

|(((

574

* 普通事件超过24小时未解决立即通知事件经理、技术负责人、相关主岗

575

)))

576

|(% rowspan="2" %)次要事件|(((

577

* 次要事件超过4小时未响应立即通知事件经理、技术负责人、相关主岗

578

)))

579

|(((

580

* 次要事件超过48小时未解决立即通知事件经理、技术负责人、相关主岗

)))

== 6.7 事件状态 ==

|**编号**|**代码**|**描述**

587

|1|已登记|新开事件记录或事件已创建

588

|2|已分派|事件已经分配给支持人员，等待处理人处理

|3|处理中|支持人员已接手处理事件

|4|已解决|事件已解决

|5|关闭|事件已关闭

== 6.8 事件结束代码 ==

|**编号**|(% colspan="2" %)**代码**|**描述**

597

|1.|服务台解决|服务台解决|由服务台维护解决

598

|(% rowspan="2" %)2.|(% rowspan="2" %)一线解决|根本解决|找到事件的根本原因

599

|替代方法|使用替代方法解决

600

|(% rowspan="2" %)3.|(% rowspan="2" %)二线解决|根本解决|找到事件的根本原因

601

|替代方法|使用替代方法解决

602

|(% rowspan="2" %)4．|(% rowspan="2" %)三线解决|飞创解决|由飞创公司人员解决

603

|厂商解决|外部厂商解决

604

|(% rowspan="2" %)5.|(% rowspan="2" %)未解决|上升到其他流程|提交到问题、变更管理流程进一步处理

605

|未解决|未解决

606

|6.|(% colspan="2" %)自动恢复|系统自动恢复，事件无法再现

607

|7.|(% colspan="2" %)误报|属于误报事件

608

|8．|(% colspan="2" %)拒绝|事件被拒绝

== 6.9 事件来源 ==

|**编号**|**代码**|**备注**

614

|1.|电话|服务台通过客户电话创建的

615

|2.|监控系统|监控系统通过接口自动创建的

616

|3.|巡检自发现|日常检查过程中由工程师自发现

617

|4.|EMAIL|服务台根据客户EMAIL创建的

618

|5|短信|短信报警

619

|6|Web自助提交|通过web自助方式提交

== 6.10 事件支持满意度 ==

|**编号**|**代码**|**备注**

625

|1|非常好|用户非常满意

626

|2|正常|用户接受处理结果

627

|3|需要提高|用户认为对处理过程或结果不满意

= 7. 事件管理流程概要设计 =

(% style="text-align:center" %)

634

[[image:1730085197614-585.png]]

事件管理概要设计流程说明：

|**序号**|**步骤名称**|**责任人**|**说明**

640

|100.1|事件记录和分类|服务台|(((

641

* 服务台对来自用户和系统自动产生的事件进行详细记录

642

* 服务台负责在接收到事件后进行分类转发，对于初步判断为重大和特大的事件马上转102走紧急事件处理流程

643

* 对于非支撑维护职责范围的事件转给其它相关责任部门

644

)))

645

|100.2|初始事件支持|服务台|(((

646

* 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无法解决需及时升级到一/二线支持

647

* 不属于服务台职责范围的事件，立即分派到相应的一/二线支持

)))

|(((

100.3

100.4

)))|一线/二线尝试解决|一线支持/二线支持|(((

654

* 一线/二线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决

655

* 在必要时根据服务协议联系厂商帮助解决并负责核查

656

* 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案

657

* 事件解决后，在事件管理平台记录事件解决方案并更新事件状态

658

* 不能解决的事件，转100.5三线尝试解决

659

* 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源

660

)))

661

|100.5|三线尝试解决|三线支持|(((

662

* 三线支持人员接受事件，进行调查诊断，提出解决方案

)))

|100.6|记录解决方案细节|(((

服务台

一线支持

二线支持

)))|(((

* 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息

672

)))

673

|100.7|关闭事件|服务台|(((

674

* 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决而关闭；否则，事件以不成功关闭，重新开事件记录，分派到原处理人员继续处理

675

* 处理过程对后续工作有指导或参考的，录入知识库

)))

|100.8|事件处理的监控|(((

服务台

事件经理

)))|(((

* 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注

683

* 事件经理负责协调资源，保证事件的最终解决

684

)))

685

|102|紧急事件处理流程|事件经理|(((

686

* 事件经理负责协调紧急事件的处理，具体过程根据所内规定处理，参见《大连商品交易所信息系统应急处置报告流程》，处理完成后，由处理人负责补录事件信息

)))

= 8. 事件管理流程详细设计 =

== 8.1 (100.1)事件记录和分类 ==

694

695

696

(% style="text-align:center" %)

[[image:图片4.jpg]]

流程描述如下：

|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**

704

705

由一二线内部新建事件单，填写的详细内容如下：

1. 事件标题和描述

1. 必要的附件

1. 事件来源和事件性质

1. 进行事件分类

)))

|100.1.2|从非监控事件队列中接受事件|服务台|事件队列|需要处理的事件|(((

713

事件任务队列的来源：非监控系统自动发送的事件

714

715

服务台负责检查事件任务队列中的新事件单，开始处理

716

)))

717

|100.1.3|新建事件|服务台|电话、邮件|新建的事件记录|(((

718

属于职责范围，服务台负责创建新的事件单，填写详细情况描述，不属于职责范围处理的，直接电话回复。

事件单填写的详细内容如下：

1. 报告人姓名、联系电话、邮件、部门

1. 事件描述

1. 必要的附件

1. 事件来源和事件性质

1. 进行事件分类

)))

|100.1.4|跟踪监控事件队列中的事件|服务台|事件队列|事件队列|(((

729

事件任务队列的来源：监控系统自动发送的告警

730

731

服务台负责检查、跟踪事件任务队列中的新事件单

)))

服务台根据业务的影响程度和事件优先级判定的条件，初步判断优先级别：

737

738

1. 事件级别为重大、特大，转102紧急事件流程；

1. 其它优先级否，转100.2初始支持

)))

== 8.2 (100.2)初始事件支持 ==

744

745

(% style="text-align:center" %)

746

[[image:1730085324548-652.png]]

747

748

749

Wiki源代码12 某市商品交易所ITIL事件管理流程设计说明书