统一事件管理 - 完整指南

IT技术已经无处不在，各行各业都离不开它。无论是银行、券商、家庭、学校还是个人，都离不开IT技术。例如：

• 我们人与人之间社交的软件，如微信、QQ、陌陌、Facebook等。

• 银行通过IT技术为我们实现金融帐户的管理、理财管理、计算理财产生收益等。

• 券商为我们提供针对股票的实时行情信息和股票交易的系统。

• 工业制造企业使用IT技术来实现ERP系统、财务管理系统等。

• 学校使用IT技术来管理学籍和图书。

• 生活中，我们通过美团等平台购买食品和订餐等服务。

• …

这些我们看不见摸不着的“服务”在保障着我们的衣、食、住、行等各个方面。一旦这些系统出现异常事件（如网络中断、系统不能登录访问、交易失败），就会严重影响我们的生活。

IT系统出现服务中断是不可避免的。因此，在事件发生时，我们必须以消费者能够容忍的方式来管理、分析、处置事件。

统一事件管理系统是任何一家企业不可或缺的基础设置。它的主要使命：与数据中心整个运维体系的工具系统进行集成、使用机器学习分析问题，并在第一时间自动采取行动解决问题。它能有效提高团队生产力，并保障为最终用户提供出色的数字体验。

本文将探索统一事件管理的最佳实践，包括：

• 什么是事件？

• 什么是事件管理？

• 事件管理示例

• 事件管理最佳实践

什么是事件？

在TIL 4版本中，事件被定义为服务意外中断或服务质量下降。

为确保客户满意度，企业必须采取适当的处置策略来应对不同的事件。以下是一些系统中发生服务中断或异常的典型事件：

• 用户无法登录

• 每次使用您的乘车卡时，卡片莫名其妙地无法打开

• 与平常相比，进行交易时交易缓慢

• URL无法访问...

什么是事件管理？

事件管理的目标是通过一定的手段和方法尽快恢复正常服务来最大程度的减少事件的负面影响。

无论是用户无法登录、交易缓慢还是打印机无法打印，我们都应该具有针对不同事件类型拥有事件管理流程。根据事件的严重等级，可以由个人、团队或多个团队共同协作来完成对事件的处置。成功的组织会在事件或应急场景下指定事件或应急指挥员角色，负责领导师临时跨职能团队，集中所有团队成员的能力快速解决问题。

事件管理的目标是通过一定的手段和方法尽快恢复正常服务，最大程度地减少事件的负面影响。

无论是用户无法登录、交易缓慢还是打印机无法打印，我们都应该拥有针对不同事件分类的事件管理流程。根据事件的严重等级，可以由个人、团队或多个团队共同协作来完成对事件的处置。成功的组织会在事件或应急场景下指定事件或应急指挥员角色，负责领导临时跨职能团队，集中所有团队成员的能力快速解决问题。

事件管理的第一步是记录事件。可以通过一些监控工具或由客户电话报障的方式获取事件，并通过一些自动化的手段获取通知，同时可以获取该事件的相关信息，包括描述、发生时间、告警来源、针对什么所发生的事件（如某个主机、某个业务）。记录的事件信息将成为后续管理事件并对其进行分析、决策、处置的基础，包括：

• 沟通：在对事件进行分析、处置过程中，需要协调不同专业领域人员进行沟通、协作以对问题进行有效分析。

• 解决：在分析完成后，事件经理或应急团队会做出事件处置的决策，并进行事件的快速修复。

• 升级：如果在分析处置的过程中发现事件已经超出事件响应人员的能力范围，则需要及时对事件进行升级，这时可以将事件转派给某个领域内的专业人员负责处理。

• 移交至其他流程：事件解决完成之后，如果事件需要建立相应的工单进行根治，则需要创建相应的问题工单，以排查问题的根本原因，并彻底解决该问题。

成功的事件管理依赖于清晰地定义客户容忍的任何事件的持续时间和处理方式。这些通常在服务级别协议（SLA）或合同中定义，其中最重要的部分是定义响应和解决事件的时间表。

作为服务提供商，如何构建相应的组织并处理不同类型的事件是事件管理执行的主要职责：

• 针对已知的事件场景：这种事件会重复发生。在这种情况下，可以定义并使用已知事件模型来进行自动化处理和解决。已知事件模型是管理特定事件的重复发生时的重要解决方案。有助于减少新员工解决事件的时间和学习曲线，并有助于将零散的知识落地到工具系统中。

• 针对一些事件发生后不容易找到解决方案，则可以采用变通的办法来尝试减少影响或再次发生的可能性。在这种情况下，处置的决策权将交由人工来确认。针对当前事件，可以采用重新启动或分流等解决方案来快速恢复。

事件管理示例

我们将通过三个不同规模的事件来说明如何使用预先定义的最佳实践和标准来处理常见的事件。

单一用户服务事件

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

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

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

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

多用户服务事件

IT服务台李经理注意到电话数据增加，基本上都接到同样的事件：手机转帐长时间没有响应。同时从告警工作台的值班经理处获得某业务系统的数据库错误，他们正在处理该问题。

