这十多年来，腾讯运维团队里发生的点点滴滴，在我内心中，每件事情印象都很深刻。

我把一些故事梳理了一下，发现有些事情可以跟大家交流分享，所以借这个机会跟大家谈谈腾讯最近一两年做的一些 AI 落地。

我们都做些什么？

在 IT 行业，稍微大一点的企业都会设有运维团队，我们的运维团队和大家一样会做很多基础工作，比如资产的管理、服务器管理、业务架构规划等等。

以 2015 年天津大爆炸的事件为例：

在业务架构上，我们之前做过 QQ 全国多地高可用分布，所以在天津大爆炸事件中，是由运维来主导将北方天津接入的用户从天津 IDC 机房迁到了上海和深圳。

这也是有史以来最大规模的用户迁移，用户是无感知的，这就是我们运维团队日常工作的一个缩影。

还有，每年的红包是大家比较熟悉的，每年都会由运维团队参与到整个项目当中。

另外，运维团队也需要关注成本，会花很多力气去优化设备、带宽的使用情况。

其他的还包括大家可能都听说过的一些突发事件，比如 8 亿人军装照、直播业务井喷、鹿晗事件、红米首发事件等等，后面都有我们的团队支撑。

我来自腾讯的 SNG 社交网络业务，旗下主要有 QQ、QQ 空间、腾讯云、QQ 会员、QQ 音乐等很多产品。

它有一些特点，比如单体业务非常大，有两万多台，也有超过 19 年的老业务，然后每年还会有 20+ 个新业务上线。

有些业务会慢慢地衰退，新老业务变换得非常快，同时我们也在做一些 2B 的事。

我们运维团队所处的环境和面临的问题都非常复杂，那么有些什么样的问题呢？今天的分享是关于我们在 AI 领域监控方面的事件，我先把这个问题抛出来。

SNG 每天有 5 万条短信告警，每个人一天最高能收到 1500 条。大家想象一下，一个手机每天收 1500 条短信是多么让人崩溃的事情。

讲个笑话，我们的一些 Leader 说，他们不看具体告警的内容，而是看告警的发送频率，频率快了就有问题，如果每天按照固定的频率发就没什么问题。

这是个玩笑，但很深刻的折射出我们运维所面临的告警量巨大的挑战是非常严峻的。

每天发出 5 万条告警，它背后有将近 900 万的监控指标，这是巨大的问题，同时也是非常宝贵的数据。但是我们过去没怎么用好，今天分享的也是我们在这点做的实践。

我们的愿望：咖啡运维

以上是我们大致的背景情况，而早先我们的愿望是能做到“咖啡运维”。什么是咖啡运维？

刚入职的时候老板跟我们说，做运维的个人目标就是喝着咖啡做运维，翘着二郎腿就把运维工作做好。

然而十多年过去了还是没有达到，非常艰难，业务增长非常快，运维的人数和规模增长却远远没有业务和研发团队增长快，我们要解决的问题反而越来越多。

正在做哪些监控？

在监控上很难做到平衡，因为要快、准、全，其实本身就是矛盾的。这是我们的业务架构，先看一下左边的时间轴：

从 2006 年我入职腾讯开始，我们的运维和研发开始 DO 分离，运维开始主导去做各种监控系统，陆陆续续十多年来，建立了 20 多个监控系统，非常可怕。

很少有企业做这么多，多数企业一套监控系统做好就可以了。而我们这么多监控系统，并非重复建设，到目前看每套系统也都有存在价值的。

在 2009 年的时候，我们的监控指标非常少，监控系统不到 10 个，每天的短信告警数量也不多。差不多到了 2014 年的时候，监控系统数超过了 20 个，算是巅峰状态了。

而现在我们的监控实例已经超过 2000 万个，随着监控实例的增加，告警也增加了非常多，告警泛滥的问题没有得到解决。

有哪些一样的地方？

先来看看我们和大家有哪些做得一样：

在运维团队上和大家一样，会被需求驱动，来自研发团队、老板、产品的各种驱动。业务受架构的能力制约，为了解决一个问题就建立一种方式方法监控，这样慢慢地建成。过去的视野放在监控点上，一个点一个点地解决问题，不断地给它们优化。可以把一件事情做得非常深入，在一个点上不断优化，对于监控这么复杂的事情，这个效果并不是特别的好。

