关于统一事件管理，一定有你想知道的（二）

本文部分内容来源于布博士----擎创科技资深产品专家

哈喽~又见面啦~ 上期内容我们说到了事件以及事件管理，戳这里一键恢复上期精彩内容：关于统一事件管理，一定有你想知道的（一）

这期主要带大家看看事件管理是怎么运用到现实生活中的，主要包括以下两个方面内容（*温馨提示：本次分享干货较多，篇幅较长，感兴趣的朋友可以先马后看，谨防丢失）：

一、事件管理的应用场景

二、如何进行统一事件管理

一、事件管理的应用场景

1.智能运维 AIOps

智能事件管理整合 IT 监控工具告警信息，智能化降低 95% 告警噪音，自动化事件管理流程，加强团队协作，加速故障定位和修复，将业务影响降到最低。

2. 安全信息事件管理 SIEM

汇聚企业内、外部安全事件，通过规则引擎和事件流处理引擎，实时洞察安全风险，并利用灵活的事件处置流程，帮助团队主动应对安全事故。

3. 物联网应用 Internet of Things

将智能设备、传感器的事件信息在物联网边缘节点和核心节点实时进行汇总、加工，通过事件流式处理，捕获和发现新的数据模型，挖掘更多高价值应用场景。

4. 业务分析 Business Analysis

打通业务运营和 IT支撑的数据边界，从系统中实时获取更多的业务数据，帮助团队对影响业务的事件做出快速、正确的反应。在危机时刻，掌控混乱局面。

从以上场景中，我们不难发现统一事件管理运用的广泛性。那统一事件管理是如何运用到日常场景中的呢？我将通过以下3个不同规模的案例来说明。

案例1：单一用户服务事件

某银⾏的私⼈银⾏中⼼经理张正在尝试登录银⾏的私⼈银⾏系统，以查看他所分配到的客户名单中近期是否有拜访安排。然⽽，他的访问认证没有通过，尽管尝试了重置密码，但仍然无法登录，于是他联系了IT服务台。

IT服务台经理⼩王获取了张经理的详细信息并验证了他是否是该银⾏的私⼈银⾏中⼼经理。验证通过后，⼩王登录私⼈银⾏系统管理员模块并检查了张经理的个人资料以及相关配置。结果发现，由于调岗的原因，个⼈资料中的某些更改没有正确执⾏，导致了错误。

⼩王针对这些更改进行了触发并重新执⾏。然后张经理重新尝试登录，并成功地登录了系统。⼩王关闭了⼯作台上的事件记录，同时系统向张经理发送了满意度调查。张经理非常满意，给⼩王打了5星的好评。

⼩王继续检查私⼈银⾏系统相关的更改情况，其他⼈的更改都已经正常运⾏。⼩王确认“不需要创建⼯单”。

案例2：多⽤户服务事件

IT服务台李经理注意到最近电话数据增加，且基本上都接到了同样的事件：⼿机转账⻓时间没有响应。同时从告警操作台的值班经理处知道了某业务系统的数据库错误，他们正在处理该问题的消息。

李经理评估这是⼀个重要的服务事件，他⽴即登录ITSM系统发布了⼿机转账问题的⼀个公告，并⽴即创建了⼀个事件⼯单，要求有团队收集到的与该问题相关的事件（包括IT服务台和统⼀事件管理平台的告警⼯作台）关联起来，以便集中进⾏管理，⽽不需要浪费重复的资源分别进⾏处理。

10分钟后，李经理收到了从IT经理那⾥得到的最新消息，该系统现在恢复运⾏，因此他重新要求IT服务台的多名值班⼈员验证⼿机转账业务，确认他们已经恢复正常，并关闭了⼯单。

最后，他在ITSM系统中重新更新了公告的内容。

案例3：重⼤IT服务事件

"不好了！"，NOC 值班⼯程师⼩李惊呼道。

统⼀事件管理平台的告警⼯作台发现告警⻛暴，屏幕上不断有新的告警涌现。⼤量的虚拟机出现了宕机情况，这意味着要么是核⼼交换机出现故障，要么是虚拟机管理程序出现问题。

⼩李在 ITSM 系统上登录了该事件，并将其定义为重⼤事件。他联系了云管理员和⽹络管理员并召开了会议。

