某公司事件管理流程研讨 - IT运维管理流程认证培训基础证书考试题库资料视频

== **事件管理流程研讨** ==

==== **█** **目标** ====

5

6

7

====== **本次研讨会的目标：** ======

8

9

10

* 介绍事件管理流程，让参会人员对事件流程有全面、深入的了解。

11

* 讨论、修正，确认事件管理流程的设计内容，包括：流程、政策、角色、KPI、参考数据等。

12

* 无法在研讨会上完成的工作，形成后续工作计划，跟踪其完成

[[image:图片1.png]]

==== **█ 事件管理的目标** ====

21

22

23

* **事件管理流程的目标：**事件管理的主要目标是争取在最短的时间内解决、恢复，尽量避免或减少事件对用户造成影响。

===== **◆◆事件和问题流程、变更流程关系紧密，往往是问题流程和变更流程的发起来源** =====

28

29

30

**[[image:图片2.png]]**

==== **█ 流程设计依据** ====

**ITIL对事件管理流程的要求：**

**◇在成本允许的范围内尽快恢复IT服务：**

41

42

* **快速响应事件：已具备，电话、监控系统**

43

* **用户在线获得帮助：无**

44

* **沟通事件解决的状态：已具备**

45

* **与客户确认事件的解决：已具备，目前是值班经理和故障处理人均可进行客户的回访与事件的关闭，事件的解决真实性存在风险**

◇**进行事件控制：**

* 按规范记录事件：不具备，目前是将众多信息存储在一些描述性的字段中，对于数据的统计与分析存在困难

52

* 就事件的优先级、影响度进行分类：已具备，但目前事件的优先级、影响度与分类的定义不够明确，执行的不好

53

* 监视并结束事件：已具备

54

* 进行定期服务流程回顾：已具备，但目前数据规范性不高，流程的回顾分析无法得到多数的关键数据，而回顾结果有限。

◇**提供IT管理信息：**

* 人力资源利用情况：不具备

* 故障处理情况：不具备，目前没有关闭代码，造成事件的处理结果无法进行可统计的标示记录，对于事件处理结果无法进行分析

62

* 支持效率：不具备，对于事件的时间记录并不准确

63

64

65

◇**通过访谈反馈结果了解各处对当前事件管理流程的改进需求：**

* 需要明确统一的分类和等级管理规范

* 需要定义重复事件和关联事件的处理规范

* 需要明确目标时间规范需要统一升级处理规范

70

* 需要明确的、中心级别的转派单规范故障单的分类太技术，对客服人员形成技术壁垒，导致沟通和处理成本上升

==== ====

==== ====

==== **█ 事件管理流程的角色与职责** ====

**◇事件管理流程负责人：**

* 全面负责流程的效率和成果

* 建立考核目标，以提升流程的有效性和效率

84

* 为保障流程的有效性，需争取高级管理层承诺投入足够的资源

85

* 鉴别和管理关键的流程成功要素

86

* 控制和带领流程的改进定义目标、流程、工作流、规范和规则，并与相关人员进行沟通

* 推动事件管理流程的执行

◇**事件管理流程负责人：**

* 确保对流程的使用者提供适当的教育

* 解决需要跨越职能部门的事件，如有需要，应升级汇报

96

* 对事件管理流程的有效性和效率进行监控，在需要的时候做出改进

97

* 召开和主持对事件管理流程改进的季度会议

98

* 作为事件管理流程对外的代表，对其他流程负责人和管理层汇报流程的状况和进度

99

* 在适当的情况下，事件管理流程负责人可以把部分责任委任给其他人员执行

◇**事件经理：**

* 传达流程的新规范和更新的规范

* 确保流程标准和步骤得到遵循

* 鉴别和实施流程的改进建议

* 对事件管理流程的负责人提出改进的建议

* 对于不遵守流程的情形进行处理

* 发生重大故障时协助值班经理进行调度、跟踪等工作

111

* 出席会议并传达和协调有关事件定期出事件管理报表

**◇值班经理：**

* 协调事件管理的日常操作

* 鉴别流程执行过程中的例外和异常情况，并进行管理，负责重大事件的及时响应和处理

119

* 作为流程的集中联络点，负责协调用户、服务供应商、管理层之间的沟通

120

* 在需要的时候，按照升级规则中所定义的途径进行升级

* 从事件管理流程的开始到结束进行跟踪

