关于DevOps的一些误解

关于DevOps有一些常见的误解，在这里做一下简单的整理和讨论。

DevOps == 工具的自动化

这种思维相当常见，自动化确实在DevOps中非常的重要。正如推动DevOps运动的标志性事件之一的Flickr的每日10+的部署的经验来说，也提到了Automation的重要性，“如果只有一件事情能做，那就做自动化”的类似共享也有提及，所以自动化的作用不言而喻。
自动化提高了生产效率，减低了手工操作的失误率，消除了多个部门协调和沟通的制约因素，可以同时降低处理时间以及等待时间，而且有实实在在的总多工具的支持，在整个DevOps实践中起到非常重要的作用。
但是这并不是全部，DevOps包含了People/Process/Technology/Culture等诸多因素，作为一种最佳实践的方法论的组合，工具的自动化是其中的一部分，但不是全部。

DevOps == NoOps

在很多项目DevOps实践中，原本运维在做的事情都工具化和自动化了，所以在很多人看来DevOps的作用之一就是为了砸运维的饭碗的。他们的理解就是DevOps是通过自动化承担了原本运维作的很多事情。确实，很多时候DevOps实践中会让Dev承担很多代码部署等的责任，但是这并不意味着不再需要运维了，相反，实施了DevOps之后的团队会发现开发和运维的紧密连接是以往从未有过的，正确地来说，是解放了运维。
所有的这一切，其实都是在精益在软件开发全生命领域的实践体现，进行了很好DevOps实践后，浪费之一的等待将会得到很大的改善，很多运维服务通过自动化变成了自助服务，降低了等待时间，极大地提高了效率。

DevOps只适合于开源项目

DevOps在很多开源项目中推行地很好，而且很多DevOps用到的工具本身都是开源的。但是这并不意味着DevOps只适合于开源项目。就像不能说精益只能实践于制造业是一样的，DevOps作为一种综合的方法论，它适合于开源和闭源的项目，这并没有特别大的区别。

DevOps只适用于初创公司

我们能看到很多DevOps在初创公司成功的例子，相比而言传统的大型的公司的比例似乎并没有那么多。其实这跟DevOps的关联并不一定有这么大，并不是每一家公司都能成为百年老店经久不衰。根据统计：1955年的500强公司的87%已经消失。缺乏创新的能力以及改变的魄力，企业的衰败像人类的生老病死一样难以改变。
而且这一速度仍然在加剧，1958年 500强的公司平均寿命为61年，而现在只有18年。而DevOps只是诸多变革方式中的一种，无论是初创公司还是大型传统公司，使用DevOps获得成功的都不在少数。所以，DevOps是一种能力，放在那里，用或不用，你有选择的自由。

独角兽公司生来就具有DevOps能力

传统公司问题重重，而那些独角兽公司看起来却风光无限，Amazon据说能够每天部署上万次。而且好像他们生来就具有DevOps能力一样。而实际上，独角兽公司作为从众多初创公司中脱颖而出的一群，其他所有公司碰到的阵痛，他们也一样未曾落下。

时间 公司 事件 2001年 Amazon 在2001年之前一直使用OBIDOS系统交付，问题重重难以为继 2009年 Twitter 对其ROR系统进行逐步重构并替代该系统，耗时多年 2011年 LinkedIn IPO后六个月，在部署上吃尽苦头，冻结两个月功能，彻底检修环境/部署和架构 2009年 Facebook 基础框架近乎崩溃，代码部署日益危险，员工不停救火。展开改革后才改变状况

好汉打掉牙或血吞，曾经的勇气和魄力，换来的是现在的一时风光无限，自我改变和革新才是一切的根本。