从0搭建AIOps智能运维系统Word文档格式.docx

从0搭建AIOps智能运维系统Word文档格式.docx

《从0搭建AIOps智能运维系统Word文档格式.docx》由会员分享，可在线阅读，更多相关《从0搭建AIOps智能运维系统Word文档格式.docx（23页珍藏版）》请在冰豆网上搜索。

3.4报警系统20

3.5CI/CD系统21

3.6线上系统22

4.爆发：

智能决策，决胜千里23

4.1模型算法23

4.2报警聚合25

4.3根因分析25

4.4预测27

我们离AIOps理想王国还有多远

今天分享分四个模块，首先我们了解和一起探讨一下，大家都在提AIOps，我们AIOps理想王国到底离咱们现在还有多远，我们一起探讨一下。

我们探讨这个问题时候考虑梦想或者理想是什么:

∙第一个，我们不背锅，我相信在座做运维的同学肯定有背锅的经历，如果我们实施AIOps让大家不用再背锅了，这算是第一个理想。

∙第二个理想，不用再起夜（半夜被叫醒），这个事情经常会发生。

我的团队，包括我自己，也会由于线上问题半夜起来操作线上服务，我们希望有了AIOps之后这是要实现的第二个理想；

∙第三个理想，我们不用去7×

24小时值班，尤其618、国庆、双十一、双十二，各种节日非常多，这种情况下要值班，希望有了AIOps这套机制后，不需要再做排班、值班，完全机器自动执行人工要干的事情，这是我们践行AIOps的三大理想。

刚才知道我们理想，那怎么去实现呢？

我们可以通过这样分析方法：

5W-1H分析方法，这个理论在公司经营管理方面用得非常多，做任何事情要问5个W，1个H。

第一个W，我们做什么。

第二个，在哪个地方做。

第三个，什么时候开始做。

第四个，谁去做，大家问完这些问题心里已经有答案，谁去做，运维去做AIOps。

我们怎么去做和为什么是我们做，而不是别人去做呢？

接下来我们探讨这个问题。

这就回到了这个问题，我们理想到底怎么去实现呢？

我觉得答案是这样的：

coding，之前做运维的同学写脚本或者做机器运维，现在我们做AIOps或者DevOps，我们进入了开发领域，所以我们要不停写代码去实现自己的理想。

有了理想之后，我们又有了方法，到底还要多久才能实现理想呢，这里可以参考借助于康波周期理论。

这是一个俄罗斯非常出名经济学泰斗人物提出的周期概念，是指我们社会的经济发展存在周期性波动的特点。

比如说我们的经济通常会经历波谷到波峰过程，每次衰退到兴盛需要科技革命的推动，比如蒸汽机、铁路，还有一些电气工业，到IT，再到我们现在AI，这是推动我们建立这样一个新周期的技术支撑。

这个理论认为，一个周期大概要50年，由此可见，对于AI，我们现在刚开始，所以我们正处于这个时代最开始，大家投身AIOps将非常有机会。

以终为始，看准目标

刚才提到我们运维从开始不用写代码，到写脚本，到我们可以做SRE工作，再做开发DevOps，再做AI，我们运维角色发生着变化。

从最开始的运维到运维工程师，再到开发工程师，再到大数据工程师，最后都变成算法工程师，所以就是这样一个角色的变化过程，我们处于这个AI时代，我觉得非常好的。

刚才我们谈了理想，有了理想之后，我们设定实施目标，所以现在我们探讨一下怎么去实施目标，要先了解一下我们行业的现状，具体的目标是什么，我们实施AIOps 

三驾马车是什么。

我们看一下行业现状，第一梯队，看国内第一梯队，BAT大家都认可的。

当然还有BATXJ，还有ATM，还有XXX，还有很多企业，比如Facebook、Google等企业。

我们跟第一梯队比稍微困难一点，他们特点是人多、兵强马壮，钱多、体量大、起步早，别人比我们聪明，起步还比我们早，我们达到他们这样阶段，比如刚才阿里和XX同学分享的技术，我们达到他们境界可能还早着呢。

对于第一梯队来讲，我们可能追赶他们稍微困难一点。

咱们看第二梯队，第二梯队我们认为市值100亿到500亿之间的企业，比如微博、搜狐、网易，这些企业更注重于业务，工程架构从零开始。

要跟他们同台竞技，咱们有《企业级AIOps实施建议》，包括我们出的智能运维这本书，从这些材料里面和高效运维公众号里面学到很多东西，可以从零搭建自己的AIOps系统。

区别就是这样，对于第一梯队来讲，BAT航空母舰，造各种轮船大炮，所有零部件自己去搞。

对于我们第二梯队来讲，我们做了什么事情呢？

我们用了很多开源的东西，对于微博来讲用了非常多开源，比如Redis集群我们是国内最大的，我们也用了其他很多的开源软件。

