聂鑫：来腾讯工作快12年了。在腾讯服务的12年里都在一个部门没有变过。2006年去腾讯的时候正好赶上腾讯在做DO分离，第一代BAT企业应该也都是在那个时候开始推进运维和研发分离这件事。那时候的运维什么基础都没有，一穷二白，真的很艰难，除了不用扛设备，其他什么事情都要做。这十多年来见证了腾讯运营体系的一系列演进的经历，中间有很多辛酸苦辣，当然也有很多收获，坚持下来自己有很多的成长，觉得这个行业很有意思。感谢主办方让我今天有机会跟大家一起聊一下这段经历。今天时间有限，主要会和大家分享是在AI里面的实践结果，一些演进过程。

首先介绍一下我们的团队，我们是一个运维团队：SNG的运维团队，和其他公司的运维团队一样需要做很多的工作，比如天津大爆炸的事情，要把用户从天津迁移到上海和深圳，完成1/3的QQ用户迁移。春节红包，这也是我们运维团队支持的项目之一，每年春节都要做很多的事情。成本优化也是一样，运维关注成本，所以也做了非常多的事情。我们腾讯SNG的业务主要包括QQ、空间、腾讯云等社交业务，腾讯还有微信、游戏等产品，和SNG的业务心态不完全一样，遇到的困难和问题也有很大的差异，所以还是需要先介绍一下背景。

SNG的业务有什么特点？单体量很大，单体超过2万台，还有很老的业务，比如说QQ近20年的产品了，新业务也很多，每年上线二三十个，每年也有一些业务消亡，这是互联网的现实情况。其他特点包括多产业、多终端。作为运维来说，要维护好其实挑战难度很高。

最直接的一个数据。我们面临一个大的挑战，比如说每天告警短信会超过5万条，人均收500条，其中最高的时候收1500条。每天上百条短信发手机上是什么样的感觉？基本上是死机状态的，所以一般两个手机，一个打电话，一个发短信。我们当年向往着做咖啡运维，喝着咖啡，翘着二郎腿就能把运维做好。希望做咖啡运维，但是实际上，到现在为止也没有真的做到，有很多的困难。

其实要往咖啡运维演进的话，自动化是很重要的。大家现在熟悉的是Docker，但是之前我们有自己的管理方式，比Docker细。前面的视图是我们做配置系统来管理资源做发布。自动化上我们会做一些基于时间序列的容量预测，判断高负载，这个是自动化的。现在是没有人值守的。当出现高负载的时候，我们自动化流程就开始跑了。大概十几个步骤，一下播放的视频是直接录的屏，大家可以看到基本是全自动的服务预测和上线扩容。

前面通过容量预测的方式预测，通过自动化的方式完成扩容，右边打着马赛克的视图是我们通过智能的方式去做上线后体检报告。服务器扩容挺容易的，但是之后的上线是一个难解决的问题。我们通过体检报告的方式来验证我这个服务上线之后的1分钟、5分钟、10分钟、20分钟的时间切片里面的所有数据，告警、监控收集起来做分析，看有没有问题，如果没有问题我们认为这次自动上线OK，如果有没有赶紧回馈。视频上可以看到自动的从3台服务器扩容到5台，并且流量已经均摊到新扩容的机器，完美应对了流量高峰。

自动化解决了我们运维的繁琐的日常工作，但是没有解决条5万条告警的问题。下面我们分享主要围绕怎么解决5万条的告警的问题。分享分三部分，第一部分是我们过去做了哪些事情，第二个是我们做了哪些有自己特点的东西。第三个是我们用AI的方式让做的事情更加智能化。

我们运维也不是希望有5万条告警，其实也是挺被动的，我们2006年做监控系统的时候有一个很大的问题，运维是根据需求来的。研发团队，产品团队业务遇到了问题，需要运维做一套系统来监控我们就根据需求去实现了某种特定场景的监控，就这样我们不断做了很多套监控系统，对各种场景的都做了覆盖。产品希望监控更快，我们不断提升监控的频率，让我们的告警发的更快。但是造成的问题是很多的误告警就出现了。监控领域的快、准、全这三个目标都能达到，但是是矛盾的。怎么利用好？是成为了运维的一种技术能力和艺术。

