哥们别逗 了,写个脚本那真不叫运维自动化! 【转载】

来源:互联网 发布:qq显示当前网络不可用 编辑:程序博客网 时间:2024/05/01 17:16

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

面试 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 ,哥们别再逗了!

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



0 0
原创粉丝点击