2019运维技能风向标

为促进社区发展,运维派寻求战略合作、赞助、投资,请联系微信:helloywp

运维是一个融合多学科(网络、系统、开发、安全、应用架构、存储等)的综合性技术岗位。从最初的网络管理(网管)发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等,可以看出,运维的分工一直在细化,并且对综合技能要求越来越高。未来运维的发展趋势是高、精、尖。高表示高度,精表示精通,尖表示尖端,也就是运维职场一定要站在一定的技术高度,在多个技术领域中,要精通某项技能,同时对尖端前沿技术一定要能掌控趋势。

运维职位的发展和趋势

根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。

1.按领域来划分

  • 1)基础设施运维:IDC/网络运维、服务器/存储设备运维
  • 2)系统运维:系统中间件运维、云计算平台运维
  • 3)数据运维:数据库运维、大数据技术平台运维
  • 4)应用运维:应用软件系统
  • 5)云平台运维:公有云平台运维
  • 6)容器运维:基于容器服务的运维

2.按技术切面来分

  • 1)安全运维
  • 2)性能运维
  • 3)数据运维
  • 4)集成运维

3.按流程来划分

  • 1)构建/持续集成、发布
  • 2)安装部署、升级、迁移、合并、扩展
  • 3)配置、初始化、配置变更
  • 4)备份、传输、恢复
  • 5)日志、监控、预警
  • 6)诊断排查、优化

系统运维技能图谱

系统运维是运维的基础,新的一年中,对基础运维技能要求也在提高,打好系统运维基础,才能深入学习后面的各种运维技能。

下图列出了系统运维要掌握的必备技能:

Web运维技能图谱

Web运维是运维岗位中岗位最多的一个,薪资也相对较高,但需要掌握的知识点也比较多,新的技能要掌握,老的运维技能也不能丢。

下图列出了web运维要掌握的各种必备技能。

大数据运维技能图谱

大数据从2017年开始逐渐走到生活的各个角落,2018年在逐渐落地,而在2019年,大数据依然火热。

加上国家对大数据产业的扶持,大数据产业在新的一年岗位需求一定会更加大,因此掌握大数据运维技能,就走在了运维的前沿。

下图列出了大数据运维要掌握的各种必备技能。

容器运维技能图谱

容器的产生,是一次IT行业的革命,2015 年到 2016 年,是业界普遍认为的容器技术爆发的一年,短短一年多时间里,容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。

时至今日,容器技术在国内大多数企业中落地已成为一种共识,而国内的生态系统,也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。

因此,2019年也是容器继续快速落地的一年,下图列出了大数据运维要掌握的各种必备技能。

数据为王的时代

万丈高楼平地起,高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。

对数据的维护和管理至关重要,特别是日志数据,对运维来说,通过日志可以比较准确全面地知道系统或是设备的运行情况,可以返查问题产生的原因,还原问题发生的整个过程。

通过日志也可以提前预测系统可能要发生的问题或是故障,如系统安全日志,如果网络攻 击会在系统安全日志中有一定的体现。

日志数据处理

这么多的日志,运维要通过各种手段完成日志的收集、过滤分析、可视化展示,那么如何实现这些功能呢?

方法很多,例如ELK集成套件(Elasticsearch , Logstash, Kibana)就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。

那么要如何使用ELK呢,根据日志量的不同,对应的ELK架构也不尽相同,看下面几个常见架构:

ELK架构1

此架构主要是将Logstash部署在各个节点上搜集相关日志、数据,并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。

Elasticsearch再将数据以分片的形式压缩存储,并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询,并根据需求生成数据报表。

此架构的优点是搭建简单,易于上手。缺点是Logstash消耗系统资源比较大,运行时占用CPU和内存资源较高。

另外,由于没有消息队列缓存,可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。

ELK架构2

由此衍生出来了第二种架构:

此架构主要特点是引入了消息队列机制,位于各个节点上的Logstash Agent(一级Logstash,主要用来传输数据)先将数据传递给消息队列(常见的有Kafka、Redis等)。

接着,Logstash server(二级Logstash,主要用来拉取消息队列数据,过滤并分析数据)将格式化的数据传递给Elasticsearch进行存储。

