抓住成本和效率，AIOps 在 360 的探索实践之路

Posted 2021-04-24 高效运维

作者简介

王哲

360 AIOps 高级专家

AIOps 白皮书核心编写专家

1. 背景

先说一下 360 运维体系的背景，主要是两个平台加上多组服务，最下面是基础运维平台，包括资源管理和流程工单等管理，基础运维平台上是360内部的私有云平台HULK，私有云上面提供虚拟化、数据库、中间件以及部分SaaS服务。

再往上其实标示的是云平台所支撑的业务线，主要分为两组，一组是360大安全线，另一组是360经济收入线，比如导航搜索商业化，公司里面比较重要的业务有自己的SRE团队，我所在的团队是 HULK 私有云平台，后面基于 AIOps 分享可能都不包含业务逻辑，因为有些业务层的数据不像前面中航信同事和周老师能拿到，如果能拿到对于 AIOps 或许更有价值。

1.1 360运维体系变化

360 在2012年开始做标准化，刚才三位老师都提到了，如果 AIOps 实施之前标准化做不好，数据降维基本上做不了。

2012年到2016年，精细化和平台化，各种都收集起来放到私有云平台上。

2016年、2017年做可视化工作，现在持续积累可视化能力，同时也把运维大数据理念提出来了，我们在收集，通过监控系统和业务层一些打点能力，我们做运维大数据平台。

到今年（2018）为止，我们单点应用和几个单点应用串联起来这部分能力突破，后面达到智能闭环，极大的解放研发和运维生产力，AI 智能辅助决策。

1.2 360 运维情况概览

360 在资源治理上，整体的规模百家IDC，十多万服务器，核心节点双环路；在技术沉淀上，比如数据有EB级别的安全大数据，请求量百亿级；在运维架构体系上，公司也是解耦分层维护；在服务上，积累了大量的通用Paas和Saas服务，后面我们也会发力在IOT场景下的服务；在业务支撑上，360拥有搜索、花椒视频，信息流，商城，金融等多种技术架构的业务。

2. 360 对 AIOps 的思考

运维要关注的三大场景，效率、成本、稳定性，360 怎么通过 AIOps 做三个大方向抉择呢，我们基于很多因素考虑的。

第一，在效率层，我们谈智能运维，整个团队特别感兴趣地方。效率上借助于技术领先，我们能够通过一些努力快速解决线上问题。

下图是运维前辈的图，我们讨论来、讨论去，唯快不破，哪些点可以做。我们提出了基于基线异常检测，在报警收敛做一些能力，做一些磁盘故障预测，可以的话做一些故障自愈能力，一个磁盘的自动清理，还有CPU报警处理，还有机器在一些合理情况下自动重启，这是在效率层。

拿马爸爸开个玩笑，效率做得再好，对团队成长帮助不大，团队扩张帮助不大，我们觉得先干掉成本的东西。

比如在十多万的服务器规模下，我们更容易去从成本侧做一些产出来证明智能运维团队的价值。我会重点提一下预算、服务器加速流转，资源回收等能力。在这些之上包含有智能调度，我们做的比较好的就是把mysql复用的端口做智能调度。

我们给 AIOps 团队的构成下了一些定义，就像看病一样，有看病的，有出方的，还要有能制药的。

看病，我们期望团队有成员懂业务，知道哪儿有什么数据，能提出需求，最关键就是告诉我期望的结果，这个叫有产品理念的运维，在 AIOps 周期里承担需求方之外，更多做一些把控。

第二个，有大数据背景运维开发，他同样懂业务，会玩数据，同时得会编程，重点考察他的交付能力，比如数据梳理，在下面的算法上面应用，就是接地气的这部分能力。

最后一部分，我们叫算法专家，我们希望有工程化经验，甚至有能力搭建工程化平台，把业务、数据和真正AI融合的这部分能力。

3. 智能运维实践

3.1 实践背景

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

1. 我们公司很多技术平台，我们负责做好整个公司运维大数据平台建设和维护。这里面提一下建设容易，维护并不容易，这要花费很长时间、很多人力去做保障。

2. 针对有AI需求的兄弟团队，他们有懂运维的人，有开发能力很强的人，但可能他们没有核心算法的理解，训练专业提供的人，我们团队面向公司提供这种角色的同事。公司里其他团队想做智能运维方向的东西，我们可以做他们的算法提供者，协助他们搞训练。这块比较好的例子，我们参与过360网络运维团队的算法提供工作。

