运维自动化的哲学

运维自动化的哲学

by purple_grape

last update:2013-12-05

   手工作坊和工厂的流水线是两种完全不同的生产模式。

   以服装生产为例，作坊工人参与了一个产品从无到有的全过程，又裁又剪又缝，每件产品都凝聚了她的全部心血，说的简单，她是一个裁缝，复杂点，她甚至是一个不错的服装设计师，可以为不同的顾客量身定制合身的衣服，她有着多年的从业经验；

   而流水线工人每天重复着少数的几个动作，他可能是个裁布的，或者剪线头的，他不关心产品制成后会是什上衣还是裤子，是什么款式，他只是个干活的，可能刚刚辍学上班。

   两种生产模式有着惊人的效率差距，除去人性化的部分，我们在追求效率的路上，必须采用标准化的分工以达到规模效应。对于系统运维来说，尤其应该这样。

   有了标准才能自动化，自动化了才算是标准。运维自动化应该由很多的标准模块组成，统一部署的操作系统、认证系统、管理系统、监控系统和备份系统。即使某一个模块的技术已经淘汰，也可以合适的新技术替换。

      首先，选用某个Linux发行版是很多CIO 的共识。如果windows和linux的异构部署不可避免，那么同时部署多个Linux发行版则是个愚蠢的选择。以历史经验看来，debian和redhat是市场首选，二者都是伟大的“母发行版”，很多其他发行版都是基于debian或redhat 。如果从易用和廉价的角度，ubuntu和centos也是不错的选择。

   其实采用Linux发行版安装已经是一个标准部署了，但是它的通用性太强，我们需要按照它的思路深度定制。因此系统部署坚持用deb或rpm二进制包，让那些编译狂人见鬼去吧！

   顺便说下运维和开发之间的冲突。目前网上充斥着各种编译的教程，完全都是误人子弟，甚至puppet这种自动化神器也难逃厄运。尽管官方不厌其烦的再三建议不要编译安装puppet。

典型的编译三步曲就是“tar zxvf  xxx => ./configure =>make&&make install"  ，无所谓精通不精通，除非对代码优化和编译器优化有很深造诣。

   编译教程里有个悖论，几乎每篇文章都号称使用的软件是“最新稳定版”，但实际上过不了几天，“最新稳定版”很快就过时了，菜鸟们依照这些教程将软件投入生产环境，后患无穷，手动编译且过时的软件版本，很快会在时间的淘汰下变得不安全，维护的成本也会越发高昂。

      世界从来不缺乏狂人，有编译癖好的多是开发人员，他们贪图一切让程序跑得更快更好的办法，比如索要更高的运行权限和更多的内存，从来不会用运维人员的角度考虑后续维护问题！

     尽管编译的性能通常更好（没有最好，只有更好，其实性能差异不大），也不是说运维人员不用懂编译，但是说实话，除非性能实在不堪忍受（为何又要犯贱用它呢,）【注：编译srpm包是另一回事】，性能调优也就是小修小补，不应该在前期考虑，典型的就是舍本逐末甚至缘木求鱼，总之，性能是开发人员最先考虑的问题，是运维人员最后才考虑的问题，术业有专攻。对于运维，标准和稳定才是王道，有了标准和稳定，持续维护才成为可能。

    精通编译说白了就是作坊里手艺精湛的裁缝，而规模自动化运维要求我们做个企业家。

   大家都知道，搞BSD和LFS的通常都是大牛，但是它们始终只是高手的玩具却不能占领市场。消费者都是聪明的懒人，有成熟现成的发行版，为何还要“再造轮子”呢？

   再说，无论是开发人员还是运维人员，水平都是良莠不齐的，有牛人也又菜鸟。有人会说，deb/rpm包也是开发人员打包的啊，我想说尽管人家也是打包的，但通常具有标准性甚至权威性，它们的特点是打包的思路完整、考虑周全，前后一致兼容，久经测试且方便升级，他们通常是软件作者或者官方（软件官方或Linux发行版）成员。

   退一步讲，以目前的情况而言，一个Linux软件连deb/rpm都没有提供，说明软件本身很不成熟或者有其他原因。苛刻一点，那么它就不应该出现在我们考虑的部署范围内。编译参数各异，各种定制脚本四处乱跑，这是需要预防和杜绝的。它显性的提高了维护难度，对于规模运维是十分有害的。

   总之，只有标准化的部署和运维才能拯救日益扩张的数据中心。在标准部署之后，不论是部署mysql数据库，还是web服务器上线，任务都变得十分简单，不用再去考虑其他因素。不论场合大小，标准化的部署总能让运维框架变得富有弹性。