* 确保日常操作中所采集信息的完整性

**◇事件分析员：**

* 初步分析请求信息，并尝试解决

* 对于填写不规范的退回提交人

* 创建或者更新事件单

* 必要时张贴和更新快速通报的信息

* 对于不能解决的三级以下（含三级）事件，确定适当的分派给合适的支持人员

133

* 发现重大事件立即上报值班经理

134

* 根据已有的应急预案执行简单的解决方案对事件单进行质监管理

**◇事件记录员：**

* 接受用户的联系

* 收集基本的联系信息

* 验证用户的基本信息，如有需要，更新用户的资料

* 收集用户的请求信息

* 创建或者更新事件单

* 初步评估请求的优先级关闭事件单

**◇支持人员：**

* 第一时间响应事件，进行故障诊断和处理

* 分析事件信息再次确认事件的优先级，及事件分类查找相同的症状的事件

151

* 确定恢复服务所需要的必要条件，并启动适当的行动

152

* 根据事件的优先级提供有效的解决方案

153

* 在可能的情况下，产生变通方法如有需要，与厂家和项目应用处协同合作

154

* 根据事件管理流程负责人预定义的标准执行复杂的解决方案

* 记录变通方法/解决方案

* 对供应商的服务质量进行评价

==== **█ 事件管理流程的角色与人员映射** ====

|角色名称|对应人员

|事件管理流程负责人|技术管理处

|事件经理|运行处运行管理组

|值班经理|沿用现在的值班经理

|事件记录员|监控、热线、巡检

|事件分析员|监控

|支持人员|相关处室各专业人员

==== **█ 事件管理流程的概要流程图** ====

172

173

174

[[image:微信图片_20240418101519.png]]

==== **█ 事件检测与记录** ====

179

180

181

**[[image:微信图片_20240418103829.png]]**

==== **█ 事件分类与初步支持** ====

186

187

188

**[[image:微信图片_20240418103931.png]]**

==== **█ 事件调查与诊断** ====

193

194

195

**[[image:微信图片_20240418104229.png]]**

==== **█ 事件解决与恢复** ====

200

201

202

**[[image:微信图片_20240418104326.png]]**

==== **█ 事件关闭** ====

**[[image:微信图片_20240418104414.png]]**

==== **█ 重大事件** ====

**[[image:微信图片_20240418104504.png]]**

==== **█ 事件管理流程的流程接口** ====

**◇与变更管理流程：**

处理中的事件可以提交变更单，事件单状态变为等待中，系统自动完成关联；变更单关闭后，会将事件单的状态置为已完成；变更执行失败，如果触发事件，需要关联事件单和变更单。

**◇与发布管理流程：**

处理中的事件可以将事件单状态至为等待中，等待发布更新包或等待程序回退；关闭代码为“变通解决且与其关联的发布单已关闭”，自动提交问题单，系统自动完成关联；关闭代码为“变通解决且与其关联的发布单未关闭”，自动修改与其关联发布单的状态。

**◇与问题管理流程：**

关闭代码为变通解决和不成功解决的自动提交问题单，系统自动完成关联。

**◇与配置管理流程：**

在事件分析阶段可关联配置项，系统自动完成关联，并在配置项中可查看关联事件情况。

**◇◇与知识管理流程（将来实现）：**

事件处理过程中可以随时查看和引用知识库；事件处理完毕后可以提交知识库。

==== **█ 总体政策** ====

◇所有对运行系统有影响的事件都会通过事件管理流程处理；将通过流程中定义的标准、规范和指导进行管理。

253

254

◇所有报告事件的部门将会参与统一的事件管理流程，不应该有任何例外。

255

256

◇所有IT支持人员对严重影响运行的事件所采取的恢复服务的行动，相比其他任何任务具有优先权。

257

258

◇事件单在业务恢复后3天内，将会被自动关闭。但是事件等级为1和2的事件单不会被自动关闭，它们必须得到事件提交者的确认后方可关闭。

259

260

◇值班经理应对事件的整个处理过程进行实时监控、跟踪，处理升级的事件。

261

262

◇事件经理应该定期产生和回顾事件管理报表。对没有解决的事件，应该举行定期的管理会议对这些事件进行评估。

263

264

◇流程负责人应该定期对流程进行回顾，以改进事件管理流程。

==== **█ 流程维护政策** ====

269

270

271

