51CTO 神马叫自动化运维

51CTO 神马叫自动化运维

http://www.cnblogs.com/lyhabc/diary/2014/12/18/4171160.html

http://3060674.blog.51cto.com/3050674/1590803

好久没写文章了，最近要来刷下存在感，近两年，运维自动化被炒的火的不行，行业趋势不可挡，现在企业招运维工程师都要求会一门开发语言。我们公司也不例外，由于刚上市，一下子有钱了，开始招兵买马瞎折腾，因此最近我也面试了不下十来个求职者，本成想可以很容易招到几个不错的小伙，结果却令我很失望，今天贴几个面试者例子上来，跟大家吐槽下：

 

面试A君：

应聘职位：高级系统工程师  ， 工资要18K

此君简历写的不错，在360干过几年，简历上写的是维护公司的360网盘平台，管理着2000多台机器，写了很多自动化工具。然后我就让他跟我聊聊他做的自动化工具，哥们娓娓到来跟我讲他写的那些脚本（自动部署、批量命令、日志分析），从他的表情中感觉他好像觉得他做过的这些东西很牛B（其实都是一堆SHELL+PYTHON拼凑起来的粗糙工具，需求稍一改变就不能满足，脚本的扩展性极差），他说他现在的工作基本上80%都能通过脚本完成，说完后直视我，貌似是等待着我的认可，出于尊重，我只好说那确实不错。接下来我就拿他写过的批量并发执行命令的脚本跟他深入聊了下，他说这个脚本是Python多线程并发的，1000台机器执行一次批量命令1分钟就能全部完成，我于是让他给我讲讲多线程与多进程的区别，在什么时候用线程或进程更合适，结果哥们说了很多废话也没有讲明白。然后我又让他用PYTHON多线程给我写个简单的生产者消费者模型，哥们愣是不知道这是啥东西？那我又问，如果你不知道生产者消费者模型是什么，那你的并发异步处理是怎么做的？哥们语塞说没在这方面做过深入研究，我于是又问了几个其它方面的问题，比如他的Ngnix 日志是如何分析的？自动部署如何跟git结合的？监控报警接口是如何优化才降低误报率的？但回答的都不理想，然后，就没有然后了….。   在这里我只能说，我不是想打击他，如果你只是写了几个脚本就声称自己就是自动化大拿了，未免有点牵强。所以他被PASS掉了，因为我觉得把他招过来，真的不会给我们公司的自动化水平提高多少!

 

 

 

面试B君：

应聘职位：运维自动化开发工程师，  工资不能低于16K

此君简历上说他擅长PHP\Python开发，在原公司做过运维自动化平台。我很感兴趣，让他讲一下他做的东西，主要是监控平台和CMDB资产数据库，让他着重讲了一下他的监控架构，他说他的项目主要是主动监控方式，就是监控服务器每隔一两分钟去轮巡一次所有的机器的SNMP接口，把各机器的基本系统性能信息抓回来，再通过RRDTOOL出图。他们有500多台机器散落在3个不同地区的机房，我问他你们这种做主动监控轮巡一次得多少时间？他说1分钟左右，我说如果轮巡过程中，如果有几台机器连不上怎么办？他说他的轮巡是并发的，连不上的不会影响其它机器的监控，我说但是你的线程池的线程个数是有限的，有几个线程因为机器连不上，那就会产生阻塞直至超时，但在超时之前这几个线程是不会再空闲出来的，因此肯定会导致整个轮巡时间的加长呀。哥们想了想说，确实存在这样的问题。然后我问他有没有考虑过用被动监控方式，就是让客户端自动汇报数据呢？他说当时他们也这样想过，但是一想到要在所有的机器上装个客户就觉得会增加复杂度，并且维护和管理不容易。我说采用被动模式确实会增加点复杂度，但会给你带来很多好处呀，监控客户端自动给你的服务器汇报数据会大大减少你主监控服务器的负载，并且可监控的东西要多的多呀，你还可以自定义插件，自动升级，并且还可以把监控客户端当做它用，比如自动化部署、任务下发等。可能是出于尊重，哥们假装同意了我的看法。

 然后我又问他们的项目是几个人开发的，他说算他在内有3个人一块做，我说那你们之前是如何协作的，比如接口互相是如何调用和约定的？他说基本上是每个人写自己的接口，互相之间约定好如何调用。我问那你们有没有遵循什么标准？比如是统一用http api还是其它的？接口格式是统一用Json还是用XML 或其它？哥们说他们有的用JSON、有的用XML。我说你们没有用restful标准吗？哥们表示没听过。。。。。OH，好吧！如果大家开发时都不遵循一定的标准和规范，我真心不知道他们的系统以后如何扩展，不知道这个哥们离职后谁还能看懂他的代码？不知道这种拿一堆随心所意写出来的脚本来拼凑起来的所谓的系统能满足多少实际需求？

 

 

