谈谈服务器运营领域的机器学习

Samwong(王镇),2011年加入腾讯网络平台部。一直专注于服务器故障发现、运营流程系统的设计与开发。参与和负责Uwork和TSC系统的构建与优化,见证了服务器运营系统工具化、自动化到数据化运营的过程。公司目前运营着国内体量最大的服务器体系,每个阶段都有来自内部和BG用户的不同运营需求,系统的架构也要与时俱进,目前与团队小伙伴一起探索运营系统智能化的发展方向。

一、前言

近一年多以来,在Google Alphago的热潮带领下,机器学习和AI在科技界非常火爆。机器学习的基本思路是利用积累的大数据构造统计模型,并使用该模型对数据进行分析和预测。我们传统的工程方式,则是用合理的系统架构,编写逻辑代码,让计算机按程序员的思路来一步步执行。前者的关键在于数据和算法,后者着重工程逻辑。本文我们来谈谈近几年机器学习在服务器运营领域的一些实践。

二、由运营的矛盾点来推导

从2011年至今每年新增的服务器开始呈现快速增长的态势,而到了2016年底过保设备占比超过50%。一般来说,服务器经过三到四年的运行后,都会出现各种各样的异常或故障。因为成本原因,不能强制业务进行服务器更换,如何保障业务在老服务器上能正常运营,成为了服务器运营团队的头等大事。服务器硬件有其固有的寿命,跟人的生老病死一样,出故障是无法避免的客观规律。这样,我们求解方向很自然的就定为以下两点:1)故障精细化监控,对故障类型尽可能细化,保证准确率和实时性;2)故障提前预警,使业务可以从容的迁移数据和业务,把故障影响降到最低。

以上两个目标,经过服务器运营和开发团队的分析后,发现用常规的系统平台,通过自动化流程,几乎是不可能实现的。在数年前,我们开始了大数据挖掘和机器学习,尝试用非工程的方法来解决这些运营难题。

第一个阶段:大数据积累。

刚开始的时候,服务器运营开发团队没有什么数据挖掘或机器学习的概念,当时只知道,自动化运营系统那么多年积累了大量数据,这些数据都躺在DB和TDW里,没有实际利用。部门老大很着急,当时也没有成熟的方案和落地场景,还是先把数据整合起来再说,大数据挖掘如果数据不够大,是成不了气候的。

从2013年开始,网平的大数据如火如荼的开展起来,把所有基础架构,包括服务器和网络的数据都统一通过自研的接入平台,往TDW里送。这个是数据平台建立的第一步—收拢数据。从下面两份数据,可以看出经过一年多的数据整合,网平的数据接入量和计算量都有了大幅的增长。

到了如今,大数据的积累更是达到了一个非常可观的量级,其中:存量数据达到了1103TB,每日入库数据量达18TB,每日的计算任务数为853个,每日的计算量达17TB。

从接入数据类型来看,服务器这边,包括了机器本身所产生的数据,如dmesg,SEL等,还有运营流程的数据,如部署、搬迁、重装重启等指标数据。这些数据也通过DISData平台自动任务进行接入。

这些在TDW的大数据,有些需要出库到本地,有些就直接在TDW上调用任务进行统计分析,这些应用为后面的服务器运营分析提供了坚实的基础。

第二个阶段:机器学习

前几年,得益于研发管理部高校合作组的牵线,我们与华中科技大学开展了高校合作,当时定了两个合作开发的项目,分别是服务器硬件故障预测与机房上架策略优化。

硬盘是服务器硬件故障率最高的一个部件,前面有提到,如果能提前预测到硬盘故障,对业务体验、完善备件管理都有莫大的收益。这也是基础架构运营在经历自动化、流程化后,需要进一步提升运营效率、降低运营成本的天然要求。

涉及硬盘的运营数据包括业务IO数据、硬盘内部的SMART和硬盘运行的环境变量数据(温度和湿度),这些数据合计起来每天的记录数上亿条。硬盘故障预测,适合使用分类算法,我们使用了目前较为流行的SVM分类算法,辅以合适的核函数来加快学习计算的效率。为何选取SVM?因为:

1)在硬盘的各项状态指标,能获取到标签,没必要用无监督学习方法,所以K-Means注定效果不够好。

2)特性指标只有10来个,用神经网络体现不出多大优势。

3)LR也尝试过,但效果对比SVM还是差了一些。

这里我们根据对历史预测结果,结合硬盘型号、服务器类型、上架月份、业务模块等维度进行统计,计算出每个小集合的正确率,然后倒排。如图所示,横坐标代表每个小集合的编号,这里就有一万多个小集合。点A之前左边对应的小集合的正确率都是100%,之后开始逐渐下降,于是累计正确率开始被拉低,到点B的时候是80.93%,如果继续往右,会继续下降,直到点C也就是整体正确率的44.46%。因此运营同学可以制定策略,通过酌情设置“门限”(对应小集合的累计正确率)就能将重要紧急的预警先放出来。期间走了不少弯路,也碰到了很多坑,在硬盘故障标准确定、业务IO分类定义等方面吃了不少的亏,我们在基于SMART数据做的故障预测,达到了令人满意的效果。目前我们覆盖了大约65%的SATA盘,提前30天的预测准确率达到86%。

