今天跟大家分享一下运维人的职业生涯发展和相应的软硬技能提升，议题分为两个部分，第一是运维工程师成长的烦恼，第二是怎么走好自己的运维之路。
一、运维工程师成长的烦恼
第一部分里，根据我自己长时间的工作经验，把运维工程师按照工龄做了一些年限上的划分，比如任职三年、五年、八年……处于不同阶段，运维人也呈现出相当不同的状态。
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：只有当你对你所负责业务的基础组建深入了解并能用得好的时候，足够的运维开发你才会得心应手。比如我们公司从运维到现在没有做过一个运维开发，但是在做运维的过程中，我们会做简单的运维开发，做一个平台实现很多的功能。
为什么不招运维开发?因为当时还没有构建完善的运维体系。只有当建立符合标准化、规范化的运维规则、制度、流程之后，我才会用运维开发。比如现在我已经有了标准化、规范化的东西，那就需要招运维开发帮我实现相应的平台，来更加高效地实现运维的目标。
所以，运维开发，我个人建议你要么去做监控，要么你想负责所有的开源组件更好地做好运维工作的话，先把运维的基础东西夯实了，然后再去做运维的架构。
讲师介绍
李强，10年以上运维及管理经验，先后在AdMaster、饿了么担任运维经理;现任天天拍车运维总监，主要负责天天拍车运维架构的管理、持续优化以及运维团队的建设、培养。擅长互联网运维体系、运维技术体系的建立以及高并发互联网基础架构的设计及优化。 同时作为国内最早一批思科网络模拟器的推广者、虚拟化先锋论坛的创始人，一直致力于网络模拟器使用的推广，为国内培养网络工程师尽一份力。