从2006年-2016年，我们断断续续做了二十多套系统，我们为了解决这个问题，不断的针对各种方面的监控，希望帮助业务解决问题。首先腾讯的业务是比较有特点的，分多层的，中间的逻辑层会比较重。把很多逻辑后置，我们的接入层的逻辑比较轻，大量的服务逻辑和业务的逻辑在逻辑层完成。这样的业务架构在整个体系里面有很多，每个业务都是这样的，造成互相之间的一些调用，一些依赖，整个关系变得很复杂。我统计了一下，从2009年开始这个量不断增加，2014年超过20多套。监控指标，实例数也是几何性的增长，比如到了2014年，告警数超过5万条。最高的告警已经超过1500条。我们做全了，很多东西都监控了，但是结果是告警泛滥。

第一部分，分享的是有哪些事情跟大家一样的。2006年-2013、2014年的时候我们当时受需驱动，受技术架构的影响，我们的监控也做的比较简单。视野主要是放在解决一些监控点上的问题，我们的运维团队不断优化这件事情，但是是在点上优化。比如说技术监控，互联网企业都有，一看曲线就了解了。自动化模拟测试也是一个用的很多的系统，模拟用户的请求，判断用户返回的结果的关键字，做告警、分析，也是好用的系统。

模块型调用。通过打点的方式在服务A和服务B的调用中把访问的延时、成功率进行收集，最后做一些数据的处理，发现A和B的调动的成功率和失败率的数据，我个人认为非常好的系统。到目前为止，有超过10多年了，也是我们最主要的系统之一。还有大家熟悉的测速访问。在用户端埋一些监控点，通过各种方式把数据报过来给大家看。前面看到的是跟同行用的方式基本一样，我们也是这么用的，用这种方式可以解决一些问题。

我找了一个例子，大概是2012年的时候，我们老大说服务做的不太好。依据是上百度搜，比如说“QQ空间打不开”，第一屏全是负面新闻，这样子觉得服务不好。当时我们想去优化，开始优化空间的首屏的打开速度，黄色的是空间，绿色和蓝色是微博和朋友网。我们的确慢很多，原因很多，比如图片很多，有装扮，有很多的feeds，所以打开慢是很正常的，微博轻量、朋友网简单。我们找了很多的理由。最后我们耗时8个多月的时间，把我们的优化，从落后它30%、40%，到优化后的比它们快20%、30%，事情挺完美，领导非常认同，做的挺好。

但是这里面隐含了一个问题，三个骨干，历时8个月时间，公司还有团队配合我们做，投入是非常巨大的，有用，但是效率并不高。所以，也是想说明我们常规的这些监控手段其实能用，但是离智能化运维和AI运维有挺大的差距。

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

第一个有意思的就是多维数据。这个比较早，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万个。基于这三个，我们训练出一个模型，放在监控系统最后，所有的告警首先经过我们的模型之后才会发出告警，这就是萧总提到的学件。

这一页展现的是达标的QQ群，运维人员在这儿打标，第一个曲线这种形态，我自己也不能判断要不要告告警，还得找研发团队确认为什么这个曲线这样，什么原因，需不需要监控。没有一种方法可以直接用AI解决问题，最终是人打标去做数据的过程。

三个算法的结合之后，我们的过滤比例可以高达万分之一，这三个算法，两种算法一起跑，三种算法一起跑，效果比之前好很多。这个是一个视频，就是学件。前面把统计判别、无监督、有监督算法串起来之后做时间序列异常检测，我们包装成一个学件，起了一个代号，我们希望把这个首先是开放出来，在腾讯云上做成一个接口。有兴趣的话可以把自己公司的时间序列的数据，通过API往里导，帮你预测。第二个是也正在做开源，把这一整套的管理方式和算法以及最后的一个基于腾讯的运维数据训练出来的模型全部开源给大家。为什么要全部开源？我们发现，我们这个算法给到公司的另外一个部门，网评部门，网络交换机的那些数据也有用，但是准确率没有自己的高。说明这些算法还是需要拿不同场景数据去做训练才能得到比较高的准确率，我们把算法开源出来，根据自己公司的数据参与一些训练打标。这是我们的打标的过程，各个公司自己做，我要告警还是不告警，基于某一种场景，也可以好几种场景分开，每一种场景训练一种模型，这样可以做成各种各样的模型开放给大家。应该会在今年9月中旬左右会开源给大家，希望我们在这里的一个尝试，已经一年多了，希望开源给大家一起去用。