我们有哪些监控呢？具体如下：

基础指标监控，每家都有，我们也一样。自动化测试模拟监控，我们通过模拟用户请求的方式来对我们的服务进行播测发现问题。模块间调用质量监控，在我们的监控里是非常重要的体系，它是由服务的调用数据上报到后通过各种运算，来反应服务调用成面的监控。测速与返回码统计，下图是直接由用户端报给我们的各种数据，其实这些监控特别多，我前面提到的有一大半都是干这些事的，大家一看也能看懂，都很熟悉。

用的方法和大家也是类似的，画线、做统计图、做一些分类，我们也做类似的事情，但就是解决不了根本的问题。

不过并不是说这些系统就不能解决问题。我举个案例，2012 年 8 月，据报告显示：QQ 空间首页比微博首页慢 35%。

为了解决这个问题，我们联合了公司十几个团队，很多骨干成员一起做系统的各种优化，历时将近 8 个月，最终取得了较好的效果。

这里面包括：

天津联通 IDC 分布，优化北方 15 省联通用户。空间首页 DOM 节点裁剪，减少首屏渲染时间。动态加速对空间框架进行加速。空间 Set 合并重整，换新机型，减少穿越。根据 GSLB 测速结果，重新调整全国各省就近接入点。空间框架机升级 QZHTTP 版本，支持新特性。中小运营商、移动宽带 CAP 接入。

非常直观的案例，说明传统的手段还是有用的，也有一定的价值。但问题是，为了做这一件事，我们投入了大量的时间、人力、精力。

所以这也促使我们不断地思考应该如何调整，因此就有了下一部分的内容——有哪些不一样的地方。

有哪些不一样的地方？

我自己总结这些不一样，其实是放下包袱去做创新。并不是要对系统进行所谓的重构，破旧立新。

因为每套系统都有自己存在的价值，现在很多监控系统也还在使用，它们的存在必有其价值，但我们可以优化后台架构落后的问题。

关于架构落后，我首先想分享的是多维的内容。这也不算创新，因为随着业界大数据处理技术的强大，海量监控数据开始被按多种纬度进行组合分析，成为发掘数据背后隐藏问题的最主要的监控手段。

数据被处理成多种维度的视角

多维是什么呢？前面提到的监控大家一看就明白了，基本上从我们想采集各种单维度或最多两个维度的数据报到我们的系统开始，根据时间的序列会进行所谓的曲线会聚，做少量的分类。

现在每一条上报的数据所带的维度是非常多的，只要研发团队愿意往我这边报，没有任何的限制，报一百个维度都能接受，我们后台能把这些报上来的成千上万的维度用各种方式去做一些聚类。

就像截图上看到的，可以用不同的维度组合去对产品各种方面的数据进行透视，这是我们的织云多维监控系统。

数据可以选择不同的纬度组合来看，比如说版本、平台、客户端、网络制式还有省份等等，这些数据其实就是在我们同一条数据报上来之后，在织云多维里做的处理。

在下面还可以看到首次缓冲率、二次缓冲率、首次加载的时长错误量等分纬度的数据。

原来的监控数据每次都要单独上报，现在通过一条就可以在系统里完美地落地，这也是我们现在主流的监控手段。

我们监控多维数据所使用的技术，应该和大家比较接近，基本是一致的：

效果如何，同样举个案例，大概在 2014 年的时候，我们手机端用户的访问开始超过 PC，带来的问题就是运维压力山大。

过去我们做的运维监控体系基本都是基于 PC 的，但是手机端用户一来，千奇百怪的问题都出现了。

运维在帮助研发团队一起优化产品体验时，利用多维的技术，把系统中各种数据全部报到织云多维监控中，运维来做分析。

以上表格里是七个优化点，实际上不止，我记得这个项目到后面运维大概有四十多个优化点。

一个手机端的产品，发现了四十多个待优化的点，这些数据原来是分散在各处的，利用多维监控之后，可以更加方便的把各种异常分析出来。

这个例子中，是我们运维团队的两位骨干在三个月左右的时间里完成的。对比前面的案例，这次场景更复杂，而且技术的难度也更高了，但在发现问题的过程中，反而效率提升是非常的明显。

前面几十个团队八个月时间做的事，在这里就两个人、两三个月也能做到，效果却能更好。

DLP：业务生死指标

