你听说过DevOps一词，或者听说过敏捷运维这个运动么？人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。传统的工作流程中，开发和运维之间存在很多的沟通错位而造成部署上的问题，由此，DevOps理念应运而生。
【51CTO精选译文】如果你对IT管理感兴趣，尤其是对Web运维感兴趣，那么最近一定会注意到“DevOps”这一热词的出现。现在#DevOps标签频繁出现在微博客Twitter上，同时DevOps相关的技术交流聚会也在慢慢增多。
在许多方面，DevOps是一个集合性概念，指的是能够理顺开发和运维之间相互配合关系的任何事物（51CTO编辑注：在英文中，Developer指开发者，Operations指运维，所以DevOps一词本身含有开发+运维的意思）。但是DevOps背后的理念要比上述说法更深远。
什么是DevOps？
人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。
正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。
开发与运维之间的“混乱之墙”
以开发为中心的人通常认为，变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。
而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。我们已经多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变（根据51CTO之前进行的调查，很多时候，仅仅是给系统应用补丁就会造成生产服务器无法正常重启）。
开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。的确，孤立的来看他们都是正确的。
更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同管理者的和竞争关系，而且通常工作在不同的地点。
开发与运维通常工作在不同的地点
让混乱之墙更坚固的还包括开发和运维工具之间的错位。看一下开发者要求和日常使用的常见工具，再看一下系统管理员，你会发现两者存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然；而且两部分工具之间也不存在重要的集成。即使在某些工具类型上有一些重叠之处，使用方式也完全不同。
开发与运维常用工具的不集成
当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在则将变得更加明显。有人将其称为一个“版本发布（Release）”，有人则称其为一次“部署（deployment）”，但有一件事情是公认的，问题可能会随之而来。下图虽然是一个抽象化场景，但是如果你经历过这一过程，一定会感觉到它的真实性。
应用程序变动从开发到运维
开发人员把一个软件版本“扔”给墙对面的运维人员。后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们重复在此前环境中已完成的工作；而糟糕的情况是，他们将引入或发现新的漏洞。
运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。当然，期间如果发生一个问题，开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题。而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。
没有一个可靠的方式来把环境回滚到此前已知的正常状态。本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。
本来应该一帆风顺的部署过程最后变成一场救火行动
部署阶段已经非常明显的需要DevOps理念来解决问题，但需要DevOps的绝不仅仅是这一阶段。正如约翰·阿尔斯帕瓦（John Allspaw）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。
DevOps所带来的好处
DevOps是一个非常强大的概念，因为它可以在众多不同层面上产生共鸣。
从开发或运维的一线人员的观点来看，DevOps可以让他们从众多烦恼中解脱出来。它虽然不是具有魔力的万灵药，但是如果你能够让DevOps奏效，则会节省大量时间，而且不至于打击自己的士气。显而易见，投入精力将DevOps落到实处，我们应该会更加高效、更加敏捷和减少挫败感。有些人可能会反驳称DevOps是一个遥不可及的目标，但这并非说我们不应该去尝试实现它。
DevOps会节省大量的时间
对于企业来说，DevOps直接有助于实现两个强大战略性企业品质，“业务敏捷性”和“IT融合”。它们可能不是IT人士所担忧的事情，但是却应该获得掌握财政大权的管理者的注意。
IT融合的一个简单定义是，“企业渴望达到的一个状态，能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力。”
通过从共同企业目标角度出发来校准开发和运维的职责和流程，DevOps有助于实现IT融合。开发和运维人员需要明白，它们仅仅是一个统一业务流程中的一部分。DevOps思想确保个体决策和行为应力求支持和改进这个统一的业务流程，无论你是来自哪一个组织架构。
DevOps有助于实现IT融合
业务敏捷性的一个简单定义是，“一个机构以高效、经济的方式迅速适应市场和环境变化的能力。”
当然对于开发人员来说，“敏捷”有专门的含义（参考51CTO开发频道的专题：初探敏捷开发），但目标是非常类似的。敏捷开发方法旨在保持软件开发工作与客户/公司的目标同步，尽管需求不断变化，也可以产生高品质软件。对于多数机构来说，迭代项目管理方法Scrum是敏捷的代名词。
Scrum
业务敏捷性承诺，在企业权益集团作出决策和开发者进行响应之间能够紧密互动和快速反馈。看一下一家运转良好的敏捷开发团体的产品，你会看到一个与业务需求保持一致的稳定持续改进。
但是，当你从企业角度回顾一下整个开发-运维周期，敏捷方法的相关优势通常会变得非常模糊。混乱之墙导致了应用程序生命周期的分裂。开发和运维分别按照不同的节奏进行。实际上，产品部署之间的长期间隔使得一个团体的敏捷工作变成了它一直试图避免的瀑布生命周期。当存在混乱之墙时，无论开发团体有多么敏捷，改变企业缓慢和迟钝的特点是极其困难的。
敏捷的开发与瀑布式企业结构的步调不同
DevOps使得敏捷开发的优势可以体现在机构层面上。通过考虑到快速、反应灵敏但稳定的业务运维，使其能够与开发过程的创新保持同步，DevOps可以做到这一点。
如果你希望在自己的组织内建立一个DevOps项目，务必牢记“IT融合”
