|
|
51CTO旗下网站
|
|
移动端

每天5万条告警,腾讯如何做到“咖啡运维”?

大家好,我从 2006 年进入腾讯至今,差不多 12 年了,而且是在一个部门里待了 12 年。

作者:佚名来源:dbaplus社群|2018-09-13 09:39

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

我把一些故事梳理了一下,发现有些事情可以跟大家交流分享,所以借这个机会跟大家谈谈腾讯最近一两年做的一些 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 万条短信告警问题。我和很多同行交流过,基本上大家都有同样的问题,每个大点的运维团队都面临着告警泛滥的问题,但到目前没有哪个