这个Metis系统是我们使用的一个方式了。相当于把大家的一个时间序列数据报上去，在这里面做各种标注，应用不同的算法，这里面有阈值的算法可以使用，未来我们希望能够把我们这个平台开放给大家直接用。这个视频会后可以发给大家看一下，就是整个过程是介绍我们怎么做时间序列标注的一个过程。

前面讲到用AI的方式去解决我们时间序列异常预测的一个问题，断断续续做了一年多，其实目前也在我们这边，在我们自己的系统上全量开始上线了，效果还是挺不错的。

第二个想跟大家分享一个AI的问题是根因分析。做AI都听过根因分析，没听过根源分析。在业界里面，应该只有根因分析，但是我们自己实践过程中发现有一些区别。我们先分析一下根因是什么，我们怎么做的。第一个是我们不断找问题，优化问题的过程，比如以前我喜欢用洋葱，一层层剥开就能找到问题。后来发现不行了，随着多维的开始，不像洋葱一层层剥就好了，变成了很多的维度的组合，这是多维系统中相对特殊的服务，是腾讯的一个服务，首先先到这个服务，再分转到后面的服务，它的维度特别多。

比如说这里面我举其中的五个维度，APPID，命令字几百个，运维定位问题的时候，过去的做法，我们基本上是运维在里面不断点、不断找，看看哪几个维度的失败率最低，找这个问题。以前维度没这么多的时候还可以这么做，但是这种情况，基本上靠运维点已经做不到，我们想说AI有没有办法解决？首先是用决策树，建立一个决策树，把维度组合，不断分，那条路最大的就是问题组合的那个失败率就是最大的，在做多维度组合的判断的时候，效果很好，但是同时引出来一些问题。什么问题呢？第一是新产生的异常的识别，训练完之后相对模型固定，但是对多维来说维度不限制，往往我们增加或者是减少维度，新增加的东西往往会出问题异常，但是往往在老的维度里面没有，被基本忽略。出现这种情况的时候就失效了。第二个是成功率不变的情况下数量发生变化，对这个场景我自己都没关注过，我们做运维找问题的时候，一般看成功率失败率，变了就认为有问题，但是很少关注量，比如说失败率可能是0，代表说正常的情况下没有失败，但是量可能会发生变化，某一个量出现问题的时候，会产生变化，被埋没到大盘数据中，基本被忽视掉了。第三个是计算量巨大。后来换了一种方式，用广告学的手段做尝试。我首先还是举了一个例子，这是腾讯直播的一个例子。

腾讯的直播里面已经接入很多的用户，比如说虎牙、YY，全是接入腾讯的直播平台上，但是出了问题，直播平台出问题，运维定位问题很痛苦，不知道哪个业务出了问题，也不知道是哪个域名，也不知道是国内还是国外，我们通过前面的多维的方式，结合新的根因分析的方式，这是一个案例。比如说有三个问题，我们系统自动分析出来的组合，可信维度的组合。比如说虎牙、YY出了问题，这两个推流域名出了问题，我们和人工研发去对，真的就是这个问题。这三个例子都差不多，都是一样的例子。那么原来在我们定位这些问题的时候，不断的去组合，但是现在系统可以自动的从中找到哪几种组合是最可疑的，对我们运维定位问题来说，特别复杂的场景定位问题，效率提升也是非常巨大的。

