腾讯社交业务规模庞大，历史悠久，架构复杂。从运维的全局角度来看，无论从运维技术还是监控难度都很大。传统的监控手段和思想已经无法应对如此海量的场景，腾讯织云平台经历多年的迭代改进，在运维监控领域经过了多个建设阶段，通过技术创新，将运维监控技术提升到新的高度，解决了很多海量业务规模下的运维监控难题。

提及腾讯的海量监控的挑战，先抛些数据，我们有将近 20 套监控系统，指标有将近 300 多个，监控的实例超过 900 万，最可怕的是每天有近 5 万条短信告警，人均 500 条。2014年收告警最多的运维，一天能收 1500 条短信，收告警比较多的研发同学，每天也有 1200 条短信。甚至我们都调侃自己说，我们要靠手机震动的频率来判断事态的严重。

通过使用一些简单的算法进行“降维”，比如上面的网状业务访问关系，可以通过有向的穷举的方式抽取成链条状，形成服务访问关系链。然后将各种告警往上叠加。我们将各种各样的告警叠加在这个业务架构的链路上面去，比如说当某一种告警产生的时候，就往链路上去叠加，其他的告警类似处理，循环着继续这样去处理，最后你会发现访问关系链路上面已经叠满了各种告警。在同一个时间片范围内就可以开始去分析，根据运维的检验，可以推测出架构中哪一条链路或者多条链路的故障现象和故障根源最有可能发生。

我们假设告警和故障根源的关联在数据上是有一定的关系，这个关系可能是一种相近性，我们认为两个服务之间的告警隔的非常近，那么互相产生影响可能性会非常的大，把全部业务进行这种降维处理后，大概有四百多万条链路进行计算，当告警发生的时候，就很容易通过一些算法浮现出最有可能的告警根源是哪里？

过去我们很苦恼，每个新的告警对运维的工作都会造成骚扰，但基于 ROOT 这样的方法论上，我们发现告警越多越好，告警越多越能够帮我们去把这个关联做得更精确。

我们将告警分成了原因告警和现象告警，原因告警才是造成那个故障的根源，现象告警可能只是故障的结果，其实看不出来故障根源在哪里。

举例说，用户 QQ 里面不能发消息了，往往不一定是 QQ 有问题，很有可能后面数据库宕掉了。在一个多运维团队协同分工运营体系下，前端负责人很多时候不知道后面那台数据库宕掉了，所以现象和结果往往是关联不起来的，我们这个方法是希望能够做到这一点。

第二个部分，我们将告警分成持续性告警，波动性告警，关联性告警。“持续性告警”属于脏数据，往往是不重要也不紧急的，我们认为不需要立刻去处理。“波动性告警”也是处理起来比较纠结的一点，很多告警会被监控发现，但故障一下子恢复，指标很快恢复，这种告警应该去区别对待，可以根据业务的重要性去做处理，服务如果重要那么可能就要处理分析一下；如果不重要，站在我的立场，我觉得可以不处理。

我们会更加去关注“关联性告警”，它是有因有果，就应该立刻去处理。有一个简单的数据，这是最后的结果，我们发现那 5 万条告警里面，有 65% 属于持续性告警，不是那么重要，可能不一定真的要把它清理掉，但是对于告警分析来说没有那么重要。波动告警又占到了 24%，也就说我们有将近 1/4 的告警，只是发生了一下故障很快就恢复了，无论是作为运维，还是作为研发，还是作为技术化团队里边的 QA，都没有必要在这里面去投入过多的人力或者精力，这种波动告警是我们这个体系里面应该过滤掉的。最后一部分，只有不到 10% 的告警才是真正能够去关联出原因的，有现象有原因的，这部分告警才是最重要的，我们需要重点去关注的一部分告警。

后面是简单的一个算法，这种链路怎么去判断权重，哪个应该告警，哪个应该不告警，这里有个简单的面积算法。简单解释一下，根据告警连续，如果一连续它的长度就加，如果不连续它的纵向就减，最后算出一个简单的面积来。

比较典型的例子，就像这种，同样是 7 个节点的一条链路，同样是有四个告警叠加的，最后算下来面积它们的面积是不一样的，算出来会发现很有意思，非常准确能够分析出关联性，关联性越大的，它的面积一定是最大的。最新的基于AI的新算法已经落地，具有更高的准确性。