我们发现第一梯队和第二梯队区别之后，就可以设定我们自己目标，明确运维目标到底是什么，这个很重要。

我们列了几点，一般大家觉得稳定性、可靠性，性能是我们做运维的目标，实际上我们要考虑的是，对于稳定性来讲，有时候运维是不能完全干预的。

稳定性一般是指一个系统稳定性或者服务稳定性（出故障的概率），可能跟开发很有关系，他写一个代码有BUG，稳定性就不高。

我们运维应该去想办法提高可用性，我们关注的最重要指标应该是系统的可用性。

可用性的定义是这样，有两个因素影响可用性：

故障出现的间隔时间，间隔时间如果越长，可用性越高。

第二，故障的修复时间，修复速度越快，可用性越高。

运维要做的工作，一是要去拉长我们故障出现的间隔时间。

第二，一旦出故障的时候，我们能够快速去修复，这两点正好可以通过自动化方式和智能化方式能够解决的问题。

我们刚才提到运维的核心目标是要提高可用性，下面我们聊一下实现AIOps有三驾马车。

第一，感知层，监控平台，我相信所有做运维平台都知道监控平台是什么样子，需要有一个报警平台，需要有一个CI/CD平台，自动化平台。

CI/CD平台负责最终执行，有了策略之后，把这个策略实施到线上，需要这三驾马车，只有这三驾马车非常充分情况下，并驾齐驱，三驾马车开足马力情况下才能实施AIOps计划。

从0开始构建AIOps大舞台

3.1拥有数据

前面讲了这么多，看一下怎么实施三驾马车，从零到一怎么搭建这个平台。

我们看一下现状，我们所有的企业或者中小企业，我们要对照的看，我们企业到底大数据公司，你的数据量大数据，还是有数据。

人工智能，还是智能人工。

前段时间有一个段子说现在很多人工智能客服，后面雇了一帮人做人工客服的，人工智能客服实际上是智能客服，后面有一堆客服人员充当机器，所以我们要看清楚到底是否需要AI，有可能我们只需要一些规则就搞定，报警聚合或者根因分析有规则就搞定，不需要太高深算法，我们要认清自己所面临的具体问题。

其次做AIOps一定要非常重视数据，我们这本书也非常详细探讨了数据重要性，要以数据为王。

如果没有数据，后面所有分析计算、模型、算法，我们无从谈起，数据最开始一定要把关好，从数据采集、存储、计算，再到分析，一定以数据为王。

3.2采集数据

从采集这端，我们可以用开源工具非常多。

在微博最开始是这个，随着性能增长它有很多问题，我们逐渐迁移，现在用我们自研的一个版本。

自研版本支持自动流量控制，我们保证数据不丢失，能够支持各种适配，然后保证我们数据根据自己规则去进行一些简单的清洗。

这是我们对采集端的性能测试。

刚才提到所有数据采集端，数据采集在实施时候，尤其从零到一需要注意的地方。

第一，采集的同时要做数据预处理，一定做数据处理，否则所有数据放到存储里面去，后面分析计算会带来很大问题，要在最开始时候对数据进行非常严格的处理。

同时我们去推动日志的标准化，如果开始架构不合理，最终改造成本非常高。

上次跟滴滴公司的同学交流，他们做的一个trace系统花了两年时间，线上的一个系统，打通所有业务系统之间的桥梁，要建立这个。

如果你开始没有考虑到这些，后面你可能需要花相当长时间构建和完善这样的系统。

我们最开始数据源头要注意这点，怎么保留数据能够正确和快速采集到。

同时我们要让运维能够影响开发和产品，这点有必要强调一下，非常重要的。

运维隐藏在开发（RD）后面，开发隐藏在产品后面，产品隐藏在业务运营后面，我们运维离业务的链路很长，没有办法直接影响业务，开发或者产品说上线找运维，立马让你上线做线上变更，我们是比较被动的。

我现在所在的团队在尝试改变这样的现状，我们希望运维把我们影响范围前置，把我们数据前置，在产品设计规划阶段，要告诉他们日志应该怎么做，系统应该怎么设计，我们需要建立这样一个机制，让运维工作能够顺利展开。

3.3存储数据

存储，我这块不用太多讲了，如果对大数据比较了解应该非常清楚，比如存储有很多的方法，对于热数据怎么存储，对于时序数据怎么存储。

对于数据的计算，我们这里面考虑几个非常关键的问题，刚才说我们数据采集完了之后怎么去做数据的计算，这里面要注意好几个问题，比如我们实时计算系统怎么去支持多种维度的聚合或者关联，这个是相对比较困难的。

对于实时系统来讲，我们关注两个点。

第一，时效性，怎么快速去完成。

第二，关注我们数据的准确性，实时流数据很难验证准确性，不像离线数据，按天重跑这个，实时数据很难验证，我们必须通过机制或者架构层面去保证。

