zhuqibs
作者zhuqibs2020-06-01 16:57
软件开发工程师, Adidas

新时代人才发展之路

字数 6987阅读 1244评论 1赞 3

作者简介

本人 75 后,在职场摸爬滚打了二十载,初期以主机服务器和数据库起家,后期从事运维工作,现在落足在全国知名的一家连锁餐饮企业,担任运维总监的职务,负责 DevOps 平台建设工作和企业内 ToB 和 ToC 端的容器云运维。从国企到私企,从传统企业到互联网企业,再到传统企业,我深刻的感觉到技术发展的速度之快,更新迭代使人几乎处于茫然的境地,我想结合技术趋势,对于在当今时代运维人员如何学习发展,谈一下自己的心得。

    • -

1 、开篇前言

在过去几十年间,技术发展的格局,发生了翻天覆地的变化。

在 90 年代时,商业化软件几乎成为了技术的全部, IOE 成为了当年每个 IT 人员最求职业高峰的不二之选。而 IOE 在那个年代也逐步统治了大部分的 IT 领域,比如 Oracle ,原来只是数据库软件,而后通过不断的兼并,变成了前后端一体的一站式解决方案提供商。从 Java 、 JavaScript 、简易 web 开发工具 Oracle Application Express ,到中间件 weblogic ,再到数据展现工具 Obiee 、再到 ERP 领域的 Sieble 、 peoplesoft ,再到数据库的高可用 RAC 、灾备 datagurad 、复制 goldengate ,最后索性提供一体机 Exadata , Oracle 展现其统治 IT 上下游的雄心和实力。其实,那个时候,对 IT 人方向是比较明确的,就是学习 Oracle ,就对了,就和学习会计要考 CPA 一样,方向明确,不会迷茫。那时的我也是这么想的,想着 Oracle 可用学习一辈子,能去 Oracle 原厂工作,必定可以大展宏图。

但是这世界唯一不变的就是变化,接下来的日子里 IT 世界发生了诸多的变化。首先是,云的兴起, AWS 横空出世, Saleforce 接着跟上, Oracle 忽视了, Oracle CEO Larry 开始时认为云无足轻重,因为云就是一堆机器用根网线上网。但事情的发展远远超出了他的意料,云的发展彻底改变了 IT 世界,源源不断的有软件 SaaS 化、 PaaS 化,到后来 Aws 的 Aurora DB 等数据库开始侵蚀 Oracle 的数据库市场份额,虽然这种侵蚀每年大约只有 0.3% 左右,但明显的 Oracle 的市场份额在慢慢下滑。而对于 IBM 来说,就是它们的服务器、小型机的订单呈下滑趋势,云端的 IaaS 使得大家不用担心服务器的庞大投资了,聪明的蓝色巨人聪明而又果断的选择了把它们卖给了联想。

其次是开源软件的广泛使用,以 google 为代表的厂商大肆在 github 上开放其软件的开源版本;对可靠性要求不高的客户,开始选择开源软件,而不去购买昂贵的 IOE 的许可证。于是开源软件开始从前端到后端开始侵蚀 IOE 的市场。每一种商业化软件,总能找到开源替代品。

再次就是分布式应用,在这点上 Oracle 为代表的厂商总是试图用他们的市场影响力阻止分布式的推广,因为这样才能符合他们的商业利益。但历史的前进是无法阻挡的。当服务器的横向线性性能扩展比纵向扩展的优势逐渐被认同, Oracle 也不得不低头,在 Oracle 12c 数据库中推出了 sharding 分片功能。但是不得不说已经晚了,各种开源版的分布式应用已经占据了大部分市场。

出于以上三点,作为技术人的我,工作和学习的轨迹发生了变化,我从一心钻研 Oracle 数据库技术,变成了多点开花,开始了从前端到后端,从应用到数据的广度学习,为了在运维这条路上走的长远而努力。

2 、运维技术之路

其实,凭心而论,运维技术这条路不好走。过去不好走,因为学习的成本高,有过经历的同学一定知道,要不停的考认证,我就考过 OCM ,当初光考试费就是 7000 多人民币。现在的路更不好走,因为开源技术发展太快了,种类繁多,不知道要学什么,容易陷入 “ 生命有限,所学无限 ” 的尴尬处境。