◇监控的告警规则信息及与事件的关联信息的维护由每天晨会讨论发起，运行支持组执行。

272

273

◇事件分类、人员映射配置、关闭代码等配置信息的优化和维护由流程负责人负责对流程回顾，每月提交运行支持组执行修改。（试运行阶段流程负责人每周回顾一次，收集分类、分级意见，不断完善）

==== **█ 责任人政策** ====

278

279

280

◇当一个事件被创建后，事件分析员负责这个事件单。

281

282

◇当事件单被分派后，支持人员负责此事件单；但是分派方（作出分派的事件分析员或是作出转派的支持人员）有责任通过电话通知被分派的支持人员并要求他接受或是拒绝此事件单。

283

284

◇对于紧急或重大事件，来不及建单的事件，事后由当时负责解决事件的支持人员通过电话等方式要求事件分析员协助建单，事后进行处理过程的补录

285

286

◇值班经理对重大事件负责，对升级的事件负责

==== **█ 事件分派政策** ====

291

292

293

◇事件分析员向支持人员分派事件时，可以直接分派事件到人，同时通知到组和组长

294

295

◇支持人员间转派事件时，可以直接到人，同时通知到组和组长

296

297

◇一个事件需要多人或组同时处理，通过分派事件任务的方式进行

==== **█ 事件分类** ====

**◇**事件分类对事件的SLA控制、知识库管理、事件统计分析、考核指标等有非常关键的作用。

305

306

◇将使用三级（CTI）分类对事件现象进行分类和一个“根原因”字段标识来描述故障根源：

307

308

|分类|原则

309

|一级分类|分类原则以能够准确定位事件所属基础架构或者应用框架为准，如QP系统、网络等

310

|二级分类|分类原则以能够指导事件分派到相应处理组为准，如报关单系统、路由器、AIX系统等

311

|现象分类|分类原则以能够描述故障现象为准，如收不到回执、闪断丢包等

312

|根源分类|分类原则以能够描述故障根源为准，如人为操作失误等

==== **█ 事件定级** ====

◇事件等级由高到低分为一级、二级、三级、四级和非等级。

319

320

◇事件定级根据应用故障和IT故障两种类别分别进行定义。

321

322

◇其中应用故障定级主要根据事件影响的项目、影响程度、影响范围和影响时间决定，分别对应一级、二级、三级和四级。

323

324

◇IT故障定级主要根据IT类型和影响情况，分别对应二级、三级、四级和非等级，非等级为预警事件。

325

326

◇事件等级在事件的生命周期中是可以改变的，关于更改事件单等级的原因和行为应该在事件单中记录。

==== **█ 目标解决时间** ====

**目标时间的定义与事件等级有关**

| |事件得到响应时间|事件找到解决方案时间|事件得到恢复时间

|一级|10分钟|30分钟|2H

|二级|20分钟|40分钟|4H

|三级|40分钟|1H|8H

|四级|1H|2H|24H

|非等级|2H|4H|48H

==== **█ 通知策略** ====

◇事件到达类通知：当事件单分派给某个组或某个人时，进行通知。

348

349

◇事件单到达分派给某个组时通知组内所有人。事件单处理完毕后通知事件单建单人。

350

351

◇重大事件通知事件经理，并根据重大事件通知列表进行上报通知。

==== **█ 上报策略** ====

◇事件单生成后根据下表上报范围进行事件上报。

359

360

◇值班经理应依据事件等级进行事件持续上报：一级事件每10分钟进行一次处理情况上报，二级事件每30分钟进行一次处理情况上报，三级事件每60分钟进行一次处理情况上报。四级及以下事件不必上报。

361

362

◇事件处理完毕后依据下表上报范围对处理结果进行上报。

|上报范围|一级事件|二级事件|三级事件

|中心领导|■|■|

|运行处领导|■|■|■

|客服处领导|■|■|■

|运行处相关负责人|■|■|■

|事件经理/值班经理|■|■|■

|事件处理人员|■|■|■

==== **█ 重大事件定义 ** ====

375

376

377

◇事件等级为一级和二级的事件被定义为重大事件。

◇重大事件发生时要求立即通知事件经理。

◇重大事件发生后需要发布H2000快速通报。

382

383

◇重大事件要求所有人员必须及时响应和处理，事件经理可召集专家进行会诊。

==== **█ 事件升级上报政策（Escalation）** ====

388

389

390