最后一个也是我们最近在做新的一个事情，全链路监控。除前面提到 20 多套运维监控系统，我们还有很多其他的数据源，比如有很多产品指标数据，服务器日志数据，用户日志数据等等各种各样的数据源。这些数据以前对我们运维来说是负担，但是现在随着大数据的兴起，我们发现这个数据也是一个宝藏，蕴藏着大量有价值的信息。我们现在在做全链路监控建设，是希望能够去帮助我们数据的生产者、消费者去合理地把数据用起来，能够帮助我们的生产者有办法去消费这些数据，过去是做不到的。

要举个例子大家才能理解什么叫全链路，这个图是 QQ 业务的一个局部服务的架构图，标记 QQ 里面好朋友见发消息的时序，消息在整个腾讯的体系里会经过 51 个步骤，这里面任何一个地方出问题了，都可能会造成丢消息。过去为了监控丢消息这个情况，整个系统中的这 51 个状态点都会去埋点，就是做染色，故障发生时可以很快知道消息到底在 51 个系统中的哪个地方丢掉的，这就是早期的染色监控方式。但随着时间服务架构越来越复杂，产品越来越多，这种方式已经很难推行，特别是站在运维的角度，希望通过这种方式去完成各种业务架构的监控，做不到了，因此“织云全链路监控方式”就诞生了。

我们会把基础监控、特性监控，现网的各种日志，各大系统中的文本类数据等灌到我们的日志中心里去。经过一系列的筛选，提取一些特征，计算一些中间值，形成全连路数据。现在我们也用到一些很多的一些开源组件比如 Elasticsearch 再做一些展现，然后全链路监控平台大概的结构就是这个样子，最终我们希望能够帮助用户去做很多分析。

比如说用户的数据在我们这边，这里一列代表了各种数据源，这个案例是个用户在空间玩直播的案例，它的数据在我们这边由各种不同的数据源上报上来。这里会把所有的数据列出来，把公共特性的值抽象出来做个对比，如果发现用户的一些值出现了异常，就可以去做告警了，可以产生一些新的运维事件，就能驱动产品和研发去改进。

这个事情一开始做的时候觉得也挺困难的，各种各样的日志格式也不一样，数据形式也不同，甚至都有怀疑说这个方式做不做的下去，但是发现不断深入去做，这里面发掘出来的一些有价值的数据反倒是越来越多，举个例子，原来我们都说用户直播的时候卡顿，我们也不知道是为什么，但现在好了，只要这个用户一上来，通过所有的数据汇聚就可以知道他用的什么机型，我们还会收集用户的 CPU，CPU 一直是 100%，很有可能这个机器不是特别高效，比如说它的网络，有的可能在用 3G 玩直播，可能在一些特殊的场景下，比如电梯里面。

有一次，我们一个同事在北京机场玩直播玩不了，终端没有任何提示的案例。通过全链路系统我们技术人员一看，很快发现它的 IP 发生了变化，由 4G 变成了北京机场 wifi，故障发生在 ip 切换后。原来他过去有去过北京机场，所以再次进北京机场的时候他的手机就自动连 WiFi，北京机场 WiFi 是要登陆的，但是他自己没意识到，APP 也没有提示，直播自然会失败。

过去这类个案的投诉只能请研发捞取用户的日志来分析定位，而现在运维就能快速定位。整个过程很流畅，比以前快太多了。全链路的数据对于我们运维和技术人员去定位故障非常有帮助，这个项目在我们现在也是主推的一个项目。

践行机器学习

后面分享的是织云监控目前正在做的一些技术探索（2017年12 月最新的进展已经在织云 AIOps 里面落地，请参考最新分享），所以写的是践行，我相信同行们都在做这件事情，跟大家交流一下，包括几个部分，主要是机器学习相关的。

织云监控给运维团队树立的愿景是：咖啡运维。希望我们做运维的坐在那里喝咖啡就行了，花了十年时间还没有到这个目标。

这是以前的做法，对数据进行各种各样的分析，大家都用过，各种曲线图对比，这都是老套路，汇聚、对比、阀值、分布、聚类，这个我们都用过，但是帮助有限。

践行机器学习 AI 运维，我们首先试水了文本处理领域，比如说这是“织云舆情监控”，就用了机器学习 NLP 处理。

这个项目还要从一个有趣的例子说起，早年我接触过一个老板，他抱怨说我们的服务质量不好。他的理由很简单，他每天上百度上去搜，有负面反馈，“空间打不开”这几个字，搜索排名第一。因此得到结论，我们的服务质量不行。他不管我们自己的监控数据质量多好，认定外面的舆情是负面的，就认为我们的服务质量不行，所以当时我也很苦恼，这个事情我怎么解决？现在我们有了高雅的解决方法，“织云舆情监控”。我们用了一些机器学习中的自然语言处理 (NLP) 方法，通过对各种渠道收集到的用户的反馈内容进行文本分析，找出异常。