大量开源的新技术出现,前端出现了 VueJS 大有取代 AngularJS 的趋势,而同时 React native 出现又大有取代 VueJS 的趋势,实现 IOS 端与 Andriod 端的统一代码;中间件家族出现了 RabbitMQ 、 RocketMQ, 使得 IT 架构中除了 Weblogic 和 Websphere 之外有了其他的选择; 数据库端除了开源 MySQl ,还有 MongoDB 等 NoSQL 数据库,以及 MyCat 、 shardingJDBC ,乃至 OceanD B 、 TiDB 等众多分布式解决方案;数据分析领域出现了 Kylin 来取代 Oracle OBIEE , Python 语言、 Hadoop Mapreduce 取代 SPSS 等分析软件的趋势;存储领域, Ceph 和超融合系统的出现,利用高速网络和 ssd 盘的优势,将本地盘组合成虚拟存储,大有取代 EMC 的昂贵阵列的趋势。

那么如何走并走好运维工程师这条路呢? Google 给我们很好的启迪,将来的运维工程师,目标是应该进化成 SRE 工程师,具备诸多技术。下面我将展开阐述我的观点。

2.1 技术选型

好,现在问题来了,面对如此之多的技术,是学什么,怎么学,学到什么程度,是摆在我们面前的难题。 我这里所提倡的是广度学习,也就是 T 字中学习法。

2.1.1 深度选型 – “T” 字之” I ”

学习中,必须首先选择好 T 字中的那个竖线,因为这是根本,将影响你今后的广度学习的众多方面。我主张首选开发,对于运维而言,就是学习 python 最为妥当, python 被誉为是开发语言中的万能胶,因为它从前台到后头都可以有用武之地,前端 python 有自己的 Django 框架,可以编出凑合的页面,运维有运维的包体,数据分析有数据分析的包体,人工智能也能对接 tensorflow ,几乎是“万精油”,日本已经把它列入了小学课程,把 python 学精深了是不会错的。然后,再把 mysql 或 Oracle 选一门选精深,形成 Python+Mysql 或 Python+Oracle 的 T 字“竖杠”。

Python 的迭代总的来说还是比较慢的, Python2 到 Python3 虽然变化挺大,不过目前都是 Python3 为主, Python2 已经不多见了,很好聚焦。而 MySql5.7 到 MySql8.0 大都只是增加了一些新功能,几乎没有颠覆性的改动,也比较稳定,学深学精,从时间上是可以保证的。

2.1.2 广度选型 – “T” 字之 “—”

记得曾经刚进一家公司的大数据部门的时候,几乎把我吓一跳,为什么呢? 因为细排了一下,这个大数据部门搞的开源软件,多达 50 多种,而整个工程师团队不过 30 人,追求新技术本质上并没有错,但学多难精,而且还有很多的新技术如同昙花,刚开始时耀眼夺目,时间一长没有了维护了,就逐步退出了历史舞台或被取代。大家黄金的学习时间区区只有十几年,如果方向选错了,不仅时间上是种浪费,对你的 IT 之路也是一种不小的打击。

首先,在广度学习的选择上必须要遵守 “ 从众 ” 原则,也就是学的人越多,用的公司越多,越是要加入你的学习列表。那如何知道呢? Github 给我们提供了很好的依据,以开源软件 ceph 为例,如图所示


大家可以看到,目前它的 commits 数量高达 11.1 万,而 Stars 有 7.8k ,也就是点赞的有 7800 次之多,要知道 Github 是不会有 “ 海军 ” 这种职业存在的(就算有也无人付工资啊),所以这个数字基本上可以反映真实情况。而且 4 小时前发生过更新,开发者更新积极。下面来对比另一个项目。


同样是分布式存储的项目, glusterfs 的 commits 数量和 stars 数量就比 Ceph 少很多,而且更新是在昨天,开发者更新不太积极。

2.1.3 实势选型 – “T” 字之整合

当今技术发展日新月异,我们一定要多看看外面,避免闭门造车,必须根据外界流行的趋势不断调整自己的方向,将 “ T” 字整合起来一起应用。

对于应用架构而言,开始时候,大家熟悉的是三段架构,前端是应用层,大都是放置 tomcat ,中间是逻辑层放置 jar 包为主的 app 和 redis 缓存,后端是数据库层。而后是 Duddo 分布式框架,再然后进化到以 SpringCloud 、 Springboot 为主的微服务框架。

对于承载架构而言,开始时候还是服务实体机或 vmware 虚机,而后 Openstack 的兴趣打破了 vmware 的垄断,但是 Openstack 毕竟是个半成品,而且本身发展也有诸多问题,于是应容器化技术 docker 、 Kubernetes 技术异军突起。

