加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 云计算 > 正文

【2018可信云大会】腾讯聂鑫: 腾讯AIOps实践演进

发布时间:2018-08-27 08:11:36 所属栏目:云计算 来源:中国IDC圈
导读:聂鑫:来腾讯工作快12年了。在腾讯服务的12年里都在一个部门没有变过。2006年去腾讯的时候正好赶上腾讯在做DO分离,第一代BAT企业应该也都是在那个时候开始推进运维和研发分离这件事。那时候的运维什么基础都没有,一穷二白,真的很艰难,除了不用扛设备,
副标题[/!--empirenews.page--]

聂鑫-1

聂鑫:来腾讯工作快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%,事情挺完美,领导非常认同,做的挺好。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读