关于数据驱动运维的几点认识
在一个新的环境中工作了两个多月，从业务模式、平台建设、工作方法和团队工作风格各个方面都有了一些认识。有了这些认识，更能让你体会到工作的发力点在哪里，这次自己的工作方法做了很大的调整，没有去平移过去的工作经验，因为当前的很多预设条件和过去不同（具体就不一一列举）。其实运维工作很多时候都聚焦在两个方面，一个是工具建设；一个是数据建设。在工具平台建设层面上，进一步突破的阻力很大，一则缺乏标准化的基础；其次还在于大家意识的改变。因此这次想从数据分析体系入手，用数据说话，用数据评价运维服务。简而言之，就是数据驱动运维（Data-Driven Ops）。
我把数据运维驱动定义为一种方法，它是通过我们对运维目标的识别，借助全量的数据体系来评价运维过程，以确认和目标的达成程度。此时看到了几个问题，数据驱动运维的目标是什么？全量的数据体系是什么样子的？如何建设？最终又如何反作用于运维过程？
数据驱动了运维什么？ 运维的日常场景很多，看似繁杂，其实最终都会有对应的目标导向，比如说对产品质量的首要负责；对效率提升有着狂热的痴迷；对成本有着近乎苛刻的要求，这一切源于生产集群都是有运维管理的。生产集群提供的是面向用户的服务，服务的质量的好与坏首先必须传递到运维侧，通过数据的方式进行评测。维护一个(超)大规模的生产集群，又必须促使运维在繁杂的工作中，找到提升效率和人力解放的方法。在很多时候，我们为了提供更好的服务质量，服务提供方不一定需要付出更多的资源成本，也许当前的资源就能够支撑未来的容量，而不是无数据支撑下，我们就给出了对应的扩容变更方。
什么样数据可以驱动运维？
面对核心的运维价值和目标，我们需要说明样的数据来说明我们当前的状态，此时需要运维采集"大"的数据来分析。一开始不要设定哪些数据是我们需要的，哪些不是我们需要的，但是需要有一个数据归类的方法，找到数据之间的关系。一个方法，就是跟着用户访问流，看请求经过了那些资源和服务，然后统一采集这些资源和服务对象的数据。初步归类如下：
A）面向用户
端对于我们来说是非常重要的数据采集点，端采集的数据需要更直接的反应用户对我们产品的感知。从用户侧来说，我们一般可以看到两类数据，一类是面向产品运营人员的；一类是面向技术人员。在数据驱动运维的价值中，我们可以采集面向技术人员的数据指标作重点，而少量的采集产品侧的数据。
少量的产品侧数据，比如说IP、用户数、PV。这样的产品数据，可以让运维在某些场景下，能够找到事件的相关性。比如说当前的资源容量和业务之间的关系等等。
技术指标，则包含很多，而不同的产品有不同的特征。比如说现在游戏的九游客户端，我们可以重点收集如下指标，崩溃率、启动速度、首屏加载时间、下载速度、用户界面点击情况、页面功能返回值、重点元素的加载时间、DNS请求的时间等等。还有一个非常重要的数据，虽然它和产品无关，但是在有端的情况下，能够帮忙快速测试获取的，就是我们的机房出口质量数据，可以通过客户端hook测试点的方法达到。网页端要采集的数据和方法基本上也和端类似，不一一列举。
B）面向资源
我们向用户提供产品和服务的时候，其实是i有很多的资源在支撑，人力资源、带宽资源、服务器资源、IDC资源、机柜资源等等，我们可以看出资源的对象非常多。如何识别这些资源对象，还是有方法可循的。在我们建设CMDB的时候，我们通过业务导向的方法，已经对我们的资源做了一次识别和入库，此时在cmdb中都建立了要管理的资源对象及其属性。对资源状态数据的收集，是为了评估它的容量，以确保对业务未来的支撑。可以转移一些指标来看一下如何和业务关联？
带宽、服务器、IDC、机柜、CPU、内存、网卡、磁盘IO，这些资源决定着服务的支撑能力。可以建立标准的容量模型，来计算资源的使用率。同时设定资源的容量模型，确保业务的突发情况。在面向用户的数据采集中，我们采集了部分的业务数据，此时可以根据业务的趋势，进一步去看未来的资源容量变更情况。
C）面向公共服务
公共服务是指我们常见的存储服务、cache服务、负载均衡服务、名字服务等等，比如说分布式存储、DNS。是在之前资源基础上，一个面向应用的能力封装。在CMDB中，其实把服务也当作一种资源，但个人还是喜欢把它剥离出来看，因它的特征表现和数据采集的方法都和传统资源采集方法截然不同。
不同的服务需要关注的指标都非常不同，比如说DNS服务，你会关注的解析成功率和解析时间，你还要关注各地LDNS的解析次数，甚至还要关注某次变更之后LDNS的解析异常情况等等。Mysql、memcache、分布式文件存储等各类服务，所需要关注的指标都截然不同。
D）面向接口
我们知道用户的请求在页面或者客户端产生之后，一定会转换到内部分布式系统之间大量的调用。分布式系统典型特征，不是函数式的编程模型，更多的是RPC事件调用的方式，因此此时对这类数据的采集显得尤为重要。接口数据有很多和其他数据采集表现不同的特征。第一、数据量非常大，因此一般采用抽样模型。不过这个地方一定要接口调用量，在很少的情况下，建议全量模式；第二、实施难度大。不同的语言，不同的RPC调用模型，采集的方式都有不同，需要开发深度的配合；第三、采集的数据分析成本高。因为量大，使用传统的技术方法和分析模型难以应对；第四、数据价值最大。在故障发现和运维优化层面，这个数据最有说服力，随用户服务好坏的最直接表现；第五、采集数据模型最容易统一。关注的都是服务访问的延时和失败情况，在加上服务实例之间的描述就可以了。
E）面向整合
当我们采集了以上四类数据之后，我们会发现这些数据是一个离散状态，而非关联。用关联的视角，更多是从业务拓扑、物理拓扑及用户访问流三个角度去看，整合之后的数据更能体现数据的价值。关联的数据也给提炼核心数据价值带来很大的困扰，因多样化的数据带来的干扰，此时需要回到运维价值驱动的角度。还有一种整合的数据，直接是在用户的实际访问流中通过染色的机制来实现数据采集，这个数据对故障定位的意义非常大，能够快速发现问题，通过染色机制，看用户请求在内部服务之间穿越，寻找故障根源点。
什么方法可以帮助构建数据体系？ 上节我们已经详细叙述了需要收集的数据，那么有哪些方法来指导我们完成这样的数据收集、分析呢？ 第一个方法：目标价值驱动法。数据的意义都是最终未来到导向运维的几个价值（质量、效率、成本），有了这些价值，我们再回到我们评估的对象，无论是产品功能、资源、服务还是接口等等，我们都有了评价的指标体系。基于这个评价体系，我们不断深入挖掘数据的构成。 第二个方法：运维场景分析法。在我们日常的运维场景中，我们可以提炼一些核心场景，比如故障定位、服务优化、自动化调度、服务管理等等。有了这些核心场景，我们就需要相应的数据支撑，此时也可以挖掘一些有价值的数据。对于故障定位来说，我们需要降低故障定位的成本，提高故障定位的效率，此时必然需要全面的数据体现，从而能够快速发现故障源；服务优化，有了业务运营数据的积累，我们才知道我们服务的瓶颈在哪里，甚至一次版本变更后的服务质量变好和变坏都可以通过数据来直接评估；自动化调度，我们需要实时的知道服务器资源、带宽的资源使用情况，从而确定准确的调度策略；服务管理，服务的生命周期的管理，需要在服务的每一个阶段，给出数据运营的状态，比如说服务部署、服务变更等等。 第三个方法：遗留系统整合法。在我们日常的运维系统中，业务规模是从小到大的，开始我们肯定使用了大量的开源系统，比如说监控cacti、nagios等等，这些数据在长期的运行过程中，必然积累了很多有意义的数据，运维日常的活动也沉淀其中，此时我们可以把整合和替换遗留系统为目标。面对遗留系统，一定有很多需求而放弃了的。我想有了这个数据改造基础之后，让用户需求来持续滚动数据的分析体系，方法快速有效。
什么方法可以构建驱动体系
前面介绍了，我们需要整理什么样的数据及数据怎么收集。那如何让数据产生价值呢？数据运营如果不遵循一套方法，最终变成毫无价值的数据。
第一、坚持数据运维的文化。在日常的运维活动中，我们需要坚持数据说话，坚持数据共享，坚持避免以定性的方法对运维过程、运维故障、运维事件的描述。甚至在有KPI的运维团队中，建议把这类的数据驱动的运维价值反应到KPI中，确保团队成员对运维数据是足够重视的。
第二、适当考虑数据的实时性。一个不能实时反应运维状态的数据是没有价值的，此时数据分析人员和运维人员需要把握一个边界，不能所有的数据都以实时的形式给出，过多实时的数据一则成本很高，其次数据干扰很大。此时可以区分不同角色的数据需求，一线运维告警人员更多的是看服务状态，因此告警的需求多一些；更上层的运维管理人员希望看到的是服务某个周期（天、周、月）的运行状态（趋势、对比、多维）；研发人员的数据需求和一线运维人员差不多；产品人员更多的是关注产品的趋势和用户体验等等。
第三、业务元数据需要沉淀在cmdb，建立底层数据关联。使用这样一套公共的基准元数据规则，可以更好的整合数据，比如说业务分类。以业务的角度大家容易统一理解数据，让数据反向作用于我们维护的业务，非常直观。
第四、持续滚动反馈的数据体系。让数据持续滚动起来，方法很简单，就是和运维目标关联，通过目标驱动，自上而下的重视这些目标价值。在持续滚动的过程，不断完善数据源及数据分析和展现方法等等。
其实当前阶段，最看重的数据价值是数据驱动了思维和意识的达成。这段时间和我的运维研发团队在这个方向上达成了一致，在六月份我们会讨论具体的行动计划。先写这么多，给自己思路做个记录。