企业级数据中心IT运维建设工作第一步也是最重要的一步，数据管理。很多情况下，企业考虑运维平台时，会侧重技术框架、开发模式、软件品牌等因素，比如大数据架构、paas、saas、微服务，选用的软件是商业产品还是开源产品等。但是，往往最重要的部分是在数据管理的规则上，在这套规则的框架下，我们去选择具备支撑相关功能、性能的技术去实现。同时，我们还不得不考虑的是数据平台的可持续性问题。可持续性方面包含了政策导向性、平台可扩展性、可移植性等。近年来由于开源技术的崛起，技术安全性的问题，导致很多企业牺牲历史投资，重构平台的案例比比皆是。这些问题已经是当前企业数据管理者及架构设计者必须面对的实际问题了。
从数据中心的业务职责上看，数据的特点主要有2个。第一，数据量巨大。第二，数据属性复杂。数据量巨大不光光是简单通过搭建大数据平台来解决。HDFS、Hadoop、ElasticSearch这些技术工具本身并不能100%的解决我们的问题。许多企业的运维咨询方案及架构是简单粗暴的针对数据量的多少，来选择数据存储及计算的资源。而忽视了从数据源头来解决问题。那么，源头问题是在哪里？其实，数据来自于各种对象，包括设备设施、应用。概括来说就是软件和硬件。数据的载体又分为命令输出、各种协议、网络包、日志、接口、人工输入、图像、视频、信号等。数据类型最常见的又分为资产数据、配置数据、告警数据、性能数据、容量数据、业务数据等等。数据的属性是可以被灵活地多重定义的，定义的标准来自于最终的应用场景，用户需要数据被如何消费，那么数据就可被定义为多种属性的标签。这样就解释了数据量巨大的由来，就是因为从各个来源，各种类型，我们常常听到的数据分析，就是需要做数据的多维度交叉分析、比对等功能。因此，这些不同的维度乘以设备/系统的数量这个基数，得出的结果就非常的惊人了。我们做的各式各样的系统的预期结果往往达不到期望的原因也在于不是数据不足以支撑功能，就是数据太多，计算过程开销太大，用户体验不友好。
如何来解决这个问题，其实是要在数据量上做一个平衡。数据并不是越多越好，数据的收集讲究的是合理、合适，同时合规。做大数据分析的朋友都听说过数据质量这个说法。意思就是数据质量直接影响到最终的输出结果质量。一般会先对所有原始数据进行质量甄选，把“靠谱”的数据挑选出来，拿这些优质数据进行模型训练。反复训练、强化训练得出比较可以接受的算法参数及结果。而我们的思路是直接在采集数据的时候，结合用户的最终需求和我们的经验，对数据采集时就添加各种规则。规则规定了我们针对不同应用场景的对象实行颗粒度不同的采集策略。举个例子来说，网络设备，一般架构中最常见的会有核心交换机、接入交换机这样的用途。那针对核心交换机，我们会通过几种不同的手段尽可能采集比较详尽的数据，包括CPU、内存、Sysuptime、温度、风扇、电源、协议状态、丢包率、延时、所有应用端口的流量、甚至是日志级别很低的用户登录消息和配置变更消息。因为，在核心交换机上任何一个不合规的登录或者变更，引起的故障影响是非常巨大的。而接入交换机呢，我们只需知道设备、特定端口是通的就可以了。就这么简单。以上是从数据采集的深度上设计的策略。同样，还要搭配时间的维度，核心交换机我们必须是7*24*365不间断的进行数据采集。接入交换机呢，就不需要了，5*8*5的采集时长就够了。如果不进行采集策略的设计，我们就可以想象平台会有多少无用的垃圾数据了。尤其，在数量上接入交换机的数量往往是核心交换机的好几倍。那有些朋友会问，数据在处理前再进行判断过滤也可以吧。的确，但是这些功能也常年会消耗平台的整体资源。逼着平台的设计往沉重、高配的方向越行越远。除此之外，不同的数据类型，也需要通过合理的方式来采集。一般性能数据，我们看的是趋势，对实时性的要求不是最重要的。我们需要持续的，稳定的间隔去采集。而故障数据，则需要第一时间发现，因此，通过实时或者准实时的发现。配置数据，则需要根据应用或者业务的需要设置更新的时间。
经过以上种种的考虑和设计，才能最有效的利用平台的资源来处理最合适的数据。最后，再结合一个实际功能说明数据接入的重要性。根源故障分析RCA是IT运维里的一个终极目标功能，很多同行都在落地实现，但往往效果并不尽如人意。原因很大程度也是数据采集的问题。数据维度不够多，导致分析出来的所谓“根源”也只是真实ROOT上衍生出来的一个节点而已。数据多了呢，反过来拖累了性能，导致分析过程超时，结果出错等等各式各样的问题。
以上是对数据运维方面的一些思考和理解，希望对各位读者在工作中有所帮助。也希望大家有问题和想法在评论区留言。
