AIOps 在腾讯的探索和实践
欢迎你们前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~算法
赵建春 腾讯 技术运营通道主席 腾讯 社交网络运营部助理总经理 AIOps 白皮书核心编写专家微信
我今天要讲的主题，AIOps，是一个比较新的话题，其实从概念的提出到咱们作，只有差很少一年的时间。一个新事物，有其发展的周期，在腾讯里面咱们作了比较多的探索，可是确定仍是有不足的地方，就像我们看到的 AI 的发展也还有不少不足的地方。今天带来一些案例跟你们分享，但愿对你们有一些借鉴和参考的意义。网络
1 从一个 NLP 故事提及框架
首先我想从一个 NLP 小的故事来讲起。运维
在二十世纪三四十年代，人们大量尝试用机器的方式去理解天然语言，开始是用相似于左图同样的语法树的基于规则的方式处理的，但后来逐渐地变化为以统计的方式去作。机器学习
到了二十世纪七十年代以后，基于规则的句法分析逐渐地走到了尽头。工具
1972年的时候，天然语言处理领域大师贾里尼克加入了IBM。1974年左右，他在 IBM 提出了基于统计概念的语音识别概念，以后天然语音识别的效果就不断被突破。学习
2005年谷歌基于统计方面的翻译系统全面超过基于规则的翻译系统，规则方法固守的最后一个语音识别的堡垒被拔掉了。测试
能够看到二十世纪七十年代前，基于规则的天然语言处理的学者和专家们，注定是失落的。
为何用这个故事来作引子，是由于我以为我们的运维环境，每一年会有大量的开发人员加入，写了大量的代码交给咱们。
随着业务量的增加，设备会不断增长，系统会愈来愈庞大，复杂度成指数级增加，而这些压力全给了咱们，还有如咱们的监控 log 等数据也是很是的海量。
因此我以为运维系统和天然语言处理是有类似之处的，语言是很是复杂的，量级也是很是大的。
第二个，运维的经验，本质上就是一组组的规则。在咱们的运维环境里，不少自动化的运维系统，就是一组组规则的实现。规则有一个好处，就是易理解，但每每有场景遗漏。
规则确定是一我的写的，一我的面对海量的数据时，处理这些问题会显得力不从心。AIOps 不是替代 DevOps 的，而是对 DevOps 的一个辅助和补充，是对里面规则化部分进行 AI 化的改造的过程。
规则是咱们的经验，也是咱们的负担，就比如20世纪70年代前的那些专家，咱们也须要进行一个转型。
那什么是AI呢?
AI就是从大量输入中总结出准确预测的规律（模型）。咱们经过x1 x2 x3这样的大量的输入，经过统计一些参数，abcdwb这样的一些参数，让咱们在新的环境中来拟合的预测作一些数值、0一、几率型的预测。包括强化的学习，也是经过另一种形式获取数据进行统计，经过每次的探测，你能知道这一次成功和受益是多少，是正收益或者是负收益，仍是零收益。
其实咱们只要有足够的数据的量级，能够重复地去探测，而且得到反馈。
易于接入 AI 的场景是特征清晰、正负特征易抽取，就是什么是对的，什么是错的，咱们能够比较好分类，有持续地反馈。
数据+算法+训练，能够训练出一个模型，这和以前的规则是有差别的，能够认为是一种有记忆功能的模型。
可是若是要接触AIOps会发现一个问题，就是我多是一个小团队，或者说我缺少算法专家，还有即便用了别人的算法模型，我还但愿了解这个算法的原理。
最后一个是，提供算法的一方和使用算法的一方，都不肯意提供数据，担忧数据泄露给对方，那双方都有这样一个担心，这是面临的困难。
那对于之前的运维的环境里面规则来说，其实你能够认为他是API，或者是一些编写的逻辑处理，特色就是不多会变，由于是人编写的，因此容易理解，专家总结了，和数据无关，他写好就放在那里，相似 if-else，case swich 等。
可是 在AI，前面讲了，实际上是一组带有记忆能力的 API，这个记忆能力是从哪里来的，就是对数据有依赖的，从数据里面统计学习而来的，同时环境里面不断地在积累这个数据，可能不断有新的案例进来。
因此这个模型时刻地在变，很是复杂，它多是决策树的决策路径、回归参数或神经网络的网络结构及路径权重。
由于它的各类的算法，决策树的神经网络的结构，以及他的权重，或者是回归参数至关复杂，这个不是人编写出来的，因此就难理解。
2 从API到学件
因此 AIOps 咱们能够来一个从 API 到学件的转变，“学件” 概念是南京大学的周志华老师提出来的，他是国内 AI 领域的泰斗级的人物，很是厉害，他提出学件是经过数据能够不断地学习，随着数据的不断地加入会更好，另外它的算法是公开的，你也能够了解它是怎么实现的。
你也能够拿过来用，经过个人数据训练好模型后给你，但没有把数据交给你，把参数、网络结构这些东西交给你，并无把数据交给你，来解决数据安全问题。
你也能够用本身的数据从新去训练改进适应本身环境的模型，因此是可演进的。算法也是公开可了解的，拿来能够重用，来解决里面的一些问题。
这是咱们前一段时间和业界同仁一块儿编写的 AIOps 白皮书的一个能力框架，我不展开来细讲。
咱们大致的想法就是说最底层就是各类机器的学习算法，这个算法和咱们的实际环境场景结合起来，经过训练一些单个的 AIOps 学件，单点场景也能够解决问题，以后把单点学件串联起来组成 AIOps 的串联应用场景，最终就能够造成一个智能调度的模型，去解决咱们的运维环节的成本、质量、效率等运维关心的问题。
AIOps 五级分类：
- 一级，尝试应用
- 二级，单点应用
- 三级，串联引用
- 第四是智能解决大多数比较重要场景的串联问题
- 第五级，既然都提到AI，咱们仍是但愿能够有更大的梦想。咱们是否能够有一个就是像黑客帝国里的天网同样的智能运维大脑，能作到质量、成本、效率多目标优化。 好比在推荐场景里，我即但愿用户规模愈来愈大，也但愿活跃愈来愈高，同时但愿他的消费水平愈来愈高，可是这三个目标是有冲突的，就像咱们的成本和质量是有冲突的，可是咱们但愿它在多目标里有一个比较好的均衡，最高级别的时候，连多目标均可以进行同步的优化去平衡。
整体来说，但愿 AIOps 是 DevOps 的一个补充，而后从单点到串联到智能调度这样一个过程，去解决运维里成本、质量和效率的问题。
而后咱们团队跟高效运维社区作了一些实践和理论方面的探索和尝试，今天也但愿经过这几个单点的串联质量效率这些纬度跟你们分享一下。
3 咱们的实践案例分享
1. 单点案例：成本 - 内存存储智能降冷
单点第一个是成本，就是内存存储智能降冷，由于咱们是社交网络业务，用户规模大，又有大量的访问，这样就致使团队喜欢用内存型的KV存储。
上线的时候，请求量可能很高，可是随着时间的推移，他的数据量不断地增加，访问密度反而在降低，对咱们的成本形成很大的压力。
那你们会想到降冷，可是降冷以前你们都熟悉就是利用数据的最晚使用时间按规则处理，可是这个你想一想其实只有一个指标，这个数据的最后使用时间，做为特征去分析，其实远远不够的。
咱们对每一类数据作了很是多的特征的抽样提取，有几十个特征，如周期的热度变化这些，就是如图上这些，还有一些没有写出来的。
而后咱们同窗根据的经验，由于他们以前手工处理过不少，就会有一些经验，哪些数据条目是能够降冷的，把他标注以后，用逻辑回归和随机森林，去学习和训练，其实就是作分类，机器学习绝大部分都是作分类。
作一个分类以后，上面是 LR 和 逻辑的回归，下面是随机森林。那在随机森林，在 30 棵树的时候效果最好，由于随机森林原本就是一个 bagging 的方法，对稳定性效果有提升。
最终的效果就是说，咱们把数据进行了一个下沉，把接近 90% 的数据，下沉到硬盘上，咱们的访问量并无降低，SS D数据没有形成访问压力，能够看到下沉和降低是很是精准的。
并且这里面的数据延迟和成功率几乎没有变化，其实以前的同事经过人工的设置作下沉的设置，其实效率是很是的低，这个模块提高了 8 到 10 倍的下沉的效率，这是第一个案例是成本的。
2. 单点案例：质量 — 统一监控去阈值
质量，你们能够看到统一监控去阈值是颇有意义的一件事情。监控有两种状况，一种是成功率的监控，它应该是一个直线，正常应该在 100% 左右，但它会往下掉。
第二个就是相似于一个累计性的曲线，或者 CPU 的曲线，这个曲线监控实际上是很是的变幻无穷的。
以前咱们多是经过设置阈值的方法，最大值最小值，阈值设置这样的方式，去设置告警。
这个曲线一直在变化，最大值和最小值也一直在变化，而后他的形式也很是的多变，也很难去设置这样的东西。
那咱们作了两种的方式第一个是成功率的方式，咱们使用了 3sigma 方式，来自于工业界，是来控制产品的次品率的，若是是 3sigma 是 99.7% 是正品，其实用这个方式咱们统计出来的告警里面，超过正常值范围里面的多少多咱们认为是多少个次品，把它找出来。
第二步用孤立森林，就是长的类似的一类的东西，是比较难分类的，要经过不少步才能够去到叶子节点上，因此看到这个 Gap，这一块就是说在比较浅的叶子的节点，就是异常的节点。
咱们经过第一步统计的方式，第二步的无监督方式找到一场。目前最后一步咱们仍是加了一些规则，让告警更可靠。这个规则其实就是看到我在何时告警和恢复，这样一个逻辑既然是一个规则，在将来咱们会进一步作一个 AI 化的改造。
那对于这个曲线型的监控，目前咱们就是由于曲线不是属于正态分布的，一个曲线是一个曲线，因此极差很大。咱们把它作了一个分段的 3sigma，就是一个小时一个段，过去7天进行一个采样。
还有曲线咱们能够用多项式去拟合这个曲线，咱们用 3sigma、统计方法、多项式拟合几种方法做为第一步，就是至关于推荐系统里的多路召回。
第二步依然就是孤立森林，和前面讲的原理一致。
第三步就是有监督的人工标注，就是图上画圈的有些告警有一些不该该告警的标注，标注训练集后去训练自动地分类。
为了得到更多的样本库，同事们用这个叫相关系数的协方差算法，寻找更多的样本库。你们能够关注一下，就是说去找一些类似的曲线，对训练很差的模型，就再进行打包去训练。
总的方式，经过三级的过滤找到异常的告警。
咱们有十万多台设备，超过 120 万个监控视图，其实以前咱们 70% 以上都没有设告警，由于很难每一个都设一个最高值最低值，因此说目前就把这些模块都归入到这个监控里面去，百分之百覆盖，这是一个监控区域值，去设置的一个案例。
3. 串联应用案例：质量 — ROOT智能根源异常分析
第三个案例，就是质量的串联案例，异常根因分析，其实咱们的同窗其实在不少的场合分享过。
咱们对咱们的系统作了不少这样的访问关系统计，生成一个业务访问关系视图，就是业务的访问关系是什么样子的，最后就会画出这样一个图来，就像蜘蛛网同样，这只是其中的一个部分，可是故障发生以后，到底哪个是根源的问题。
根因分析最开始的作法，是经过先降维关系的方式，右图左边这一列全是同一个模块，由这个模块产生的每一条路径，咱们都列出来，就是右边多条路径，这个路径模块里面，把告警出现叠加在模块上，而后设置一我的为定义的面积算法，从面积的大小，就断定哪一个模块是异常的根源，虽然是基于规则的，但以前效果还不错，能够帮助咱们找到多是根源的 TOPN 告警，但如今咱们又把它作了一些基于AI算法的更新。
中间这一排，就是前面介绍的根因分析的主逻辑。在告警叠加前面，访问相关的模块才是致使根源告警的模块，因此咱们先经过访问关系紧密度进行社团 Group 划分，把一些互相访问紧密的模块，作了一个聚类。
而后告警严重程度接近的，互相致使告警的可能性也更高一些，再用 DBSCAN 类的密度聚类算法，进行聚类。最后再用频繁项集和相关系数等去找一些重复出现的，就是相关性的，贡献度和支持度这样的一些方式去找这个缘由。
另外咱们在作交流的时候，也有人给咱们提出一个建议，就是用贝叶斯算法来找TOP根因的几率，由于这个是一个几率性的统计，咱们目前也在进行实验和测试。
4. 智能调度案例：效率 — 织云全自动扩容
再来看一个智能的调度的案例，我以前想智能调度是一个很宏大的目标，并非只是有点像这样的东西是一个小的改进，那咱们智能的全自控的扩容流程。
以前咱们在不少的场合讲过智能的工做的流程，他实际上把一个业务模块上须要的资源所有登记进去，以后经过申请设备、获取的资源，发布部署、发布自检、业务测试、灰度上线这样的 6 大步，实际上有二十多小步，咱们会组合，组合成不一样的流程，那咱们看一下这个流程。
（视频播放时对视频内容的简要解释）一个模块的自动扩容，先是添加一些资源，其实就是上线一个新的业务，可是正常状况下他是自动执行的。会有一些业务包，会有一些基础包，还有一些权限，这个权限也是基础化的东西。
咱们监控看到压力不断地增加， CPU 增加到 75% 以上，随着增加，咱们发现这个系统压力超标了，系统自动启动了扩容，这个是加快的了好几倍的样子。
这样一个过程，就是刚才列了 20 多步的扩容的步骤，就自动地在执行，执行以后企业微信提示对这个模块进行快速上线，而后监控到他有问题，就是快速地上线。
上了两台新的设备，而后这两台新的设备，负载在增长，老的流量在逐渐地降低，最后达到一个平衡。
这就是咱们腾讯织云的全自动扩容，目前其中的容量预测及不少监控都已经通过了必定程度的AI化的改造。
我还想重点讲下其中有一个叫平衡木的模块。为何要平衡木，由于监控这一块也讲过了，平衡木对于一个模块来说，一个模块几百台上千台的设备都有，虽然对它设的一样的压力权重，这是真实环境里的数据，就是上下差别很是大。
而后咱们经过平衡木这样的一个调整，就能够把上面这样的负载曲线，基本上能够缩成一条线，第二个的曲线容量就变成的 40%，也就是说你经过这样的一个调整，让你的支撑能力，增加了 22%，那它是怎么作的？
实际上咱们有一个机器学习，就是但愿咱们的模块里面，每台单机的负载，尽量的一致，设置一个loss function，咱们用梯度降低的方式，找到这个 loss function 里参数w1～wn的设置。以后经过几轮调整，使得全部设备的负载趋于一致。
5. 更多单点或串联应用
还有更多的单点和串联应用，其中一些因为以前在 GOPS 上海分享过，这里只是简述一下，作为一些案例参考。
第一就是多维下钻智能分析，由于一个 APP 上线以后，你可能会有播放平台，运营商有域名，每一个里面有几百个设备，运营商里面有多个运营商，一旦出现一个问题，有多是魔方里面的块出现问题，很难定位。
好比咱们找到先后数据差别化很大，但访问量很小，那它就不是核心的，核心的就是差别性越大，贡献度越大的那些异常，就多是出问题的那个。
你们都知道啤酒尿布的案例，那频繁项集算法，就是 A 告警出现以后，B 告警确定会出现，同时 AB 出现的几率还会超过必定的比例，咱们就能够找到这样的一些东西，对他进行合并的告警。
第三个就是咱们一直有一个智能体检变动报告的东西，就像以前谷歌的讲师也讲到，谷歌经过各类的监控方式发现此次变动以后，是否出现故障。好比可能流量增高，或者有异常告警。
咱们的变动检测报告，会自动监测变动后模块的各项指标变化，来辅助工程师判断，此次变动是否正常，输出分 2 类，正常状况不输出能够忽略:
一类是变动后致使了数据的大幅波动，但可能不是异常，如流量大幅增加；
一类是变动后可能出现了异常，如产生了大量 coredump，须要去处理。如何处理也是一个二分类的问题，咱们也会在将来改造。
上一次也讲到咱们智能客服的问题，利用 NLP 技术，能够作信息检索类、操做执行类的智能客服工具机器人。
4 思考和展望
作一点简单的思考和展望， AIOps 才刚刚起步，可是作的时候，能够考虑把它作成相似公共的组件这样的形式，就是学件，不一样的是它们带了一种学习的结果在里面。
有些场景是公司的内部的场景，能够在内部变成一个学件来用。可是对于一些共性的东西，好比说监控，各个公司的监控场景是同样的，若是咱们把它定义成标准的上报的格式，标准的时间区间，训练好了 AIOps 的模型，你们承认了效果，就能够一块儿来使用。
“学件”这个词，周志华老师也在多个场合去讲过。经过编写相似这些共识的上报格式，命名规范等，会让公共的 AIOps 组件变得更加的共享、共识，这个也是咱们将来但愿更多放到标准里面东西。
这个也是AIOps的标准委员会存在的一个意义。
下面这个图是咱们织云的 Metis 平台，咱们但愿先在内部造成更多的学件库，再去解决一些串联的问题，刚才也举了一些例子，也但愿在将来的几个月，或者一段时间里，开放出来跟你们一块儿学习，共同地探讨和改进，可能个人演讲就到这里了。
最后用一句颇有名的话作个总结：通常状况下，人们经常会高估一个新技术在一两年内的影响而低估其在将来五到十年的影响。
而 AIOps 就是这么一个技术，做为 DevOps 的辅助和改进，相信它必定会让 IT 运维变的更简单从容，真正地成为运维同窗，运维线的一个助手工具和智能化的大脑。谢谢你们。
此文已由做者受权腾讯云+社区发布，更多原文请点击
搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！
海量技术实践经验，尽在云加社区！