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

李强 2018-09-29 09:41:57
本文根据李强老师在〖2018 DAMS中国数据资产管理峰会〗现场演讲内容整理而成。

 

(点击“此处”可获取李强演讲完整PPT)

 

讲师介绍

李强,10年以上运维及管理经验,先后在AdMaster、饿了么担任运维经理;现任天天拍车运维总监,主要负责天天拍车运维架构的管理、持续优化以及运维团队的建设、培养。擅长互联网运维体系、运维技术体系的建立以及高并发互联网基础架构的设计及优化。 同时作为国内最早一批思科网络模拟器的推广者、虚拟化先锋论坛的创始人,一直致力于网络模拟器使用的推广,为国内培养网络工程师尽一份力。

 

今天跟大家分享一下运维人的职业生涯发展和相应的软硬技能提升,议题分为两个部分,第一是运维工程师成长的烦恼,第二是怎么走好自己的运维之路。

 

一、运维工程师成长的烦恼

 

第一部分里,根据我自己长时间的工作经验,把运维工程师按照工龄做了一些年限上的划分,比如任职三年、五年、八年……处于不同阶段,运维人也呈现出相当不同的状态。  

 

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)项目管理能力以及事件回顾、复盘能力

 

最后,项目管理能力以及事件回顾、复盘能力也同样是需要提升的软实力,推荐看看《复盘:对过去的事情做思维演练》这本书。

 

Q & A
 

 

Q1:我是做系统安全运维的,目前我所了解的安全事件一般都是因用户泄露引起的,想问一下,您对现阶段运维安全结合的方向有什么指导吗?

 

A1:我聊一下我的感受:运维如果是面向安全的话,我都不知道怎么去面对。为什么?因为运维在做一些开源组件配置的时候,很多时候安全问题本身是可以避免的。像之前网上看到的NTP、DNS的域名反射攻击,还有数据泄露,这些其实在我看来都不是一个应该发生的问题。因为作为一个运维,他的职责,第一个是稳定,第二个是安全,我们讨论的安全问题80%就是运维引起的,为什么呢?因为不去把配置思考,默认把配置全部建立到公共的IP上,你的数据就是直接暴露的。

 

我认为,如果安全方面你把这些开源组件用好,更直接一点,如果这个开源组件里有参数是指定的IP,你只要把这个IP指向内网IP,然后让端口指向内网,你的安全运维80%就做到了。

 

Q2:我是一名运维开发,想咨询一下,您怎么看待运维跟运维开发的关系?

 

A2:只有当你对你所负责业务的基础组建深入了解并能用得好的时候,足够的运维开发你才会得心应手。比如我们公司从运维到现在没有做过一个运维开发,但是在做运维的过程中,我们会做简单的运维开发,做一个平台实现很多的功能。

 

为什么不招运维开发?因为当时还没有构建完善的运维体系。只有当建立符合标准化、规范化的运维规则、制度、流程之后,我才会用运维开发。比如现在我已经有了标准化、规范化的东西,那就需要招运维开发帮我实现相应的平台,来更加高效地实现运维的目标。

 

所以,运维开发,我个人建议你要么去做监控,要么你想负责所有的开源组件更好地做好运维工作的话,先把运维的基础东西夯实了,然后再去做运维的架构。

活动预告