3.2 资源回收体系

大概分这六步:

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

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

第一部分，基于业务流程的容量预估，我们获取到业务结构，我们会做两部分预估：

1、通过机器维度监控项做预测。

2、把历史的数据做定量的分析。

在预估这块，针对不同监控项，我们会做一些不同的算法并做比较。

做验证时候有些经验跟大家分享，使用Python的多线程模型不能改善CPU密集型分析的时间，我们尝试使用四台高配虚拟机并行计算跑全量的机器列表，不同的算法有不同的精准度，有些算法性价比更高，这里面需要考量的是你预计投入的成本和最终期望达到的目标。

定量分析比较通用，有些监控项用一些均值的方法，有些使用最大值，拿这些来做机器的画像即可。

主机分类，我们做完预估后的主机会引入分类模型，这里尝试使用过bpann，svm，决策树等算法，决策树验证的准确度是最高，达到99%。分类后中间有一个流转过程，我们先用决策值算法判断是否该回收，能够达到用户的要求，我们把这些主机记录到 机器分类DB 里给用户推荐回收。

推荐后如果达不到用户的需要，我们就要调整阀值。我们后面会做一个标注的系统，这个标注系统业务线的运维可以标注，云平台的运维工程师也可以标注，以此反推回去给一些训练集，让这个模型更加完善。

上面就是是刚才提到的全套体系，我们在中间还做了点儿比较有意思的事，原来的系统自动给用户发回收邮件都比较生硬，比如：A业务下，我们判断多少台机器你需要回收，业务线同事看多了疲乏了，大概率会忽略。

我们智能运维小组同事玩了一个小技巧。发件人用几个特别女性名字，组织一堆语料匹配人性化语气来做第一次回收的提示，比如：我们今天又做了资产检查，发现某块业务的资产利用率偏低。等下一个周期用一个男性的名字，更严厉语气跟业务线表述说公司做经营分析，对这块东西分析完了之后，发觉你的事业部下面资源严重的损耗。

我们通过这种方式让业务线同事不会忽略邮件，促使他们很积极解释这个东西该不该回收。

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

3.3 MySQL智能调度系统

这是第二个智能运维落地的场景在数据库团队，DBA团队同事想尽办法在这个领域做了些尝试。

大部分互联网公司，基于历史因素，线上数据库资源都存在大量浪费，如何把不同资源利用率的MySQL端口合理分配到多个物理机上以最大限度节省资源是我们的目标。

我们有一套比较强大的监控系统能取得各种数据库指标，最终能够掌握数据库特征数据，这是我们数据的积累。

这个图是私有云系统的一个后台界面，举例的是一个MySQL端口，它在CPU，IO很闲情况下，内存使用很高，所以只能把它所在的主机判定为很忙，但其实这个实例仅仅大量使用了内存。线上针对不同的业务，在CPU，IO，内存上均有不同的使用情况，我们能看到这里有极大的浪费。

针对这个问题，我们需要去选择一些监控项来辅助分配端口实例，采集的监控项比如CPU，实际内存，磁盘占有量，IO的读写性能，网卡的流量，拿这些来为MySQL端口画像。

然后我们把整个MySQL数据库端口分为四类，1、写入和读取比较低，2、计算型，3、磁盘损耗型，4、综合型（既耗CPU又耗磁盘）。

在分析过程中，取900多实例做了一个训练集，人肉对上述实例划分到这四类中。

在样本处理阶段，我们用了比较通用的一个归一化处理，就是一个偏移度，把它变成零到一之间。

在标签这块为了匹配神经网络的效果，讲四种标签类型用编码的方式展现出来。

输入的神经元个数即我们获取的监控项，这里是7。输出层是4。算法的同事选取的隐藏层个数是14。

刚才提到的900多个样本，按照七比三划分600多训练集，200多测试集，通过这种迭代我们能够判断测试集准确率达到95%，基本上判断这个算法是可用的。

通过上述手段，我们把机器和MySQL端口实例分别做了画像（机器画像复用了资源回收的那个系统）。

因为我们获取实例画像，怎么把实例更好分布在我们认为闲置的机器上，然后回收掉没有实例的主机，就是我们的目标。

我们定了一些基本调度的需求，比如要求迁移次数少，迁移影响线上服务尽量小，确保主库和大访问量端口保持稳定，

还有控制主库个数。我们还会加黑名单，有些未来增长量比较大的MySQL端口冗余。

目前看，现在30台高配数据库机型，14台可以节省出来复用。

