新时代人才发展之路.docx

新时代人才发展之路.docx

《新时代人才发展之路.docx》由会员分享，可在线阅读，更多相关《新时代人才发展之路.docx（11页珍藏版）》请在冰点文库上搜索。

新时代人才发展之路

新时代人才发展之路

作者简介

本人75后，在职场摸爬滚打了二十载，初期以主机服务器和数据库起家，后期从事运维工作，现在落足在全国知名的一家连锁餐饮企业，担任运维总监的职务，负责DevOps平台建设工作和企业内ToB和ToC端的容器云运维。

从国企到私企，从传统企业到互联网企业，再到传统企业，我深刻的感觉到技术发展的速度之快，更新迭代使人几乎处于茫然的境地，我想结合技术趋势，对于在当今时代运维人员如何学习发展，谈一下自己的心得。

1、开篇前言

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

在90年代时，商业化软件几乎成为了技术的全部，IOE成为了当年每个IT人员最求职业高峰的不二之选。

而IOE在那个年代也逐步统治了大部分的IT领域，比如Oracle，原来只是数据库软件，而后通过不断的兼并，变成了前后端一体的一站式解决方案提供商。

从Java、JavaScript、简易web开发工具OracleApplicationExpress，到中间件weblogic，再到数据展现工具Obiee、再到ERP领域的Sieble、peoplesoft，再到数据库的高可用RAC、灾备datagurad、复制goldengate，最后索性提供一体机Exadata，Oracle展现其统治IT上下游的雄心和实力。

其实，那个时候，对IT人方向是比较明确的，就是学习Oracle，就对了，就和学习会计要考CPA一样，方向明确，不会迷茫。

那时的我也是这么想的，想着Oracle可用学习一辈子，能去Oracle原厂工作，必定可以大展宏图。

但是这世界唯一不变的就是变化，接下来的日子里IT世界发生了诸多的变化。

首先是，云的兴起，AWS横空出世，Saleforce接着跟上，Oracle忽视了，OracleCEOLarry开始时认为云无足轻重，因为云就是一堆机器用根网线上网。

但事情的发展远远超出了他的意料，云的发展彻底改变了IT世界，源源不断的有软件SaaS化、PaaS化，到后来Aws的AuroraDB等数据库开始侵蚀Oracle的数据库市场份额，虽然这种侵蚀每年大约只有0.3%左右，但明显的Oracle的市场份额在慢慢下滑。

而对于IBM来说，就是它们的服务器、小型机的订单呈下滑趋势，云端的IaaS使得大家不用担心服务器的庞大投资了，聪明的蓝色巨人聪明而又果断的选择了把它们卖给了联想。

其次是开源软件的广泛使用，以google为代表的厂商大肆在github上开放其软件的开源版本；对可靠性要求不高的客户，开始选择开源软件，而不去购买昂贵的IOE的许可证。

于是开源软件开始从前端到后端开始侵蚀IOE的市场。

每一种商业化软件，总能找到开源替代品。

再次就是分布式应用，在这点上Oracle为代表的厂商总是试图用他们的市场影响力阻止分布式的推广，因为这样才能符合他们的商业利益。

但历史的前进是无法阻挡的。

当服务器的横向线性性能扩展比纵向扩展的优势逐渐被认同，Oracle也不得不低头，在Oracle12c数据库中推出了sharding分片功能。

但是不得不说已经晚了，各种开源版的分布式应用已经占据了大部分市场。

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

2、运维技术之路

其实，凭心而论，运维技术这条路不好走。

过去不好走，因为学习的成本高，有过经历的同学一定知道，要不停的考认证，我就考过OCM，当初光考试费就是7000多人民币。

现在的路更不好走，因为开源技术发展太快了，种类繁多，不知道要学什么，容易陷入“生命有限，所学无限”的尴尬处境。

