写在最后互联网时代 IT 相关的衍生产品多种多样，其中监控工具成为了其中的佼佼者。多种多样的监控工具对于确保网站和应用的平稳运行做了非常多的工作，但是，对于告警产生到通知运维人员的过程，还有很大的改善空间。
举个例子：假设某企业的 IT 环境中的某个底层基础设施，如网络或存储设备出现异常，相关联的主机、中间件数据库、消息队列、缓存，应用程序，业务服务会受到影响。当监控和管理系统全面的探测发现这些问题的话，会在数十秒钟产生大量的告警事件，而且这些事件随着时间的推移不断的发生。设想一下如果把所有的告警全部都加入通知提醒的话，想必运维人员的邮箱会瞬间爆满。实际上，随着规模化和复杂度增加，这些现象经常性发生。
告警管理需要降噪
其实对于事件管理，其基本的核心思路就是对数据进行处理，将成千上万的事件过滤、筛选、甄别，让整个事件管理的流程体系如漏斗般，通过多层过滤杂质，沉淀下金沙。
当大量的杂音事件频发骚扰我们工程师，就会引发告警疲劳，就是带来所谓的无感。体现为事件收到的太多，跟自己相关的却很少，重要的事情淹没在汪洋大海中，根本无从下手。降噪的目的，就是去除噪音，留下乐章。事件处理过程中，传统的做法是去重，将重复的事件去除掉，简单有效。从时间维度上，相同的事件仅发生一次，之后再发生只会在事件的计数器上体现。这个方法基本就能达到 80%-95% 左右的压缩率，去掉噪音告警，数万数千条的事件就会缩减为数百和数十。
去重的做法简单有效，然而不能完全解决上述例子中的很多不同类型事件发生问题，特别规模大的时候，几百主机、数十中间件、数百应用、数千微服务、数十业务服务的告警事件的过滤。所以这个时候引入了新的人工智能算法成了告警管理的救命稻草。
信息熵和自然语言处理
信息是一个很抽象的概念，信息多少很难说清楚。如一本小说有多少信息量?一个事件有多少信息量？直到 1948年，信息论之父香农提出了“信息熵”的概念，才解决了信息的量化度量问题。热力学的热熵表示分子状态混乱程度，香农用信息熵来度量信源的不确定性。熵越大，信息的不确定性就越高，利用熵的特性，我们尝试来解决告警事件信息的过滤问题。
由于睿象云的智能告警平台 Cloud Alert 提供了大量开箱即用的平台支持和强大的 API 。通过智能告警平台可以轻松地从企业现有的 IT 环境中采集事件和告警，但是平台从各个工具接收到的事件是非结构化的文本数据，只有通过人工智能算法，并结合平台的数据治理能力，针对不同事件源产生的事件，进行数据格式化，自定义数据提取和数据内容丰富。通过事件流处理可以最大程度的对事件和告警内容进行深加工，为基于规则和算法的事件集生成提供全面的数据支撑。
从内容信息上的信息量(熵)。例如 CPU 使用率超过阈值，和存储设备宕机是完全不同的，后者明显重要和信息量更大。做到这一点需要解决两个问题：
1. 需要从自然语言内容的角度去理解信息。特别要指出的是 IT 运营支撑专业术语和电商语言、新闻类语言是有差异的。例如电商里面，面膜和护肤词语有很大关联，而监控里面交换机 Switch 和端口 Port 有很大关联，通用的自然语言处理技术应用到专业领域里面有一定的难度。
2. 某个用户的告警事件有可能从来没有发生过，意味着第一次发生的时候这些数据(内容)需要在识别出来。如新上的存储设备3月来运行良好，结果今天刚好故障。
解决这两个问题，依赖于智能告警平台多年来 SaaS 运营积累了各行各业的超过2亿条原始告警事件数据，通过对这些数据进行处理，建立起专业的监控告警自然语言文本语料库。
1. 覆盖行业多：包括金融、运营商、云服务商、游戏、电商等；
2. 覆盖层次多：基础设施、中间件、应用、大数据、业务以及微服务，生产制造过程中各类信息。
通过建立专业的告警事件自然语言语料库，帮助我们深入的从内容的角度去告警事件信息。A 用户首次发生的存储故障，其实在 B 用户已经发生过了，我们能够识别该信息的内容熵，比 CPU 使用率告警更重要(每家每户都发生)。
除了信息内容的理解，建立内容熵，我们还考虑时间维度，我们称为时间熵。例如同样是 MySQL Slave Down 进程故障，天天发生和几个月发生一次的信息量也不同，所以我们还要考虑时间维度的发生频率问题。结合内容熵和时间熵，我们标识事件(告警)的重要度，帮助工程聚焦问题，实现降噪处理。
信息熵的应用还很广，在事件处理上，应该还要考虑上下文、IT 环境等一系列因素，我们也在探索。例如存储设备/网络故障会比主机故障更为重要，拓扑依赖关系、层次结构等上下文因素会对信息的识别有更大影响。通过信息论技术和人工智能算法，对符合特定特征的事件进行分类、聚合、降噪，生成对应的事件集，并自动监测和发现事件流中的异常情况，提升问题发现能力。
智能化事件处理，帮助用户对海量事件进行实时的自动化筛选和甄别，主动发现事件、告警中蕴含的业务运行风险和用户体验问题，降低超过95% 的 IT 噪音。
通过智能聚类实现事件事物化
回到文章开始的例子，降噪将告警事件处理后，还有数十数百个事件，很多是类似的，例如存储类 Lun1、Lun2 故障，主机 A\B\C… 故障，数据库 Master1、Master2、Slave1… 应用 Order_1_8080,order_2_8080…，业务支付、门户等。其实就是有几类事情，存储类、主机类(支付类主机、门户类主机)、数据库集群、支付类应用、门户类应用等几大类。从职责划分和管理流程方面，也是不同团队负责。如果能够将这些零散的事件分门别类，就更清晰和有助于处理(职责划分)。
睿象云希望通过轻量级的方式和重量级相结合来实现聚类的准确性。轻量级的意思是，通过算法和简化的策略规则，无需过多的前提条件，快速实现告警事件的聚合。将上述例子中的大量事件，划分为存储、数据库、应用和不同业务。
告警事件之间是存在一定的关联性的，将一组类似的有关系的事件聚合在一起就是一个场景。以场景为单位去实现团队的分派/协作，最终解决问题，而不是单一事件的逐条解决。用户可以通过组合服务可以将单个业务下多个对象产生的事件进行聚合，如将承载 OA系统的服务器、网络、中间件、数据库、应用等事件和告警从海量信息中剥离出来，汇总到一个 OA 服务之中，交由负责该系统的团队进行统一的管理和分析，从而提升业务管理的可见性。
利用人工智能无监督学习技术，结合自然语言处理 NLP，我们从内容相似性、相关性进行数据挖掘和学习。内容相似性上，我们利用在降噪过程中我们建立的专业语料库，能够识别出当下相似告警，将符合相似度(如80%)的事件聚合在一起。时间相关性上，可以根据事件发生的时间差，在一瞬间爆发的大量事件是存在一定关联性的，特别是开篇的那个栗子。然而由于监控工具的数据采集问题，现实的事件并不是严格的按照时间序列过来的，例如业务故障和存储故障，从直觉角度上看，应该是存储故障先发生，之后才影响业务。实际上，两者的事件时间有可能是相反的。
通过算法，在没有过多的前提条件下，实现将相似相关事件聚合称为一个场景。与降噪一样，算法应该跟上下文和环境相关，所以未来在聚类的方面可以做的更深入，更重量级。
助力识别问题根因
到现在为止通过降噪将事件从数千数万降低为数百数十，聚类降低为数类数十。对于告警已经基本上实现了更高效的处理问题，然而，我们总是期望能够定位到根源，甄别是那些异常引发的，快速识别根因是所有IT支撑工程师的追求。
现实是很困难，如果想100%的确定根因，必须对 IT 环境的每个环节和设施进行管理，并建立数据模型。在当今的规模化、虚拟化、微服务化情况下，这是很困难的事情。所以往往依赖于有经验的工程师进行分析和判断，如果在跨职责、跨业务、跨团队的时候，就需要多个不同领域的专家工程师去诊断和分析了。
借助人工智能算法，通过有监督的训练方式，通过历史和人为标注的数据。工程师每一次的根源识别，都可以作为机器学习训练的素材。随着时间的推移，诊断标注的根源数据积累越多，机器就能够准确的识别出因果关系，根源识别也越来越准确。像前文的例子中，如果有类似历史数据，并且完成人工标注，那么再次发生的时候，我们就可以判断存储或者是网络故障是根因，可能性85%。通过人工智能方式，逐渐的摆脱严重依赖专家工程师的模式，让运营支撑系统成为一个能够自我学习和进化的智能系统。
识别场景，甄选根因后，我们基本上就可以着手解决问题。在处理问题的过程中，会出现一个知识传递的问题。例如有经验的工程师和新入职的工程师的差异，其实这就是一个集体知识共享的问题。我们也通过人工智能的方式做了一些尝试，让整个事件(告警)处理更流畅起来。场景历史推荐，对于新发生的场景，如果以前有类似的场景，系统会推荐出来，如在上个月有一个类似的故障，相似度80%，也是一个存储类故障。通过查看历史场景的解决方案/过程，帮助我们做决策，可以快速的复用历史知识。整个过程中，人工智能自动学习和推荐，告别人工手动编辑知识文档的方式。所以经过一定时间的积累，这些解决方案将沉淀为企业特有的知识储备，而不是一个泛泛的功能。为之后的发生相同或是类似事件提供可参考的解决办法。
写在最后
人工智能技术的应用和实践会越来越多，我们有理由相信 AIOps 会对 IT 运营支撑产生极大的影响力。我们的智能告警平台和智能事件平台也都还在这个领域里不断的探索中，欢迎大家登陆官网进行产品试用，与我们一起探索。
随着更多的用户对人工智能的了解应用，相信不久的将来，正如 Gartner 说的，未来将有越来越多的企业使用 AIOps 方式运营支撑，人工智能对企业 IT 运营效率的提升和变革，也将促进这些企业的商业发展提速。
阅读(1264) | 评论(0) | 转发(0) |
