AIOps在360中的实践和探索

白凡

分享：王哲
编辑：白凡

1. 背景

先说一下我们的背景，整个360运维体系，两个平台加上很多服务，最底下技术平台，很多人提到的系统，接下来还有系统管理这些，基础运维平台上有一个hulk云平台，我们内部做得比较大私有云，上面提供虚拟化、数据库或者一些SaaS服务等等。再往上，我们两组，一组360安全，一组360盈利导航搜索之类，这里面比较大的业务有自己SRE我负责部分是HULK云平台，我后面基于AIOps分享可能去业务逻辑，有些数据不像中航信同事和周老师能拿到，如果能拿到对于AIOps更有价值。

1.1 360运维体系变化

2012年做标准化，刚才三位老师都提到了，如果我们AIOps之前标准化做不好，数据降维基本上做不了。2012年到2016年，精细化和平台化，各种都收集起来放到私有云平台上。2016年、2017年做可视化工作，现在持续积累可视化能力，同时也把运维大数据理念提出来了，我们在收集，通过监控系统和业务层一些打点能力，我们做运维大数据平台。到今年为止，我们单点应用和几个单点应用串联起来这部分能力突破，后面达到智能闭环，极大的解放研发和运维生产力，AI只能辅助决策。

1.2 360运维情况概览

我们技术沉淀上，比如说数据有2EB安全大旅居，请求量150亿。我们的产品上，这套东西各阿里一样，稍微大点公司都会分层，产品呈现出来，100家IDC，十多万服务器，核心节点双环路。在服务上常用这几个服务，而且后面在IOT服务上多下工夫。在业务上，360拥有搜索、花椒视频，信息流比较多，基本上都玩遍了，成功不成功再另说。

2. 360对AIOps的思考

谈运维三个大东西，效率、成本、稳定性，我们怎么在AIOps里面做三个大方向抉择呢，我们基于很多因素考虑的。

第一，在效率层，我们谈智能运维，整个团队大家特别感兴趣地方，效率其实我们技术领先，我们能够通过一些努力快速解决线上问题，这个图是运维前辈的图，我们讨论来、讨论去，唯快不破，哪些点可以做。我们提出了基于基线异常检测，在报警收敛做一些能力，做一些磁盘故障预测，可以的话做一些故障自愈能力，这个也做得很简单，一个磁盘的自动清理，还有CPU报警处理，还有机器在一些合理情况下自动重启，这是在效率层。

拿马爸爸开个玩笑，效率做得再好，对团队成长帮助不大，团队扩张帮助不大，我们觉得先干掉成本的东西。比如十多万的服务器规模下，我们更容易去有一些产出来证明这个团队的价值。我会重点提一下服务器加速浏览，资源回收、预算等上的能力。后面有只能调度，我们把这个端口做智能调度也有一些收获。

这是我们怎么看AIOps团队的构成，我们给下的一些定义，像看病一样，需要治病一样，有要看病，有要出方，还要能制药的。看病，有产品理念的运维，我们期望懂业务，知道哪儿有什么数据，能提出需求，而且最关键的就是告诉你我期望的结果，这个叫有产品理念的运维，它在AIOps周期里承担需求方之外，它更多做一些把控。

第二个，有大数据背景运维开发，他同样懂业务，会玩数据，同时得会编程，重点考察他的交付能力，比如他的数据梳理，在下面的算法上面应用，就是接地气的这部分能力。最后一部分，我们叫算法专家，他有工程化经验，甚至有能力搭建工程化平台，把业务、数据和真正AI融合的这部分能力。

3. 智能运维实践

3.1 实践背景

连接产生价值，我们面对有很多公司的团队，他们有自己独有数据，他们想做智能运维或者这方向的探索，但是他不知道别的团队有什么数据，或者底层团队有什么数据，公司运维体系协调。我们给大家建立连接，让大家懂数据，能够获取更多的数据一起来做这个AIOps研发工作。

1. 我们公司很多技术平台，我们复杂做好整个公司运维大数据平台建设和维护。这里面提一下建设容易，维护并不容易，这要花费很长时间、很多人力去做保障。
2. 针对有AI需求团队，可能他们有懂运维的人，有开发能力很强的人，他们没有核心算法专业提供者，我们有对应同事，公司里其他团队想做这方面东西，我们可以做他们的算法提供者。这块比较好的例子，360一个团队做的时候，我们参与过算法提供。
3. 我们的一些实践，从我们这一层，真正业务数据得到不多，有IDC数据偏底层。那个不说了，那是进程一些数据，不是特别清楚。

3.2 资源回收体系

大概分这六步:

第一，取到各种各样监控项做数据治理。

第二，做容量预估，这里面智能方法。接下来机器做一个画像，我们把画像机器做好分类，需要在分类里人工做验证，运维经验库的原理，最后通知合并，通知各个业务线去，让他们能够信服我们的数据，红色的部分是我待会儿会提到AI能力部分。