第二个想分享的，是关于 5 万条短信告警问题。我和很多同行交流过，基本上大家都有同样的问题，每个大点的运维团队都面临着告警泛滥的问题，但到目前没有哪个是可以完美解决的。

所以我们做了一些尝试，在 2016 年的时候推出 DLP，也就是业务生死指标，它有几个限定：

第一个要求，不能设定阈值。这是运维规定的，完全根据指标值做波动判断。

第二个要求，一个服务只能有一个生死指标。大家会奇怪为什么有这样的要求，那么请思考一下，我们为什么有那么多的告警？

为了保证这个服务不出问题或是出了问题能第一时间被发现，有的服务有四百多个指标来监控它，这些监控指标有运维配的、有研发配的、也有产品配的。

这样下来，怎么可能不出现告警泛滥的情况？所以生死指标里一个服务只允许有一个指标，衡量这个服务到底生还是死的指标。

第三个要求，不建议用业务指标做生死指标。什么叫业务指标？比如说在线、收入曲线等这些指标对业务来说非常重要，但对于衡量一个系统是否有“生死”故障来说，这些指标很有可能变成干扰。

举个例子，比如你的业务正好在做一个推广活动、那么用户的在线数、购买量等产品指标都会发生巨大的变化。

如果你对这些指标进行监控，并不能衡量这个业务是生是死，所以我们不推荐用业务指标来做 DLP 监控。

什么叫阈值？过去我们绝大多数的监控系统都是通过阈值来告警的：比如访问量超过一万的要告警、量低于几百的要告警……

以前的监控都是这样做的，但是在我们这里面不允许，全部是去掉阈值的。我个人认为“去阈值”是未来运维监控的趋势，而我们只是通过另外一个手段践行了这个概念。

当然一开始推行，项目难度非常大，基本上所有的产品都不接受，研发也不接受，因为好像太不合情理了，推动起来非常痛苦。

但是后来随着我们不断的推动，有的业务逐渐开始试用并感受到了好处，他们收到的 DLP 告警非常的准，告警的数量也很少。

以前一天要收一千条，现在可能一天一条两条，多了也就十条，这是很明显的差异。数量少了反而大家愿意去处理告警了，故障反而少了。

怎么去阈值？很简单，我们在成功率上使用了统计学的方式，设一个成功率的滑动窗口，利用环比同比数据通过 3Sigma 算法计算出一个动态率值区间，只要超出这个区间就认为 DLP 出现了问题。

这不算是一个很难的技术但实践效果却非常好，作为最早尝试将“去阈值”概念用于生产环境，我觉得一定要跟大家分享 DLP 的实践。

目前正在遇到告警泛滥的企业可以考虑借鉴尝试一下，至少在我们团队实实在在落地了，我们二十多万的服务器都已经上线了，也经过了两年多的验证。

举个例子，这是我们 DLP 告警的效果：

一旦告警出来，它会把这个告警发生的影响时间区间画出来，并绘制出和过去的同比变化。

同时通过对多种维度进行聚类，会把是否有主调 IP、被调 IP、返回码汇聚等情况分析出来，也会把是否有版本发布、网络变更等事件关联起来。

由于 DLP 告警本身很准，再加上告警出来后用户可以得到这么多的辅助信息，用户自然会发现 DLP 非常有帮助。

这个图的最下方是访问关系的记录，也是下面要重点跟大家分享的。

# ROOT：根源智能分析法

ROOT 是今天想重点跟大家分享的内容，这个项目是在 2010 年做的，当时我们也不知道有什么根源分析的概念，只是要做一个尝试去解决运维分析故障时特别困难的问题。

于是 2010 年启动代号 ROOT 的项目，大约在 2012 年做出来，2014 年才在行业大会上分享出来。

今天，我再把这个项目拿出来跟大家一起探讨，是因为我们用 AI 的方式将这个理念重新地 AI 化了，非常有意思，我个人认为对于 AI 在我们传统数据上落地非常有借鉴价值。

首先，什么是 ROOT？我们现在把它叫做根源定位（有别于根因分析）。

我总结了一句话来描述它：基于业务架构，结合数据访问关系流，通过时间相关性、面积权重等算法，将监控告警进行筛选分类，发掘有业务价值的告警，并直接分析给出告警根源。

