【2018可信云大会】腾讯聂鑫： 腾讯AIOps实践演进

第二部分，我想分享一下有哪些做的不太一样的东西有很多，我取了两个案例分享一下。首先有个小小的总结，就是放下包袱创新，尊重历史，存在必有价值，有二三十套系统，存在是真的有价值的，不是把这些系统优化一下就解决问题了。可能是架构中存在一些问题，这个先把它列出来，后面详细讲一讲。

第一个有意思的就是多维数据。这个比较早，2012年的时候就已经做好了，现在很多公司也都开始在用，比如说这是我们的图，前面分享的主要是监控的点，自动化测试也好，模块间调用，都是为了监控一个点的问题。那么到了多维的时候，我们已经开始将服务上报的数据按多种维度来组合。一条数据上来之后，可以不受限制的维度，通过大数据处理之后做排位组合，重新找到问题。这种方式在2012年的时候对我们帮助非常大。后来我们基于这样的方法想打造数据银行，这不是今天的关键，用的手段跟大家类似。基于大数据的一些处理方式成熟之后才有这样的技术，在此之前也没有办法解决这个问题。

在这里想举个例子，又是一个有特点的例子。这个是在2012年，这有什么事件？是移动端超越PC的时候。2012年的时候，手机端从数量和请求量全面超越PC，带来很多的问题。我们过去做了那么多年的监控系统很多是为PC做的，都是为PC服务。当移动端的用户来了，运维没有准备好。很多问题曝露之后不知道怎么查。当时应该在2012年的时候，很多QQ端的手机用户认为丢消息，连不上网，什么东西刷不出来，各种PC端没有的问题都蜂拥而至，我们又开始做优化。我们当时做分析，安排了两个工程师，也算是资深的工程师，在多维的组合维度里面去找，看哪些组合的失败率比较高，总是能找到最差的指标。指标之后就和研发去分析。PPT右边的部分我列了七个，有兴趣的可以看一下，这就是跟移动端问题相关的PPT，当时花了3个月的时间找出了四五十项有疑问的这个待优化的技术点，和研发团队一起推动。其中七个是比较影响大的。最终大概3个月左右的时间，我们的结果是移动端的投诉量下降70%多。安全限制占投诉的50%，WIFI健全，热点切换等等这些LOW的问题占了很多的投诉，运维排查效率保守估计是4倍。

这个例子和前面的例子对比，大家有没有想到差别是什么？刚才那个例子，我们的三四位骨干，七八个团队耗时8个月，这里只是两位同学3个月找到了40多个待优化的点，这是真实的数据。通过新的运维的方法论，运维排查问题和帮助业务优化的手段上，效率提升非常大。其实还有一个例子，运维花了2分钟就定位了一个问题，今天时间有限就不分享了。随着我们运维技术的不断演进，在分析故障效率的提升很可观，这两个例子我觉得很有特点。

第二个是腾讯比较有意思的尝试就是DLP，就是生死指标。前面提到有5万条短信，运维很痛苦，但是怎么去优化，也尝试过很多办法，效果也都有，但是可能也就优化几千条或者是50%、60%的告警量，但是想把5万条全部优化掉是做不到的。所以2016年的时候尝试了一个业务生死指标。现在回顾起来这就是AI里面的去阈值的尝试，我们是比较早落地的。这个DLP有几个要求，第一个是不允许有阈值的设定。我们发现那么多误告警，大部分是阈值有问题。很早之前是别人设置的，比如说访问量5万或者是超过50%告警，当时好像很合理，但是随着时间推移，业务变化已经变得不合理，没有人管它。曾经有个代号“ROOT”的案例分析过，有将近60%多的告警是持续告警。就是每天无时无刻都在发告警，有60%多，怎么来的？基本上都是被的不太正确的阈值造成的。所以当时推动DLP的第一条就是不允许设置阈值。

第二个是很多人会挑战说只设置一个指标。比如说产品和在线收入都应该做，每一个服务要把各方面都监控起来，可以看下PPT，为了监控一个服务，设400个监控指标，就是为了监控各方面的数据，有的阈值不对，造成大量的误告警。所以我们规定一个服务只能一个指标。生死指标衡量这个指标是生是死。

第三个是不建议用业务指标。比如说收入，在线。我们推的时候，产品反馈阻力最大，他们认为收入很重要，但对一个服务来说，在线才是衡量业务最重要的指标。但是反过来，这些产品指标受什么影响？除了受服务质量影响也有很多受策略影响，比活动、推广，产品策略调整，涨或跌，都会产生大量的告警。我也不建议做业务指标做告警。因为有了这三个之后DLP就产生了。

不让用阈值了，用什么？我们方法很简单，用一个滑动窗口，4、5分钟左右的一个滑动窗口，根据环比和同比的数据，算出一个动态区间，只要是在区间之内的都不告警，只有超过一定的时间，比如说5分钟就告警。方法很简单，很容易实现。这是我们从几百个指标中去选择几个关键的指标做成DLP。有人常会问这么多的指标怎么选？我们选成功率，如果没有成功率，也可以从这些指标里面可以找出成功数，总数，简单的算法就是算出成功率或失败率。

这套系统上线之后，在推动时阻力很大。业务的研发、产品，都觉得对这种方式不太认同。但是推了几个业务之后，发现效果特别好，因为这个告警的准确率特别高，高达95%以上。一旦告警爆出来基本上是有问题。咱们的研发团队开始觉得，我原来是靠我的告警发生的频率来看有没有故障，一天几百条看不完，现在只要DLP一告警就一定代表有故障，定位问题的时候会非常集中。所以从一开始比较的有排斥心理到慢慢开始接受这种方法论了。

以上的两个小的案例是我们比较有意思的，有我们自己的特点。后面想分享一下怎么通过AI把这个做的更加自然化。

前面四个图我们通过AI怎么做？一开始我们认为AI应该能解决。前面的DLP是用了3Sigma，还有一些算法都跟3Sigma类似。后来我们干脆就上无监督的，希望找一些算法。也用了One-Class SVM，Isolation Forest。最后，发现做AI还是要靠数据，需要人工打标的这个事情。有监督我们也做了，最后我们想干脆把三个算法串起来。所以后来我们开始尝试做一种思路，就是首先把我们的监控领域的数，先扔到我们的算法里面跑一遍，统计判别把符合正态分布的，没有问题的先过滤一遍。疑似有问题的通过无监督的方式，把明显有毛刺的，比如说前面第一张图上去马上下来这种，但是不是严格意义上将这种问题给过滤掉。再进入有监督，我们会把剩下的量不太大的数据，就到我们的QQ群，利用自己的优势，自己建QQ群，发一些有疑问的曲线，我们的运维工程师在群里打标，这个要告警，或者是不要告警，打标之后再去做。目前为止政府样本超过1万个。基于这三个，我们训练出一个模型，放在监控系统最后，所有的告警首先经过我们的模型之后才会发出告警，这就是萧总提到的学件。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!