大量开源的新技术出现，前端出现了VueJS大有取代AngularJS的趋势，而同时Reactnative出现又大有取代VueJS的趋势，实现IOS端与Andriod端的统一代码；中间件家族出现了RabbitMQ、RocketMQ,使得IT架构中除了Weblogic和Websphere之外有了其他的选择；数据库端除了开源MySQl，还有MongoDB等NoSQL数据库，以及MyCat、shardingJDBC，乃至OceanDB、TiDB等众多分布式解决方案；数据分析领域出现了Kylin来取代OracleOBIEE，Python语言、HadoopMapreduce取代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边车来控制东西向流量，构成了服务网格（ServiceMesh）。

当所有人认为这已经是架构演变的最终形态时，又出现了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不求甚解

有很多人学习中容易犯的一个毛病就是“期望过高”，他们往往看文档前立下大志向，但很快发现有些东西难以理解，就中途放弃了。

知识体系的复杂有时是前后关联的，文档并不是学校的课本，不可能循序渐进。

所以正确的学习姿势应该是先通读，后精读。

遇到不懂的地方，先查XX，查谷歌，尽力理解，实在不行，就要暂时放弃，去读后面的篇章，等通读完成后，精读时，再反过来解决先前不懂的东西。

2.3“懒人”至上

做运维工作，必须有懒人的意识，就是尽量“减少”自己的工作量。

当然，我们这里绝对不是鼓励大家逃避工作，推卸责任；而是鼓励大家用先进的工具技术，提高工作效率，避免重复无谓的工作。

2.3.1ITIL流程规范

没有规矩不成方圆，有些公司的运维做的不好，不是因为技术不行，而是没有好的规范。

这点我是有切身感受的。

我经历过一家公司，内部的运维岗位基本上是受虐的，每天忙的不可开交，而且还要承接老板安排的即时工作，基本就是随叫随到，这样导致运维力量消耗厉害，运维工作很难开展。

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

记住把工作安排好，工作量合适，也是一种能力。

2.3.2DevOps理念和工具

DevOps的目的是将一个项目的发起、设计、开发、质量测试、安全检查、部署等流程完全标准化、自动化、流程化，把运维、开发、项目管理人员紧密配合，无缝衔接，最终达到端到端的应用交付。

这是当前运维领域，比较流行的理念。

运维人员必须对此了解，认知并接受，把自己从一个纯粹的运维，变成运维开发人员。

也就是说，将来的运维人员，并不是天天如同救火队一样的，去解决问题；而是去搭建维护一个平台，来承载项目管理、持续集成持续部署、自动化质量测试等工作。

3未来运维展望

运维的未来会是如何呢？

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

3.1人才方向–SRE转型

在传统Ops模式上的主要问题是：

过分关注如何解决那些常规问题、紧急问题，而不是找到根本原因和减少紧急事件的数量。

SRE是google提出的运维工程师理念，是一套方法论体系。

全称叫SiteReliabilityEngineer（网站可靠性工程师）。

一个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自愈功能

运维体系会和人工智能相结合，利用深度学习算法，让这个系统架构有“智慧”，实现自愈功能。

比如现在的XX，如何服务器中有几台宕机了，是不用立马去更好换的，系统会自动判断非正常的服务器，然后利用算法去规避这些服务器，然后，尝试通过重启和重新安装系统的方法，自动尝试去恢复这些服务器，恢复后，又能自动加入集群中。

3.2.2自动工单

人工智能能够根据故障的特点，来自动填写工单，自动发送到相关的部门去处理解决。

这个在电信等大企业中已经有相关应用。

4、结束语

运维工程师之路，其实是知易行难的，而且通常都是幕后的，其中辛酸难以为人所表，通常都是有“背锅侠”之称，并且，学的东西博而杂，难以统一集中。

所以，我根据自身的经历提出几点考量，提供给大家借鉴，帮助大家努力把自己塑造成为一名合格的、适合未来需要的运维工程师。