怎么做的呢？我们在 2010 年的时候，正好在尝试做“自然运维”（和现在的 DevOps 理念很像）。

研发和运维要分工、做配合，基于特定的一些流程去完成我们的日常工作和运维管理，包括现在所谓的交互链，我们当时没有把它包装成 DevOps 这么高大上的名词。

当时的理念是基于业务架构去运维。腾讯的业务挺复杂的，人员变动也很大，运维不熟悉业务架构往往是做好运维工作的障碍。

于是我们和研发一起制定了关于业务架构的规范，研发团队会在我们规范出来的业务架构中去完成增加或减少、变更服务等的一系列任务，我们运维也会做一些系统把这个业务架构图展现出来，并管理起来。

下图这是我们产品的页面。在这个页面上，运维和研发都能看到当前的业务架构是怎样的，这就是我们的初衷：

也是基于这个背景，大约 2010 年的时候，我们将各个业务的架构管理起来。上图是一个广告业务架构的一部分。

有了这个产品后，我们突发奇想：如果其中有一个节点在产生告警的时候，问题是否不一定是它自己的，而是后面某个节点出的问题？

这是非常合理的考虑。举个例子，如果我的用户说我的服务访问很慢，有可能不是接入层的问题，而是后端的逻辑服务比较慢，死机、宕机或者是网络问题……

我们不能把问题定位只限制在接入层，那怎么把整条的业务撮到一起去呢？能不能有种技术把它降维到网状呢？

我们通过把高维度的网状访问关系数据降维到链状，主要通过穷举的方式把访问关系链从图中拎出来，顺利完成降维。

降维的方式挺简单的，从访问开始，把整个访问数据列举出来，就能得到降维之后的二维数据。

刚才大家看到的复杂网络图其实是这样的一条一条的链路，没有任何逻辑的，然后再把我们前面有提到的 20 多套监控系统发出来的告警数据，都在这条链路上进行各种叠加。

得到如下的效果：

从运维经验上看，相隔近的连续告警，后面告警是引起前端告警原因的概率更大。

我们现在要做的是用数学的方式把它描绘出来，这就是我们整个系统的主要思想和实现方式。

产品上我们把它做成如下图所示，把权重最高的告警链路按时间维度透视出来。

图中纵轴是这条访问链路的模块，横轴是时间轴，粉红色的点是我们的告警叠加在时间链上后的效果。

我就可以看到在同一个时间片内有告警，这些告警虽然属于不同的模块，相关性也不是很大。

但下面两个模块每天都在告警，这个情况很正常，是阈值配错了，这种情况也非常常见，我们没有办法一个个去解决。

这一种持续告警在我们的系统中大量存在，对我们的告警分析是很大的一种干扰，我们希望把这个过滤掉，而聚焦在某一个时间片范围内相关性非常大的告警分析上。

时间片与时间的相关性是很重要的，我们认为告警本身有一个所谓的时效性，所以有时间窗，比如告警有快慢，还有告警延迟的问题。

连续性的告警绝大多数都是干扰因素，基于这样的想法，我们把告警做了分类，分成了原因告警和现象告警。

现象告警往往只是一个表象，好像服务出了问题、前端服务访问慢，但可能只是一个现象，原因不在自己身上而是在后端的某一个服务器上。源在别的地方，我们要找到根源，这是根源分析的思路。

我们把告警分为持续告警、波动告警和关联告警。这是 2014 年的数据，我们惊奇地发现在系统中有 65% 是持续的，代表了 65% 的告警数据极大可能是干扰，因为不明的原因而每天在告警。

有 24% 的告警是波动告警，这种告警指标一会儿上去，没一会儿又下去了，可能是某个服务中断后恢复了，或者有某个产品进行版本发布，都有可能，但是最终是恢复了。

运维也不需要去查，不需要关注。真正的我们系统能关联出来的告警只有 9.2%，也就是不到 10% 的才是真正有问题。

我们应该把运维的精力放到这里，绝大多数的告警运维都不需要花时间去查的，这是我们的数据分析。那么前面的数据算法，怎么做这个分析呢？

2012 年左右，运维根据经验所设计的“权重与面积算法”，原理就是在同样长度的链路上通过叠加上去的告警的排列不同，可以把它优先的权重算出来。

从运维的经验上来判断，告警间隔越紧密，这些告警的相关性就越高；告警的间隔越稀疏，它的关联性就越低。

