2.2.3 数据化驱动

1.什么是数据化运维

20世纪初期，移动互联网开始萌芽发展，如今各式各样的App已经渗透到我们工作和生活的各个领域。对于企业来说，供应、研发、制造、销售、运营等环节涉及的IT系统则更加广泛。随着用户的多元化需求，企业IT系统及应用的复杂程度和数量呈现急增的趋势，也促使IT运维管理系统的增加，运维系统采集的数据种类和数据量同步激增。

对传统企业来说，监控系统呈现分散的状态，而在一些复杂的运维场景如故障定位、服务优化、服务管理等中，常常在需要一些关键数据作为辅助决策时，才发现缺少相应的数据支撑。随着时间的推进，传统的IT运维监控系统已难以支撑企业业务发展的需要。在技术的变革演进过程中，新一代IT监控运维系统以应用为中心，逐渐开始将运维工作的重心进行转移，从工具建设聚集到数据建设，以数据驱动运维，运维走向数据化的时代。

简单来说，数据化运维是以数据架构为基础，以分析为手段，采集全领域相关的运维数据，从而达到掌握运维过程、衡量运维目标的目的。以提升服务质量为例，当遇到系统运行变慢的时候，用户体验就会变得越来越差，一线运维人员会第一时刻想到优化扩容，但是提升服务质量并不意味着一味地付出更多的资源成本。数据化运维更关注以下问题：现有的业务资源是否能够支撑未来业务的持续增长？业务扩容方案的设计与评估的标准是什么？有没有关键的数据作为支撑？数据是否具备说服力？这些都是运维数字化时代需要思考的问题。

数据运维驱动可以定义为一种运维的新方法，它通过数据化更清晰地识别运维目标的达成情况，借助数据评价体系来衡量运维过程的有效性。在数据化建设过程中通常会遇到以下问题：数据化运维的核心目标是什么？数据分析体系是什么样的？如何建设？最终又如何反作用于运维过程？我们运维的日常场景非常繁杂，但其实最终都会有其对应的目标作为导向，比如：IT系统产品的质量追求，运维的效率提升，运维成本的降低，业务连续性的要求等。业务应用集群提供的是面向用户的服务，而服务质量的好坏必须先传递到运维侧，通过付出更多的资源成本进行观测。在数据化运维能力的支撑下，我们可以更科学地评估用户服务规模和容量，以更好地适应业务的扩张。

2.什么数据可以驱动运维

面对运维的核心价值与目标，我们需要明确什么数据能识别当前的运维状态，此时就需要使用运维大数据的能力进行分析。开始时可以采集全量的运维数据，不需要考虑哪些数据才是需要的，数据归集后需要对数据进行清洗和识别，找到数据之间的依赖关系。其中一个有效的方法就是从用户访问流出发，看具体的用户请求经过了哪些资源和服务，然后统一采集这些系统产生的相关数据。数据的初步归类如下。

（1）面向用户

设备端是非常重要的数据采集点，从设备端采集回来的数据能直接反映用户对产品的感知情况。从用户侧来说，通常我们可以看到两类数据：一类是面向技术运营人员的，另一类是面向产品运营人员的。在数据驱动运维的实践中，一方面可以采集面向技术人员的数据指标，另一方面可以少量采集产品侧的数据。

（2）面向资源

向用户提供产品和服务的时候，后台有很多的资源在支撑，包括人力资源、带宽资源、存储资源、计算资源、IDC资源、机柜资源等，可以看出资源的对象非常多。为了更好地识别并管理这些资源对象，企业常规的做法就是建设一套CMDB系统。在建设CMDB系统的时候，需使用以业务为导向、以应用为中心的方法，对所有资源实例进行识别，以业务维度进行相关资源实例指标的采集，如带宽使用率、CPU使用率、内存使用率、磁盘IO使用率、数据库读写峰值等，这些指标决定着服务的支撑能力。我们可以建立标准的容量模型来计算资源的饱和度，同时可以设定业务资源的容量模型，确保支撑的业务规模大小。在面向用户的数据采集中，我们还可以采集部分的业务数据，根据业务的增长趋势进一步去看未来的资源容量需求。