目前这套MySQL资源分配体系很多地方不能自动化，但上面的尝试是我们在一个月内完成的，我觉得还可以，后面也会一直持续不断地去做类似的事情。

下面是我们做的一个异常检测的应用。

传统的检测方式，一类是我们定义的阀值超过多少报警；还有一类是超过这个数和达到一个数字后报警。

比如下图的360内部的监控系统，能做成这样也算比较复杂了。

阀值有了，监控多少次，当这个次数平均或者最大、最小等于时候才报警，而且我们限制报警次数，报了多少次不报了之类的能力。

而且当同类报警出现，满足某些情况下，我们将其合并，把报警收敛起来，我们认为已经很极致了。

十多万台机器，我们用一套硬件监控体系，把所有认为可能合并的能力都放在那儿，但是运维工程师还是很苦，有很多重要信息还是被淹没。

刚才那个的应用场景是带宽流量，主要涉及交换机流量变化，还有LVS突变。

但是有些时候还要关注业务的属性以及所属业务的重要性，有些业务线挂了一段时间也可以不管。

基于这个诉求，我们又把它做了一个检测等级划分，即刚才整个外面的算法后面加一个系数，再根据敏感程度最终去判断是否值得报警。

这些调整后，我们线上验证准确度达到80%。还是能节省大量人力。

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

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

这是我们基于主机报警事件的根因分析，报警是一个事件，报警的时候有一堆监控项，如果发现报警监控项的相关性，我们可以做到一些根因分析，这部分能力资深运维能看到。如果没有经验是否能分析出来相关性，我们算法来实现。

这是微软2014年的论文，在发生特定事件时候，我们前面取一个窗口，后面取一个窗口，中间取一个窗口，如果这三个窗口规则和模型一致，我们认为这个事件各报警没有关联性。如果不一致的话，说明这个报警对我们监控项可能导致报警的因素，我们会找到这些因素用信息增益比判断其中哪些因素导致报警核心的原因。

这部分还在持续开发，我们已经获取了下面这些关联关系（事件、关键指标、准确率）。99%事件几率是由哪些关键指标体现出来的。有些结果我们发现比较有趣，比如磁盘读写性能会受这些东西影响，报警时候跟这些东西正相关的。

4. 经验和总结

这是最后一部分，团队对 AIOps 的经验和总结。

第一个，我们的数据库选型，搞 AIOps 时序数据很重要，我们尝试用过很多时序数据库，因为考虑到写入性能问题，成本问题，最后influxDB，而且我们没有多写，就写一份，允许丢失，丢就丢了。针对事件告警日志还是用MongoDB，可视化展现需求用rrd。如果为了一些场景下提到的关系展现，我们还是用MySQL。针对实时的热数据、计数器，比如取TOP多少用Redis 。ES也可以用，主要做检索引擎，也可以可以做些日志。

第二个经验不是技术问题，是项目管理问题，PDCA，我们每做一个智能 AIOps 项目要不断地迭代。

我们做运维项目和AIOps项目很多时候能做到有计划、能执行，但是实现之后，能否持续检查和演进处理可能扔掉了。最终导致这件事情越做可能达不到我们趋近完美结果。

AIOps的项目失败率很高。如果大家做这个方向的话，自己心里应该知道，很多时候奔着一个目标去，但是得到结果很不理想。强烈建议大家一定要在计划、执行、检查和处理过程中把这个东西一步步改进好，当然该舍弃时候要舍弃。

第三个经验，我们按照大数据理念，把整个运维大数据做了一些分层，构成了运维大数据平台，主要分为原始层、明细层、汇聚层、应用层。

原始层就是上面这些指标和数据；明细层，完成数据标准化，同时按照业务分类完成数据分类，这个业务分类也很泛泛，运维里面还是我们经验，可以这样分类就这么分；到了汇聚层，我们在哪一个领域里做AIOps能力，我们按照主体域完成对于数据汇聚，形成统一试图；然后就是将这些汇聚的维度各种组合，解决AIOps要在哪些场景实现哪些能力的问题。

这就是对于运维大数据资产的架构，这是脱胎于360大数据平台部门的一套体系。

本文根据作者在GOPS 2018 · 上海站的演讲整理发布

《企业级 AIOps 实施建议白皮书》v1.0  GOPS 2019 上海站正式发布

各大行业名企案例等你来撩~

GOPS 2019 · 深圳站官方视频新鲜出炉

点击阅读原文，访问大会官网