所以这三条链路虽然同样是七个节点的链路，同样每个链路上都叠加了四种不同类型的告警，我们最终还是能算出来，第一个权重是最高的，这个算法挺简单的，后面有源代码的公开。

这个算法也开创了咱们在做根源分析时通过数据做运维分析的方式，用过一段时间，准确率不是很高，大概 60% 左右。

它的想法和技术都是很老的，这是 ROOT 在 2012 到 2014 年的时候我们做的比较有意思的尝试。

跟进时代，践行 AIOps

我们这两年对 AI 的思考，做了很多在运维监控的 AI 尝试，发现其实根源分析这块是很重要的一部分。所以，下面也是我今天分享的重点。

我们践行 AI 的一些尝试，整个内容有 5 个阶段：

文本 + NLP

第一个阶段是文本 + NLP 的处理问题，比较有特点的产品叫舆情监控，还有智能对话机器人这部分。

预测 / 判问题

第二个阶段是预测和预判问题。预测是大家比较喜欢的，很多团队都通过 AI 的方式做预测。

比如基于在线预算量、预测未来等等相关的比较多，基本上是基于时间序列。

信息收敛问题

第三个阶段是信息收敛的阶段，前面提到这么多，有很多的方式去收敛。多维的系统就非常的好用，我觉得也是未来的趋势。虽然不是我们重点分析的，但是可以去借鉴。

根因分析

第四个是根因分析问题，其实并不重要，重要的是下一个阶段。

根源分析

最后是根源分析的问题，下面详细介绍一下根源分析方面在 AI 上的尝试。

我把前面 ROOT 的问题给大家引出来，它的准确率只有 60%，同时还有很多别的问题。

为什么只有 60% 呢？原因在于：

有的场景是解决不了的。比如各种 GW 等 IP 接口大量汇聚的场景，这在腾讯是很普遍的。

而这种高汇聚的场景成了 ROOT 系统构建关系链路中的关键点，很多的流量都会经过它。这个节点结果成了 ROOT 分析的干扰因素，用 AI 的说法是它的熵太大了。

关系链不是完整的。前面提到业务拓扑图关系能绘出来的前提，首先是我们基于业务架构去做运维管理，然后通过模块之间的调用关系来构建链路。

这些数据都是基于 CMDB 来汇聚关系，也就是关系是限定在业务逻辑范围内，空间就是空间，音乐就是音乐，不会超出范围。

所以我们现在怎么去解决这些问题呢？

第一，针对于 IP 汇聚的问题，就是我们把所有汇聚在 DBSCAN 上面进行分类，如下图：

通过一些特征对数据进行分类，把我们关键的数据拆开，拆成多个服务页，参与数据的重新运算。

原来只是一个点，现在变成了很多很多的服务节点，解决了以前解决不了的一些问题。

第二个，关系划分。前面有提到我们服务有很强的业务逻辑在里面，但实际的关系不是这样的，我们尝试用社交领域的市场，通过实际的访问关系来划分。

这里可以看到，左边的图是所有的访问关系，右边的图是经过划分之后形成的访问关系。

以前我们系统是直接割断，而现在，我们的系统因为实际上有很强的关系，就像我们的 QQ 关系链一样，会有各种的交互，哪怕可能不属于同一类人，但是之间的关系是非常强的，解决了链路被切断的问题。

第三个，权重。刚才前面提到的面积权重方案是经验问题，我们通过把链路告警数据，历史上所有的告警数据拿出来做平面计算，发现 A 和 B、B 和 C 之间的真实告警相关性上的数据概念。

这就是非常符合逻辑了，AB 同时告警的情况下，历史上出现的概率非常高，当前又出现这种情况，它的相关性很高，这个业务的概念是很合适的，这是相当于把传统的数据用运维的理念通过 AI 的方式重新定义。

我们新系统中的准确率会高很多，发现通过 AI 的引进之后，方法还是这个方法，原理还是这样的原理，但是它的价值是大幅度提升的。

聂鑫，腾讯运维总监。从开发到运维，伴随腾讯社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作，目前主要负责业务运维、织云产品、AIOps 体系等团队管理工作。经历多个业务产品的诞生到蓬勃，伴随着运维团队的成长和成熟，见证着腾讯一代代运营技术的创新和发展。