本文根据2021国际AIOps挑战赛决赛暨AIOps创新高峰论坛上,必示科技CEO刘大鹏的主题演讲整理而成。
以下为演讲内容:
大家好!
今天我从一个很具体的点——排障场景,跟大家分享一些实践经验。我分享的题目是《知识与算法结合的智能排障方案》。
提起人工智能,大家脑海中第一印象可能是下图左侧的这些酷炫的词汇。但从真正的实践来看,人工智能是一个广泛的定义,指的是模拟人的行为的一种计算机技术,不仅仅是算法本身,而是包括知识、数据、算法和算力四个要素。我们对人工智能的第一印象,其实只是人工智能四要素的其中一环。
为什么我们会有这样的固有印象?这是由于我们平时在做智能运维相关工作和方案设计时,已经有专家根据运维知识提前定义了若干明确的场景,剩余工作看起来就是解决这些具体场景,做好算法优化和设计工作。
这里做一个比喻,就像不同的桶装不同的水,先由既有运维经验又有一定算法能力的专家定义好“桶”,“桶”即专家根据知识定义的问题;然后在上面做算法研究,往里面倒“水”,“水”即用算法解决具体问题,把“算法”做得越来越好,把“桶”倒得越来越满。
我们总容易看到算法,但实际上背后有很多领域知识。比如本届国际AIOps挑战赛题目,及其背后很多问题的解决,都包含了很多运维经验和知识。
必示科技团队在智能运维实践过程中,经历了几个阶段。第一阶段,我们联合合作企业的专家们一起定义了一些常见场景,定义了一些“桶”,比如利用业务指标数据做异常检测、利用交易数据做定位、利用机器数据做定位、利用中间件层面指标做定位等。我们在这样明确的场景中去做好算法达到预期效果。但依然是先有人根据经验框定了具体范围,正是因为框定了这些范围,才有可能做好算法设计,因为算法解决的是明确、具体的问题。
比如业务指标异常检测,指标的形态多种多样,怎么去设计算法?银行可能有几百套系统,不同系统的业务模式不一样,指标形态也不一样。针对不同形态的业务指标,比如交易量、响应时间、成功率、响应率等,算法怎么能够做到鲁棒性更强?在检测出异常之后,怎么通过跨系统调用、多维度的交易明细数据、底层机器层面的数据去做定位?这些都是很具体的问题,才有算法去发挥实力的空间。
这个模式是过去几年智能运维实践最主流的一种方式,确实带来了很多业务价值。比如发现故障时间提前30%,比如故障告警准确率可以达到97%,比如故障的定位时间减少82%。下图右侧也列了几个具体案例,汇总了一些实践中的数据。这是我们利用第一阶段专家定义好的“桶”、再由算法专业人士做好算法的模式,所带来的一系列成效。
伴随这样的实践往前走,我们发现开始遇到新的挑战,如同看到冰山一角逐渐延展开一样,要解决的场景(桶)特别多。大家可以看下我列的标题,“行业×技术架构×运维对象×数据源×故障类型”,乘积之后问题维度变得特别多、特别繁杂。
不同的行业,从金融、运营商、能源、电力到制造业等;不同技术的迭代,从最早的集中式架构到开放式架构,再到容器化、微服务;再到不同组件的更新换代,包括国产化的组件等,都带来了运维对象的改变。
整个运维架构中,有很多不同的运维对象,每一个运维对象的问题、数据、每一种故障类型都会不同。可以看到,这个空间很大,每一个小的方块都相当于一个明确要去解决的问题。如此一来,我们需要一个更加系统化的方法,把智能运维按照能够不断扩展、成体系化的方向去建设,不再是单点、零散地逐一突破,这就进入到第二阶段。
为了解决问题,最重要是把知识纳入进来。比如,在2021国际AIOps挑战赛比赛过程中,选手需要用一些指标和日志去做故障定位。比赛中没有给出SQL层面的详细数据,如果给你的话你会怎么做?你再去做一个算法对数据库层面做检测,检测后的结果如何跟之前的东西链接起来?将来再把存储或者底层网络的数据给你,怎么把做的这么多算法有机地组合起来,然后在上面做定位?这里,知识就变得不可或缺,需要把它纳入到整个系统建设,也许是一个步骤,也许是一个核心构成。
通过下图,我们可以看到知识包括很多内容,比如定义不同数据源需要检测什么样的异常信号,比如不同数据源检测出来的异常信号之间的因果关系和时空关系。时空关系,典型的如组件之间的部署关系、调用关系。因果关系更多的是我们通过计算机的常识与经验,比如当线程池变高之后经常要排查什么问题。
当把整个智能运维的架构定义出来之后,上图中橙色小方块,加上这些“边”就是它们的时空关系和因果关系。接下来就是算法的发力点,每一个层次的小方块都是一个明确的问题,都有明确的数据输入和需要得到的明确输出。这里要对不同的算法做逐一突破,将来可以不断地去延展。
接下来,整个架构会成为一个数据中心级的智能排障平台,至少从我们的实践经验来看,**最佳实践就是按照经验知识与算法结合的方式去建设平台,然后再逐渐扩展。**第一期的时候,数据可能比较有限,数据质量好的可能也只有一部分。这没关系,按照这个思路来,最开始点亮的模块可能会少一点,排查的范围会少一点,之后会逐步增加。
比如说下图(右侧色块对应的位置),上面的域可能是应用系统管理员经常会排查和检测的问题,我们知道应用其实依赖各种各样的服务运行在各种中间件上,比如Weblogic、WAS、Tomcat等。这些中间件的领域知识又有排查的异常,可能有指标,可能有日志,也可能有别的内容。最下面会连接数据库,包括Oracle、MySQL等数据库,包括DBA经常排查的内容,有些可能是简单的规则阈值,有些就需要动态适配的算法。按此架构,我们可以不断地扩展排障领域。
所以,第一期可能只做这一块,甚至只做这一块里面的一小部分。随着数据质量的完善,算法逐步开发,这个平台会逐渐扩展,整个数据中心运维智能化的覆盖面也会越来越大。这是我这次演讲跟大家分享的最关键的地方,一定不能把橙色部分(知识)抛弃掉,只关注绿色部分(算法)。
关于经验,或许很多专家会有疑问:经验能不能共享和复制?这是一个好问题,经验确实可以共享复制,这恰恰是运维这个AI可落地的黄金行业可以做的事情。因为我们有非常多的标准化组件,排障和经验是可以被复制的。不同的企业之间,Oracle、交换机,或者底层的操作系统,虽然各家企业可能有些自己常见的问题,但是在排障方面的交集是很大的,而且全集是可共享的。举一个直观的例子,比如某银行的DBA找工作,其他银行或其他企业会不会考虑招?答案是肯定的,因为他的经验可以在其他银行和领域内复用。
知识本身涉及到积累,与运维对象的建模如出一辙,对不同的应用对象进行建模,就是它应该有怎样的数据、检测怎样的问题、如何检测。我们实践中也积累了各种常见组件的排障知识、不同组件要做怎样的算法,整个场景是可以不断去扩展和积累的。
———————————————————
最后总结一下。第一点想说,必示科技团队从2017年开始做智能运维实践落地,经过一段时间的探索逐渐进入到刚才提到的第一阶段,我们找到了运维中一些很典型的、数据普遍具备的场景,围绕这些场景做了很多算法,然后深耕、做穿、打透。我们逐渐发现运维细分场景越来越多,开始进入到第二阶段后,我们愈发认识到算法跟知识同等重要,运维专家对运维场景的梳理和拆解非常关键,在构建整个智能运维架构后才有算法发挥的空间。
第二点想说的是,运维是一个非常关注实际效果的行业,所以智能运维也要从实际场景出发,不是拿锤子去找钉子,不是说手头有一堆算法看看在运维场景能解决什么问题,而是要构建出运维实际场景到底需要什么,然后为它去研制算法,即便这个算法之前不存在。这个是非常有效的方法,分阶段进行建设,逐步扩展、逐步积累。最重要的是不同企业之间的排障经验,通过平台被复制,我们就去构建这样的生态。比如将来AIOps挑战赛出的很多题目,大家在上面做的事情,就有可能变成企业真正运维里的一个环节。
以上就是我分享的内容,因为时间有限,很多细节没有展开,希望能抛砖引玉,对大家在智能运维这条路有所帮助。谢谢大家!