需要重点指出的是,我们做的预测结果,除了training阶段用历史数据外,验证的过程是用现网的实时数据来进行的。就是说,经过SVM算法得到的预测模型后,我们是用最新采集的实时数据输入到模型中,得到的ok和fail两种预测结果,在3天、8天、38天后再对预测的结果进行验证。这个比传统的预测方式(训练和验证都是使用历史数据),对现网应用的价值大大提高了。正是有了部件故障预测,在服务器自维保项目中,我们可以通过Uwork流程,给业务运维发出硬盘故障预警的代办单,并且可以根据故障预测的数量,准确的进行备件管理。

我们做的另外一个非常有意思的项目是机房上架策略优化。当时,大部分服务器是在租赁机房进行上架的,提供者租用机架是按照机架数量计费,过低的机架上架率会造成更高的运营成本。所以,目标是利用数据挖掘和机器学习的方式,来实时计算出合理的上架策略。

问题的推导过程如下:

这样,问题就可以归纳为,在可接受的服务器性能损失下,确定新的服务器额定上架功率,以提升机架上架率。功耗本身采集的数据量不算多,但需要计算服务器限电后对业务的影响,所以把这块当作重点发力的方向。为此,我们设计出了一套根据CPU利用率的性能损失统计公式。简单来说,就是采用积分的方法表示作业的任务量以及运行时间:

受影响的任务量可以由以下等式表示,该计算方式记作C1。

由于采集频率和业务类型等原因,也提供了一种粗粒度的计算方式,记作C2,统计的是超过限电限额的部分任务量的多少作为受影响的任务量。以上的计算理论基于任务在计算性能限制后会被延后,延后的任务会在CPU资源充足的时候进行补偿的假设。(PS:当时性能损失是基于CPU利用率作为基础数据,在新的Intel平台,有了PCM来更精确的反应CPU的状态)

第三个阶段:数据分析系统平台化

在前面第一个阶段做数据接入时,就建立了网平的大数据系统Disdata,功能包括数据接入、数据地图、分析、查询、审计和接口管理等功能。随着数据分析功能的增加,在数据的清洗和任务调度方面有了越来越高的要求,在2016年把接入、数据清洗、数据分析、机器学习、存储系统等模块形成了统一平台。

Disdata平台化的主要目就是放开系统核心的能力。在采集上,开放数据采集控制能力,做到数据定制采集;在接入方面,开放数据接入运营能力,做到一键配置接入以及接入运营能力;数据分析方面,开放审计分析能力,成为流程的组成部分,净化数据;在应用层,提供数据决策流程配置,接入流程,打通数据驱动最后一环。机器学习的基础是大数据,有了数据平台的支撑,使数据的采集+清洗+存储+出库等环节每天自动循环,为机器学习源源不断的输送炮弹。

第四个阶段:深度学习

在腾讯云对服务器精细化异常管理的需求驱动下,我们启动了Mbox项目,在这个项目里,我们第一次接触到了深度学习。这里需要把服务器内核的dmesg和带外的SEL日志结合起来,把ping告警、上报超时和硬盘只读这几类告警进行原因明确化。dmesg和SEL日志信息,光从字面上,很难判断其所代表的含义。并且在分词和distinct后,有将近3万多个单词,几乎不可能对其进行打标签。只能借助深度学习,结合历史故障现场定位的情况,来确定这些关键字跟故障的对应关系。日志的分析跟NLP文本分析类似,这里我们用了word2vec来对单词进行向量化,并用向量空间上的相似度来表示文本语义上的相似度。以下是对SEL分析的其中一个测试,可以看出,“correctable”、“ECC asserted”等单词是跟故障的相关性最高,跟实际的故障情况高度关联!

该项目还在进行中,目前已经建立故障分类模型,将逻辑盘只读非明确故障分为硬件、软件故障两类,统计出的软件故障占比94%,并且圈定大约30个关键字关联软件故障,下一步就是把这些关键字放到现网中进行验证。

三、服务器运营的AI铁三角

经过多年的积累,除了开发能力的提升外,在业务方面,我们形成了服务器运营AI的铁三角,这三个领域,也代表了精细化运营的方向。

后面,我们会基于已有的项目经验,在这三个领域持续发力,希望在智能化运营上有更多的成果输出。

四、一些感悟

1) 与业务紧密结合,充分理解业务场景,才能有落地的价值。

