一名出色的运维，都是成功的大数据使用者

【导读】如果说以前的运维工作者还只是一个“仓库管理员”，那么现在的运维者就是看一名“仓库盗窃者”。尤其是大企业的运维者，每天面对着海量的数据，就是面对着一座巨大的宝库。要学会利用大数据分析从中提炼出自己所需要的有价值信息。

下面我们就谈谈运维都需要了解哪些数据，哪些指标，以及数据呈现。从而帮助运维者，能让这些数据真的变得活起来。

运维监控现状

很多公司的运维的监控具有如下特质：

只能监控基础运维层次，通过zabbit等工具提供服务器,CPU,内存等相关的监控。这部分重要，但确实不是运维的核心。

对业务的监控是最复杂的，而现在很多公司的要么还处于Shell脚本的刀耕火种阶段，要么开发能力较强，但是还是东一榔头西一棒子，不同的业务需要不同的监控系统，人人都可以根据的自己的想法开发一个监控的工具也好，系统也好，平台也好。总之是比较凌乱的。

使用第三方的监控平台：这个似乎在Rails/NodeJS/Pythone相关语系开发的产品中比较常见。当然也有抽象得很好的，比如点评网的运维监控据说就做得相当好，运维很闲，天天没事就根据自己的监控找开发的茬，让开发持续改进。不过他们的指导思想主要有两个：

运维自动化。怎么能够实现这个目标就怎么搞，这严重依赖于搞的人的规划能力和经验。

抽象化，根据实际面临的问题做出抽象，得到对应的系统，比如需要发布，于是又发布系统，需要管理配置文件，所以有配管系统，需要日志分析所以有了有日志分析系统。然而这样是比较零散的。

数据源的特性

所有的数据源都有一个共性，就是日志。无论文本的也好，二进制的也好。所以日志是整个信息的源头。日志包含的信息足以让我们追查到下面几件事情：

• 系统健康状况监控
• 查找故障根源
• 系统瓶颈诊断和调优
• 追踪安全相关问题
  
  

从日志我们可以挖掘出什么?

我觉得抽象起来就一个：指标。

指标可以再进行分类：

• 业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等；
• 应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等；
• 系统资源层面，如cpu、内存、swap、磁盘、load、主进程存活等；
• 网络层面，如丢包、ping存活、流量、tcp连接数等；
  
  

每个分类里的每个小点其实都是一个指标。

大数据运维思维

对于运维的监控，利用大数据思维，需要分三步走：

1、找到数据

2、分析定义从数据里中我能得到什么

3、从大数据平台中挑选你要的组件完成搭积木式开发

工程数据

描述出你所运维的系统或者工程项目的所有价值数据，体现如下：

1)工单数量

这里应该包括你的每天完成工单的质量和时间。而且要有平台可视化的体现。在完成工单的同时对业务的稳定性和目的要加以描述让你的工作变得更有意义。

2)SLA可用性

在老板眼里只关心两件事：一是他赚了多少钱，二是他花了多少钱。SLA影响产品和业务性能也就间接影响老板的财路。所以这里要完美的体现出来你在帮老板赚钱了。我希望的是运维的同行真的每周的报表里要体现出来并为此运维锁做的努力和付出。哪怕只有三个9这也是我们努力过的。

3)基础资源

我们运维的服务器数量和网络设备数量，IDC数量。之间的数据交互延时多少。我们每天的业务调用数量是多少？调用的RTT如何？我们报废的设备多少等等这些都要体现出来。反正这些数据即使你不主动表达一般的老板也不会台关心。除非你发生了故障。

4)故障率

木有故障是大家的集体愿望。有的人也请来了法师给机房开光祈福平安。但是所有的事件都是有规律和原因的。可能是我们的不经意的一个升级zlib库就会导致服务不可用。所以我还是愿意在平台化上展示出这些数据。如果有进步让老板看到实际变化，如果没有对自己的工作也是一个重要的警醒。

5)报警统计

