Moogsoft 的员工 Steve Burton 曾分享过一个非常极端但不少见的事例：有个服务提供商 4 万台服务器每小时生成超过 60 万个事件，而且其中有 4.7 万张帮助工单，每月有 2000 次以上的二级升级。也就是说，每天都有 66 次升级，不过这还不是最糟糕的。最糟的是，这 4.7 万张帮助工单须由几百号人进行手动分析、排列优先级以及分类。
现阶段事件管理现状
目前，IT运营中的事件管理 ( Event management ) 是手动的、劳动密集型的（因此成本高昂）活动，难以扩展。企业每年要在事件风暴管理上花掉 7000 万 rmb 以上，以期能在生产业务受到冲击之前发现异常现象和意外事件。
过去，事件数量相对较小且变化幅度不大，企业通常采用 IBM Netcool 或 CA Spectrum 等传统管理系统进行事件管理。IT 运营团队会制定并维护一些基本规则和筛选方法，从而聚合事件或使事件关联（例如，若事件 A 和事件 B 同时发生，则将两个事件合并以创建事件 C ）。在 IT 运营仅需处理几百个熟知的事件时，这种事件管理形式是可行的。不幸的是，如今的 IT 运营团队面临的是几百万个事件，没有一个人能足够迅速地制定规则或筛选方法来处理这些庞大的事件。这就解释了为什么如今 IT 运营非常重视机器学习和数据科学，以及 LZ 在 Steve Burton 对事件管理问题的两种解决方法进行对比的基础上进行整理的理由。
事件风暴及传统解决办法
下图为事件简图，展示了典型的一级或企业监控团队可能遇到的情况。此图展示了多种事件源工具，并包含在同一天内由各种事件源工具引起的事件。
大多数企业会用一级运营团队手动逐个分析上面 93 个事件，并为重要的或反常的事件创建工单。
该方法需面临的挑战：
- 运营团队需要花超过 30 分钟发现异常
- 因不同运营团队所分析的事件源可能不同，故运营团队缺乏态势感知和关联信息
- 工单与事件比值较高
- 工单重复率较高
- 工单检查团队人力消耗较大
事件聚合
解决上述问题的一种途径是将一级运营团队需要完成的事件分析部分自动化。OneAlert 等供应商通过事件聚合完成这一工作，即通过事件源（如 Nagios）将事件告警整合起来，并利用主机 ID 和时间等元素减少事件、进行事件归类并以单个事件的形式呈现多种事件。
例如，通过事件风暴示例可见，事件聚合可用于减少这 93 个不同的事件，并将其分类为 15 个单独事件。
这样就不再需要一级运营团队分析 93 个不同告警，只需分析 15 个事件，工作量降低了84%。
事件聚合的优点：
- 在一些事件源较多的应用环境下非常好用（例如：事件源 < 5 且主机数 < 100 ）
- 缩短运营商发现问题所需的时间
- 降低工单与事件的比值
事件聚合遇到的挑战：
- 运营团队仍然缺乏对事件源的态势感知，因此仍可能出现重复工单和重复的故障排查
- 对于千变万化的高度动态环境，事件聚合中使用的时间窗（如一小时）可能太长。
- 在包含大量糟糕事件源的较大应用环境中（例如，事件源 5 且主机数 100 ），仍然存在严重的生产力消耗。
事件关联
另一种事件管理方法就是，使用机器学习算法（如 Moogsoft ）减少并关联不同事件源的事件。具体方法为：语汇单元化、分析各事件中的自然语言，并寻找各种相关属性、模式以及可推断的异常情况。例如，采用拓扑算法验证事件的相关网络邻近性，此外还可将时间或语言算法用于语言相似度分析。
在同一事件风暴示例中可以看出，通过事件关联，可将这 93 个不同事件分组为 2 个单独事件：
这样就不再需要一级运营团队逐个分析 93 个不同警告，仅需分析两个事件，工作量减少了 98%。
事件关联的优点：
- 非常适用于包含大量事件源的应用环境（例如：事件源 5 且主机数 100 ）
- 运营团队对于事件源有完全的态势感知，因此重复工单数能降至最少
- 缩短运营团队发现问题所需时间
- 降低工单与事件的比值
- 降低重复工单的出现频率
- 减少工单检查团队的生产力消耗
事件关联中的挑战：
- 不适用包含少量嘈杂事件源的小应用环境（例如：事件源 < 5 且主机数 < 100 ）
- 整合多重事件源
- 机器学习算法可能需要根据具体环境进行协调优化
现在你应该明白，如今的事件管理对于企业和服务供应商来说仍然存在很大的问题，每年几乎都要耗费他们几千万 rmb 的劳务费用。尽管 IT 运营团队能使用软件进行事件聚合和关联，但是两种方式也都各有利弊。
对你来说最管用的方法是什么呢？