面试C君：

应聘职位：运维工程师    工资要求11K

 

哥们刚工作不到2年就要11K，真比我当时工作了2年挣的多多了(即使去掉通货膨胀影响)，但如果技术好那也没有问题的。结果问了一堆基础问题都答不好，再要这些钱是否有点自不量力了？问他LVS，结果只是配置过，让他讲几种负载调度原理也讲不明白，问他平时怎么管理大量机器，他说用SaltStack 或自己批量写脚本，我问那你用脚本批量管理机器，是通过什么方式呢？他说是用SSH批量密钥登录，我说那你给我讲讲RSA密钥认证原理吧，他接下说的就是怎么通过ssh-keygen命令，怎么把公钥拷到客户端机器上等怎么实现密钥认证的过程。我打断他说我想听的是原理，不是认证方法，结果哥们一点都说不出来，接下来问的一些其它问题也是这样，只知其然，不知其所以然，最后我说，你这种情况我们给不了11K，如果低点你愿意考虑吗？哥们说不太会考虑，那。。。。好吧，只能打发他走了。

 

 

 

 

其它的一些面试者情况也好不到哪里去，一路十多个面下来，让我很失望，本以为过了这么多年以后，整个行业的从业素质会提高很多。但结果却还是老样子，所以大家可以想想业内大家都在炒的运维自动化到底实际有多水？如果从业人员技术水平都这样，还谈个妹自动化呢？自动化真的是写写脚本，再拿个开源软件拼拼凑凑下就完了吗？在我看来这撑死了只能叫辅助运维，不叫自动化，自动化应该是真正的开始让机器帮你监测问题＼发现问题＼处理问题＼解决问题＼自我修复＼自我维护＼自带干粮，各模块之间尽量低耦合＼可扩展＼可插拔。应该是真正能帮企业降低IT运营成本，使运营成本可视化＼可测量＼可对比，应该是真正能减轻运维人员的工作量而不是又制造一堆新的问题，应该是切合企业真正的实际需求做出来一些好用的工具和平台，而不是搞一些花里胡哨却最后扔在那里没人用的花架子（我自己在这方面就掉进过大坑，之前主导做的一个开源软件就是个失败案例）。　

 

总之最后给我的感觉是，会开发的不真正的懂业务逻辑，开发出来的东西没人用，会运维的开发水平又太烂，写出来的代码烂到哭。想找个真正合格的运维自动化人才真是不容易。

 

 

 

我近期一共只面了10多个，确实不能代表全行业水平，有些真正技术牛人估计我也没有碰到，但是10多个样本里面一个合适的都找不到，我觉得这也能差不多从侧面说明一个行业的整体平均水平了，这些求职者水平不高，却又想要高工资，我能说这是眼高手低、好高骛远的表现么？打铁还需自身用，如果真想要高工资，请先踏实点把自身技术水平提高，如果真想做架构师，那请把架构技术和思想学好，如果真要做自动化运维，请先把至少一门开发语言学好、学透，不只是会写个脚本就完了，脚本只是脚本，那不是自动化，So，哥们别再逗了！

 

希望此文能给业内小伙伴选择职业路径时提供帮助！

 

P.S: 我也不是什么大牛，只不过做好几年运维，做了几年自动化开发，大多数运维人员走过的路我都走过，上面写的这几案例在我自己求职时也发生过，我也是一个从月薪2500一路走过来的屌丝而已，我写这篇文章只是为了表达对这个行业的低质、粗糙、落后的现状吐槽一下，我也是这个行业里的一员，所以所有的问题也有我的一份， SO评论里骂我装逼的人我就不解释了，我这人就这风格，我写的其它文章比这篇可激进多了，So如果某些看官不喜欢，那就let it be 吧。 

 

 

 

