下载掌阅APP，畅读海量书库
立即打开
本书传递的一个关键信息是：你不能只通过聚焦云技术就能在云上取得成功。为了在云计算中获得成功，企业不仅需要对技术进行变革，还需要对用于交付和运维软件的组织结构和旧有流程进行变革。当组织采用云计算时，拥抱DevOps是成功转型的关键因素。但真正的DevOps到底是什么呢？
对DevOps这个术语最大的误解之一是，它是一组开发人员和运维人员用来将“所有事情”自动化的技术和工具。DevOps不仅仅是工具和技术，并且在任何企业中成功采用DevOps也不仅仅只是开发人员和运维人员的事情。很多人对这个争论不屑一顾，认为它只是字面上的意思，但是理解DevOps对于任何组织战略都至关重要。如果你认为DevOps只不过是自动化的CI/CD流水线，那么你可能会忽略许多在云中实现规模化交付所需的重要步骤。
定义DevOps的方式有很多。早在2014年，我就将其定义为“一种文化转变或一种运动，它鼓励通过良好的沟通和协作（又名团队合作）来更快速、更可靠地构建质量更高的软件”（ https://www.astroarch.com/tvp_strategy/devops-engineer-25120 ）。我接着补充道：“DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的延伸，而且专注于从SDLC中消除浪费。”
但是不要只相信我的话，看看引领DevOps的作家、思想领袖和布道师所做的工作。Gene Kim是流行DevOps书籍（如 The Phoenix Project 、 DevOps Hand-book 和 The Unicorn Project （全由IT Revolution出版））的合著者，他将DevOps定义为：
一套文化基准和技术实践，可确保计划中的工作快速投入运营，同时保持世界一流的可靠性、可维护性和安全性。
DevOps不是关于你做了什么，而是你做成了什么。我们与DevOps关联的许多事物都适合于这种广义的信念和实践框架……显然，沟通和文化是其中的一部分 [1] 。
Buntel和Stroud在 The IT Manager's Guide to DevOps （XebiaLabs）一书中将DevOps定义为“一组文化哲学、流程、实践和工具，它们从根本上消除了软件生产过程中的浪费”。类似地， The DevOps Handbook 告诉我们“想象一个产品负责人、开发、QA、IT运维和信息安全人员一起工作的世界，他们不仅在互相帮助，而且在确保整个组织的成功”。
Forsgren、Humble和Kim合著的畅销书 Accelerate ， The Science of Lean Software and DevOps （IT Revolution出版社）这样描述DevOps：
开发软件的新方式、方法和范式……重点关注从开发向下游延伸的敏捷和精益流程，并优先考虑信任和信息流通的文化，让小型跨职能团队来创造软件。
当你阅读这些定义时，会注意许多提及的目标：特别是质量、信任、共担和协作，以及消除浪费。让我们来逐一讨论。
质量
当我们努力提高进入市场的速度时，必然不能在这个过程中牺牲质量。我们产品和服务的用户希望这些产品和服务能够工作，无法按预期开展的事情越多，客户的整体满意度就越低。此外，质量问题会导致计划外的工作，这可能会导致长时间的工作、快速解决关键问题的高压力、较低的生产力和职业倦怠。DevOps的目标是确保整个SDLC的高质量，以创造更好的产品和服务，并让客户和员工满意。
信任
筒仓结构导致各筒仓之间缺乏信任，它们通常有相互冲突的优先级。例如，安全团队关注减少威胁，测试团队关注发现缺陷，运维团队关注稳定性，开发团队关注上市速度。每个筒仓通过构建流程与其他筒仓合作，其目标是提高实现各自年度目标的可能性。因此，安全团队添加了请求表单、评审会议和标准规范，寻求引入系统中软件和基础设施中潜在风险的可见性。问题是，安全团队通常不考虑其他团队的目的和目标，其他筒仓也是如此。与此同时，开发构建过程加快了软件的构建和生产部署，这与测试团队在将代码发布到生产环境之前就捕获缺陷的目标直接冲突，也对目标是维护可接受的可靠性水平的运维造成了挑战，因为它们不能有效地跟踪变更和对依赖系统的潜在影响。
在筒仓中设定狭隘的目标会造成团队间的不信任和组织的冲突。DevOps的目标是在SDLC中建立更多的信任，这样团队就可以更好地协作并优化流程，从而产生更高的敏捷性和士气。
共担与协作
共担和协作是相辅相成的，当不同领域的专家紧密合作时，他们会产生更好的结果。协作的一个关键组成部分就是共享信息，包括目标、经验教训、反馈和代码示例等。如果没有良好的合作，项目往往会陷入瀑布式思维。例如，我工作过的一个开发团队完成了编码和测试，并要求安全团队进行审查。安全团队拒绝了他们的工作单元，因为它们不符合他们的安全需求。修复这些问题需要几轮来回的工作。然后他们不得不重复操作、合规和架构的过程。这导致从客户要求某个特性到该特性在生产中可用的时间更长。其结果是，业务用户对漫长的交付周期感到沮丧，并开始寻找IT部门之外的IT解决方案。
DevOps的目标是促进不同技术领域之间更好地进行协作，这样就可以尽早解决问题。DevOps还旨在创造一种协作文化，让每个人都朝着共同的成果而努力。
消除浪费
DevOps的思想大部分来自精益生产流程和Eliyahu Goldratt的 The Goal （North River出版），该著作专注于通过识别和消除浪费及流程瓶颈来优化生产装配线。构建和部署软件的过程经常充斥着大量的人工干预、审查关卡、多次批准和许多其他瓶颈，这些瓶颈降低了敏捷性，并且通常对消除风险和提高质量的目标贡献甚微。DevOps的目标是在SDLC中推动系统思维，简化工作并创造持续改进的文化。
如果所有这些思想是DevOps所信奉的，那么为什么这么多组织创建了一个名为DevOps、专注于编写自动化脚本的新筒仓，而不是与产品负责人和开发人员合作呢？一些公司利用现有的运维团队，采用一些新工具，并将其称为DevOps。虽然这些步骤取得了相应的进步，但一个通往DevOps的片面方法并不能兑现它的承诺。“DevOps”筒仓常常导致更多的浪费，因为焦点通常只集中在工具和脚本上，而不是他们所支持产品团队的真正目标上。
DevSecOps怎么样？NoOps呢？AutoOps呢？AIOps呢？难道这些东西都不比DevOps好吗？我应该采纳哪一个呢？
对于大多数成熟的DevOps实践者来说，DevOps就是我刚才列出的所有内容。当你把注意力集中在成果上时，就会使用最能帮助你达到这些成果的技术。这些新术语强调了其创建者认为体系中代表性不足的方面（安全、自动化、人工智能等），他们让咨询师和客户感到新鲜。但是不要搞错了：这些新一代流行语和老式（大约2009年）术语DevOps之间没有真正的区别。
如果遵循本章的原则，你想怎么叫都行。
要理解DevOps，我们必须了解它的起源。它的发展始于2008年，在Agile 2008 Toronto会议上，正如视频中回忆的那样（ https://www.youtube.com/watch?v=Y_u84PNrX9g ），敏捷开发者Andrew Shafer做了一个题为“Agile Infrastructure”的演讲，比利时基础设施专家Patrick Debois是唯一的与会者。两人讨论了如何使用敏捷基础设施来解决开发和运维之间的瓶颈和冲突，他们的对话促成了合作，随之创立Agile Systems Administration Group来试图改善IT界的现状。
在2009年的O'Reilly Velocity Conference上，John Allspaw和Paul Hammond通过他们的演讲“10+Deploys Per Day：Dev and Ops Cooperation At Flickr”吸引了IT社区（包括Debois）的注意。当时，每天部署多次几乎是闻所未闻的，而且会被普遍认为是鲁莽和不负责任的。受到这次演讲的启发，Debois组织了一场大会，并在他的Twitter人际网上发送邀请。他将其命名为DevOpsDays，并在Twitter上推广时使用了#DevOps的标签。如果没有当时Twitter的140个字符的限制，我们在行业中可能没有一个如此简明的运动
。
显而易见，为什么很多人认为DevOps只不过是开发人员和运维人员一起工作。但是，DevOps此后得到了更广泛的传播，今天的DevOps涉足所有业务领域。许多人开始DevOps之旅时仅考虑自动化基础设施或应用程序的构建过程，但是具备更高DevOps成熟度的高效能公司正在重新设计IT内外部的整个组织和流程。
在DevOps之旅中取得成功的公司倾向于分享一些共同的信念，包括：
拥抱变化和不断学习的企业在三到四年后看起来截然不同。表1-2显示了公司解决瓶颈以改善交付和业务成果的典型顺序。通常，当它们在消除一个瓶颈（例如，不一致的环境）后取得长足进步时，便会着手解决下一个大瓶颈（例如，安全性）。
表1-2：瓶颈和痛点
以上只是我看到的一些问题，并且实施了相应的变革以消除瓶颈。许多企业采取了大胆的举措以重塑其员工队伍，甚至重新思考工作的未来。我们为员工提供的激励措施必须改变，以达到预期的成果。随着我们从许可和维护转变为按需付费模式，采购流程也必须发生变化。简而言之，组织的每个部分都以某种方式受到影响。
[1] Gene Kim于2017年11月在San Francisco的DevOps Enterprise Summit大会上的Keynote演讲，由Michael Kavis在文章“The Four Stages of DevOps Maturity”（ https://www.forbes.com/sites/mikekavis/2017/11/17/the-four-stages-of-devops-maturity/#72efabce2f62 ）中引用。