服务器运营领域的机器学习,其目标都是为了更好的提升运营效率和节约成本,所以,机器学习的研究方向,必须要跟运营同学一道,探讨出当前运营的主要矛盾,针对具体的问题就开展研究,要不AI的成果只能是空中之花,无法落地。另一方面,AI研究的领域较为前瞻,不能等所有条件都成熟或所有的运营模式都思考成熟后再开始,一个实际的现象就是,机器学习所需要的数据,必须要在现网经过一段较长时间的积累,才能形成大数据,做测试的数据是越多越好,训练出来的模型才具有代表性,更能接近实际的场景。AI研究与运营场景的关系,一句话可以概括:“在一切背后,更在一切之前”!AI是在运营的后面,在运营的前端,无需关心背后所采用的实现方式;AI的研究要适当提前,对运营的场景要有前瞻性。

2) 用合适的算法做合适的事情,不能一味追求深度学习。有些项目,只要有合理的运营经验,用数据统计的方式,也能有很好的产出。例如服务器健康度评估和备件预测,就是运营同学凭借深厚的运营经验,把各种纬度的数据设置不同的权重组合而统计形成的公式。

3) 在机器学习建模过程中,有些参数的设置和算法的选用,可以直接使用前人的经验数字,例如神经网络里的节点数的选择,有几个经验公式,可以拿来套用,可以大大减少我们寻找最优方案的尝试次数。

4) 机器学习,感觉可以总结出一个公式:大数据+算法= 机器学习,这里说的大数据,第一是要够大,量要足,这里也特指经过清洗的数据。算法则是经过不断试错、调整和总结才能形成最优方案。

“瑞雪兆丰年”,这里的“兆”是预兆的意思,今年下大雪,来年很大几率是个丰收年。在古代,人们没有什么理论科学来验证这一现象,都是靠经验和规律来获悉未来天气的变化以安排农事。下大雪,来年就能丰收,这个是通过现象(特征数据)来预测结果的典型应用,跟机器学习的训练、验证、测试的过程几乎是一模一样的。在服务器运营领域,大家印象中都是体力活,其运营开发都是工程系统的工作。但AI的热潮给我们带来的新的气象,经过我们多年的努力实践,发现AI给我们运营效率和运营深度都达到了前所未有的境界,真正用实际落地的项目证明了AI无所不在!

原文发布于微信公众号 - TEG云端专业号(TEGYunduan)

原文发表时间:2017-06-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏量子位

百度让AI像婴儿一样学语言,还能举一反三听老师指挥走迷宫

李杉 李林 编译整理 量子位 出品 | 公众号 QbitAI 把已经学会的技能用在新的任务上,对于人类来说是很简单的事,但这种“泛化”能力是机器所缺乏的。 百度...

34480
来自专栏PPV课数据科学社区

哪一种编程语言适合人工智能?——Python在人工智能中的作用

? 谷歌的AI击败了一位围棋大师,是一种衡量人工智能突然的快速发展的方式,也揭示了这些技术如何发展而来和将来可以如何发展。 人工智能是一种未来性的技术,目前正...

43860
来自专栏人工智能头条

[访谈]数据大师Olivier Grisel给志向高远的数据科学家的指引

18420
来自专栏PPV课数据科学社区

【翻译】数据科学的多语言协作编程方式:Python + R + SQL

在这篇文章中,我将试图使用一种新的方法来介绍数据科学编程。 R vs. Python question中集中谈论了数据科学编程的问题,每个人都...

33940
来自专栏AI科技评论

开发 | Twitter客户支持数据集公布:来自大企业的超百万条推文与回复

AI科技评论消息,近日,Kaggle平台上公布了Twitter客户支持数据集,这个数据集包括来自大企业的超百万条推文与回复,大家可以利用这个数据集做很多有意思的...

43650
来自专栏PPV课数据科学社区

【学习】干货收藏:如何进行大数据分析及处理?

众所周知,大数据已经不简简单单是数据大的事实了,而最重要的现实是对大数据进行分析,只有通过分析才能获取很多智能的,深入的,有价值的信息。 那么越来越多的应用涉及...

1K60
来自专栏FreeBuf

走近科学:隐藏在图像数据库中的安全问题

本文原刊登于IEEE IT Professional杂志。 由于系统改造的代价之高,使用适于系统设计的网络安全措施则是最好的选择。而新科技和应用则带来更多安全与...

225100
来自专栏数据科学与人工智能

【智能】数据科学管道初学者指南

曾几何时,有一个名叫Data的男孩。 在他的一生中,他总是试图了解他的目的是什么。 我有什么价值观? 我可以对这个世界产生什么影响? 数据来自哪里? 看到你和数...

11130
来自专栏PPV课数据科学社区

2017年最全的数据科学学习计划(完结篇)

注: 在PPV课微信公众号回复“数据科学计划”获取PDF全文,内附学习资料网址推荐,让学习直达源头,不用找度娘更省心! 本文为2017年最全的数据科学学习计划(...

435110
来自专栏程序你好

5个有趣的大数据行业应用

大数据分析推动了过去五年的机器学习。还有很多东西有待探索。想要实现大多数大数据项目,需要了解Hadoop生态系统等框架。Hadoop下的MapReduce框架为...

12830

扫码关注云+社区

领取腾讯云代金券