语义分析首先要分词，然后做情感分析，发现到底是表扬我们的还是批评我们的，如果是批评我们的，它的量会不会有波动，正常每天 20 几 30 几，如果突然短暂时间内各种渠道有很多人反馈有问题了，基本上就会有故障，这个语义分析就是我们对机器学习文本这边的尝试，效果还蛮好的，这个现在我们所有的产品团队都在用。

第二部分就是机器图像学习，前面有一个有滚动条的图，大家会发现一个模块下将近有 400 属性，当一旦有问题的时候，它的监控曲线有很多图都是类似的，所以我们也在做图像之间的相似性学习，有 400 个属性没关系，也不判断阀值，就看你曲线长的像不像，我们人很容易判断，机器也能判断出来，这也是个挺好的思路，这对完全告警收敛有一定的帮助。

第三个部分是告诉 AI 规则是什么，通过一些有监督学习的方式，让机器首先去做一些粗判，人工去做一些监督，训练机器，对曲线的形态有准确的判断，对我们的告警检测会相当有帮助。（201712 月最新的进展已经在织云 AIOps 里面落地，请参考最新分享）

前面提到“全链路数据”项目里蕴含着大量的数据宝藏，但这些宝藏目前想要分析出来还相当的困难，这里面全是大量的无规则文本，人肉去做分析难度非常大，机器可以做的到，我们能够做舆情分析，那么对于日志上下文的分析也是有可能实现的。

值得关注点

最后对于监控，除了技术和创新，还有其他值得关注的地方。

过去为了实现快、准、全，我们在监控平台上做了很多的技术优化，但真正运用的比较好的监控还需要持续的“运营”。如何去运营监控有很多的方法论。比如说我们的指标怎么建立，我们的闭环怎么形成，如何建立监控生态，把相关的团队，各个团队全部能够卷进，比如 QA、研发、运维的角色是什么，怎么去定义，包括这些产品的服务质量考核怎么和监控结合起来，并通过运维指标的变化来反推产品质量优化，这都是我们运维团队需要思考的。

  TIPS  

最后是一些小的运维经验分享，看着小但对运维效率提升很有益处，值得参考。

比如舆情监控相当建议有能力的团队去尝试一下，相当的准，对于产品的体验来说，产品体验好不好，看数据是一方面，看反馈比看数据还要有效，这是我们切身体会，如果有能力的团队可以考虑一下舆情的监控。

机器的自动处理（服务自愈），运维人力一般不可能有研发和业务增长快速，有很多事情一定要尽早开始实现自动化处理，比如有些基础的告警能够让机器去处理的就应该让机器尽早处理，方法也很简单。

移动运维，还有就是借助方便的手机端处理运维工作，微信还有 QQ 这些工具非常方便，我们现在很多的故障都是在微信里面处理的，在微信可以打开自己的工具，直接就把故障给处理掉了，也很方便。

最后想提一下“告警的分级”。站在运维的角度怎么去做告警分级，和站在研发或产品的角度并不相同，在告警分级这里面有个简单的规则：合适的人处理合适的告警。

第一个是告警它本身就要级别。第二个，时间上一定要分级，比如该什么时间发的，该什么时间不发的，什么时间应该让大家去休息和睡觉的，还有范围也要分级，升级机制也要分级。前面我们之所以有 5 万条告警，在于之前没做好规划，比如一个告警有 20 个关注人，一旦发生问题，这 20 个人都会收到告警，这 20 个人都认为别人在处理，自己都不处理，继续睡觉，结果带来的坏处就是，这个告警没有真正指定到人。所以在告警的一个范围上应该去做些思考的，告警刚刚发生的时候应该发给谁，告警如果一直没有被恢复应该发给谁，告警产生了严重的质量问题后，或者对一些指标数据产生了影响之后，应该升级到什么规模，这些应该在运维体系里面应该去做。

作者介绍

聂鑫，腾讯运维总监。从开发到运维，伴随腾讯社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作。目前主要负责 QQ、空间等产品运维团队管理工作。经历多个业务产品的诞生到蓬勃，伴随着运维团队的成长和成熟，见证着腾讯一代代运营技术的创新和发展。作为运维界老兵有好多故事想和大家讲，也特别愿意听听各位经历的酸甜苦辣。