做个运维精英有多难？
做个运维精英有多难？
运维工程师，在英文里面名为 “Operations Engineer”，看字面意思，貌似就是操作服务器、管理系统的工程师。百度百科给出的说法是，集合网络、系统、开发工作于一身的“复合性人才”。一般可以根据工作内容的不同，把它分为两个大类：Ops 和 DevOps。Ops 即运维，DevOps 即开发运维。顾名思义，开发运维则比运维多了开发、写代码方面的工作。那么怎样才能成为一个月薪过万的运维精英呢？一线城市、大学学历更容易实现一线城市的薪水更高一线，无忧精英网上运维工程师职位中，一线城市的职位占了69%。在二线城市想做枚月薪过万的运维工程师，则需要较高的技术水平，去到一些知名大公司。大学学历是起步要求，66%的岗位要求本科及以上学历。运维工作对高学历要求不多，几乎没有职位要求硕士或以上的学历。加分技能才是精英传送门基础技能精通C/Python/Perl等1至2种编程语言熟练掌握常用数据结构和算法，并能灵活运用熟悉网络基础知识深入理解Linux操作系统加分技能熟悉开源的监控平台工具，比如：Ganglia、Nagios等熟练掌握Shell脚本熟悉Awk、Sed等基础工具熟悉分布式计算或者存储系统，比如Hadoop/Hbase/Storm等熟悉机器学习原理能付诸实践者更佳熟悉TCP/IP、HTTP等网络协议，精通socket网络编程运维所涉及的知识面、专业点非常广，加分技能掌握得越多，薪水也会越高。从无忧精英网上的开发运维职位看，多数年薪超过20万，多的则能达到40-50万。越老越值钱 经验相当重要运维是个吃经验的工作，看经验给薪水相当明显。年薪过万的运维工程师岗位中，高达77%的岗位要求3年以上工作经验。另外，有过中大型系统运维工作经验的常能获得更高的薪水都说运维是个遇坑、填坑、再遇坑、再填坑无限循环的工作，每次从自己了解不够深入，或不够细心所留下来的坑里爬出来都是一次经验的积累。这些吃过的亏、爬过的坑，每一个都算数，最后成就了一枚成熟的运营工程师，也成就了更高的薪水。杠得住压力 加得了班对于运维来说，线上稳定大于天，任何风吹草动都得赶紧处理，日常工作有点“消防队长”的感觉，加班，半夜被叫起也时有发生，上下班没有明确时间，必然是十分辛苦。遇到网站的某个重要节点挂了，压力全部堆到运维身上，如何在紧急之中找出问题并及时解决，除了过硬的技术及丰富的经验，过人的心理素质也是最重要的因素之一。想成为运维精英除了广泛吸收打好基础，还需要找到今后要走的路，抓住一个方向深入，再配以大局观和全局视角从而成为一枚牛逼的运维工程师。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
百家号 最近更新：
简介: 主要以时尚、IT、科技。
作者最新文章验&&证&&码：
当前位置： &
我现在在一家汽车工装企业上班，大概一年的时间里在给公司做ERP项目，从流程整理到ERP使用培训及编写说明书。也想转入SAP行业，今年28岁了，材料学硕士毕业，跟计算机一点都不搭界的，数据库也没有学过，只是有点SAP BYD实施经验。不知道是否可以转行进入此行业~~
将回答分享到微信
继续做ERP，直到你有做到对你的技能要求不是很高
将回答分享到微信
技术好就等机会，erp很多还是相通的
将回答分享到微信
就职业规划而言，如果想转行做SAP开发就必须一切从头开始，积累经验。另一条线是继续做ERP，我个人更倾向于继续做ERP的开发和运维，纵向深度上您有优势。
将回答分享到微信
SAP的开发您多指的是，插件或外围开发吧？您的职场经理，我建议职场选择应该向前段序列转型。如果不是去SAP原厂的化。或可尝试集合朋友和资源做SAP项目周边的自由开发者或组件咨询公司承接SAP项目。
将回答分享到微信
看机会吧~从小职位做起~~
将回答分享到微信
IT技术发展日新月异，如你对自己未来有更多期望可以转，毕竟年轻可以学习去做，继续做ERP那就做成资深做成行家，开发与运维未来转入去做需求分析走规划专家是条路子。
将回答分享到微信
看机会，要实在心里难受就去寺庙拜拜
将回答分享到微信
只能从小职位开始，现在的技术类工作愿意接受一个没有经验的人的机会很少
将回答分享到微信
继续做ERP，直到你有做到对你的技能要求不是很高，而是对的思维能力，管理能力要求高的时候，你就可以任意转换；现在也可以转，除非有特别好的机会，或者你重新开始
将回答分享到微信
技术好就等机会，erp很多还是相通的
将回答分享到微信
这个要看机会了。。。
将回答分享到微信
找不到满意答案？没解决问题？
点下方按钮开启问答新篇章
大家都在搜帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:4&分页:Bible发信人: praisestream (Bible), 信区: Career_Plaza
标&&题: 银行科技部的offer，是选择做开发好，还是做运维好啊？
发信站: 水木社区 (Fri Dec&&7 21:41:32 2012), 站内 && RT
-- && ※ 来源:·水木社区 ·[FROM: 118.186.58.*]
上局沪段T103/4发信人: johnbird (上局沪段T103/4), 信区: Career_Plaza
标&&题: Re: 银行科技部的offer，是选择做开发好，还是做运维好啊？
发信站: 水木社区 (Fri Dec&&7 21:45:38 2012), 站内 && 开发好一点，运维没什么技术含量
【 在 praisestream (Bible) 的大作中提到: 】
欢迎光临 RailWay/铁路 版 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 166.111.139.*]
兽神官－Xelloss发信人: Torigo (兽神官－Xelloss), 信区: Career_Plaza
标&&题: Re: 银行科技部的offer，是选择做开发好，还是做运维好啊？
发信站: 水木社区 (Sat Dec&&8 00:15:08 2012), 站内 && 一看就是没做过运维的，银行运维技术还是挺好的
当然比开发辛苦，系统上线一般都是半夜加班 &&&&&& 【 在 johnbird (上局沪段T103/4) 的大作中提到: 】
: 开发好一点，运维没什么技术含量
&&&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 123.116.120.*]
耗子发信人: hicer (耗子), 信区: Career_Plaza
标&&题: Re: 银行科技部的offer，是选择做开发好，还是做运维好啊？
发信站: 水木社区 (Sat Dec&&8 10:44:07 2012), 站内 && 一看就是不懂运维的，我就是从开发转到运维的，现在某国有银行数据中心，运维虽然辛苦但总体比开发还是要轻松点的，没有上线变更的时候还不算忙，基本能准时下班，开发的基本不可能吧 && 【 在 johnbird 的大作中提到: 】
: 开发好一点，运维没什么技术含量
:&& && -- && ※ 来源:·水木社区 ·[FROM: 117.136.1.*]
文章数:4&分页:中国领先的IT技术网站
51CTO旗下网站
亲身经历：远离培训机构才能做好运维
如今，运维自动化热潮如火如荼，puppet和python风靡运维行业。但其实运维自动化是一个很鸡肋的技能，就像屠龙之术一样，对大部分人来说，是无龙可屠的。本文中作者老曹就运维自动化技术热潮的现象发表了自己的看法，欢迎各位小伙伴们拍砖。
作者：老曹来源：| 09:37
【编者按】本文作者老曹，在车联网、互联网、通讯等行业都有丰富的运维工作经验，在热潮如火如荼之时，他幽幽的说了这句话：&如果你入职第一个月就被要求设计部署自动化方案，那只能证明这个公司确实没有运维人才，且这个公司很闲其实不需要运维。&
早在2010年，老曹就开始了puppet运维自动化之旅，但他逐渐了解到运维自动化是一个很鸡肋的技能，就像屠龙之术一样，对大部分人来说学会了很炫的技能，但是无龙可屠。现在的自动化运维都有很大的忽悠成分，大公司请个外来户搞自动化几乎不太可能，小公司就那么两台机器，做运维自动化更是浪费人力。老曹希望做运维的小伙伴们不要沉迷于自动化培训的热潮上，而是把更多精力用在技术浪潮上&&只有这样才能真的提高竞争力，故而写下了此文，给大家做个参考，纯属个人建议，欢迎拍砖。
运维自动化是2010年开始炒得很热的一个概念，也让很多工程师、用人单位瞎激动了很久，我也跟风学过puppet和python，求职双方也经常在面试时花大量时间谈运维自动化。
但冷静下来想想，所谓自动化，只是让培训机构赚钱的噱头而已。
一句话概括运维自动化
单说&运维自动化&几个字太抽象容易被主观塞进去很多概念，上百科搜索到自动化的介绍又太详细、大帽子太多。
如果把运维自动化在一句话说清楚，比较官派的说法就是：&运维自动化就是在企业业务越来越复杂、对IT人员要求越来越高&&balabalabla&&的前提下，靠人工已经无法满足运维工作的需求，只能靠自动化技术来解决这一问题。&
如果用比较粗糙的说法就是&活多人少的情况下，运维不想靠堆人力去解决繁琐的问题，只能靠运维自动化来给自己减负。&
运维自动化理论与现实相悖
粗看这些理论挺有道理，但仔细分析根本不是这么回事。首先，我们真的忙了吗？
我认为运维的工作量并没有随着企业需求越来越复杂而变大，就算变大也不是靠自动化能解决的体力活。
运维自动化是给运维用的，请各位运维想想，我们的日常工作，这些年来有太大变化吗？
初级运维大部分时间在做上线和监控，高级运维在改结构修bug。对于那些重复性的工作，云计算供应商能比你做的更好，云主机、云监控、云RDS、云存储等等服务都是在给运维减负。
企业业务需求越来越复杂是真的，具体来说是技术进步企业要求越来越刁钻了。数据库要求主从实时同步，存储不能用NFS要用，前端业务要求无缝切换等等。我是不是谈偏题了，这些东西跟运维自动化有什么关系？你意识到问题就好，我们这些年新增的业务需求，没多少是可以靠运维自动化解决的，要解决这些问题，还要靠我们自己的脑子。
运维自动化=shell脚本
其实我们一直在做运维自动化，因为我们会用shell脚本。
我们可以说只要企业需求有变动，我们就要搭服务、搭监控，做这些事情都要写。当你激动的说到&自动化脚本&的时候，我想问一下，你不会写shell脚本吗？
搭完某个服务以后，一个有经验有责任心的运维，自然会写好系统优化脚本，复制监控监控模版。如果我们用puppet，用python，最后一样脱不了指定主机名的工作。
我们完全可以用shell脚本完成各种模拟运维操作的动作，熟练使用shell脚本也是每个运维的必修课，我们有必要为了一个噱头去学习python吗？
我曾经看过puppet的官方文档，他能管理的资源列出来的有&文件&&属主属组&&挂载&&软件包&&服务&&-exec使用本地shell&，在我看来其实也就是&文件&和&-exec&。
在脚本里，关于运维有这么多命令&cp、scp、nc、ssh、rsync、svn、chmod、chown、service、/etc/init.d/&，这些命令已经够用了。
我用puppet的时候，只是用他频繁监控几个重要的系统配置文件。上线的工作真正繁琐在要把realserver从LB上摘下来，且需要用人力去判断能不能摘。
具体摘设备、传新备老代码、重启java容器、回滚代码的工作我都写好脚本了，就这样还因为麻痹大意而出了几次高负载或丢步骤的情况。
如果能运维自动化的东西，必然能写shell脚本搞定，如果用shell脚本搞不定的东西，&运维自动&&挂&。
运维自动化&优化
老生常谈，运维应该眼界高一些，不要总是忙着优化手头的工作，而要想手头的工作有没有必要。
有朋友肯定要说我的工作不到家，上线居然还需要人力判断，我承认这是问题，但这问题在架构不在运维。如果上线不需要人工干预，为什么不直接让开发执行？甚至更进一步，让应用服务器定期去svn上检测有没有新代码？在测试环境我们也会用hudson和maven让开发自己搞，但我肯定做好一个系统镜像保证他们把系统玩坏了也能快速恢复。
在生产环境里，运维该做的不应该是纠结一步人肉操作该用shell还是python代劳，而是说好好去推动一下，能不能多上几台服务器，能不能降低一下耦合度，不要让我们手动盯着上线工作了。
我现在的公司后台做的不好，很多业务相关的sql修改都要开发写好语句给运维执行。如果这个时候我给mysql安装个phpadmin就是本末倒置，写个脚本能自动传sql过去还是本末倒置，我实际该做的是催促公司尽快做出来企业管理后台可以让运营和客服人员直接去改业务数据。
我们写多少牛逼的python脚本，不如做一个稳定到单机房断电都不会宕机的架构；用好运维自动化很牛逼吗？是的，就跟用好某种文本编辑器一样牛逼。
运维自动化背后的利益推动
鼓吹自动化的大师里，很多位其实是运维开发两条腿都很短的杂鱼。
我曾经看到过一个运维自动化的教程，作者很认真的教我们，如何用某种自动化工具调用本地shell，用sed命令将crontab里的ntpdata任务时间给变更了。看到这一段，我被他的执着蠢哭了，所谓的自动化居然是用ntpdate更新系统时间。
我也见过某大师写的自动化代码，朋友告诉我他的python水平只值6k&&连异常都不处理，我用半瓶醋的水平仔细看了一下他的源码我真的笑出来了，每隔几行必然能看到一个os.system(&shell命令&)。
在工作环境里，我用&tar/var/aaa/bbb/ccc/*.jpg&这类通配符匹配出来目标文件，写了个10行的脚本，将某高手用perl写了100多行，但其实就是find+tar的脚本给替换掉了。
在处理数据的时候，我也写python脚本，因为效率远超shell脚本。但运维自动化一定要用python脚本，更新文件必用puppet，对高手来说这是风格，对新手来说这是跟风。
有心的朋友可以帮忙查一下，从2010年开始，都有哪些培训机构新增了运维自动化课程或python运维课程，又有哪些人靠这些技术把自己包装成了大师。
运维自动化的困境
那些高端大气上档次的运维自动化教师们，永远无法回避我这两个问题：
1、在一个100台机器下的小公司，搞运维自动化是不是在自己立项冒功？你写好的运维自动化系统，是不是配合着把文档写的很细很好了，会不会系统升级一下就运维自动挂了。
越是小公司，越容易出现单台机器跑多个业务、不同机器的环境变量完全不同的情况。假设你是个技术新兵，不用自动化只会挂一台机器，用自动化挂一堆机器；假设你是个技术高手，你知道其中的风险更不会盲目的信任一个脚本。
2、在500台机器机器以上的大公司，确实很需要运维自动化，否则光是手动画网络拓扑图和加监控就能累死人。
但在这个环境里，最重要最有含金量的是系统架构的设计和演进；运维自动化只是减负的工作而已，哪有聪明人放着金砖不要却要板砖的？
你觉得有没有可能这个公司几十个技术高手天天为上传个js文件累的要死，就等你一个空降兵来部署自动化系统解救他们的？
做运维自动化，必然是自己公司内部的服务器有大量增加，增加到你觉得手动操作很累的地步，这个时候做运维自动化是水到渠成的。但运维自动化的工作一般是企业内部已有的运维来推动的，这不应该当作招人的理由。
运维自动化也不是简单的写一些脚本或部署文件同步工具，它没有真正成型的方案，因为这是要用机器模拟运维工程师的劳动方式。每个运维团队的工作风格都不同，生搬硬套外来的自动化方案只会让我们邯郸学步举步维艰。
如果你入职第一个月就被要求设计部署自动化方案，那只能证明这个公司确实没有运维人才，且这个公司很闲其实不需要运维。
重新审视运维自动化
运维自动化的目的，放低端点，就是解决运维手动操作容易出错的问题，放高端点是希望运维忽略具体命令而更重视最终成果。
在低端领域，我们可以很自信的说，用shell脚本就是运维自动化；在高端领域，肯定已经搭建好了自动化环境供我们观摩学习和修改；如果你有幸参与到大规模自动化部署，那是确实是一次很有趣的挑战；在一个更高的层次上，你会发现诸如系统标准化、应用模块化、统一认证系统等等更有价值但没人炒作的技术。。运维自动化不用专门去学习，自动化的&大师&也不用刻意招聘。
最顺手的工具就是最好的工具
IT人热爱某个技术就应该成为某项技术的主人而非信徒；我在文中多次强调shell脚本的可用性是因为shell脚本是每个运维必须掌握的技能。
在本文中我大量引用了对时下最热门的几个自动化运维工具的一些批评案例。但这些样例并不是用来攻击这些技术本身。事实上我Puppet应用QQ群是我唯一一个没有退出的Linux技术群，而我明白自己的Python水平看复杂的代码都费力。只因为这两个技术被野风吹的最火，我用他们来说明每杆大旗下都少不了盲从的人。
如果你坚信某个技术是特别强悍的并对我的言论怒火中烧，请你想想你能用你的工具做到的事情，在我的环境里能不能提前绕过，就算碰到了我能不能用shell脚本解决掉。我并不反对你推广你的方案，但我认为&循环调用SSH命令是一个我能接受的、可行的方案&。
我们应该减少盲从，拿起最顺手的工具去做一番事业，而不是玩赏最精美的道具却迷失了目标。
原文链接：
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条热点头条热点
24H热文一周话题本月最赞
讲师：132417人学习过
讲师：145342人学习过
讲师：228051人学习过
精选博文论坛热帖下载排行
本书论述了软件开发价值增加的思维方式。这一思维方式构成了VSTS的基础，包括VSTS的指导思想，为什么这些指导思想会以某些方式表现，以及它...
订阅51CTO邮刊