标签：运维
从中华武术谈运维工程师以及运维自动化
任何事物都没有完美一说，但是我们可以死磕自己，追求极致...
无论我们现在是搬砖呢，砌墙呢，还是在逗自己混日子，我们需要关注的是自己的方向在哪里，而不是过于在意自己当前的所站的位置，人生不能受限于自己的意识。
平时和小伙伴们聊人生谈理想的时候，我会经常和别人讲我所认为的专业化运维工程师和运维工作的方向，有认可的也有不认可的，认可的多在努力让自己的工作越来越轻松，自己的价值越来越能得到体现，不认可者多属于一天都很忙，而且认为运维就是帮开发人员打打杂，做大量重复琐碎的事情。搬砖只是临时的，利用我们手头上的资源去打仗才是我们的努力的方向，所有人工手动操作的事情都是临时性的，运维的价值不在于你删除了多少日志，重启了多少次服务，写了多少个脚本，而是业务运营的可用率，而运维工程师的价值就是通过投入更少的成本保障业务更高的可用率。
这是一个极好的时代，也是一个极糟糕的时代，对于个人而言如此，对于我们从事的运维行业也是如此。极好表现在我们有着很多高大上的理念，各种超牛逼的开源技术，极糟糕表现在运维工作的门槛极低，从业人员专业素质层次不齐，大部分人从各种培训学习里面出来就去做运维工作。不是会装LAMP环境，不是学完RHCE,OCP,CCNP的培训课程就能成为一个合格的运维工程师，这些学完后只能算一只脚迈进运维的大门。还有很多人，这些人就在我们的身边，虽然不是从各种培训学校出来做网站运维工作的，但是时刻抱有一种想法，我学会某门技术或者去培训学校参加完某门培训课程就牛逼大发了，老板就得给我升职加薪，让我当上CEO，迎娶百富美，走上人生巅峰，运维工作对从业人员真得就是这么简单么，你掌握了某项技能，开发出某项工具，你当真天下无敌了么？
有人的地方就是江湖，现在一个行业又何尝不是一种江湖呢？运维当然也不出其外。
对于运维工作，我们应该往哪里走呢，无论ITTL还是ITSM这些高大上的理念都是为了指引我们如何达到我们的目标，那我们的目标是什么呢？
当我们还不能异口同声地说出运维工作的目标时，我们不妨可以向古人取取经，看看历史是如何告诉我们答案的。中华武术博大精深，异彩纷呈，当然不是影视里面吊着一根绳子飞来飞去，打起仗来框框响的那种。大道至简，殊途同归，无论你是哪家门派，所强调的要求和方法，最终极的目标是一致的，差异的只在表现形式。
通过武术看我们从事的运维工作：
1.入门只是基础，基本功不可荒废，如何做一个靠谱的美男子
基本功修炼的目的是减小我们和目标之间的差距，降低我们达成目标的难度。
一般在正式练武术之前，所有人都需要经历一段时间的基本功练习时间，什么扎马步，手提重物，倒立等等，这个阶段就是为以后做准备打基础。这个阶段的重要性在于如果基本功练到位而且时常练习的话，就会减少很多伤痛的可能性，而且能够更加容易达到之后更高难度动作对于身形的要求。
运维工作的基本功是什么呢，个人认为是做运维工作需要的最基础的知识，也就是各种培训学校能够教给那些对运维行业感兴趣或者基本功缺失人员的东西。
基本功只是入门前的准备工作，基本功练不到位不影响你去练习一门武艺，但是越练到后面感觉会越困难和痛苦。因为有了一定的功力了，反倒在重新连基本功就不太可能了。这就是为什么我们会经常碰到一些人，这些人有可能从业多年，但是有可能很多基础一问三不知。重要么，重要但是也不是非常重要，如果是某项基本技能或者一些基本常识，如果愿意去学应该也是很容易掌握的。之前看到某个搞培训的哥们写的一篇文章《哥们别逗了，写个脚本那真不叫运维自动化!》（内容拉仇恨过多，已被作者删除，内容贴于后文），道理是没错的，但是文中不乏“你怎么连这个都不会，你怎么连那个也不知道”，最后对应聘者一通“小样就你这点本事还敢要这么高的工资”，虽然自问达不到某些要求，看看别人要的工资，再看看自己感觉甚是惭愧。不过从文中和日常运维同行交流也可以看出，一方面说明，很多人基本功不扎实，问啥啥都知道一点但是啥都讲不清楚，一方面说明，很多人在招聘的时候搞不清楚什么是重点，什么是他们需要的，想着最好你什么都会。
很多人基本功没练好就去练功了，还有一些人基本功刚练好就以为自己已经是一个习武之人，更有甚者以为自己基本功做得足够好就已经天下无敌了，不少培训学校“XX时间学完XX，月薪XX不用愁”宣传的就是这种思想。
2.内功的修炼与外在的身形，如何做一个有深度的美男子
我们都应该从电视或小说中看到过过这样的场景，同样是修习一门武艺的两个人，师从一人，刚开始可能还打得难解难分，最终成败不在于招式的花样，而在于功力的深厚。
武术讲究的是内外兼修，不仅要练刀剑拳脚，还要练呼吸和反应能力，内在的功夫很多时候要比外在的身形更要重要，就像瑜伽的呼吸和冥想相较于标准动作是更应该被关注的，内在功力能让我们更加高效，轻松地完成外在的形体动作。做运维工作，我们“外在”的功力是一方面，“内功”的修炼也是很重要的一面，外在表现于我们做了什么事情，内在在于我们对于所做事情的方法理论和思考的总结。
运维人员的外在身形是什么呢？写个脚本，安装一个什么软件，排查一个什么异常可能是运维人员外在的身形。
运维人员的内在功力是什么呢？私以为，我们在学校里面学到的计算机理论，程序背后的运行原理，业务的架构设计亦或是沟通，归纳，抽象等我们看不到，无法量化，但是能够帮助我们更好地发挥我们的实力的东西是需要我们锻炼的内功。
有些人忽略了内功的修炼，就成为了给开发人员打杂的角色，自己能做的也就是安装下软件，排查下异常，写几个脚本。写个脚本，只能说明写脚本的能力强，仅此而已。
有些人过于强调理论的重要性，我们身边应该不乏这类人，道理说的头头是道但是怎么做他们就不关心了或者说他们就不知道了。
我们可以看到所谓的高手绝对是身形和内功都练到位的行家里手，身形好顶多就是所谓的三脚猫功夫，当然这样说可能会犯了很多人的忌讳，伤了很多人的心。
知其然，更要知其所以然。
与什么都知道相比，把一个东西搞清楚弄明白更值得去做。
3.十八般武器，工具的重要性，如何做一个秒杀疑难杂症，有效率的美男子
在影视中我们可能会看到这样的场面，某某大侠赤手空拳打败了一群手拿精良武器的敌人或者一个超牛逼的高手用刀剑挡开飞来的弓箭，这些有且只能在影视中出现，影视是夸张的，现实是开不得玩笑的。之前跟一个老师傅聊过，如何徒手跟拿一群武器的人打斗，及胜算有几何？老师傅说，你傻呀，碰到这种情况跑还来不及，怎么可能还去跟别人玩命。所谓刀枪无眼棍棒无情，乱拳打死老师傅，不是你功力不够，是玩法不一样了。有武器和没有武器那完全不是同一个层次，这是比拼的就不是实力，而是靠的是运气和技巧。
运维工作中，有工具和没有工具，有单一场景的工具还是平台化的工具，那更差异就更大了。运维的工具一般只能运维人员自己去打造了，一则大部分开发人员基本上不懂运维（能碰上像大众点评里面某些既懂开发又懂运维的开发人员，对很多人而言绝对是人生之幸），二则开发人员一般没有精力去维护运维工具，毕竟在一个以KPI为准绳的时代，很难要求开发资源的投入。如果招新人专门做运维开发，就存在第一个问题，如果让懂业务的开发人员去开发相应的工具就会存在第二个问题。最终只能运维人员自己去学习开发工具，这也就是devops的由来，也是以后的发展趋势。
目前大部分的公司，对于运维人员的人力成本投入方面要比业务开发人员少的多了，一般一个运维人员至少要应对多个业务，处理十几个以上开发人员的需求。如果不是专职做运维开发的运维人员，开发工具一般限制都比较大，由于投入的资源有限，那么开发工具就尽可能的要求可以多次复用，那么就要求工具的设计足够抽象，实施对象足够标准化，否则开发的工作量和设计的难度就会高出多个量级了，但是这又是现实所不允许的。
因此，在打造武器之前，要求我们的业务足够标准，无论是开发环节还是测试，运维环节，任何差异都需要额外的人力成本投入，也会加大处理问题的难度和增加无谓的工作量。
想想，你可能需要手动几个小时才能搞定的一件事情，有了工具你可能分分钟就搞定了，而且还不用返工。在足够标准的环境下，就像古代行军打仗，人就是最标准的环境，一个人和一万个人是没有差异的，有了工具（比如大炮）你就可以很高效的解决战斗。
敌人为我们造粮食和武器的场景在运维这里就不复存在了，而这所有一切，不能依赖别人，只能自己去做。
4.关于阵法：流程和协同组织的重要性，你不是一个人在战斗，如何做一个克敌制胜，无往不利的团队成员？
单兵战斗力强就能决定胜败吗？这里的单兵不是说那些小喽啰，像关羽这样的猛将也在所属之列。想当初关羽温酒斩华雄，最后也落得一个败走麦城的下场，可见单兵的作战力再强也强不过一个有组织的团队或者外部的轮番挑战。
在中国的武术中也有阵法的讲究，可能没有什么七星北斗阵这么吊炸天，在群战中也是非常讲究人与人的协同与互补的。在战争中自然就不必多说了，整体的战略其实就是一个大型的战阵思想的高度抽象，不同兵种的协同作战流程和组织之间的紧密配合。相信再牛逼的武林高手在正规的军队面前都得心惊胆颤，望风而逃，像赵子龙这种七进七出的事情，如果不是曹操下令活捉赵子龙的话，估计都不知道是什么下场了。
扯到运维的工作，其实也有很多相通之处。
个人能力再强，也强不过一个专业化，流程化，高度协同的团队，可能团队中每个人拉出来都不是很牛逼，但是加在一起就是一根筷子和一捆筷子的区别了。
运维应该是由意识（研发人员，包括产品，开发，测试，运维）+ 技术（提升效率，打造工具的关键）+流程（工具是流程的固化手段）
想一想，当业务环境能够在我们的努力下，保持干净，一致，极简，同时在流程固化下不断降低人力成本与人为的失误，极大消灭低级问题，真正碰到的问题是值得我们投入精力去付出的，这才是运维人员的价值所在。碰到问题解决问题，写脚本处理变更需求，解决告警问题，都只是一种低层次的手段，很多事情考虑在业务之前，事后需要做的事情就会少很多，这是运维人员的方向，也是目标。运维的角色被很多地方分为：操作型运维，开发型运维，架构型运维，很多人在操作性和架构之间苦苦挣扎，适时思考下，为什么会存在这种情况，就会明白自己该怎么去做了。
一个人的牛逼不是牛逼，一个团队的牛逼才是真牛逼。
5.关于流程自动化，当我们有了战略武器，所有的一切需要重新开始
一个程序的质量是从程序设计之初，写代码之前就决定的了，一个糟糕的程序设计，就算是再牛逼的程序员大婶估计也写不出什么好结果吧。同理，一个天生不良的业务，后天的运维工作做得再好也改变不了多灾多难，故障频发的现实，运维从业务的立项之处就要考虑业务的运维特性，当然如果这个业务只是写出来给老板秀秀功绩，那完全可以不用考虑。
运维工作的流程自动化涵盖了从代码的安全扫描到功能测试，部署到线上运营环境，性能和异常监测，故障的自愈，容量和健康度的反馈，程序的再次修改和业务架构的调整等。所有的环节尽可能减少人为的介入，只有流程出现异常时才需要人的介入，产生的经验应该时刻回馈到流程中，当下次碰到同样的问题流程自动化的工具可以依据经验自行处理掉，这也是故障自愈的一个基础思想。
如果一切都流程化，自动化，配套的工具都到位了，还要运维人员干什么？
可能有很多人会有此一问，我相信对此很多所谓的有经验的人会有一种深深的担心，这将会淘汰掉很大一批写写脚本，删删日志，扯扯淡的人，可能你我就是其中一员。
以前会计都是用算盘的，后来大家都开始用计算机了，使用算盘的就只剩下那些超级大牛了，大部分没有学会计算机，算盘用的一般的人都被社会变革淘汰掉了。任何事务都是在往前发展的，任何行业也将会从边缘行业成为主流行业，再从主流行业变为夕阳行业，有人主动去调整了然后不断适应外界地各种挑战，有人就死在这不断的变革之中，这一切都不以人的意志而转变。
当然，一切流程化和自动化都只是趋势，等真正完全实现流程自动化，我相信运维的玩法肯定和现在就完全不一样了,就如同在***时代，一切冷兵器时代的玩法就都玩不转了，剩下的就是那些高度抽象出来的思想，比如孙子兵法，那些排兵布阵，刀枪剑戟，战斗经验就统统被历史淘汰了，如果你不愿意被淘汰，看看晚清时代的历史你就知道那些用***去砍英法联军的***是什么下场了。
在这一切到来之前，我们需要做的是不断提升自己的意识以及影响他人的意识，运维不是打杂的，就跟建筑不是搬砖的同一个道理，不断提升自身的技术和能力，将整个业务流程化，然后打造出工具不断固化和完善已有的流程。
那些不思进取，不能接受挑战的，终将会被淘汰...
运维不会写代码，开发不懂运维，可能现在公司和人员看来无所谓，但是无论是云服务的到来还是自助创业，不懂开发的运维，不懂运维的开发，其结果都是一样的，就算你把是李刚，都是会被淘汰的。
人的意识，工具（技术），流程，结合起来，无往不利......
附录：《哥们别逗了，写个脚本那真不叫运维自动化!》
虽然很多说法有待商榷，但是有些看法还是值得我们思考的，写个脚本是真不能叫运维自动化，如此一说可能会伤害到很多运维兄弟的情感，但是我们要努力做到伤感情不伤面子不伤钱。
运维有做到刘天斯出书这样的，但是更多的是埋头瞎干的兄弟。
如果你是大牛，请忽略本文，如果你在埋头瞎干最好还是抬头看看天，好好思考下。
有感而发，所写纯属扯淡，看官们尽可一笑置之，切莫当真。
哥们别逗了，写个脚本那真不叫运维自动化!
原文地址：http://3060674.blog.51cto.com/3050674/1590803
2014-12-16 19:16:04
好久没写文章了，最近要来刷下存在感，近两年，运维自动化被炒的火的不行，行业趋势不可挡，现在企业招运维工程师都要求会一门开发语言。我们公司也不例外，由于刚上市，一下子有钱了，开始招兵买马瞎折腾，因此最近我也面试了不下十来个求职者，本成想可以很容易招到几个不错的小伙，结果却令我很失望，今天贴几个面试者例子上来，跟大家吐槽下：
面试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 吧。
下面附上我认为一些很好的问题，我回答了下：
---------------------------------------
问：我的问题不涉及技术原理,就是要问下运维工程师的工资怎么定的，一个熟练使用工具或者说自己写的脚本的人，起码是对运维这块有过多年经验的人，为什么不值18k，这类人的定位完全可以定位于一个可以干活的人，试问一个可以干活的人，怎么就不能值18k。如果招人都执着于原理，能干出活的人少，执着于原理何用，我绝对不是说懂原理的人不会干活。that‘s all
回复 花花工资hgz:
我很想认真的回答下这个问题，但一会我又要去面试一个人，所以只能简要回答了，我做过5年运维，2年开发到现在，你说的，在我看来，这个要18K的人就跟我最后2年做运维的时候情形是一样的，就是感觉自己什么都懂了，其实是什么都大概懂了，就像一个汽车修理工一样，干了好多年了，感觉什么车都会修了，车子出了问题很快就能修好。但是如果这个厂商把车造出来时就有技术缺陷的话，这个他是不会去关注的。因为他只会修车，再深入的比如说发动机的详细原理他是不知道并不关注的，他只能靠听声音来确定是不是发动机出了问题。 我觉得现在好多工作了多年的运维人员就是这种情况，工作多年也只是变成了熟练的修车工人，而自动化则是尝试改变修车行业的事情，熟练的修车工人不去多关注的话，那我是不看好他接下来的发展前景的，但一旦说到自动化，他如果只是自己闭门造车的话，可能造出来的又只是一个三蹦子，那怎么办呢？ 在我看来，如果做运维时间久了，迷茫了，就应该想想如何提高自动化水平，多跟开发人员多学学开发模式，不要只满足于只是把各种开源软件和脚本拼凑起来就完了，做运维的如果只止步于运维，不去多想想如果做点创造性的东西的话，那你也就只能是一个运维。
--------------------------
问：是不是有些太矫情，运维最最重要的就是解决各种问题，原理，呵呵...
答：我看到很多类似的评论，觉得运维最重要的是能干活，能解决各种问题，那我们来讨论下什么叫能干活？什么叫能解决各种问题？ 把把各种服务配置好、业务运行稳定不出问题算不算能干活？当然算！但是你是花了多少的成本和代价让业务运行稳定了？这个问题你自己有没有衡量过？ 我买一堆F5，一堆豪华服务器让厂商把东西都给我配置好，出了稳定找厂商帮解决，这算不算能干活？一个优秀的运维人员能把负责的整个业务以最小的代价和成本管理的井井有条并努力尝试整个公司的IT管理环境，一个普通的运维会认为他也做到了这一点，但是是否真的做到了呢？谁知道呢？毕竟他自己相信了。
再说能解决各种问题，什么叫能解决各种问题？我相信大多数的运维人员所谓的解决问题就是处理各种故障，但不怎么涉及优化，尤其是业务级的、代码级的优化，运维通常只关注CPU、内存、负载是否过高，但业务非常慢怎么办？加CDN？加负载？加完后如果还是慢怎么办？如果确实是因为代码写的不好导致慢怎么办？想过没有？当然你可以说这他妈哪是运维的问题，这是开发写的代码烂导致的问题， 但是如果你能告诉开发是他的哪块代码的调用可能导致了业务变慢的话，是否能更凸显你的价值呢？当然如果只去解决一些常规问题也无可厚非呀，但那就不要老想着拿太高的工资了吧！
附赠在群里看网友讨论看到的一段不错的话：
----北京-菜菜左 2014/12/17 12:12:07
建议搞运维的还是要把计算机体系的基础知识打牢，万丈高楼平地起，基础很重要。看似没用只是因为你没学，所以你不知道学了是啥样。别人都说不重要只是因为大家都说不重要，也反映了运维行业的浮躁。不跟风不盲从，不迷信权威不吹水忽悠，走自己的路，不忘初心。这些话可能反对的人很多，就当我吹水吧。
本文出自 “运维者说：从菜鸟到老鸟” 博客，请务必保留此出处http://liuqunying.blog.51cto.com/3984207/1596186
标签：运维
原文地址：http://liuqunying.blog.51cto.com/3984207/1596186