◇升级上报的目的是，对于不同等级的事件，确保分配到合适的资源来解决。

391

392

◇事件升级上报触发条件：事件得到响应事件超时、事件找到解决方案时间超时、事件得到恢复时间超时、事件单被转派3次及以上。

◇事件升级后需通知到事件经理**。**

==== **█ 重复事件政策** ====

399

400

401

◇如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的

402

403

◇事件分析员线需要经过分析后，将引发两个工单的主事件标注为“主事件”，被引发的工单标注为“子事件”

404

405

◇主事件调整为“已解决”状态的同时，相关的子事件相应调整为“已解决”状态，主事件关闭后子事件也需要经过确认后才可以关闭。

==== **█ 复发政策** ====

◇如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。

==== **█ 关闭政策** ====

◇所有事件由事件分析员完成事件回访后关闭所有关闭代码为“变通解决”和“不成功解决”的事件单关单后自动创建问题单

420

421

◇复发的事件如果原来关闭代码为“成功解决”，关单时自动创建问题单

422

423

◇复发的事件如果原来关闭代码为“变通解决”或“不成功解决”，关单时不需要创建问题单

==== **█ 重开政策** ====

◇已关闭的事件单不允许重新打开，任何人都没有权限重新打开已关闭的事件单

431

432

◇如果事件复发，则创建一个新的事件单，并复制原始内容到新创建的事件单中

==== **█ 事件管理的KPI** ====

◇一线支持解决事件的比例（%）

◇超时的事件统计事件单分类的数量统计

◇事件单分级的数量统计

◇等待中的事件统计

◇重大事件数量统计

◇平均事件单解决时间

◇事件分类失误比例

◇周期内事件总数统计（每周、月、季度、半年、全年）

◇目标时间内解决的事件所占比例

◇远程指导事件分析员解决事件所占比例

◇故障平均解决所用成本转发不当的服务请求占服务请求的比例

==== **█ 事件单的输入项** ====

|对象|内容

|事件单号|系统自动生成

|事件描述|必填，简短描述

|事件详细信息|

|事件发生时间|默认为工单的生成时间

|事件等级|

|事件类别|

|事件子类|以类别为依据

|事件条目|以类别、子类为依据

|事件受理组|工单当前受理人所处技能组

|事件受理人|对工单进行受理的人员

|事件请求人|事件请求人信息

|事件日志|包括工单的处理时间、处理人员、处理行为记录

|信息附件|协助解决事件

==== **█ 事件单的状态** ====

|状态代码|描述

|新建|一个事件被记录或创建

|已指派|一个事件已被分派待处理

|(% rowspan="15" %)等待中|事件信息不完整，或在某些情况下阻止记录员或分析员对，事件分析员对事件进行处理

|

|等待原因有：

|

|等待用户进一步的信息，需要从提交者处获取更信息

|

|等待变更

|

|等待发布程序包

|

|等待回退

|

|等待厂商到场

|

|等待其他信息

|处理中|一个事件单被受理，并正在处理

|已解决|为一个事件找到解决方案或变通方法

|已关闭|事件已经关闭

|已取消|误报事件已被取消

==== **█ 事件来源** ====

|事件来源|描述

|监控|监控人员采用人工和技术工具相结合的方式，按照设定监控点的技术指标和阀值，对信息系统相关的网络、系统、应用的运行状态进行全方位、全过程、实时的监控，能够及时发现系统的异常情况

515

|热线|热线人员接受企业及海关的热线服务请求，将用户提出的事件进行开单进入事件管理流程

516

|巡检|机房巡检人员通过定期的、有重点的对网络、系统、应用资产等的运行状态和周边环境进行检查、记录、分析，及时发现事件

517

|其他|来源于支持人员主动发现事件及分中心、企业通过联系领导等方式上报事件

==== **█ 关闭代码** ====

|关闭代码（中文）|描述

|成功解决|事件被正常解决

|变通解决|事件已通过变通方法解决掉，但是需要进行更进一步的根源分析

527

|变通解决且与其关联的发布单已关闭|事件由发布引发，已通过变通方法解决掉，但是需要进行根本解决

528

|变通解决且与其关联的发布单未关闭|事件由发布引发，已通过变通方法解决掉，但是需要回退或重新发布

529

|不成功解决|实施的解决方案或变通方法失败，不能解决这个事件

|用户撤销|用户撤销事件单

Wiki源代码某公司事件管理流程研讨