而后的应用架构和承载架构整合起来了,形成了基于容器的微服务架构 istio ,所有的应用装载在容器的 pod 中、 pod 中又有 sidecar 边车来控制东西向流量,构成了服务网格( Service Mesh )。

当所有人认为这已经是架构演变的最终形态时,又出现了 Serverless 模式,无服务架构,这种服务架构,更为节省资源,容器在 pod 在用时才建,不用就销毁。

对应于如此变革,你不需要如何快的变,但你需要知道外面的技术形势是如何的,根据外界的形势,及时修正自己的学习方向和计划,学无止境,学习是一辈子的事,无论你的年龄,无论你的位置。

2.2 学习方法

在学校学习我们是根据大纲,按照书本按部就班的来学习。但工作了要学习 IT 技术,就没这么 “ 好 ” 的条件了。

2.2.1 文档学习

首先,“好”的书本是不存在的,因为技术变化太快的。记得前两年,我“立志”学习大数据买了一本一年前的 hadoop 大数据的书,不料看了网上的资料都与书中不同,原来书中 hadoop 版本早已淘汰。

所以,我们要靠最新的资料来学习,对应开源软件最好的学习资料就是 document 文档,而文档大都是英文的,大家可以借助于翻译软件翻阅学习。

2.2.2 实践学习

光说不练总是不对的,所以,建立自己的一个实践平台是很有必要的。这里我们可以用 vmware 或 vbox 虚拟机平台,当然如果有条件,也可以用公有云上的资源,总之,搞运维的 IT 人,必须有环境进行实操。

每个文档基本上都是这个软件的最佳实践,最好就是把最佳实践都在自己的虚拟机环境中运行一遍,形成自己的初步经验。

2.2.3 学以致用

有很多时候,学过的的东西,如果不用,过段时间就会忘。所以在工作中的学习是尤为重要的,从事运维工作的 IT 人应该在平时工作时,努力将所学的东西应用于工作,比如:一个非常 routine 的工作,你就要想如何通过自己学习的 Python 把它变得自动化,这就是学以致用。这样一来有成就感,二来学过的也不容易忘。

2.2.4 以教代学

虽然有实验环境实践、工作上也尽量使用,但总有些软件,我们没有办法持续接触,那怎么办呢? 我们可以用把所学的东西整理一下放在博客上,放在知乎上,这个有时并不是给别人看,是为了自己的学习,应该总结整理过的东西,是非常有逻辑性的,而有逻辑性的东西印象就深刻。

更进一步,可以尝试把所学的编制成 ppt 教材,尝试对着镜子讲出来,我的经验是,知识讲的过程才能发现你理解上的不足,讲过几遍后,就完全是你自己的东西了。

2.2.5 不求甚解

有很多人学习中容易犯的一个毛病就是“期望过高”,他们往往看文档前立下大志向,但很快发现有些东西难以理解,就中途放弃了。知识体系的复杂有时是前后关联的,文档并不是学校的课本,不可能循序渐进。所以正确的学习姿势应该是先通读,后精读。遇到不懂的地方,先查百度,查谷歌,尽力理解,实在不行,就要暂时放弃,去读后面的篇章,等通读完成后,精读时,再反过来解决先前不懂的东西。

2.3 “懒人”至上

做运维工作,必须有懒人的意识,就是尽量“减少”自己的工作量。当然,我们这里绝对不是鼓励大家逃避工作,推卸责任;而是鼓励大家用先进的工具技术,提高工作效率,避免重复无谓的工作。

2.3.1 ITIL 流程规范

没有规矩不成方圆,有些公司的运维做的不好,不是因为技术不行,而是没有好的规范。这点我是有切身感受的。我经历过一家公司,内部的运维岗位基本上是受虐的,每天忙的不可开交,而且还要承接老板安排的即时工作,基本就是随叫随到,这样导致运维力量消耗厉害,运维工作很难开展。

正确的方法是按照 ITIL 的规范,将工作和责任分散到不同的部门,一切工作按相对固定的流程办事,建立发布流程、变更流程、事件处理流程、问题处理流程等等,这样才能有章可循。记住把工作安排好,工作量合适,也是一种能力。

2.3.2 DevOps 理念和工具

DevOps 的目的是将一个项目的发起、设计、开发、质量测试、安全检查、部署等流程完全标准化、自动化、流程化,把运维、开发、项目管理人员紧密配合,无缝衔接,最终达到端到端的应用交付。这是当前运维领域,比较流行的理念。运维人员必须对此了解,认知并接受,把自己从一个纯粹的运维,变成运维开发人员。也就是说,将来的运维人员,并不是天天如同救火队一样的,去解决问题;而是去搭建维护一个平台,来承载项目管理、持续集成持续部署、自动化质量测试等工作。

