【51CTO精选译文】若是你对IT管理感兴趣，尤为是对Web运维感兴趣，那么最近必定会注意到“DevOps”这一热词的出现。如今#DevOps标签频繁出如今微博客Twitter上，同时DevOps相关的技术交流聚会也在慢慢增多。html
在许多方面，DevOps是一个集合性概念，指的是可以理顺开发和运维之间相互配合关系的任何事物（51CTO编辑注：在英文中，Developer指开发者，Operations指运维，因此DevOps一词自己含有开发+运维的意思）。可是DevOps背后的理念要比上述说法更深远。安全
什么是DevOps？服务器
人们愈来愈意识到传统意义上的开发行为和运维行为存在脱节现象，从而致使冲突和低效，所以DevOps应运而生。架构
正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具致使了这面“墙”的存在。运维
开发与运维之间的“混乱之墙”ide
以开发为中心的人一般认为，变化会带来回报。企业依靠他们来应对不断变化的需求。所以他们被鼓励尽量进行变革。工具
而运维人员则每每视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。因为变化会影响稳定性和可靠性，运维业务有理由对它说不。咱们已经屡次听到过以下统计数字：在全部宕机事件中有80%状况是源于自杀式的改变（根据51CTO以前进行的调查，不少时候，仅仅是给系统应用补丁就会形成生产服务器没法正常重启）。post
开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差异。他们都认为本身的作法是正确的。的确，孤立的来看他们都是正确的。测试
更糟糕的是，开发和运维团队一般处于公司组织架构的不一样部分，一般具备不一样管理者的和竞争关系，并且一般工做在不一样的地点。spa
开发与运维一般工做在不一样的地点
让混乱之墙更坚固的还包括开发和运维工具之间的错位。看一下开发者要求和平常使用的常见工具，再看一下系统管理员，你会发现二者存在很大不一样，开发人员没有兴趣使用运维人员的工具，反之亦然；并且两部分工具之间也不存在重要的集成。即便在某些工具类型上有一些重叠之处，使用方式也彻底不一样。
开发与运维经常使用工具的不集成
当应用程序变更须要从开发团队推向运维团队时，混乱之墙的存在则将变得更加明显。有人将其称为一个“版本发布（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融合” 和“业务敏捷性”。
如何将DevOps落到实处？
和多数新出现的话题同样，发现问题的共性特色要比找到解决方案容易的多。
要想实现DevOps相关解决方案，如下三方面须要关注：
一、评价和鼓励改变文化
改变文化和激励系统历来不是一件易事。可是，若是你不改变企业文化，兑现DevOps的承诺将很是困难。考察一个企业的主导文化时，你须要紧密关注如何评价和判断企业业绩。评价的内容将影响和刺激行为的发生。开发-运维生命周期中的全部当事方须要明白，在更大的企业流程中本身只是其中一部分。个体和团队的成功都要放在整个开发-运维生命周期内来进行评价。对于许多机构来讲，这是一个转变，再也不是孤立的来进行业绩评价，每个团队再也不是基于本身的团队来评价和判断业绩好坏。
二、统一标准化的流程
这是DevOps的一个重要主题，整个开发-运维生命周期必须被看做一个端对端过流程。流程的不一样阶段能够采起不一样的方法，只要这些流程能够被组合到一块儿建立一个统一的流程。与评价和激励的问题类似的是，实现这个统一的流程时每一个组织可能会有略微不一样的需求。
三、统一的工具
这是大多数DevOps讨论一直在关注的领域。这一点不使人吃惊，由于当技术专家在考虑解决一个问题时，第一反应每每就是直接跳转到工具讨论上。若是你关注Puppet、Chef或ControlTier等工具社区，那么你可能已经意识到人们对在开发和运维工具之间创建桥梁的重大关注。“基础设施即代码（Infrastructure as code）”、“模型驱动自动化（model driven automation）”和“持续性部署（continuous deployment）”都是能够划归DevOps旗下的概念。
关于把DevOps变为现实须要哪些类型的工具，杰克·索罗夫曼（Jake Sorofman）提出以下建议：
一个版本控制软件库
它能够确保全部系统产品在整个版本发布生命周期中被很好的定义，且可以实现一致性共享，同时保持最新信息。开发和QA机构可以从中取得相同平台版本，生产机构部署已经被QA机构验证过的相同版本。
深层模型系统
它的版本系统清晰的描述了软件系统相关的全部组件、策略和依赖性，从而能够简单的根据须要复制一个系统或在无冲突的状况下引入变化。
人工任务的自动化
在依赖关系发现、系统构造、配置、更新和回滚等过程当中，减小人工干涉。自动操做变为高速、无冲突和大规模系统管理的命令和控制基础。
在从开发到运维的生命周期中存在许多不一样的工具。工具选择和执行决策须要根据它们对端到端生命周期的影响来决定。
关于DevOps的澄清
如今某些系统管理员正在试图把本身的岗位名称改成“DevOps”。可是，DevOps不该该是一个单一的位置或职称。把DevOps变成一个新职位名称或特定角色是一件很是危险的事情。例如这会致使如下错误端点：你是一个DBA？或者是一个安全专家？那么不用担忧DevOps，由于那是DevOps团队的问题。
设想一下，你不会说“我须要招聘一个Agile”或“我须要招聘一个Scrum”或“我须要招聘一个ITIL”，而只是会说须要招聘了解这些概念或方法的开发人员、项目经理、测试人员或系统管理员。DevOps也是一样道理。
与DevOps具备相同理念的术语不少，例如敏捷运维（Agile Operations）、敏捷基础设施（Agile Infrastructure）和Dev2Ops。还有不少人虽然没有说起“DevOps”，但却在遵循着相似的理念。
原文：http://dev2ops.org/blog/2010/2/22/what-is-devops.html