数据运维
应用运维思路
-
运维数据:
- 业务数据
- 系统性能数据
- 日志数据
- 监控告警数据
-
应用运维:
-
运维分析:
-
业务数据流分析
- 车辆数据处理流图
- 控制流图
- 网络及负载调度拓朴
- 业务模块部署结构
-
业务量趋势分析
- 连接增涨趋势
- 用户增涨趋势
- 业务请求量趋势
-
业务日志分析
- 服务处理日志分析
- 终端连接日志分析
- 慢查询分析
-
告警记录、性能指标趋势分析
- 业务失败率
- 接口响应时长趋势
- 主机性能指标
- 网络流量趋势
- 系统巡检
- --->系统运行状态
-
业务数据流分析
-
系统预警:
- 系统负载及容量
- 系统瓶颈
-
系统优化:
- 应急调优:参数调优
- 扩容规划:集群节点调整及扩容,升级网络带宽
-
业务优化:
- 瓶颈分析及压测
- 业务实现优化措施
-
运维分析:
数据运维对于运维具有哪些重要意义
- 来源:http://os.51cto.com/art/201510/495483.htm
- 作者:一苇可航来源:一苇可航的运维故事|2015-10-30 10:40
大数据模式已经到来!个体既是数据的创造者也是数据的使用者,医疗,科技,教育领域都早已参与其中。并创造无数的好产品和价值。核心数据搜索和推荐、电商定点广告和推送,基因健康预测等都在不断重新定义互联网的生活。人们的生活并因此而改变。大数据的确对社会进步会产生深远影响和意义。简单来说就是数据可以产生价值!
每个人都在工作中对结果负责并为此带来效益和价值,同时有些人冲在一线在做体系之外的绿叶。他们的工作不直接产生效益但是他们可以足够影响效益结果,这就是苦逼而沉默的运维。默默无闻的运维一代是否可以真正爆发,来证明自己的存在意义和价值。让自己的未来工作充满驱动力和想象力,这就需要运维拯救自己。特别是在互联网冲击时代下的运维更要如此,那么在运维时代的你和我,如何能够了解数据价值呢?
不要让老板在有问题的时候才感觉到你的存在!这是多么痛的领悟啊!想到这里就眼镜湿润的想起了自己的梦想,我可不是想这样工作下去。的确需要改变,一定要打破“出了问题是你的,不出问题你应该做的” 这样的狗屁理念。那么我们就要提出数据运维的概念。
工程数据
描述出你所运维的系统或者工程项目的所有价值数据,体现如下:
- 工单数量
这里应该包括你的每天完成工单的质量和时间。而且要有平台可视化的体现。在完成工单的同时对业务的稳定性和目的要加以描述让你的工作变得更有意义。
- SLA可用性
在老板眼里只关心两件事:一是他赚了多少钱,二是他花了多少钱。 SLA影响产品和业务性能也就间接影响老板的财路。所以这里要完美的体现出来你在帮老板赚钱了。我希望的是运维的同行真的每周的报表里要体现出来并为此运维所做的努力和付出。哪怕只有三个9这也是我们努力过的。
- 基础资源
我们运维的服务器数量和网络设备数量,IDC数量。之间的数据交互延时多少。我们每天的业务调用数量是多少? 调用的RTT如何? 我们报废的设备多少等等这些都要体现出来。反正这些数据即使你不主动表达一般的老板也不会台关心。除非你发生了故障...
- 故障率
没有故障是大家的集体愿望。但是所有的事件都是有规律和原因的。可能是我们的不经意的一个升级zlib库就会导致服务不可用。所以,我还是愿意在平台化上展示出这些数据。如果有进步让老板看到实际变化,如果没有对自己的工作也是一个重要的警醒。
- 报警统计
如果要消灭报警,我们就可以高枕无忧了。也有人说消灭报警自己TM 不就失业了吗? 但是老天会告诉你失业除非是你rm了服务器上的资源,否则老天会保佑你的,我们通过报警数据的统计根据内容做一些数据挖掘和提前预警。同时也要对报警内容进行问题分析和指引。如果老板欣喜的看到了你把短信报警的条数已经控制在3%以内,那么老板没有理由不给你涨工资的。
业务数据
业务运维系统的价值数据。如下:
- 业务dashboard
说白一点就是类似业务层的监控数据。我们可以做一些数据汇总然后平台化展示出来。比如业务的可用性访问状态,访问量的数据状态,DNS解析服务的状态,模拟产品化的监控状态等。可以让这些数据活的更有价值从而也更直观体现出业务的稳定状态。
- trace调用链
这一点重要性毋庸置疑,从Google的dapper到twitter的zippikn再到赵海平跳槽到阿里(其实是说在做这样的鹰眼系统)。可以清晰看到业务调用之间的耗时,模块之间的依赖map可以非常快速的帮助运维定位问题。从而提高业务稳定状态和自身效率。
- 业务拓扑切换
有很多的重要业务都不是单点在一个IDC中心,往往多活在多个地方为了可控单点风险。所以在这样繁杂的业务体系当中,经常会有业务的稳定性切换。
比如模块降级次数,比如切换频率,切换之后的稳定时间,切换之后的访问质量等这些都需要数据描绘出来。
- 业务指标
每个运维要明确自己的服务的业务指标。如果是做Web要看访问量,如果是做电商要看订单率等。而且要实时展示出来自己的业务指标。我们可以根据历史数据和经验进行预测和总结。比如我们要扩容带宽,我们要购买服务器这些数据都是我们的依据。
- 业务基准数据
比如运维锁服务器的平台的业务最大QPS,购买新服务器硬件性能的测试基准数据。在业务模式下的资源状态数据都需要记录和展现,特别是对我们在处理问题的时候能提供强大的依据。
- 业务日志挖掘
原来我们就习惯使用syslogd做统一化展现。现在的大数据时代激情四射早已颠覆了传统的技术。ELK就有一统江湖的意思。同时也有很多大公司开始自修复系统,其实深度来源就是做数据挖掘。根据我们所有收集到的日志做挖掘,展现。最后做调度分配,自修复,子降级。这也是我个人非常期待的事情。
数据如何有效展示
- 平台可视化
运维的本质-可视化,我觉得可视化是描述数据最好的方式方法。我们根据数据做归档,做分析,做rrd,最后分析展示这本身也是想表达我们的本意。
- 业务耦合关联
这个就是说如何让老板,让RD能够容纳我们的平台。本来我们是说要展现自己但是这里就涉及到边界问题。因为有些数据需要和业务交互,有些数据需要和服务器交互。这就需要和业务解耦过程是否无污染的影响业务,是否可以有良好的API实现都是非常的关键。
- 沟通先行
我们在做这些事情的时候要给予老板希望与细心,阐述我们的目的和价值。因为我们在完善一个看似意义不大的平台。所以这里一定要多接触业务,运营阐述我们自己的想法给予我们足够的时间来作这些事情。
- 技术方向
其实这里做平台化的体系,语言工具太多了。我觉得还是那句话拥抱开源,避免重复造轮子! 因为当我们争取到的时间,我们就已经有KPI在身了。如何能用好身边的资源和把控时间非常重要。因为一旦项目失败所有的印象都会要在从0开始。
数据对于我们的工作和生活都足够重要。我们要尊重科技学会善用数据来为我们的工作支撑方向,体现价值!运维的工作特性也是特别需要数据来体现。足可以提高我们的存在价值和对工作的长远影响。希望这些能够对运维的兄弟有所帮助!