作为⼀家公有云服务商，公关经理也需要参与进来，因为她需要实时了解事件的情况、严重性、影响范围等，并需要及时通知客户以应对该事件可能造成的舆论压⼒。

云管理员很快发现这是虚拟机管理程序上的⼀个错误造成的。他们⽴即电话联系了虚拟机管理程序的供应商。同时，云管理员将该事件的优先级调整为最⾼。

由于越来越多的虚拟机出现问题，电话涌⼊呼叫中⼼，CEO 也亲⾃介⼊，并亲⾃打电话给受影响的⼤客户。此时供应商还没有尽快响应该事件，但是 CTO 已经触发了应急响应，该事件在 2 ⼩时内得到解决。

接下来的⼀段时间⾥，CTO 组织进⾏了事件复盘，以查明事件的根本原因，供应商也参与其中。形成事件报告，针对报告的内容会发起⼀系列的研发、测试及变更计划，以确保此类事件不会再次发⽣。

二、如何进行统一事件管理

从3个不同规模的⽰例中可以看出，在进⾏事件或应急响应的过程中，为了满⾜客户的服务需求，IT团队将按照以下最佳实践的过程执⾏各种活动，主要包括：

1.检测事件

事件检测通常包括以下三种⽅式：

⽤户报告问题，⽽服务台的值班⼈员将验证是否为事件。
紧急程度，取决于对客户SLA的承诺，即恢复服务的速度。
优先级，针对不同的业务或客户影响，哪些应该优先被处理。

2.记录事件

⼀般情况下，事件的记录是通过系统来完成的，这些系统提供了对历史事件的管理、总结及分析的能⼒，包括：

呼叫中⼼系统：外部客户⼀般通过电话联系呼叫中⼼系统，客户服务⼈员负责在此记录客户的问题。
IT⼯作台：内部⽤户进⾏问题报障时通常会访问IT⼯作台。
监控系统：为了⾃动化监控并发现系统的潜在问题，会对服务和相关的服务组件进⾏监控，以发现异常。
统⼀事件管理平台：会统⼀收集不同监控系统产⽣的异常，并及时同步针对呼叫中⼼系统、IT⼯作台的⽤户及客户报障⾄统⼀事件管理平台，进⾏统⼀的管理。
ITSM系统：如果事件被确认属于重⼤事件，需要留存，则需要事后在ITSM系统中创建事件单，以备审计。

3.事件分类

在事件分类阶段，主要根据以下内容对事件进⾏分类：

属于什么类型：如硬件故障、软件故障、⽹络故障或其它。
影响程度及范围：如对哪些业务、客户造成了影响。
紧急程度：取决于对客户SLA的承诺，即恢复服务的速度。
优先级：针对不同的业务或客户影响，哪些应该优先被处理。

分类有助于：

加速对事件的识别及处置效率；有效识别谁应该对该事件负责；降低事件处置成本。

4.诊断事件

事件诊断的核⼼在于确定出了什么问题，以及针对该问题恢复正常服务的最快⽅法。

如果事件之前已经发⽣过且已经命中了事件模型，则可以由⼀线⼈员直接进⾏诊断即可。但是，对于更复杂或之前没有发⽣过的事件，则需要跨职能团队或由⼆线的专家进⾏联合调查。

5.解决事件

事件的解决是指诊断完成之后，针对该事件的解决⽅案，包括临时修复解决⽅案和永久修复解决⽅案。⼀般在应急及事件处置过程中不追求永久修复，⽽是希望在最短的时间内通过⼀系列的操作尽快恢复⽣产。主要的操作包括以下⼏种：

⾃动实施：⼀般是根据事先定义的已知事件模型，完成对事件的⾃动解决、⾃动恢复，不需要⼈⼯诊断和处置，全部有⾃动化来完成。
记录下来供运维⼯程师⾃⾏解决：⼀般会根据事件模型或系统分析结果给出处置的建议，由运维⼯程师进⾏决策，并最终通过⼈⼯的操作来完成恢复过程。针对⼀些复杂场景，也可以请⽀持团或供应商来提供相应的解决⽅案，由运维⼯程师来执⾏操作过程。