十年来，在腾讯运维团队发生的点点滴滴，在我心里，都印象深刻。整理了一些故事，发现有些东西可以跟大家交流分享，所以借此机会和大家聊聊腾讯近一两年做的一些AI实现。我们做什么？在IT行业，稍微大一点的公司都会有运维团队。我们的运维团队会和大家一样做很多基础工作，比如资产管理、服务器管理、业务架构规划等等。以2015年天津大爆炸事件为例：在业务架构上，我们在全国多地做了QQ的高可用分发。天津IDC机房迁至上海、深圳。这也是史上最大规模的用户迁移。用户对此一无所知。这是我们运维团队日常工作的一个缩影。另外，每年的红包大家都很熟悉，运维团队每年都会参与整个项目。此外，运维团队还需要关注成本，会花费大量精力优化设备和带宽的使用。其他的还有大家可能听说过的一些突发事件，比如八亿人穿军装的照片，直播业务井喷，鹿晗事件，红米首发事件等等，都是有我们团队支持的。我来自腾讯的SNG社交业务，主要包括QQ、Q空间、腾讯云、QQ会员、QQ音乐等众多产品。它有一些特点，比如非常大的单体业务，有20000多台，老业务超过19年，每年还会有20+个新业务上线。有些业务会慢慢衰落，新老业务变化很快，我们也在做一些2B的东西。我们运维团队面临的环境和问题非常复杂，那么有哪些问题呢？今天的分享是关于我们在AI领域的监控事件。我先抛出这个问题。SNG每天有5万条短信报警，每人每天可以收到1500条短信。想象一下，一部手机每天收到1500条短信是多么令人沮丧。开个玩笑，我们有的领导说，他们看的不是报警的具体内容，而是看报警的频率。如果频率太快，就会出现问题。如果每天以固定的频率发送，就没有问题。这是一句玩笑话，却深刻反映出海量告警对我们运维的挑战是非常严峻的。每天发出5万条告警，背后有近900万个监控指标。这是一个巨大的问题，也是非常有价值的数据。但是我们以前没有用好，今天分享的也是我们在这一点上的实践。我们的愿望：咖啡运维以上是我们的大致背景，更早的时候我们的愿望是能够实现“咖啡运维”。什么是咖啡运维？刚进公司的时候，老大就告诉我们，做运维的个人目标就是边喝咖啡边做运维，翘着二郎腿把运维工作做好。然而，十多年过去了，仍未实现。这个非常困难。业务增长非常快。运维的数量和规模远远赶不上业务和研发团队的增长。相反，我们有越来越多的问题需要解决。正在进行哪些监控？监控很难做到平衡，因为快速、准确、全面是矛盾的。这是我们的业务结构。我们看左边的时间线：从我2006年加入腾讯开始，我们的运维和研发开始从DO中分离出来，运维开始主导各种监控系统的开发，长达十几年。得了吧，建立了20多个监控系统，很吓人。很少有公司做这么多，大部分公司都能做好一个监控系统。而且我们有这么多的监控系统，没有重复建设，到目前为止，每个系统都有价值。2009年，我们的监控指标很少，不到10个监控系统，每天的短信报警数量也不多。几乎在2014年，监控系统的数量就超过了20个，算是处于绝对的状态。现在我们有超过2000万个监控实例。随着监控实例的增多，告警也随之增多，告警泛滥的问题并没有得到解决。有什么相似之处？再看看我们和大家一样的做法：在运维团队，和大家一样，我们会被需求驱动，被研发团队、老板、产品的各种驱动驱动。业务受到架构能力的限制。为了解决一个问题，建立一个监控的方法和方法，慢慢的建立起来。过去的眼光放在监控点上，一个一个解决问题，不断优化。一件事情可以在一个点上做的非常深入，不断优化。对于监控这么复杂的东西，这个效果不是特别好。我们有什么监控？具体如下：基础指标监控，每个公司都有，我们也有。自动化测试模拟监控。我们广播和测试我们的服务，通过模拟用户请求来发现问题。模块间调用质量监控是我们监控中非常重要的一个系统。它报告服务调用数据并执行各种计算以反映对服务调用的监控。测速和返回码统计，下图是客户端直接上报给我们的各种数据。其实还有很多监控。我前面提到的超过一半的人都在做这些事情。大家一看就明白了。很熟悉。我们用的方法和大家差不多，画线，做统计图表，做一些分类。我们也做类似的事情，但就是解决不了根本问题。不过，这并不意味着这些系统无法解决问题。让我给你一个案例。2012年8月，一份报告显示，Q空间主页比微博主页慢35%。为了解决这个问题，我们联合了公司的十几个团队，众多骨干成员通力合作，对系统进行了优化。历时近8个月，终于取得了不错的效果。其中包括：天津联通IDC布局，优化北方15省联通用户。空间首页DOM节点裁剪，减少首屏渲染时间。动态加速度使空间框架加速。空间集合并重组，新模型更换，旅行时间减少。根据GSLB测速结果，重新调整全国各省就近接入点。空间框架机升级QZHTTP版本，支持新特性。中小运营商移动宽带CAP接入。一个很直观的案例说明，传统手段还是有用的，有一定的价值。但问题是，为了做到这一点，我们投入了大量的时间、人力和精力。所以这也促使我们不断思考如何调整，于是就有了下一部分——有什么不同。有什么区别？我自己总结这些不同，其实就是放下包袱，创新。不是进行所谓的体制改造，不是推陈出新。因为每个系统都有自己的价值，很多监控系统还在使用，它们的存在必然有它们的价值，但是我们可以优化后台架构落后的问题。关于架构的落后，我首先要分享的是多维度的内容。这算不上创新，因为随着业界强大的大数据处理技术，海量监控数据开始在多纬度进行组合分析，成为发现数据背后隐藏问题的最重要的监控手段。什么是将数据处理成多个维度的透视多维性？上面说的监控，一看就懂。基本上，我们想收集各种一维或最多二维的数据并将它们报告给我们的系统。按照时间顺序进行所谓的曲线收敛，进行少量的分类。.现在每条报告的数据都有很多维度。只要研发团队愿意向我汇报，没有限制。可以接受一百个维度。我们的后台可以上报几千个10000的维度，用各种方法做一些聚类。截图中可以看到，可以通过不同的维度组合来透视产品的各个方面的数据。这就是我们的智云多维监控系统。可以在版本、平台、客户端、网络制式、省份等不同纬度的组合中查看数据，这些数据实际上是在同一份数据报表上传后，在WeavingCloud中进行处理的。下面还可以看到最大缓冲率、二级缓冲率、最大加载时间误差量的纬度数据。原来的监控数据每次都要单独上报，现在可以通过一种方式准确的在系统中实现，这也是我们目前主流的监控方式。我们用来监控多维数据的技术应该更贴近大家，基本相同：效果是什么？举同样的例子。2014年前后，我们的手机用户开始访问超过PC。带来的问题是运维压力巨大。以前我们搭建的运维监控系统基本都是基于PC，但是当手机用户来了，各种奇怪的问题就出现了。运维在帮助研发团队共同优化产品体验时，利用多维技术将系统中的所有数据上报至智云多维监控，供运维分析。上表有七个优化点，但实际上不止这些。我记得在这个项目的运维中大概有四十个优化点。手机上的一款产品，发现了40多个需要优化的地方。这些数据原本分散在各个地方。使用多维监控后，可以更方便地分析各种异常情况。这个例子，我们运维团队的两个骨干用了三个月左右的时间就完成了。与之前的案例相比，这次的场景更加复杂，技术难度也更高，但是在发现问题的过程中，效率提升非常明显。以前几十个团队八个月做的事情，这里两个人两三个月就可以做完，而且效果还可以更好。DLP：企业生死指标我想分享的第二件事是关于50,000条短信警报。跟很多同事交流过，基本上大家都有同样的问题。每个大型运维团队都面临着告警泛滥的问题，但目前还没有一个能够彻底解决。所以我们做了一些尝试，在2016年推出了DLP，这个是业务生死指标。它有几个限制：第一个要求是不能设置阈值。这是运维规定的，涨跌判断完全是根据指标值来的。第二个要求是一个服务只能有一个生死指标。大家可能会奇怪为什么会有这样的要求，那么请大家想一想，我们为什么会有这么多的告警？为了保证这个服务不出问题或者能在第一时间发现问题，有的服务有400多个指标来监控。这些监控指标包括运维配置、研发配置、产品配置。的。如此一来，怎么可能没有警报泛滥呢？所以在生死指标中，一个服务只允许有一个指标，这个指标是衡量服务是活的还是死的指标。第三个要求是不建议将业务指标作为生死指标。什么是业务指标？例如，在线、收入曲线等指标对业务来说非常重要，但对于衡量一个系统是否存在“生死”故障，这些指标很可能成为干扰。例如，如果您的企业正在做促销活动，在线用户数、购买量和其他产品指标将发生巨大变化。如果你监控这些指标，你无法衡量业务是活的还是死的，所以我们不建议使用业务指标进行DLP监控。什么是门槛？以往我们的监控系统大多采用阈值来告警：比如访问量超过10000次就需要告警，访问量小于几百次就需要告警……之前的监控是这样进行的，但是在我们的Notallowed中，所有的阈值都去掉了。我个人认为“去门槛化”是未来运维监控的趋势，而我们只是通过另一种方式践行了这个理念。当然一开始立项难度很大，基本上所有的产品都不接受，R&D也不接受，因为看起来太不合理了，推广起来很痛苦。但是，随着我们的不断推广，逐渐有一些商家开始尝试并感受到了好处。他们收到的DLP警报非常准确，而且警报数量非常少。以前一天要收一千张纸，现在一天可能要收一两张，再多也只有十张。这是一个明显的区别。数量越少，越愿意处理告警，故障越少。如何到达门槛？这很简单。我们对成功率采用统计方法，为成功率设置一个滑动窗口，通过3Sigma算法利用月环比数据计算出一个动态的费率取值范围。只要超过这个范围，就认为DLP有问题。这不是什么难的技术，但是练习效果很好。作为最早将“去门槛化”的概念应用到生产环境的尝试，我觉得有必要和大家分享一下DLP的实践。目前告警泛滥的企业可以考虑借鉴和尝试。至少在我们的团队真正落地之后，我们的20万多台服务器已经上线，并且已经验证了两年多。比如我们的DLP告警效果是这样的：一旦告警发出，就会绘制告警的影响时间区间，绘制与过去相比的同比变化。同时，通过多维度聚类，分析是否有主IP、转IP、返回码聚合等，还会关联版本发布、网络变化等事件。由于DLP告警本身就非常准确，而且告警出来后用户又能得到这么多辅助信息，用户自然会觉得DLP非常有帮助。这张图最下面是访问关系的记录，也是下面跟大家分享的重点。#ROOT：根根智能分析法ROOT就是今天要跟大家分享的。这个项目是2010年做的，那时候还不知道根本原因分析这个概念。我们只是想尝试解决运维分析失败。特别困难的问题。于是在2010年推出了代号ROOT的项目，大概2012年做的，2014年才在行业大会上分享过，今天把这个项目拿出来和大家再讨论一下，因为我们有用AI来re-AI这个概念，非常有意思，个人认为对于AI在我们传统数据上的应用是非常有价值的。首先，什么是ROOT？我们现在称之为根本原因定位（与根本原因分析不同）。我总结了一句话来形容它：基于业务架构，结合数据访问关系流，通过时间关联、区域权重等算法，对监控告警进行筛选分类，发现具有业务价值的告警，并直接分析告警根源。.你怎么做呢？2010年，我们在尝试做“自然运维”（类似于现在的DevOps理念）。研发和运维需要分工合作，根据具体的流程来完成我们的日常工作和运维管理，包括现在所谓的交互链，我们当时没有像DevOps那样包装成一个高层次的名词时间。当时的想法是基于业务架构来运维。腾讯的业务比较复杂，人事变动也很大。运维中对业务结构的不熟悉，往往是做好运维工作的障碍。所以我们和R&D一起制定了一个关于业务架构的规范。研发团队将在我们标准化的业务架构中完成增减、变更服务等一系列工作。我们运维也会做一些系统去集成这个业务架构。图形被显示和管理。下图是我们的产品页面。在这个页面上，无论是运维还是研发，都可以看到当前的业务架构是什么样子的。这就是我们的初衷：基于这样的背景，在2010年左右，我们对各个业务的架构进行了管理。上图是广告业务架构的一部分。有了这个产品之后，我们突然想：如果其中一个节点告警了，是不是一定是自己的问题，而是后面某个节点的问题？这是一个非常合理的考虑。比如我的用户说我的服务访问很慢，可能不是接入层的问题，而是后端逻辑服务比较慢，死机，宕机或者网络问题……我们无法定位到问题只限于接入层，那么如何把整个业务整合起来呢？有没有一种技术可以将其缩小为网格？通过将高维网络访问关系数据降维成链，主要通过穷举法从图中提取访问关系链，成功完成降维。降维的方法很简单。从access开始，枚举整个access数据，就可以得到降维后的二维数据。刚才大家看到的那个复杂的网络图其实就是这么一个链接，没有任何逻辑，然后我们前面提到的20多套监控系统发送的告警数据，都是在这个链接上做各种叠加。得到如下效果：从运维经验来看，连续告警间隔越近，后续告警导致前端告警的概率越高。我们现在要做的就是用数学来描述它，这是我们整个系统的主要思想和实现。在产品方面，我们做成下图所示，按照时间维度看透权重最高的告警链接。图中纵轴是这个接入链路的模块，横轴是时间轴，粉红色的点是我们的alarm叠加在时间链上的效果。我可以看到同一时间片内有警报。这些告警虽然属于不同的模块，但相关性不是很大。但是下面两个模块每天都在报警。这种情况是正常的，阈值匹配错误。这种情况也很常见，我们也没有办法一一解决。这种连续告警在我们的系统中大量存在，对我们的告警分析有很大的干扰。我们希望将其过滤掉，重点分析一定时间片范围内相关性非常高的告警。.时间片与时间的相关性非常重要。我们认为报警本身是有所谓时效性的，所以有一个时间窗口，比如报警的快慢，报警的延迟。绝大多数连续报警都是干扰因素。基于这种思路，我们将告警分为原因告警和现象告警。现象告警往往只是一种表象，好像服务有问题或者访问前端服务慢，但也有可能只是一种现象，原因不在自己身上而是在某个后端服务器上.源头在别处，我们需要找到根本原因。这就是根本原因分析的思路。我们将告警分为连续告警、波动告警和关联告警。这是2014年的数据，我们惊奇的发现65%的系统是连续的，也就是说65%的告警数据很可能是干扰，每天不知什么原因告警。24%的告警是波动告警。这种告警指示灯会先上升一段时间，然后又下降。可能是某个服务中断后恢复，或者某个产品发布。这是可能的，但最终它被恢复了。.无需检查或注意操作和维护。我们的系统能够关联的真实告警中只有9.2%，也就是不到10%是真正的问题。我们应该把运维的精力放在这里。大部分告警运维不需要花时间检查。这是我们的数据分析。那么之前的数据算法是如何做这个分析的呢？2012年前后，奥美根据经验设计了“权面积算法”。原理是在相同长度的链路上，叠加的告警排列不同，可以计算其优先级权重。从运维经验来看，告警间隔越近，这些告警的相关性越高；警报间隔越稀疏，其相关性越低。因此，虽然这三个链路也是七个节点的链路，并且每个链路上叠加了四种不同类型的告警，但我们最终可以计算出第一个权重最好。算法很简单，后面会公开源码。这个算法也为我们在做根因分析的时候，通过数据来做运维分析开辟了一条路子。用了一段时间后，准确率不是很高，60%左右。它的思想和技术非常古老。这是我们2012年到2014年在ROOT做的一个有趣的尝试，跟上时代，践行AIOps，这两年我们思考AI，在运维监控方面做了大量的AI尝试，发现根本原因分析实际上是一个非常重要的部分。那么，以下也是我今天分享的重点。我们做了一些实践AI的尝试。整个内容分为5个阶段：文本+NLP。第一阶段是文本+NLP的处理。比较有特色的产品叫舆情监测，还有智能对话机器人的部分。预测/判断问题第二阶段是预测和预判问题。预测是大家都喜欢的，很多团队都用AI来做预测。比如基于在线预算，预测未来等等，相关的还有很多，基本都是基于时间序列的。信息收敛问题的第三个阶段是信息收敛阶段。如上所述，收敛的方式有很多种。多维系统很好用，我觉得也是未来的趋势。虽然不是我们分析的重点，但是可以借鉴。根本原因分析第四个问题是根本原因分析，这个其实不重要，重要的是下一阶段。Rootcauseanalysis***是根本原因分析的问题。下面详细介绍AI的根因分析。之前的ROOT问题给大家介绍一下。它的准确率只有60%，还有很多其他问题。为什么只有60%？原因是：有些场景无法解决。比如各种GW等大量IP接口汇聚的场景，在腾讯很常见。而这种高收敛的场景成为了ROOT系统中构建关系链接的一个关键点，大量的流量会从中经过。这个节点原来是ROOT分析的干扰因素，用AI的话来说，它的熵太大了。关系链不完整。前面说到，能够画出业务拓扑图之间关系的前提，首先是我们基于业务架构进行运维管理，然后通过模块之间的调用关系建立链接。这些数据是基于CMDB聚合关系，即关系被限制在业务逻辑范围内，空间是空间，音乐是音乐，不会超出范围。那么我们现在如何解决这些问题呢？***，针对IP聚合的问题，我们在DBSCAN上对所有的聚合进行分类，如下图：通过一些特征对数据进行分类，将我们的关键数据拆解，拆分成多个服务页面，参与数据重新计算。以前只是一个点，现在变成了很多很多的服务节点，解决了一些以前解决不了的问题。二是关系分割。前面说了，我们的服务里面有很强的业务逻辑，但是实际的关系不是这样的。我们尝试用社交领域的市场，按照实际的接入关系来划分。这里可以看到，左边的图展示了所有的访问关系，右边的图展示了划分后形成的访问关系。以前我们的系统是直接断掉的，但是现在，因为我们的系统其实是有很强的关系的，就像我们的QQ关系链一样，会有各种各样的互动，即使可能不属于同一类人，但是therelationship之间的关系非常牢固，解决了链接被切断的问题。第三，体重。刚才提到的面积权重方案是一个经验问题。通过取出链路告警数据和所有历史告警数据进行平面计算，我们找到了A和B、B和C概念之间真正的告警关联数据。这是非常合乎逻辑的。AB同时报警的情况，在历史上出现的概率是非常高的。现在又出现这种情况，而且相关性非常高。这个业务的概念非常契合，相当于通过AI，用运维的概念重新定义了传统数据。我们新系统的准确率会高很多。引入AI之后，方法还是一样，原理还是一样，但是它的价值已经大大提升了。腾讯运维总监聂欣。从开发到运维，伴随着腾讯社交网络运营部十年的成长，一直负责腾讯社交产品的所有业务运维。目前主要负责业务运维、智云产品、AIOps系统等团队管理工作。从多个业务产品的诞生到繁荣，伴随着运维团队的成长与成熟，见证了腾讯一代又一代运营技术的创新与发展。