如果要消灭报警我们就可以高枕无忧了。也有人说消灭报警自己TM不就失业了吗？但是老天会告诉你失业除非是你rm了服务器上的资源否则老天会保佑你的，我们通过报警数据的统计根据内容做一些数据挖掘和提前预警。同时也要对报警内容进行问题分析和指引。如果老板欣喜的看到了你把短信报警的条数已经控制在3%以内，那么老板没有理由不给你涨工资的。

业务数据

业务运维系统的价值数据。如下：

1)业务dashboard

说白一点就是类似业务层的监控数据。我们可以做一些数据汇总然后平台化展示出来。比如业务的可用性访问状态，访问量的数据状态，DNS解析服务的状态，模拟产品话的监控状态等。可以让这些数据活的更有价值从而也更直观体现出业务的稳定状态。

2)trace调用链

这一点重要性毋庸置疑，从GOOGLE的dapper到twitter的zippikn在到赵海平跳槽到阿里（其实是说在做这样的鹰眼系统）。可以清晰看到业务调用之间的耗时，模块之间的依赖map可以非常快速的帮助运维定位问题。从而提高业务稳定状态和自身效率

3)业务拓扑切换

有很多的重要业务都不是单点在一个IDC中心，往往多活在多个地方为了可控单点风险。所以在这样繁杂的业务体系当中经常会有业务的稳定性切换。

比如模块降级次数，比如切换频率，切换之后的稳定时间，切换之后的访问质量等这些都需要数据描绘出来。

4)业务指标

每个运维要明确自己的服务的业务指标。如果是做WEB要看访问量，如果是做电商要看订单率等。而且要实时展示出来自己的业务指标。我们可以根据历史数据和经验进行预测和总结。比如我们要扩容带宽，我们要购买服务器这些数据都是我们的依据。

5)业务基准数据

比如运维锁服务器的平台的业务最大QPS，购买新服务器硬件性能的测试基准数据。在业务模式下的资源状态数据都需要记录和展现，特别是对我们在处理问题的时候能提供强大的依据。

6)业务日志挖掘

原来我们就习惯使用syslogd做统一化展现。现在的大数据时代激情四射早已颠覆了传统的技术。ELK就有一统江湖的意思。同时也有很多大公司开始自修复系统，其实深度来源就是做数据挖掘。根据我们所有收集到的日志做挖掘，展现。最后做调度分配，自修复，子降级。这也是我个人非常期待的事情。

如何有效分析大数据

1)平台可视化

运维的本质-可视化，可视化是描述数据最好的方式方法。我们根据数据做归档，做分析，做rrd最后分析展示这本身也是想表达我们的本意。

2)业务耦合关联

这个嘛就是说如何让老板，让RD能够容纳我们的平台。本来我们是说要展现自己但是这里就是涉及到了边界问题。因为有些数据需要和业务交互，有些数据需要和服务器交互。这就需要和业务解耦过程是否无污染的影响业务，是否可以有良好的API实现都是非常的关键。

3)沟通先行

我们在做这些事情的时候要给予老板希望与细心，阐述我们的目的和价值。因为我们在完善一个看似意义不大的平台。所以这里一定要多接触业务，运营阐述我们自己的想法给予我们足够的时间来作这些事情。

4)技术方向

其实这里做平台化的体系，语言工具太多了。我觉得还是那句话拥抱开源，避免重复早轮子！因为当我们争取到的时间我们就已经有KPI在身了。如何能用好身边的资源和把控时间非常重要。因为一旦项目失败所有的印象都会要在从0开始。

总结

每个人都在工作中对结果负责并为此带来效益和价值，同时有些人冲在一线在做体系之外的绿叶。他们的工作不直接产生效益但是他们可以足够影响效益结果，这就是苦逼而沉默的运维。摸摸无闻的运维一代是否可以真正爆发，来证明自己的存在意义和价值。让自己的未来工作充满驱动力和想象力，这就需要运维拯救自己。特别是在互联网冲击时代下的运维更要如此，那么在运维时代的你和我，如何能够了解数据价值呢？