李经理意识到这是一个重要的服务事件，他立即登录ITSM系统发布了手机转帐问题的一个公告，并立即创建了一个事件工单，要求所有团队收集到的于该问题相关的事件（包括IT服务台和统一事件管理平台的告警工作台）关联起来，以便集中进行管理，而不需要浪费重复的资源分别进行处理。

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

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

重大IT服务事件

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

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

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

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

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

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

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

事件管理最佳实践

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

检测事件

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

• 用户报告问题，而服务台的值班人员将验证是否为事件。

• 通过针对服务或相关技术组件所采集的数据进行观测，来自动发现事件。

• 通过趋势预测的手段来发现即将产生的事件，以便提前发现事件。

记录事件

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

• 呼叫中心系统：外部客户一般通过电话联系呼叫中心系统，客户服务人员负责在此记录客户的问题。

• IT工作台：内部用户进行问题报障时通常会访问IT工作台。

• 监控系统：为了自动化监控并发现系统的潜在问题，会对服务和相关的服务组件进行监控，以发现异常。

• 统一事件管理平台：会统一收集不同监控系统产生的异常，并及时同步针对呼叫中心系统、IT工作台的用户及客户报障至统一事件管理平台，进行统一的管理。

• ITSM系统：如果事件被确认属于重大事件，需要留存，则需要事后在ITSM系统中创建事件单，以备审计。

事件分类

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

• 这是一个什么类型的事件：如硬件故障、软件故障、网络故障或其它。

• 影响程度及范围：如对哪些业务、客户造成了影响。

• 紧急程度，取决于对客户SLA的承诺，即恢复服务的速度。

• 优先级，针对不同的业务或客户影响，哪些应该优先被处理。

分类有助于：

• 加速对事件的识别及处置效率

• 有效识别谁应该对该事件负责

• 降低事件处置成本

• …

诊断事件

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

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

解决事件

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

• 自动实施：一般是根据事先定义的已知事件模型，完成对事件的自动解决、自动恢复，不需要人工诊断和处置，全部有自动化来完成。

• 记录下来供运维工程师自行解决：一般会根据事件模型或系统分析结果给出处置的建议，由运维工程师进行决策，并最终通过人工的操作来完成恢复过程。针对一些复杂场景，也可以请支持团或供应商来提供相应的解决方案，由运维工程师来执行操作过程。

关闭事件

一旦事件得到解决，就需要对该事件进行正式关闭。关闭需要完成以下动作：

• 与用户、客户或其他管理层及利益相关者沟通，告知业务服务已经恢复正常。

• 根据需要，更新CMDB的配置信息，例如为了恢复业务而增加了数据库集群的规模。

• 更新计费，例如内外部人力的投入、增加新的服务器等。

• …

事后复盘

事后复盘往往被许多组织所忽略，但其是进行知识总结、优化监控、优化事件处置、优化现有事件及应用流程必不可少的重要环节。

事件复盘一般在事件发生后5个工作日内完成，在这一环节一定要设置审查岗，详细审查运维工程师针对事件处置的总结报告，报告主要内容包括：

• 报告日期

• 报告负责人

• 事件概述：

  通过一两句简短的话，简述事件以及根本原因、发生时间和造成的影响。如，2023.8.5日上午9:25，由于数据库故障，造成故障时段约20%的交易出现响应时间变长，影响了用户使用体验，持续时间约15分钟，严重等级为“主要”。

• 事件详情

  • 详细描述发生了什么事件

  • 什对该问题的根本原因是什么

  • 针对该问题的临时解决方案（为了尽快恢复业务，而制定的快速恢复解决方案）

  • 针对该问题的永久解决方案

• 造成的影响：针对业务、对用户、对交易等造成的影响，严重等级

• 时间线：为了保障SLA，需要详细记录发现时间、通知负责人时间、响应时间、解决时间、关闭时间等，主要参照企业内部的相应考核标准以及对最终用户的承诺标准。

• 参与人员（应急及事件场景不同参与人员会有所不同）：

  • 事件指挥官

  • 记录员

  • 联络员

  • 还有哪些参与人：如不同领域的专家、开发或测试等

• 针对该事件我们是如何响应的

  • 做的好的地方：比如在之前的应急及事件响应过程中我们从来没有使用过的流程、方法、技术等，这些可以大大改善事件响应时效的。

  • 做得不好的地方：比如在响应过程中我们发现现有的流程或方法针对特定的环节会造成阻力，需要加以改善。

• 后续行动计划

  • 任何必要的修复措施，以防止类似的问题未来再次发生。如：

    • 针对特定的指标监控太敏感了，需要在监控源做一些调整

    • 由于程序的BUG引起，同工程研发团队一起制定BUG修复计划，并进入排期

    • …

  • 任何必要的修复措施，以防止类似的问题未来再次发生。如：

    • 针对特定的指标监控太敏感了，需要在监控源做一些调整
    • 由于程序的BUG引起，同工程研发团队一起制定BUG修复计划，并进入排期
    • …

  • 如果不能永久性修复，当再次发生类似的事件时，我们是否可以通过自动化手段快速修复。如：针对特定的告警，可以配置规则和自动修复脚本，当再次发生时，可以自动修复，而无需人工干预。

  • 针对现有的流程做优化，以提高响应的效率