这个是引入新的算法，比如说这个是正常曲线下应该产生的样式，这个线是电信、联通和移动的数据，正常是这样子的，但是出现异常的时候会发现不一致的地方。比如说移动的失败率这么高了，发生问题的可能性就很大。那么第二个是解释力度值，下面横轴是省份。比如移动的数据，其中四个省份和其他省份的失败率的比例不一样，这四个省份的根因的贡献率就更大，通过这两个算法可以做组合，很快能找到，两种三种或者是四种组合造成了问题。

这样我们通过新的算法之后，当出现问题的时候，系统会自动给到一个组合结果，告诉你这两种组合，这里是APPID，这里是访问码，告诉你这里有问题。系统可以引导用户点进去看，如果这两个失败率和成功率出现了最大的波动，就可以很快找到根因。

我又截了一张图，到底什么东西是成功率和失败率不变，但是量在在发生变化。平时量是不变的，但是出了问题量就变化了，这种以前常常被忽略，但是现在可以纠出来。

分享两个案例。到目前为止我不太知道哪家企业去做阈值，但是2016年我们做了，效果不错。建议大家尝试一下在各自的团队和企业中尝试一下DevOps的概念。通过AI的方式，就是我们前面的开源的学件，可能有86%左右，招回率也可以达到一个能让人让接受的一个水平。第二个就是多维，我们认为多维的分析手段应该是未来运维在排查问题中最主要的一个手段。但是定位问题的效率确实不太高，咱们也分享一下用AI的方式能帮助我们快速在多种维度组合中找到最有可能的可用维度的组合。两个案例结合我们两个AI的落地，跟大家分享一下。

最后是一个总结，也是一个小小的心得。做AI真的要数据。我们做AI的成绩来自于我们从2010年就开始累积大量的数据，现在发现这些数据是特别宝贵。第二个是一定要参与其中，除了AI的工程师以外，要有业务的工程师。通过打标，最终还是需要有很多的语料库，包括我们的标注库，能去发现一些问题，做合适的样本库。第三个部分就是一个演进，我也是做这个监控的一个回顾的时候自己总结的。比如说2012之前我们做的事情全是点，做了很多的事情，做了很多的监控，基本上是基于点，但是2012年之后有很多我们开始做面的，比如说ROOT的根源分析，今天先抛一个名词出来，还有微形分析，多元分析等等。到了2016年左右开始往深度去做，比如说AI的方式在数据挖掘，做去阈值的申请，这也是运维在监控领域演进的一个必经之路。方法也在不断变化。从传统的展现手段到通过大数据的分类具备的手段，到AI的去规则、去阈值，这个变化也是显而易见的。

最后我还一有本书，前面我们讲到20多套监控系统，有时候有朋友说有没有计划优化它？我把这个抛给大家，看看大家有什么优化的建议。

现场观众：可以整合一下。

聂鑫：大家可以一起探讨一下。这个问题其实和大家交流的时候，大家说到整合，就是把多个系统合并，这个是最常见的一个回答，我们过去也这么多做，想着20多套太多了，拼命的优化，优化到10套、8套、2套、3套，但是前面提到，存在必有价值，有时候做不了，没有办法说某一套系统没用，你会发现很少的系统被优化了，大多数的系统还存在。

我们怎么优化？就是监控数据基于数据本质优化。第一个是流监控，第二是多维，第三是日志。流监控的维度很低，一维两维左右，20多套系统里面80%、90%都是流式监控。现在我其实把这个流式监控的后台平台做好之后，把监控系统的数据迁移到新的体系架构下就行了，我们通过这种方式进行优化。多维也是2012年左右产生的，现在只有一套。日志这是新做的，也只有一套。我们通过数据本质的方法把未来想做的监控和已经存在的监控按这三种分类，把数据迁到新的体系架构上去，最终实现我们的优化。会发现我们监控系统可能还有10几20套，原来有的监控还有，但是后台的架构被集中了，这样子对运维不是一个问题。这是我们的一个简单的分享。

最后这是我们的一个希望，基于AI做优化，迟早有一天做成咖啡运维，喝着咖啡干运维。最后还是想说一下我们9月份会开源，有兴趣的同学可以用一下。今天的分享就到这里，感谢大家。