最后,由Kibana将日志和数据呈现给用户。由于引入了Kafka(或者Redis)缓存机制,即使远端Logstash server因故障停止运行,数据也不会丢失,因为数据已经被存储下来了。

这种架构适合于较大集群、数据量一般的应用环境,但由于二级Logstash要分析处理大量数据,同时Elasticsearch也要存储和索引大量数据,因此它们的负荷会比较重,解决的方法是将它们配置为集群模式,以分担负载。

此架构的优点在于引入了消息队列机制,均衡了网络传输,从而降低了网络闭塞尤其是丢失数据的可能性,但依然存在Logstash占用系统资源过多的问题,在海量数据应用场景下,可能会出现性能瓶颈。

ELK架构3

最后,还有第三种架构:

这个架构是在上面第二个架构基础上改进而来的,主要是将前端收集数据的Logstash Agent换成了filebeat,消息队列使用了kafka集群,然后将Logstash和Elasticsearch都通过集群模式进行构建。

此架构适合大型集群、海量数据的业务场景,它通过将前端Logstash Agent替换成filebeat,有效降低了收集日志对业务系统资源的消耗。

同时,消息队列使用kafka集群架构,有效保障了收集数据的安全性和稳定性,而后端Logstash和Elasticsearch均采用集群模式搭建,从整体上提高了ELK系统的高效性、扩展性和吞吐量。

用大数据思维做运维监控

大数据分析最早就来源于运维人的日志分析,到逐渐发展对各种业务的分析,人们发现这些数据蕴涵着非常大的价值。

那么如何用大数据思维做运维呢,大数据架构上的一个思维就是:提供一个平台让运维方便解决这些问题, 而不是,让大数据平台去解决出现的问题。

基本的一个大数据运维架构是这样的:

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

获取需要的数据过滤出异常数据并设置告警阀值通过第三方监控平台进行告警

所有系统最可靠的就是日志输出,系统是不是正常,发生了什么情况,我们以前是出了问题去查日志,或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上,我们唯一要做的就是定义分析日志的的逻辑。

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

  1. woxizishen说道:

    1.结合工业4.0时代。你说的这个方向太大了。现在开源工具功能大同小异。个人觉得运维工程师要做的不是拓宽,而是要收缩战线,做精通。如果能把一套软件运用的滚瓜烂熟,形成自己一套运维理念,比那些所谓新出来开的新工具要更胜任。
    2.个人觉得shell或者bat高手,不比写程序开发一个可视化平台的效率低。前者可以做到很多时候故障进行自动处理,而所谓可视化平台给大boss炫耀战绩确实不错。实质上在工作效率算。脚本才是王道!!!
    一切把工作最后都仍在图形界面作业的,都是在脱裤子放屁。图形界面适合新人玩,但是一旦有问题,底层东西不知道,最后还得找这个开发人员解决,通用性极差。
    如果可以我建议互联网大企业,对于优秀的脚本运维代码一定要保留。一个精通脚本的运维工程师效率,可以顶数十个程序猿甚至上百个图形化作业的工程师。国内运维工程师普片工作效率低下,因为太依赖与图形,而不想着通过操作系统自带的命令自己解决问题,将很多问题提前杀于萌芽之中。
    我个人目前管控上百个服务器,错错由于。没有什么高深莫测技术。
    我只需要一个nagios报警软件,监控所有有网络的设备,不管电脑,交换机,路哟器,防火墙。其次将一些偶尔会发生问题,但是规律性出现的,我宁愿花一天时间为他写一个脚本自动进行,让问题永远在萌芽状态就被解决掉。而不是等报警,我还要人工取干预。

    在我理解工业4.0.
    IT要做的不只是运用什么高大上的新技术,而是运维更加要高效的保证问题被杀死于萌芽之中,而不是被动救火,除了保证业务连续性,更重要是分析问题根源,从预防,监控,灾难发生应急预案等等

    • SunMan说道:

      你说的是100台,如果是是1000台,10000台呢? 图形可以对这10000台服务器各时间段负载各时间段用户数运行情况的曲线一目了然,每天看看,什么时候扩容,什么时候需要人工介入,可以做到胸有成竹。

Copyright © 2012-2019 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部