第一部分，容量预估，业务流程，我们渠道业务结构，我们会做两个部分预估：

1. 通过机器维度监控项做预测，还有一个会把历史的数据做一个定量的分析。在预估这块，我们算法，比如针对不同监控项，我们会做一些不同的算法，做比较。做验证时候有些经验各大家分享，CPU密集型的多线程不能降低时间，所以没必要。我们并行计算尝试使用四台虚拟一机跑全量的机器列表，如果用LR一小时，这里面你的成本和最重要达到的目标要有考量的。定量分析比较通用了，用一些均值的方法。内容很简单，我去做机器的画像，我取它使用最大值就可以了。

1. 我们的分类，刚才的那几个红字，我们预估以后的机器会引入分类模型这块，我们曾经使用过的决策数等等，这些算法。决策数验证的结果是最高，达到99%。但是中间有一个流转过程，我们先用决策值算法判断是否该回收，能够达到用户的要求，我们把机器补到DB里给用户推荐。如果达不到用户的需要，我们就要调整阀值。可能有一个标注的系统，这个标注系统用户可以标注，我们运维工程师也可以标注，以此反退回去给一些训练集，让这个模型更加完善。

这个东西是刚才提到的体系，刚才还有一个没说到的，我们基于判断给用户做推荐，比较有意思的事，可以说一下，我们之前做工作的时候，给用户发回收邮件比较生硬，什么业务下，我们判断多少台机器，你需要回收，业务线同事看多了疲乏了，不搭理你了。

我们运维小组同事玩了一个小技巧，发件箱模拟特别女性名字，里面各种语调匹配，用人性化语气，我们今天做了资产检查，发现你这块资产利用率偏低，下一个周期一个男性的更严厉语气跟他说公司做经营分析，对这块东西分析完了之后，发觉你的事业部下面资源优严重的资源损耗。我们把人工智能也放到了这一层，通过这种方式让业务线同事不会忽略邮件，每一封邮件人发的，很积极解释这个东西该不该退。

这是例子，这是业务方收到周报，告诉他你哪些地方有些浪费，你把它省下来大概能省多少钱，这是我们半年总结的时候一个成果。

不知道是否看得清，左侧业务线，右侧基于业务线的数据，我们给它回收了多少，减少多少成本的报表。

3.3 MySQL智能调度系统

这是第二个，虽然玩得不大，说明我们同事想尽办法在这个领域做了尝试。历史因素，线上资源存在大量浪费，我们业务驱动上的产品，它申请一堆数据库，我们把端口分上去。我们有比较强大的一套监控系统，我们能取得数据库指标，我们最终能够掌握数据库特征数据，这是我们数据的积累。这个图标是内部HULK系统，比如这是一个端口，它在这些地方都很闲置情况下，因为业务内存使用很高，所以没办法，只能把它判断这台机器负载很高，这也是一个线上的情况，在复盘上有一个极大的浪费。

针对这个问题，我们需要去原则一些监控项，大家可以理解为监控项，我们采集的监控项，比如CPU，还有内存，我们用这个断口占用内存百分比，乘以机器内存总量，判定为实际内存，可以理解为实体画像。还有实际的磁盘占有量，还有IO的读写性能，还有个网卡的流量。

我们把整个数据库端口分为四类，业务申请完了之后写入和度曲比较低，还有一种偏计算型，一种耗磁盘，还有一种综合性，既耗CPU又耗磁盘，我们做了四种分类。我们整个DB管理过程中，有900多实例做了一个训练集，人肉的分了一个。

样本处理阶段，我们用了比较通用的一个规划，就是一个偏移，把它变成零到一之间，在标签这块是神经网络，各种标签类型用编码的方式展现出来。前面7，后面4，这块隐藏是14，这块当时按照算法推进是12或13，算法工程师调整成14了。刚才提到这些叫样本，按照七比三划分600多训练集，200多测试集，通过这种迭代我们能够判断测试集准确率达到95%，这就是可用的。

通过这些事情，我们把机器，MySQL端口实例做了画像。大家看到这部分，资源回收部分也有定量分析，MySQL跑机器的分析，我们基于这两个系统。
第二，实例画像。
第三，机器分类，找到高负载机器，还有一个闲置机器，这里面再接下来数据库通用场景。因为我们获取实例画像，怎么把实例更好分布在我们认为闲置的机器上，我们定一堆因素，迁移次数少，迁移影响线上。
主户和大容量端口保持稳定，这种情况下认为不迁移端的。
还有控制主库个数。我们还会加黑名单，有些未来增长量比较大的MySQL端口冗余。

现在30台高配数据库机型，14台可用的。

这套体系很多不能自动化，我们一个月能够做这些，我觉得还可以，后面会一直持续不断地去做，比如用MySQL实际画像，最终合理分配，这个事更多是事后，接下来申请资源时候，很难获取未来数据库实例到底哪种类型。

这里提一个异常检测，我们偏入门，别的讲史可能做得更好一些。