我们有一个算子，通过不同算子完成不同维度数据关联和聚合，通过配置方式可以实现线上的灵活变更，比如新增一个数据指标关联，你只需要改下配置搞定，不需要再上线发布。

3.4报警系统

对于第二驾马车，报警系统，我们觉得最关键一点，这里面有开源的这个可以用。

我们核心思想把报警集成监控平台里面去，通过监控页面可是化和报警规则，这两个要打通，开发同学配了一个监控图，他希望根据这个趋势设定他自己的报警阈值或者是配置，这两个需要能够做到关联。

3.5CI/CD系统

第三驾马车，CI/CD系统，这个系统很关键一点，它要能去集成我们QA的自动化测试功能，否则我们在所有的线上变更时候都会去做自动化测试，如果你没有自动化的测试环节，你很难保证我们线上的发布质量。

刚才王艺提到我们线上有40%多的问题，因为线上变更导致，现实中可能更当，百分之八九十都是线上变更导致。

因此我们必须有一套机制去保证所有的变更是安全，是没有问题的。

从刚才数据的采集到我们数据的存储，再到数据的计算，再到其他报警和监控，整个系统如果合在一起，是这样一个架构，这是我们可以实施架构，不是BAT很难很很高深架构，很多模块可以投入开源框架去完成。

3.6线上系统

最下面是我们线上的系统，线上系统产生很多数据，这个数据通过一些存储介质，我们客户端收集，收集以后进入实时队列，再由实时系统进行消费，期间可能进行数据的关联和聚合，实时数据进入持续数据的存储引擎，比如这里面的这些，很多。

再通过查询引擎，可能需要建立一套缓存机制，最终进行可视化，这个监控系统就出来了。

监控系统出来之后，我们去配合我们的报警，我们需要有报警的策略，这个策略直接触发我们线上变更，微博里面有个名人出轨了，我们对系统进行降级或者扩容，这个操作要通过策略直接去影响到线上变更系统，CI/CD变更系统，最终影响我们线上。

同时这里面有一条逻辑，我们还需要一个标注系统，对于实际报警规则有误报情况，对于这些信息进入标注系统，最终去反馈我们线上的特征里面去，这是一个整体的架构情况。

智能决策，决胜千里

4.1模型算法

前面很多老师讲了智能运维根因分析和异常检测，其实简单来讲，你不拿算法来讲，对于异常检测，其实很简单。

比如基于统计的模型，基于统计模型一定分析数据统计的规律，或者它的概率分布，这是必须要有，不一定是所有的数据都可以拿这个统计模型来去做。

你去分析发现这个数据属于正态分布，就可以用这个方法做检测。

如果没有分布、没有规律，你可能只能按照其他方法，比如基于临近度或者密度的方法。

临近度很简单，可以理解异常数据和正常数据，它是一个分类的问题，正常数据在一堆，异常数据在一堆，异常数据距离比较短，这里面可以用分类算法。

基于密度也是一样，物以类聚，聚在一起密度更高一些，它和异常点密度会更小一些，通过这两种方式都可以做。

基于临近度和密度方法做，我们选K值可能困难一些，计算复杂非常高。

右边我们通过基于独立森林的算法做检测效果，我们发现这个算法能够带来的效果，我们准确率可以达到90%以上，这里一定要提到一点，我们异常检测不能完全替代，我们希望通过算法提高运维的效率。

4.2报警聚合

对于报警的聚合，这里面报警聚合，我们希望报出来的警，刚才提到有个名人出轨了，可能导致一堆系统都出了问题，这一堆系统可能成千上百台机器发报警信息，不知道该怎么处理了，对于这样的情况，我们需要用报警聚合的方法。

比如我们用的AI方法，基于属性归纳，比如某台机器出了问题，这台机器存储服务，它导致存储服务部可用，存储服务上层业务支撑发博文，会导致发博文会受到影响。

归纳起来，这个机器报警，存储出了问题，发博文受到影响，我们归纳起来只需要发一条报警的短信过来就行了，我们现在发博文是异常的，需要谁去处理，这样就可以极大的降低我们的报警条数。

4.3根因分析

对于根因分析，正好和报警聚合是一个反的方向，刚才是自下而上去做归纳，根因分析自上而下做分析和判断，最常见的方法决策树，也是最简单的办法。

发博文出了问题，它可能是存储服务导致，存储服务运行哪些机器上，哪些机器出了问题，自上而下判断具体的原因。

还有一些关联分析，这里面不展开讲了。

4.4预测

我觉得AIOps的未来，应该是预测，很少有人重点讲，我要重点讲一下这一块，我们把祖师也搬出来，诸葛亮他在三国时期很好运用到了预测这种技术，比如赤壁之战、草船借箭和借东风的故事大家耳熟能详，诸葛亮通过预测的方法，预测到11月份冬至时候有大风。

根据什么来的？

根据历史数据统计情况得来。