补充：其实我上面面的这几个人，我都是可以把他们留下的，只是没有办法给他们期待的工资而已，论运维水平，A君要１８K，但我觉得他不值这些呀，我最多只能给到１５K以下，因为如果我校招一个２１１学校计算机毕业的研究生也就给１１-１３就可以了，再培养一年的话，相信运维＋开发水平都会比A君强很多！B君也是，一个连开发模式和标准都没搞明白的半调子程序员我能给他10K+就不错了，我现在手下的一个刚本科毕业的学生写出来的东西都比他强,有人说我对求职者要求太高，没有人什么都精通，我当然不要他什么都精通了呀，但是在我看来是一些基础性的、通用性的知识，如果你都不了解的话，在我看来只能算做不合格，不能说我要求高。　

 

 

 

 

下面附上我认为一些很好的问题，我回答了下：

---------------------------------------

问：我的问题不涉及技术原理,就是要问下运维工程师的工资怎么定的，一个熟练使用工具或者说自己写的脚本的人，起码是对运维这块有过多年经验的人，为什么不值18k，这类人的定位完全可以定位于一个可以干活的人，试问一个可以干活的人，怎么就不能值18k。如果招人都执着于原理，能干出活的人少，执着于原理何用，我绝对不是说懂原理的人不会干活。that's all

回复 花花工资hgz:

我很想认真的回答下这个问题，但一会我又要去面试一个人，所以只能简要回答了，我做过5年运维，2年开发到现在，你说的，在我看来，这个要18K的人就跟我最后2年做运维的时候情形是一样的，就是感觉自己什么都懂了，其实是什么都大概懂了，就像一个汽车修理工一样，干了好多年了，感觉什么车都会修了，车子出了问题很快就能修好。但是如果这个厂商把车造出来时就有技术缺陷的话，这个他是不会去关注的。因为他只会修车，再深入的比如说发动机的详细原理他是不知道并不关注的，他只能靠听声音来确定是不是发动机出了问题。 我觉得现在好多工作了多年的运维人员就是这种情况，工作多年也只是变成了熟练的修车工人，而自动化则是尝试改变修车行业的事情，熟练的修车工人不去多关注的话，那我是不看好他接下来的发展前景的，但一旦说到自动化，他如果只是自己闭门造车的话，可能造出来的又只是一个三蹦子，那怎么办呢？  在我看来，如果做运维时间久了，迷茫了，就应该想想如何提高自动化水平，多跟开发人员多学学开发模式，不要只满足于只是把各种开源软件和脚本拼凑起来就完了，做运维的如果只止步于运维，不去多想想如果做点创造性的东西的话，那你也就只能是一个运维。

--------------------------

问：是不是有些太矫情，运维最最重要的就是解决各种问题，原理，呵呵...

答：我看到很多类似的评论，觉得运维最重要的是能干活，能解决各种问题，那我们来讨论下什么叫能干活？什么叫能解决各种问题？ 把把各种服务配置好、业务运行稳定不出问题算不算能干活？当然算！但是你是花了多少的成本和代价让业务运行稳定了？这个问题你自己有没有衡量过？ 我买一堆F5，一堆豪华服务器让厂商把东西都给我配置好，出了稳定找厂商帮解决，这算不算能干活？一个优秀的运维人员能把负责的整个业务以最小的代价和成本管理的井井有条并努力尝试整个公司的IT管理环境，一个普通的运维会认为他也做到了这一点，但是是否真的做到了呢？谁知道呢？毕竟他自己相信了。

再说能解决各种问题，什么叫能解决各种问题？我相信大多数的运维人员所谓的解决问题就是处理各种故障，但不怎么涉及优化，尤其是业务级的、代码级的优化，运维通常只关注CPU、内存、负载是否过高，但业务非常慢怎么办？加CDN？加负载？加完后如果还是慢怎么办？如果确实是因为代码写的不好导致慢怎么办？想过没有？当然你可以说这他妈哪是运维的问题，这是开发写的代码烂导致的问题， 但是如果你能告诉开发是他的哪块代码的调用可能导致了业务变慢的话，是否能更凸显你的价值呢？当然如果只去解决一些常规问题也无可厚非呀，但那就不要老想着拿太高的工资了吧！

附赠在群里看网友讨论看到的一段不错的话：

 ----北京-菜菜左 2014/12/17 12:12:07
建议搞运维的还是要把计算机体系的基础知识打牢，万丈高楼平地起，基础很重要。看似没用只是因为你没学，所以你不知道学了是啥样。别人都说不重要只是因为大家都说不重要，也反映了运维行业的浮躁。不跟风不盲从，不迷信权威不吹水忽悠，走自己的路，不忘初心。这些话可能反对的人很多，就当我吹水吧。