如何通过各种数据挖掘运维价值

关于作者

温峥峰，百田信息运维技术专家，DevOps team leader，运维自动化平台负责人，曾就职于网易游戏，专注于 运维自动化建设、DevOps实践 与 海量游戏技术运营。知乎ID @Hi峰兄

前言

改进一个功能是否真的有效果，需要数据说话；

一个运维操作是否有效果，也需要数据说话；

杜绝拍脑袋，数据为王。

「可量化」是一个严谨的技术人员需要追求的客观准则，用一个更加高级的词汇来描述是「可计价」。

一切行为都是有价值的，特别是对线上环境的各种的运维操作、变更，会造成怎样的影响，我们如何判断其价值所在？

作者之前所写的《中小型运维团队如何设计运维自动化系统》https://zhuanlan.zhihu.com/p/31285905，主要讲述了 DevOps 体系中最核心的两大模块：CMDB 和 作业平台，然后次核心是数据平台 ，无论是监控、辅助运营、智能伸缩、故障自愈等高级功能都要依赖数据来驱动实现。

在运维自动化体系里面，数据是一个非常核心且是承上启下的重要元素，它即可以反映运维服务的效率、故障比例、高可性，也可以衡量业务运维状态的稳定性、成本、速度、质量等。

而且在前文的最后部分，就有一个利用作业平台执行数据来挖掘运维价值的例子，因为和本文主题相关，所以也推荐给读者，这两个例子分别是关于运维人力价值和故障分析价值。

除此之外，怎样利用数据来提供运维团队的增值服务，本文通过几个实战例子来描述说明。

技术栈的选择

关于数据收集、处理和展示，业界比较常见的技术栈主要这几类：

第一类是著名的ELK，即 Elasticsearch、Logstash、Kibana（或者EFK，F 是 Fluentd 代替 Logstash，毕竟Logstash因性能问题所以口碑不咋的）；

第二类是 Flume + Kafka + Storm，Java系的技术团队会比较倾向选用这套工具集；

还有一类比较少见的是用 Scribe 作为收集工具；

以上是主流的技术选型方案，但本文的重点不是介绍各种数据分析技术的优缺点，这