基于一线工作中的积累和认识，早就想写一篇数据题材的文章了，因为各种事情一直拖了又拖，其实就是拖延癌在作祟，再就是文笔差、落字慢，脑袋里框架清晰可到了指尖却敲不出几

基于一线工作中的积累和认识，早就想写一篇数据题材的文章了，因为各种事情一直拖了又拖，其实就是拖延癌在作祟，再就是文笔差、落字慢，脑袋里框架清晰可到了指尖却敲不出几个字，悔透了上学时没好好背书没好好看文学巨著，各位朋友一定要以我为鉴，好了转入正题。

随着行业的发展，运维职能在发生微妙的变化，现在谈何为运维，其实我觉得更像是技术运营，通过运营的方式技术的手段牵头协同各部门来保证产品的SLA（服务质量），控制产品的成本和可管理性。作为技术运营来说，最重要的是拿到各种信息来描述产品的各种指标，也就是通过数据将产品的形态画出来，然后通过这些指标形成合理的产品决策和战略方案建议，那么这些信息从哪里来呢，不错，就是从数据中来，所以产品中数据的应用是运维工作中最重要的一环。

 一个产品在运行中会产生各种数据，而产品的健康情况、业务指标就藏在这些海量的数据里，数据通过汇聚整理形成有组织的信息，这些信息服务于运维就是监控告警、异常检测、apm等，服务于业务部门就是DAU、PV、UV等各种运营指标，服务于老板就用于公司决策，继续对这些信息进行归纳总结形成知识，对处理方式进行归纳总结形成经验，对经验抽象总结形成方法论也就是规律。现在是概念横飞的时代，为了展现技术的先进，什么热炒什么，但作为一个一线的从业者还是要剖开表象看本质，对于事物的认识必将经历知道、不知道、再知道和简单、复杂再简单的过程，到了第三个阶段可以说是真正知道了，PS现在热炒的机器学习等说到底其实就是改变在某一个点的数据处理操作，不要把它神化了。

回归到“运维中的数据应用”的主题，我认为数据应用中最重要的有三个环节：采数据、管数据、用数据，其中偏技术能力的是采数据、管数据，比如说从海量数据里实时汇聚计算出有用的数据按照特定条件发送给相关人，1G、2G的数据好处理，但是1T、2T数据的实时处理就是个技术工作了，这也是考验运维人员技术能力的一个点，而用数据更多的是业务能力，业务场景的建模。在运维工作中，我们将服务器的CPU、内存、IO、网络等基础指标进行采集，对业务日志进行采集，对依赖资源的健康情况进行采集，形成一个庞大的基础数据源，对这些数据进行实时收敛画成曲线就形成了监控，对监控继续收敛将一些能反应业务健康指标的项提炼出来并加上触发器就形成了告警，这些监控和告警都是需要管理的，因此就诞生了监控告警管理系统，但是有了监控告警并不能根本解决问题，你还需要看到一些详细的信息，就有了日志分析系统........自然而然的一环扣一环的发展。

现在再看运维中的数据应用是什么？采集服务器上的数据，通过不同维度的收敛聚合做成实时监控图像，再针对不同的指标添加触发器形成告警，告警的同时附上数据分析报告形成告警分析，为了提前预防故障，将还没有形成故障的产品薄弱点做成异常检测分析报告定期发送预警，为了根因排查必须做到可以随时查询详细日志，还需要通过SDK等将代码内部执行层面数据收集起来进行性能分析，通过采集数据中各种指标的计算又形成了容量评估，这些对有故障时流量的调度也提供依据，总而言之产品运行的数据为一切的问题定位和实际操作提供了数据支撑，这些都是运维中数据应用。那么问题来了，怎么做？这就是运维层面的技术方案了，每个环节都对应有不同的工具，工具可能会变，但其中的道理是不会变化的，所谓道法自然而术变万千。例如说我现在使用的一个运维数据方案，如下：

好了，就写这么多，在运维中通过各种工具将产品呈现出来、风险暴露出来，就已经完成了运维的绝大部分工作了，运维中的监控告警、日志分析、异常检测、APM、容量管理等都是围绕数据的应用，把数据运营使用好，会给你带来很多意外的收获。

后附（实时收集的一个告警分析）：

“运维网咖社”原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://www.net-add.com

社长"矢量比特"，曾就职中软、新浪，现任职小米，致力于DevOps运维体系的探索和运维技术的研究实践.