（3）面向公共服务

公共服务是指常见的DNS服务、文件服务、缓存服务、负载均衡服务、队列服务等，比如分布式存储、Redis缓存等，是一种面向应用的基础资源能力封装。在CMDB中，服务也是一种特别的资源，因为它的关键特征、数据采集方式、表现形式都与传统资源截然不同。不同的服务关注的指标有所不同。比如DNS服务，它关注的核心指标是解析成功率和解析时间，并且关注各地LDNS的解析次数，甚至还关注变更后解析异常情况等。Redis、MySQL、分布式文件存储等服务，所需要关注的指标都不同。

（4）面向接口

当用户对页面发出请求或与客户端连接之后，都会转换到业务内部分布式系统之间进行大量的相互调用。分布式系统的典型特征不是函数式的内部访问，而是RPC的远程调用方式，因此对这类接口访问数据的采集显得尤为重要。接口数据有很多和其他对象指标不同之处：第一，数据量非常大，因此一般使用抽样采集，但在关注某些关键指标的情况下，需要全量模式；第二，实施难度巨大，不同的编程语言或者不同的RPC调用模型，采集的方式都大不相同，需要开发人员的深度配合；第三，采集数据的分析难度大，由于数据量大造成使用传统的技术方法和分析模型难以应对，需要使用运维大数据分析技术；第四，数据价值明显，在故障发现和系统优化等运维场景中，这个数据最具有说服力，直接体现出用户服务的好坏；第五，数据采集模型最容易统一，关注的核心指标是服务访问的延时、失败率等，再加上服务实例之间的描述信息。

（5）面向整合

当我们采集了上述4类数据之后，会发现这些数据都属于离散状态，而非关联的状态。用关联的视角，例如从业务拓扑、物理拓扑及用户访问流三个角度去看，整合之后的数据才能体现数据的核心价值。数据关联也给提炼核心数据价值带来一定的困扰，由于数据的多样化带来的干扰，因此需要回归数据使用消费场景才能识别出数据价值。还有一种数据整合方式，是在用户的实际访问流中通过字段丰富的机制来实现数据采集，这样的数据对故障定位的意义非常大。通过字段丰富的机制，看用户在内部服务之间的请求历史，寻找故障根源点，快速发现问题的所在。

3.数据化运维开展方向

“数据驱动运维”战略围绕以下几个方面展开。

1）感知能力。在数据中心的建设过程中，可以应用数字孪生技术，把运维对象数字化，构建可视化的界面。运维人员通过界面可以直观看到系统的运行状况。同时，监控平台覆盖了运维全领域，拥有维度丰富的数据，再通过智能运维算法智能发现故障，对数据中心整个运行组件做到全感知。

2）决策能力。人工决策单纯依赖的是运维专家的经验，对数据中心来说很重要。数字化时代下，需要采用“可视化+专家大脑”去代替部分的人工决策，同时通过“大数据+机器学习”来做智能决策。

3）执行能力。有感知有决策，但当服务质量有所下降或出现故障的时候，要怎么去恢复服务、减少故障恢复时间？这就需要在执行能力方面下功夫。建设了标准化流程、标准化动作、标准化场景，之后再通过自动化运维系统固化起来，这样在出现对应故障的时候，可以采用一键恢复的方式来提高问题处理的效率。

4）数据底座。要建设上面提到的3种能力，数据底座是基础。前面提到，运维工具很多，数据很丰富，但因为“数据孤岛”加上数据维度庞杂，构建统一的运维数据中台作为底座就非常重要。

5）组织转型。数据中心有各个领域的技术专家，网络专家精于网络知识，系统专家负责系统知识，所擅长的领域各不相同。而采用智能运维的方式时，运维感知和决策建立在数据的基础上，这时候就需要组织做相应的转型。采用Google SRE的理念来提高运维开发能力，提升运维效率。