原文地址
本文内容
- 为什么 DevOps
- 什么是 DevOps
- DevOps 所带来的好处
- 如何将 DevOps 落到实处？
- 关于 DevOps 的澄清
- 参考资料
编写软件之所以难，是因为没有哪两个软件是完全相同的（这也是人们喜欢编程的原因，解决问题带给自己的快感），这跟物理、化学，建筑行业等等完全不同，而且还是不可见的，物理过程、化学反应至少看得见、摸得着，建筑业还有图纸……更要命的是，需求在不断的变……需求的变化，不仅仅在于客户改变了想法，而是在当今移动互联网时代，今天客户有个销售活动，明天就要在网站上体现出来……到最后，本来架构和设计良好的软件，被改得面目全非~于是，人们想到并采用了“敏捷开发”，从一个原型开始，快速开发，快速部署，尽早让客户看见软件，然后重构，不断完善……我们说，“Build”这个词，准确来说，不是“生成”，而是“构建”，也正是编程是一个“搭建”软件的真正含义~但是“敏捷开发”主要针对的是开发过程，可是整个软件生命周期，开发只是第一步，还有后来的测试、部署、集成、质量保证，我们经常能看见开发软件与运维人员之间永无休止的争论，这就造成了，开发与运维、质量保证的严重脱节，最近跳槽，测试人员每次找另一个组的开发人员，每次交流的时间都在2个小时左右（太长了，毫无意义的2个小时），测试人员说这样，开发人员不愿意……因此 DevOps 应运而生，不仅仅开发要敏捷，运维也要敏捷……
事实上，无论是哪方面的“敏捷”，它们都只是一套方法论而已，包括一套指导思想和相应的工具（编程跟一些实证科学，如物理化学等，相比本身就缺乏一套理论基础，数学基础，有的也就是方法论了），方法论的最大弱点是，操作性比较差，要想把 DevOps 用起来，实在不容易~
有些人对 DevOps 不爽的原因是“让开发人员做运维的事”，其实，我倒不觉得，软件开发的历史并不长，还不到100年，还很幼稚，而像物理化学建筑等人类已经有几千年的历史，加之硬件发展的速度实在太快，你会发现，几年以前还激动人心的框架或工具，现在已经落伍了，今天的 Java 跟十年前的 Java 已经大不相同了，如果你看了亚马逊的《架构师》的话。另一个方面，往往事情本身并不复杂，可一牵涉到人，情况就完全不同了，人越多情况越严峻~所以，良好的沟通和项目管理在软件研发过程始终都比写代码、测试、集成重要的多。
为什么 DevOps
人们越来越意识到传统意义上的开发与运维之间存在脱节现象，从而导致冲突和低效，于是 DevOps 应运而生。
正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所说：“在开发和运维之间存在一面‘混乱之墙’”。相互冲突的动机、流程和工具导致了这面“墙”的存在。
以开发为中心的人通常认为，变化会带来回报。企业依靠他们来应对不断变化的市场需求（比如，打折、优惠），因此他们被鼓励尽可能进行变革；而运维人员则往往视变化为敌人，因为，变化会影响稳定性和可靠性，运维业务有理由对它说不。企业依靠它们维持正常业务让企业赚钱。我们已经多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变。
开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。的确，孤立的来看他们都是正确的。
更糟糕的是，开发团队和运维团队通常处于公司组织架构的不同部分，具有不同管理者和竞争关系，甚至工作地点都可能不同。
让”混乱之墙“更坚固的还包括开发和运维工具之间的错位。看一下开发者与系统管理员日常使用的工具，你会发现两者存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然；而且它们之间也不存在重要的集成。即使在某些工具类型上有一些重叠，使用方式也完全不同。
当应用程序需要从开发团队推向运维团队时，”混乱之墙“将变得更加明显。有人将其称为一个“版本发布（Release）”，有人则称其为一次“部署（deployment）”，但有一件事情是公认的，问题可能会随之而来。下图虽然是一个抽象化场景，但是如果你经历过这一过程，一定会感觉到它的真实性。
开发人员把一个软件版本“扔”给墙对面的运维人员，后者拿后开始准备部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们成功地重复了之前的工作；糟糕的是，他们将引入或发现新的漏洞。
然后，运维人员进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署实际上也是首次被执行。当然，期间如果发生一个问题，开发人员会被要求来帮助。运维人员会说开发团队给的产品存在问题（相比你也知道，当别人对你说，你的程序有问题时，你的第一反应）。而开发人员则会回应，该产品在他们的环境下运行良好，一定是运维人员在部署过程中做错了什么。由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。
没有一个可靠的方式来把环境回滚到之前已知的正常状态。本应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试后才让生产环境恢复到正常状态。
正如约翰·阿尔斯帕瓦（John Allspaw）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。
这就是需要 DevOps 的原因，但需要 DevOps 绝不仅仅是这些。
什么是 DevOps
DevOps（英文 Development 和 Operations 的组合）是一组过程、方法与系统的统称，用于促进软件开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而现在却需要极其紧密的多部门协作。然而 DevOps 考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对 DevOps 有一个大致的了解。Flickr 发展了自己的 DevOps 能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。从2009年起，相关的工作组、专业组织和博客快速涌现。
DevOps 的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏 DevOps 能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入 DevOps：
- 使用敏捷或其他软件开发过程与方法
- 业务负责人要求加快产品交付的速率
- 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
- 数据中心自动化技术和配置管理工具的普及
- 有一种观点认为，目前占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）[16]会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
DevOps 经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
DevOps 所带来的好处
DevOps 是一个非常强大的概念，因为它可以在众多不同层面上产生共鸣。
从开发或运维的一线人员的观点来看，DevOps 可以让他们从众多烦恼中解脱出来。它虽然不是具有魔力的万灵药，但是如果你能够让 DevOps 奏效，则会节省大量时间，而且不至于打击自己的士气。显而易见，投入精力将 DevOps 落到实处，我们应该会更加高效、更加敏捷和减少挫败感。有些人可能会反驳称DevOps 是一个遥不可及的目标，但这并非说我们不应该去尝试实现它。
对于企业来说，DevOps 直接有助于实现两个强大战略性企业品质，“业务敏捷性”和“IT融合”。它们可能不是IT人士所担忧的事情，但是却应该获得掌握财政大权的管理者的注意。
IT融合的一个简单定义是，“企业渴望达到的一个状态，能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力。”
通过从共同企业目标角度出发来校准开发和运维的职责和流程，DevOps 有助于实现IT融合。开发和运维人员需要明白，它们仅仅是一个统一业务流程中的一部分。DevOps 思想确保个体决策和行为应力求支持和改进这个统一的业务流程，无论你是来自哪一个组织架构。
业务敏捷性的一个简单定义是，“一个机构以高效、经济的方式迅速适应市场和环境变化的能力。”
当然对于开发人员来说，“敏捷”有专门的含义，但目标是非常类似的。敏捷开发方法旨在保持软件开发工作与客户/公司的目标同步，尽管需求不断变化，也可以产生高品质软件。对于多数机构来说，迭代项目管理方法 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”，但却在遵循着类似的理念。