大家下午好，我是来自腾讯的王镇，今天给大家带来的分享主题叫“海量服务器监管控最佳实践”。
前面分享的是硬件相关的，下面我分享的是和软件系统相关的。
回顾一下腾讯服务器的发展历程，回溯到2007年，这个阶段我们的服务器只有几千台的数量，我们依靠人力和一些自动化脚本，搞定了基础交付和基础监控。当我们的服务器起量，进入到5万或者10万这个级别之后，光靠人力已经不能完全满足，必须要依靠我们的自动化和工具平台。再到现在业务快速发展，现在我们机房运营的服务器体量已经有超过50万台。
介绍一下我们怎么定义服务器的监管控。腾讯服务器都是以OEM为主，从OEM的厂商，从服务器出厂到腾讯的机房商家，整个周期我们都会进行精细化管理，这里面包括三个阶段，第一是资源准备阶段，第二是资源生产阶段，第三是资源运营阶段，第三个阶段是最为关注的，这个生命周期里时间是最长的，而且和我们的业务是紧密绑定在一起的，这阶段里服务器有任何异常都会直接反映到业务进程里，这 我们整个管控平台在这块投入的精力、时间、人力都是最多的。
跟大家分享一下，因为腾讯的业务跟其他互联网公司有一些不一样的地方，腾讯的业务种类非常多，部署在我们服务器上的业务、进程、数据也非常复杂。在研发整个管控平台，在研发整个系统的时候，对块的考量也是特别多。例如说在海量服务器上部署Agent，再下来是整个海量服务器环境也是非常复杂多变的，有些周期是一天，有些周期是一周，总的来说，我们的系统架构首先要考虑到我们的系统是可分布式的，在应对不同的业务峰值的时候，我们的管控策略在不同的场景下，我们要考虑到很平滑的对我们的管控系统进行扩容和缩容。
下面看看整个管控平台在系统化工具化这方面我们是怎么进行建设的。我们整个管控平台建设有那么长时间，整个过程中我们遇到的问题非常多，在不断总结的过程中，总结那一下我们整个管控平台开发的几个设计理念，最想跟大家分享的是第三点，管控平台要提供一个底层能力和对外开放的API，这样我们的业务和前就可以很放心的和我们的底层来进行解耦，他们就可以很容易的来做上层的一些业务架构。我们的系统平台，我们借鉴微信开放接口的设计理念，把我们所有接口都按照完全独立的设计理念对整个接口进行重构，在有限的资源、有限的人力下来对外提供底层架构管控的能力。
简单介绍一下整个管控体系的功能框图，可以看到整个管控的基础架构，包括网络设备、服务器设备，这些设备经过数据采集管控之后，经过一轮的数据清洗，在上层分为三个大的模块，分别是BME，基础管控引擎，还有集成监控、集成告警模块，在完成这些逻辑处理之后，通过统一的API对外提供服务。在过去我们只有海量系统的时候列了一个API来对海量系统、海量用户直接提供我们的底层服务能力，让运维人员和运维系统可以直接对接进来。业务发展起来以后，业务对这块的功能需求，个性化需求非常多，我们也提供了独立的API来对这个业务提供单独的个性化的服务。以上这些服务，功能模块非常多，每一个功能模块单独拿下来我们都可以独立成为一个系统。
简单跟大家分享一下监控模块逻辑框图。首先介绍服务器，对服务器的管控、监控主要有两条路径，第一个是带内，第二个是带外，带内通过服务器上面开发一个Agent，去采集服务器上面的信息，再通过转发来汇集到后台数据分发中心。在带外，通过BMC采集这些基础信息，这些基础信息采集到之后，通过Jobsvr，把这些信息汇聚，汇报到数据分发层。在数据分发层设了一个Redis cluster有了这一层之后就可以很好应付当这些上报峰值来的时候，先把这些数据存进来，在后来再慢慢处理。再上面一层是告警集群，解析逻辑，这个解析逻辑大家可以注意到这里面有非常多的节点，这里面都是可以水平进行扩展的。解析出来之后有两条路径，第一条路径是直接通过派单系统/流程系统，直接上报到业务运维系统这边跟他们进行对接，这样业务运维系统就可以根据服务器当前的状态来对它们数据进行迁移或者搬迁。还有一个方面，我们跟腾讯服务器的供应商的接口进行了打通，我们的监控系统发现告警之后，直接可以通过这些接口来进行报障，不像以前是通过线下来进行的，这个接口打通极大提高了我们服务器故障处理的效率。
前面讲的都是带内采集的工作，这里也介绍一下近一两年我们在带外这块也有一些发力，从我们整个服务器监控的经验来看，带外数据跟服务器硬件更贴合，上面能获取到一些信息更能直接反映到整个服务器硬件上的状态。从带外主编主要利用这几个方面，第一个方面是我们对带外进行重启操作，整个重启操作，10万次是比较老的，最新的应该是远远超过10万。第二个方面是采集的数据，包括服务器上面带外的SDR、SEL这些信息，这些数据采上来之后第一对这些数据做分析，看看这上面能不能拿到一些告警和异常的信息。第一个内容是用来做告警。第二个方面是做数据分析，通过分析这些信息的曲线，再反馈到机房这边，也可以做很多方面的应用。对功耗的一些处理，整个PUE怎么降低，很大程度上取决于服务器能耗合理的管控，如果把这部分的能耗能够控制下来，我相信整个绿色机房PUE降低也是有非常大的帮助的。
这里有一些问题，这也是我为什么要反复提标准化的原因所在。第一，现在我们一些服务器硬件部件都是从OEM厂商二次购物的，这样我们的厂商汇兑它进行二次封装，这样导致我们在采集的时候，采集商量的并不是原始的信息，导致我们采集的PN还有手民信息出现很多不准的情况。第二，随着服务器运营的历史加长，而且整个服务器在机房停留的时间越长，上面的服务器、OS版本越旧，造成我们服务器不兼容的情况越来越多。
随着我们运营有那么多年的历史，我们积累的数据越来越多，我们大概从4年前开始建设数据平台，有了数据平台建设之后，我们才能对后面的数据化运营、对我们的机器学习、对我们的AI才能有原始的数据。数据业务分析这块，从内圈里来看，从数据的生命周期来看，我们把数据分为四个类别，数据生产、数据接入、数据分析和数据应用。在外圈这一层是具体到数据分析的业务，我们对CPU、网络、IO这些数据进行分析，就可以知道我们的业务对我们服务器利用的情况怎么样，通过对利用率的分析我们可以很好的在下一代平台里对这些CPU进行合理的选型。
跟大家分享一下我们整个数据平台的功能框图，采集服务器上的信息分为两个路径，一个是带内，一个是带外，这些数据采集上来之后都会经过统一的消息队列kafka，从消息队列里经过简单的数据主力，这里面也会把这个数据吐到两个地方，第一个是存储平台，分成不同的数据类型，分别用了HDFS/Hbase/tsdb。第二个方面，把我们的数据吐到三个处理模块，第一个是实时数据处理模块，用到storm、Ssark，这些数据实时性要求非常高，第二个是数据批量处理，第三个是出库和入库。这些数据处理完也有两条路子，第一个路子是数据上报的环节，最近我们针对一些日志类型的数据也引入了Elasticsearch，通过不同的业务系统，通过统一的API，就可以获取到数据服务了。还有一块是内部的应用，包括硬盘故障预测，批次问题分析，服务器健康管理，机房温度管理，能耗管理。
下面是讲机器学习和AI，这里跟大家分享三个业务，第一是故障告警，我们通过这个应用，把更多的非明确的告警把原因分析出来，我们通过OS内核日志还有带外的日志进行分析，通过机器学习的方法，把这个原因分析出来，再通过人工翻译，翻译成业务看得懂的原因，附在告警单里，让业务对我们这些机器会有更多的信心。第二个方面是故障预测，跟大家公布一下硬盘故障预测最新的效果，我们在全网用得量最多的一款硬盘上，提前30天预测的准确率可以达到90%上，覆盖率可以达到80%以上。第三块是健康度管理，有这样一个业务背景，腾讯的服务器体量比较大，现在已经有超过半数的服务器过保了，针对这种情况，把全网所有的服务器分不的维度来对这些服务器的健康度进行等级的划分，分为健康、亚健康、故障等这样一些等级，这样我们在资源分配还有资源交付的过程中，根据这些不同等级的服务器，可以做更多可选的选择。
这里讲的是数据平台建设情况，今年AI确实非常火，大家可以在不同场合、不同论坛里都可以接触到。这个是我们之前做的单机版。最近我们有了经验积累之后，把所有的算法做成平台，包括反类、聚集、神经网络。最后一块是深度学习平台，得益于近期GPU的广泛利用，我们在这块也会有一些投入。
一路走来，腾讯在整个服务器监管控这块遇到的问题非常多，今年我们也跟各个服务器厂商一起推动了多个标准的落地，最终的目的都是为了推动整个服务器在后面运营阶段可以更顺畅的进行。我们推出了标准化，包括带外命令、软件配置、监控工具还有带外采集这样的一些标准化。这个事情不是一蹴而就的，需要在座各位和业界上下游厂商大家共同的努力，如果把这个事情做成了，绝对是一件功在当代、利在千秋的大事。作为国内服务器运营成熟度较高的互联网公司，腾讯愿意跟大家一起努力，谢谢大家！
热门专题