3 未来运维展望

运维的未来会是如何呢? 我其实 DevOps 的出现已经给大家一个很好的启示,未来运维必然是在 DevOps 的基础上继续走下去。

3.1 人才方向 – SRE 转型

在传统 Ops 模式上的主要问题是:过分关注如何解决那些常规问题、紧急问题,而不是找到根本原因和减少紧急事件的数量。

SRE 是 google 提出的运维工程师理念,是一套方法论体系。全称叫 Site Reliability Engineer ( 网站可靠性工程师 ) 。一个 SRE 工程师基本上需要掌握很多知识:算法,数据结构,编程能力,网络编程,分布式系统,可扩展架构,故障排除,这些也就是我在上面让大家技术选型和学习之路。

SRE 工程师,要做到以下四点

3.1.1 拥抱风险

把风险识别出来,用 SLI/SLO 加以评估、度量、量化出来,最终达到消除风险的目的。

3.1.2 质量目标

一般可能认为没有故障就是正常,万事大吉了。 SRE 要求明确定义 SLI 、 SLO ,定量分析某项服务的质量,而监控系统是 SRE 团队监控服务质量和可用性的一个主要手段。通过设立这样的指标,可量化质量,使得我们有权力 PK 业务研发,也能跟老板对话,取得更大的话语权。

3.1.3 减少琐事

SRE 理念里讲究要花 50% 左右的时间在工程研发上,剩余 50% 的时间用来做一些如资源准备、变更、部署的常规运维,以及查看和处理监控、应急事务处理、事后总结等应急处理工作。如果一个屏幕上十几个窗口,各种刷屏,但却不彻底解决问题,这时就需要用更好的方式 —— 自动化、系统化、工具化的方式 , 甚至是自治的方式去处理这些 “ 琐事 ” 。

这里对传统运维的思维也有一些挑战,因为我们日常做得最多的工作在 SRE 中是被定义为价值不高的琐事,运维不是操作, “ 运维 ” 是个工作内容,人工或是软件都可以做。

在谷歌里,会要求 SRE 有能力进行自动化工具研发,对各种技术进行研究 ,用自动化软件完成运维工作 ,并通过软件来制定、管理合理 SLI/SLO 。

3.1.4 工程研发

我个人理解的工程研发工作包括三个方面:

a 、推进产品研发改进架构,经常和研发探讨架构、集群、性能问题。

b 、引入新的运维技术,基础组件要 hold 住,比如 TSDB 、 Bosun 、 Consul 、 Zipkin 等。

c 、自研工程技术、平台、工具、系统、基础组件、框架。

3.2 运维方向 – AIOps 之路

AIOps 自从 Gartner 于 2016 年提出至今已有一段时间 , ,一直是运维的方向。在顶级互联网及电信企业,已有较多落地,主要包括:精准智能告警、智能异常检测、智能趋势预测、智能化故障处理。这里拿智能化故障处理的两个功能举例。

3.2.1 自愈功能

运维体系会和人工智能相结合,利用深度学习算法,让这个系统架构有“智慧”,实现自愈功能。比如现在的百度,如何服务器中有几台宕机了,是不用立马去更好换的,系统会自动判断非正常的服务器,然后利用算法去规避这些服务器,然后,尝试通过重启和重新安装系统的方法,自动尝试去恢复这些服务器,恢复后,又能自动加入集群中。

3.2.2 自动工单

人工智能能够根据故障的特点,来自动填写工单,自动发送到相关的部门去处理解决。这个在电信等大企业中已经有相关应用。

4 、结束语

运维工程师之路,其实是知易行难的,而且通常都是幕后的,其中辛酸难以为人所表,通常都是有 “ 背锅侠 ” 之称,并且,学的东西博而杂,难以统一集中。所以,我根据自身的经历提出几点考量,提供给大家借鉴,帮助大家努力把自己塑造成为一名合格的、适合未来需要的运维工程师。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论1 条评论

匿名用户
2021-02-26 13:21
写得真好~回顾了以往的职业发展路径和新的大背景下运维体系急速变化下产生的面临的问题,最后罗列了自己的思考提供了自己的方法论。好文~遇到了类似的问题,处于被各种开源软件和自动化运维体系带节奏的混乱状态。看到这篇文章思路瞬间清晰了不少~
Ctrl+Enter 发表

作者其他文章

相关文章

相关资料

X社区推广