传统的检测方式，一类我们定义的阀值超过多少报警。还有一类，超过这个数和达到一个数字之后报警，比如说这是内部整个监控系统做的也还好，也算比较复杂了。首先阀值有了，监控多少次，当这个次平均或者最大、最小等于时候才报警，而且我们限制报警次数，报了多少次不报了。当同类报警出现，满足这个情况下，我们是否合并，把报警收敛非人工智能能力，我们认为已经很极致了。十多万台机器，我们基本一套监控体系里，我们把所有认为可能合并的能力都放在那儿，但是运维工程师还是很苦，有很多情况很多重要信息还是被淹没。

这是刚才说的一些场景，用恒定阀值，刚才说了突发情况，大面积报警，用累计方式可能漏掉关键的报警，我们用多种检测方法来定阀值。
第一，数据输入进来，我们用一个通用的环比，可能现在很多公司不用固定都是用一个环比，可能下面有一个同比最值或者同比振幅，我们同事这边引用了两种方式，一个叫隔离森林，二叉树，还有基于这种判定。一个通用的动态阀值，带过来之后三种方式做比较。三种方式就有两个达到了报警程度，我们让它报警。如果小于两个，一个，我们认为这个是正常的，我们先不报警。

刚才那个东西场景是带宽流量，我们交换机流量变化，还有LVS突变。应用过程中根据业务的属性或者公司重要程度，可能有些业务线挂了一段时间也可以不管，我们又把它做了一个检测等级划分，刚才整个外面的算法后面加一个系数，再根据敏感程度最终去判断是否值得报警。这个部分，我们线上验证大将达到80%的情况。比如这种点排除极其特殊的点，我们还是能节省大量人力。

这是我们做的报警收敛尝试，其实再一个时间窗口之内多个报警一起发生，我们能不能基于Apriori算法看有多少关联度，先一维再变成二维。基于这种方式，我们统计出来生成20+关系规则，凡是涉及这些关联规则在系统里做了相关处理，这部分报警减少60%到80%，有些挺有意思。我们认为没关联，至少整个过程中看到还是有很大的关联性。

这是我们基于主机报警事件的根因分析，报警是一个事件，报警的时候有一堆监控项，如果发现报警监控项的相关性，我们可以做到一些根因分析，这部分能力资深运维能看到。如果没有经验是否能分析出来相关性，我们算法来实现。这是微软2014年的论文，在发这个事件时候，我们前面取一个窗口，后面取一个窗口，中间取一个窗口，我们这三个窗口规则和模型一致，我们认为这个事件各报警没有关联性。如果不一致的话，说明这个报警对我们监控项可能导致报警的因素，我们会找到这些因素用信息增益比判断其中哪些因素导致报警核心的原因。

这部分在开发，我们获取了这几类，这几类导致它的，这是事件，这是指标，这是准确率。99%几率这些因素导致，这个到现在也觉得挺奇怪，磁盘读写性能会受这些东西影响，报警时候跟这些东西正相关的。

4. 经验和总结

这是最后一部分，我们玩的没多大，四五个人的团队，我们对这块经验和总结。
第一个，我们数据库选型，搞AIOps实际数据很重要，我们尝试用过很多，因为考虑到成本问题，我们觉得后边的全套体系，实际数据丢了不影响现状业务，这样选influxDB，而且我们没有多写，就写一份，丢就丢了。针对事件告警日志还是MongoDB，可视化需求用rrd。如果为了一些刚才提到的关系，还有一些相对经的数据，需要一些支持，我们还是用MySQL。针对实时的热数据、计数器，比如取TOP多少用Redis 。ES也可以用，它是检索引擎，它可以做日志。

第二个经验，这不是技术问题，是项目管理问题，PDCA，我们每做一个智能AIOps项目要不断地迭代。包括我们做运维项目和AIOps项目，我们经常做到有计划、能执行，但是是否检查可能扔掉了。因为不检查，后面的事处理，既不总结，也不处理，最终导致这件事情越做可能达不到我们趋近完美结果，期望我们做一个事情，AIOps失败率很高。如果大家做自己心里应该知道，很多时候奔着一个目标去，但是得到结果很不理想，强烈建议大家一定要在计划、执行、检查和处理过程中把这个东西一步步改进好，当然该舍弃时候要舍弃。

因为我们有大数据团队，我们按照大数据理念，把整个数据做了一些分层，按照一种标准大数据的方式做大数据平台，这是大概分原始层、明细层、汇聚层、应用层。原始层就是上面这些。明细层，完成数据标准化，同时按照业务分类完成数据分类，这个业务分类也很泛泛，运维里面还是我们经验，可以这样分类就这么分。到了汇聚层，我们在哪一个领域里做AIOps能力，我们按照主体域完成对于数据汇聚，形成统一试图。现在AIOps要在哪些场景实现哪些能力，对于运维大数据资产的架构，这是脱胎于360大数据的一套体系。