腾讯公司从2012年开始，通过对服务器运营流程、工具系统的建设，服务器从一线到三线的运营基本转入线上自动化。在服务器静态配置、动态的运行状态和生命周期各个节点的运营这几个方面，产生了大量的运营数据，这些信息像滚雪球一样，以几何量级快速增长。数据越来越多，该如何着手处理呢？这就像刚入门的厨子一样，在农贸市场里面对堆积如小山般的食材，无从下手。到2013年，建立网平的大数据平台，把所有的基础架构运营数据统一接入和管理，从此，我们开始了在数据矿山中挖掘金矿的历程。
大数据的处理
经过长时间的实践和总结，我们发现服务器运营的大数据有以下四个特点，由浅入深，分别是：1）Volume 数据体量巨大，特别是腾讯有海量的服务器，综合起来，数据量可以到PB级别，需要大容量、高性能的存储技术，分析的算法也需要最优化；2）Variety 数据类型众多，涉及大量的运行日志、部件状态、生产链运营、环境变量等，经常要抽丝剥茧，才能找到有用的数据；3）Value 价值巨大，但并不是每个数据都有价值，需要经过清洗和加工处理后，其产生的效果才能显现，以机房环境温度告警为例，数百万条温度的信息，经过分析对比后，才有可能发现温度异常；4）Velocity 数据需要快速处理，特别是告警类的应用，时效性是非常重要的。
下面讲讲我们是怎么收集和存储服务器运营数据的，给我三分钟，给你一个帅气又有营养的答案！
运营系统架构
对于海量服务器的管理，我们建立了一套功能强大的运营分析系统，从服务器的带内和带外收集了全面的静态属性和动态运行数据，对服务器的每个关节进行的全方位的数据采集和监控。犹如我们平时体检，把心、肝、脾、肺、肾，甚至每个毛孔，都进行了检查。系统架构如下图所示。
存储和分析
数据收集起来后，除了一部分实时的数据存在本地数据库，几乎全部的历史数据都会存储在公司级的数据平台中。这个数据平台提供了丰富的工具系统，功能全面，涵盖了数据存储、分析、实时计算等。例如，TPG是基于postgreSQL的数据库，用于存放TDW（Tencent distributed Data Warehouse腾讯分布式数据仓库）离线分析后的结果数据，便于系统调用（如服务器利用率分析，故障分析、服务器生命周期等生产数据）；Hbase基于No SQL，万亿级的分布式、有序数据存储，用于存放分析后的结果数据（如温度功耗分析结果数据）。整体的架构如下图所示。
大数据的四个实践
大数据的规划分析，决策者和开发者首先要从业务驱动的角度，选择数据生产的业务场景，即要预计数据分析得到的结果能带来哪些效益。根据公司服务器运营的特点，我们在以下四个场景做了大数据的分析和应用，给实际的运营带来的实实在在的好处。
硬盘故障预测
硬盘是服务器硬件故障率最高的一个部件，如果能提前预测到硬盘故障，对业务体验、完善备件管理都有莫大的收益。这也是基础架构运营在经历自动化、流程化后，需要进一步提升运营效率、降低运营成本的天然要求。
涉及硬盘的运营数据包括业务IO数据、硬盘内部的SMART和硬盘运行的环境变量数据(温度和湿度)。目前，运营系统对IO数据是每小时采集一次，SMART数据每三小时采集一次，温度和湿度每半小时采集一次，这些数据合计起来每天的记录数上亿条。硬盘故障预测，适合使用分类算法，我们使用了目前较为流行的SVM分类算法，辅以合适的核函数来加快学习计算的效率。
经过了一年多时间的实践，走了不少弯路，也碰到了很多坑，在硬盘故障标准确定、业务IO分类定义等方面吃了不少的亏，我们在基于SMART数据做的故障预测，达到了令人满意的效果。在实际运营环境中验证的结果如下：准确率precision达到98%，预测时间leadtime的整体偏差不超过2天。
需要重点指出的是，我们做的预测结果，除了training阶段用历史数据外，验证的过程是用现网的实时数据来进行的。就是说，经过SVM算法得到的预测模型后，我们是用最新采集的实时数据输入到模型中，得到的ok和fail两种预测结果，在3天、7天、14天后再对预测的结果进行验证。这个比传统的预测方式（训练和验证都是使用历史数据），对现网应用的价值大大提高了。目前在现网环境中，主要的落地场景包括：1）预测出来的结果，经过运营流程，对BG业务提前发出预警，以提高业务运维效率； 2）根据预测出来的大规模硬盘故障，对备件进行有效管理。
服务器利用率分析
腾讯的业务类型和机型都相当多，机器分配给业务后，使用的情况如何？我们需要跟踪服务器的利用率情况，下图是某业务某机型磁盘IO的利用率统计分析图。分析过程如下：存储类机型，看到一段时间统计出来的IO的利用率并不高，并且是写少读多的应用，是否可以考虑使用IOPS相对不高的廉价硬盘？还是业务的架构存在优化的空间？
服务器利用率分析给运营带来的好处在于：1）结合业务模型，发现业务应用服务器的短板，在发现并修复系统架构缺陷的同时，提高整体利用率；2）对机型选型的优化，例如对于磁盘容量使用率不高的机型，在后续的机型定制中减少硬盘的数量。
故障率分析
服务器故障分析对服务器的各个部件的故障率都做了分析和监控，包括1）生成月度故障率报表；2）故障率异常的实时监控和自动告警；3）分析外部条件与故障率的关系；4）与OS的软件告警信息联动起来，及时发现服务器的亚健康状态。
上图是某服务器硬件最近几周的故障率统计信息。按部件给出各个机型的故障率情况，及时发现批次性故障并给出告警
环境监控
2013年8月，华东地区遭遇罕见的高温天气，很多机房空调制冷扛不住了，频繁发生服务器高温重启的事件。如果能把机房环境温度有效的监控起来，我们就能在发现异常时发出高温告警，提前采取措施。对服务器入风口温度进行采集和监控是一个较为有效的方案。
上图显示服务器入风口温度变化的异常情况，经过数据的规整和误差修正，产生了高温告警。通过自动化流程，及时知会到机房现场负责人。
一些思考
不要被数据误导
人们很容易被大数据忽悠。在很多场合我们都谈了大数据强大的功能和美好的未来，认为可以解决许多社会问题，甚至预测未来。无论大数据如何神奇，若试图用大数据引领未来只会误入歧途，因为大数据背后本就存在着“先天不足”：从本质上看，大数据最大的缺陷就在于试图以确定去“颠覆”混沌与不确定性。之前我们做硬盘故障预测，直观的认为硬盘的读写压力对硬盘老化和故障是有直接关系的，但经过分析，发现业务使用硬盘的随机性太大了，硬盘响应IO的模式也很多变，对于业务的IO读写比例、块大小等，有太多的不确定性，就是前面说的混沌，导致前面基于IO做的预测结果非常糟糕。其实这里要说的就是，目前这个阶段，依靠大数据来指导服务器运营，不靠谱，服务器运营智能化远远没有达到。这里还是要靠运营和开发人员的思维和头脑，把自动化运营先做好。
数据质量的把控
数据的质量和字段规范性对后面分析效果的影响很大。但业务开发所设计的数据不是为了运营分析而服务的，很多情况下都是为了功能开发而存在，如果可以在系统构建初期进行介入，其实可用避免很多清洗工作，数据可直接投入分析使用。这里开发人员和数据分析的人员存在一个gap，如果对数据在系统设计中遇上各种约束的话，开发人员会觉得很痛苦，开发效率非常低；而数据分析人员却觉得如果数据能做到工具级定制，就是连数据的表字段的名称，注释，连内部关系，都是由系统统一生成，这样采集完美的。
后来，我们内部经过一段时间的讨论和磨合，形成的共识。我们做的是运营系统，归根到底是为运营服务的，而数据分析是运营的一个重要功能。所以没有办法，这个问题还是需要开发阶段来解决，开发人员只能克服了。
对大数据未来的设想
精细化的传感器
对于服务器上传感器的设计，互联网企业有特殊的需求，对上游硬件厂商的依赖是比较高的。腾讯有大量的服务器运营数据，非常希望可以跟业界一起在数据、资源、算法等各个维度可以共享，寻求更多提高运营效率的途径。这里的传感器也可以从广义上来展开，除了服务器物理上的sensor越来越多，在服务器各个运营环节都可以在流程中加入各种采集代码，把服务器部署、搬迁、退役等每个细小的步骤都如实的记录下来。运营系统的不断优化将使“传感器”体积微型化，它将出现在生产的每一个角落，为运营决策提供更科学的数据支撑。
数据服务即开即用
随着数据的逐步完善和开放，互联网和企业都将建立起完善的大数据服务基础架构及商业化模式，从数据的存储、挖掘、管理、计算等方面提供一站式服务，将各行各业的数据孤岛打通互联。而且数据应用的生态系统也将变得非常成熟，甚至出现用户与数据服务商之间的算法提供商，他们有专业领域内的精英人才，通过数据挖掘的方式，寻找事物间的联系。用户只需将其原始数据导入，提供商很快的就能在线的将分析结果返回，如水和电一样，即开即用。