首页 > 移动应用 > 正文

给1到10年运维人的修仙指南

2018-10-26 10:43:04  来源:今日头条

摘要:根据我自己长时间的工作经验,把运维工程师按照工龄做了一些年限上的划分,比如任职三年、五年、八年……处于不同阶段,运维人也呈现出相当不同的状态。
关键词: 运维
  今天跟大家分享一下运维人的职业生涯发展和相应的软硬技能提升,议题分为两个部分,第一是运维工程师成长的烦恼,第二是怎么走好自己的运维之路。
 
  一、运维工程师成长的烦恼
 
  第一部分里,根据我自己长时间的工作经验,把运维工程师按照工龄做了一些年限上的划分,比如任职三年、五年、八年……处于不同阶段,运维人也呈现出相当不同的状态。
 
\
 
  1-3年:有技术的逗逼
 
  (1)随性工程师
 
  在工作时间内,一般是比较随性的工程师,做一天和尚撞一天钟,我也亲身经历过此阶段。这时候还没有什么责任心,不会有过多的想法,只负责去执行,而不做过多的思考。与工作时间内的“被动思维”呼应的是,下班之后夜生活比较丰富,撩妹、抖音、打游戏等。
 
  (2)做技术容易“管中窥豹”
 
  什么概念呢?一到三年的运维人大部分靠度娘,例如Nginx配置最大连接数只知道上网获取65535相关的配置,但是配置背后的原因和原理,他们不知道也不甚关心。至于各种一些文章里的配图,更不会做深入研究。
 
  (3)工作态度积极,冲劲足
 
  我曾接带过一个实习运维工程师:3月份入职,9月份离职。初来乍到特别散漫,做事只应付我们的基本期待。后来接受了一些思想指导,小伙子工作突然很有冲劲;他所做的事情,包括日报、周报内容的撰写,表现得判若两人。2015年4月份的22个工作日,他加班22天,天天至凌晨两三点。期间技能也得到了极大提升:比如让他测试集群的性能,积极去做之外,也会认真思考为什么去做这件事情;对新技术进行研究,思考怎么样把它快速地掌握。
 
  (4)事务型人才
 
  最后,我把各个行业的小朋友都称为事务型人才,顾名思义,只需要把事情做好,达到公司的业务目的即可。“顾头不顾尾”也是一种常态,我指导过一名90后的运维工程师,他做代码发布,只管发上去,无视后期事态,比如是否发布成功、业务是否可以访问等。
 
  3-5年专业资深人士
 
  (1)技术提升
 
  技术的确得到一定的提升,这是生存规律。初入公司,一张白纸,为了掌握了解公司的业务,你会去学习,否则就只能被淘汰。
 
  (2)“跳槽”惯性
 
  技术提高以后,会陷入“跳槽”惯性。上面提到的2015年3月份到我这边的运维工程师,刚入职时转正5K,9月份离职去大麦网以后薪资一下到13K,的确这时候跳槽提升得很快。但是容易迷茫,如果频繁跳槽,发现好像跳到这家公司和那家去差不多,到底应该怎样去做,就不明晰了。这时候,我们运维的技术方向就发生变化了,基础架构运维和开发型运维开始分化,其中DevOps会更多一些,一些运维工程师会产生迷茫,到底是去做什么。我所认识的一些人做到五年左右,基础架构运维的事情还没有非常深入的时候,就去做了DevOps,发现原有的开源组件并不能用得很好,给公司以及个人的发展带来了一定的风险。
 
  (3)技术能力与高薪预期的“错位”
 
  技术能力提升减缓与高薪预期的“错位”,这一阶段的中级运维或高级运维都容易自傲。我面试的运维人有跟我同龄的,还有比我大的,他们中有些人技术知识还停留在五年前,却因为自己从事这方面有一定时间了,产生高薪的期望。这就造成错位,高薪期待和实际能力不匹配。
 
  (4)事务型和思考型人才
 
  3-5年运维人属于事务型和思考型人才,身为中级或再高一级的运维工程师,大部分人还是处于被领导的状态。有经验和学习能力加持,他们会思考什么是该掌握的东西,不过思考的强度往往还不够。
 
  (5)缺乏总结跟复盘
 
  最后,缺乏总结跟复盘。我相信运维人面对新的技术,或者做一些测试的时候,都会做笔记。那为什么还缺乏总结?很多时候笔记就只是一本笔记,并没有回翻笔记来复习,更不会及时更新笔记内容和分类。
 
  5-8年:运维经理,至少运维主管
 
  5-8年的运维人基本上是运维经理,至少是运维主管。但是,很多运维工程师是凭着技术能力和工作年限成为运维经理的,这中间要面对一个从技术到管理的跳跃,所以存在较多问题等待适应和解决。
 
  (1)找不到自己的定位
 
  升任到运维经理后,很多事情还是自己承担,导致团队里的其他兄弟分担任务很少,进步很慢,长远来看也不利于整个团队的发展。
 
  (2)团队意识薄弱
 
  不会带团队,不懂得利用团队的力量来满足公司的业务需要,还是做原来的角色。
 
  (3)对管理角色的认知出现偏差
 
  身份转变来得突然,面对新角色不适应,比如开始摆架子,趾高气昂,指使别人做这个做那个。另外,不习惯处理管理类事务,比如某一公司的业务在机房的哥们先是运维工程师,被提到了IT主管。每天都要做报表,他会觉得太烦了,宁可不做,想回去继续做一个运维工程师。
 
  (4)思考与事务占比相对来说会更均衡
 
  做了运维经理以后,你更多的时候要思考的是怎么让自己的运维更加有效率,怎么让公司形成这种标准化、规范化的运维体系以及运维技术体系。所以这时候,作为一个领导者,可能既要处理团队里疑难的技术问题,同时还要去规范运维体系。
 
  (5)运维技术容易达到瓶颈期
 
  公司里面处理线上事务特别多的时候,对于一个运维经理来讲,时间、精力用来补足管理,很少能进行技术知识的更新,所以技术知识往往就会停留在那个阶段。但是在做技术的圈子里有个特别好玩的现象,底下的普通员工如果要服你,就要看你的技术能力是否够强。技术能力不强,即使你的管理能力很强,下面的兄弟也不认你。
 
  我遇上好多这样的情况。有一位运维工程师朋友认为自己经理的技术能力不强,瞎指挥。但纵然这位经理技不如人,他可以把一些任务安排有时间节点地完成,而且保证一定的质量,这就是懂得管理。而我认识的这个朋友,虽然他也做了八九年了,却始终是一个普通的基层技术人员,做不上管理岗。
 
  8-10年:运维总监/运维架构师
 
  8-10年的运维人,已达运维总监/运维架构师层次。这时候技术经验和管理经验都已经非常丰富,加上做了运维总监或运维架构师,他们都有比较好的职业习惯。
 
  (1)知识陈旧
 
  因为他们不再做一线的运维了,问题交给团队的人处理,自己只会给一个思路。比如说:不管做DBA还是做运维的,他们对听过的名词都熟得不能再熟,但就是做不到毫秒级的故障切换。不久有人来问我,你们是怎么能做到毫秒级故障切换的?我回答说我们对于技术的领域是一直更新的,Failover用的最多的还是Keepalived,Keepalived官方已经给了答案。另外做技术是我的兴趣,做管理是我的工作。
 
  (2)学习能力下降
 
  能做到运维总监或运维架构师,年龄绝对不会特别小,一般都在33到35岁之间。这时候,家庭、团队、公司都有很多事情会分散精力,相比而言学习能力会有所下降。 我在没有孩子之前,一周至少有三个晚上可以腾出来三个小时学习。现在,常常被两个孩子缠着玩,等他们睡着以后发现剩下的一个小时或半个小时压根儿就不够,加上早起,精神上会很累。
 
  (3)新事务接受能力下降
 
  比如做数据仓库和区块链这些比较火的技术,没法让一帮三十几岁的人去搞技术攻关,攻不了,精力也不够。
 
  (4)不懂的东西会越来越多
 
  现在的新技术非常多,如果你不保持更新自己的知识体系,就会发现跟不上行业的发展节奏。
 
  (5)对于事情目的、目标不明确
 
  很多人对于运维这件事只管做,但为什么做、到底要做成什么样子的,并不在乎。比如做故障切换的时候,我们是要求十毫秒必须发现问题,两毫秒以内故障切换。但很多公司并没有这个要求,只要出了故障切过去就行,至于你的业务中断多少时间可能都不会去思考。
 
  以上是我根据实际工作经验,对不同阶段运维工程师的特征做的一些总结。我还是希望更多的运维工程师可以走好自己的职业生涯,因此有了下面的一些建议。
 
  二、怎么走好自己的运维之路
 
  先分享一下我最近面试新人时的一些经验。我面试时不会问过多问题,我就问应聘者:你会不会安装操作系统?
 
  这个问题看似简单,其实不那么容易回答。应聘者没有一个人说得上来,为什么我的操作系统安装到服务器上,服务器可以正常运行,也没有一个人说得上来。
 
  我又问,你能在任何一个服务器上安装操作系统吗?他们回答是“能”。这就是不善于去深入挖掘,是比较肤浅的。
 
  再比如做配置的时候,很多人会选择输入网上的资料,我们操作系统里面配置/etc/security/limits.conf时,有人会将nofile配置为65535。我问他们,你为什么不配一个65536呢?他说不允许。我就笑了,说明很多人不会仔细地深究这个65535到底能配还是不能配,能不能比这个大,大多少倍,这些都没有人去思考。
 
  所以,面试结束我都会告诉他们说,能够深入,你才会有价值。
 
  对于刚入职场的人而言,五年以内的发展多凭借硬实力;而五年之后,运维软实力才决定他能走多远。
 
  1、打磨硬实力
 
  (1)官方文档
 
  红帽招人面试时会问一个问题,当运维的环境出现故障,你首先从哪里查找资料解决问题?如果回答,我先从红帽的官方文档上找,然后再去处理思路,你已经把一只脚踏入红帽了;如果说你先通过谷歌搜索,还能继续往下聊一会儿,但如果你说先通过百度搜索,下面就已经不用再进行了。这些都是红帽相关负责人告诉我的。
 
  (2)及时跟上时下比较火的技术
 
  现在很多人学运维,只把技术停留在落后的架构上,然后根据百度上查找到的资料使用起来,而且没办法做到更深入的使用。对于优化也仅仅停留在稍微修改就可以的程度,不会做更深入的研究。
 
  (3)多关注技术公众号
 
  我关注了二十多个技术类的公众号,不为别的,就是为了能及时了解新技术,提升自己的见识。
 
  (4)给自己投资技术类书籍
 
  我有一个观点,给自己家庭买东西的时候,要舍得花钱;给自己手底下兄弟谋福利的时候,眼睛眨都不要眨;给自己的大脑做投资的时候,也是如此。看书就是一项对自己有益的投资,以下是我看过后觉得不错的书,推荐给大家:
 
  《亿级流量网站架构核心技术》
  《Linux性能优化》
  《Linux防火墙第四版》
  《海量运维运营规划之道》
  《精通Nginx第二版》
  《MySQL运维内参》
  《高性能MySQL第三版》
 
  (5)实验
 
  因为技术对我而言是一种兴趣爱好,虽然精力上分不开那么多,但每当出来一些新软件或新版本,我都会去摸一摸,看看根据自己以前的技术知识能不能把它运作起来,同时摸索是否有更好的新用法。
 
  2、提升软实力
 
  我现在对部门所有运维工程师的软实力提升,要求非常高,比硬实力要高得多。
 
  (1)沟通能力
 
  面试沟通:我面试的时候,发现有些人沟通能力太差,坐了一会儿就开始紧张,紧张得手都不知道该往哪放了。虽然我已经尽可能地让他在轻松的环境里面试,以最轻松的话题谈起再逐渐进入主题,但他还是紧张得不知所措。
 
  不过,沟通能力不代表口若悬河,应该具备一些关键要素,交流时讲清楚做了什么事、为什么做这个事、有多少种方法去做,这才是沟通能力。
 
  上下级沟通:做管理的时候会发现,领导者最希望听到下属的反馈。当我向下安排任务时,我希望他们过一会儿会来找我,了解做这件事的目的、怎么规避风险、有没有其他应急预案等。如果不沟通的话,上下级很容易会产生这样的问题:比如说我安排的配置要求很高,但他们并不知道我所希望达到的程度,自以为已经配置得很好了,到了交付成果的时候才发现效果不够好。如此反复,领导者只能不时盯紧手下人的任务进程。
 
  我们建立呼叫中心的时候,招来了一个管人力资源的人,他入职第一周下午下班后给我和公司所有高管发了周报,汇报项目的完成进度、完成结果、由谁负责、为何延期等,写得非常详细。当时所有人的反应都是,这个人一定要好好留着。所以说,通过写周报,就体现了他的价值。推荐看看《不懂汇报工作,还敢拼职场》这本书。
 
  (2)时间管理能力(碎片时间)
 
  大家在不加班的情况下,下班后手机一般都是用来干什么的呢?我的习惯是如果坐地铁,会利用这个时间看看文档、PDF等。
 
  非常值得一提的是去年给我们公司做培训的一位讲师,他的碎片时间管理极为优秀。比如这会儿在我们的峰会现场,会有10分钟的短歇时间,他可以在这10分钟里写一份PPT为明天的演讲做准备,但一般人都会在做完今天这场分享之后再去做下一场的PPT。所以说,懂得利用碎片时间是很重要的。
 
  (3)方法论
 
  作为技术人员经常会用到的方法论是什么?
 
  SWOT
  6W2H
  PDCA
 
  鱼骨图:人、机、法、料、环
 
  任务分解法
 
  SMART原则:具体、可衡量、可实现、时效性、相关性
 
  思维导图
 
  SWOT原则可用于分析你自己的优势和劣势。当你去新的一家公司工作,挑战、机遇各是什么?所以我面试的时候常会问两个问题,你认识你自己吗?有些人想过,有些人没想过,我会再细化,你自己的优势是什么?劣势是什么?
 
  PDCA原则其实就是帮助我们在做事情前做好计划,做完了再去检查,检查之后发现有没有改进,或者有偏差的地方通过纠偏,通过不断的PDCA原则越做越好。很多时候,如果想做好,PDCA原则是一定要有的。推荐看看《管理管到位就这几招》这本书。
 
  鱼骨图、任务分解法、思维导图,这三个是我做任何事情都会用到。如果用鱼骨图做不成功,反过头来,把做不成功的原因定位,做好方案,再根据思维导图做这个任务;你的执行计划是什么,执行计划做出来,接着任务分解:什么时间,做什么事情,你需要什么配合。
 
  (4)工具
 
  以下这些工具也是技术人员经常需要用到的:
 
  Xmind:用于做思维导图;
 
  JIRA:通过JIRA管理项目,根据项目的进度来评估团队每个人每周工作是否饱和。如果谁这周空着,我就让他做学习、提升或优化;
 
  Confluence:在这个系统里做文档管理。
 
  (5)项目管理能力以及事件回顾、复盘能力
 
  最后,项目管理能力以及事件回顾、复盘能力也同样是需要提升的软实力,推荐看看《复盘:对过去的事情做思维演练》这本书。
 
 

第三十八届CIO班招生
国际CIO认证培训
首席数据官(CDO)认证培训
责编:pingxiaoli

免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。