运维自动化不是每个人都认可的，作者认为运维的工作量并没有随着企业需求越来越复杂而变大，就算变大也不是靠自动化能解决的体力活。
运维自动化是2010年开始炒得很热的一个概念，也让很多工程师、用人单位瞎激动了很久，我也跟风学过puppet和python，求职双方也经常在面试时花大量时间谈运维自动化。
但冷静下来想想，所谓自动化，只是让培训机构赚钱的噱头而已。
一句话概括运维自动化
单说“运维自动化”几个字太抽象容易被主观塞进去很多概念，上百科搜索到IT运维自动化的介绍又太详细、大帽子太多。
如果把运维自动化在一句话说清楚，比较官派的说法就是：“运维自动化就是在企业业务越来越复杂、对IT人员要求越来越高……balabalabla……的前提下，靠人工已经无法满足运维工作的需求，只能靠自动化技术来解决这一问题。”
如果用比较粗糙的说法就是“活多人少的情况下，运维不想靠堆人力去解决繁琐的问题，只能靠运维自动化来给自己减负。”
运维自动化理论与现实相悖
粗看这些理论挺有道理，但仔细分析根本不是这么回事。首先，我们真的忙了吗？
我认为运维的工作量并没有随着企业需求越来越复杂而变大，就算变大也不是靠自动化能解决的体力活。
运维自动化是给运维用的，请各位运维想想，我们的日常工作，这些年来有太大变化吗？
初级运维大部分时间在做上线和监控，高级运维在改结构修bug。对于那些重复性的工作，云计算供应商能比你做的更好，云主机、云监控、云RDS、云存储等等服务都是在给运维减负。
企业业务需求越来越复杂是真的，具体来说是技术进步企业要求越来越刁钻了。数据库要求主从实时同步，存储不能用NFS要用分布式，前端业务要求无缝切换等等。我是不是谈偏题了，这些东西跟运维自动化有什么关系？你意识到问题就好，我们这些年新增的业务需求，没多少是可以靠运维自动化解决的，要解决这些问题，还要靠我们自己的脑子。
运维自动化=shell脚本
其实我们一直在做运维自动化，因为我们会用shell脚本。
我们可以说只要企业需求有变动，我们就要搭服务、搭监控，做这些事情都要写自动化脚本。当你激动的说到“自动化脚本”的时候，我想问一下，你不会写shell脚本吗？
搭完某个服务以后，一个有经验有责任心的运维，自然会写好系统优化脚本，复制监控监控模版。如果我们用puppet，用python，最后一样脱不了指定主机名的工作。
我们完全可以用shell脚本完成各种模拟运维操作的动作，熟练使用shell脚本也是每个运维的必修课，我们有必要为了一个噱头去学习python吗？
我曾经看过puppet的官方文档，他能管理的资源列出来的有“文件”“属主属组”“挂载”“软件包”“服务”“-exec使用本地shell”，在我看来其实也就是“文件”和“-exec”。
在linux shell脚本里，关于运维有这么多命令“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命令是一个我能接受的、可行的方案”。
我们应该减少盲从，拿起最顺手的工具去做一番事业，而不是玩赏最精美的道具却迷失了目标。
本文出自 “让技术做的更清晰” 博客，请务必保留此出处http://caoyameng.blog.51cto.com/4975863/1359732
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
