首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >谈谈服务器运营领域的机器学习

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

作者头像
TEG云端专业号
发布2018-03-14 16:09:07
1.7K0
发布2018-03-14 16:09:07
举报

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无所不在!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-06-20,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 TEG云端专业号 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
流计算 Oceanus
流计算 Oceanus 是大数据产品生态体系的实时化分析利器,是基于 Apache Flink 构建的企业级实时大数据分析平台,具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点。流计算 Oceanus 以实现企业数据价值最大化为目标,加速企业实时化数字化的建设进程。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档