1.1 DevOps方法
DevOps是一个持续改善软件产品的过程，它通过极短的发布周期、全面自动化的集成和交付流水线，以及团队间的紧密协作来不断改善产品。DevOps的目标是缩短将创意变成用户可以使用的产品的时间，并降低这个过程的成本。DevOps充分利用自动化流程来加速开发和部署。图1.1对比了传统软件构建方法和DevOps方法，传统方法在上面，DevOps在下面。
•图的上半部分，从概念构思到用户可用的时间周期是八天。基础设施部署占用的时间最多，因为工程师需要在互联网上创建托管软件所需的组件。另一个大的时间耗费来自部署之间的测试和评审步骤。
•图的下半部分，从概念构思到用户可用的时间周期缩短到了两天。这是通过使用处理部署和软件测试/评审的自动化流程来实现的。
图1.1 DevOps缩短了从功能构思到客户可用的时间。
如果一个组织构建软件的速度能比对手快四倍，那么这将会给它带来巨大的竞争优势。实践表明，客户中意的创新产品一开始可以不完整，但要能够快速稳定地改进。组织可采纳DevOps来降低开发生命周期的成本和延迟，并响应用户的要求。
通过DevOps，开发人员仅用数小时就可以发布新版本软件，对它们进行测试，并部署给客户。这并非意味着版本总是可以这么快地发布，适当的质量保障（QA，Quality Assurance）需要投入时间，而DevOps提供了在必要时能快速行动的能力。图1.2放大了图1.1下半部分的细节，展示了持续集成、持续交付及基础设施即服务这些技术如何被整合在一起以实现快速的发布周期。
图1.2中的流水线的关键部分是，从开发人员提交补丁到生产环境中的服务部署这些自动化步骤，最终以完全自动化的方式串联成的一个链条。如果这个链条上的任何一个自动化步骤出现失败，那么流水线就会停止，代码就不会部署。这种机制将确保在所有类型的测试都通过之后，新版本的软件才能被发布到生产环境中。
1.1.1 持续集成
将新特性快速集成进软件的过程叫作持续集成（CI，Continuous Integration）。CI定义了一个在软件产品中实现、测试及合并新特性的工作流。产品经理和开发人员定义一组小特性集合，这些特性能在较短的周期内实现。每个特性添加在主要源代码的一个分支上，并提交评审，由另一位得到授权的开发人员来评审。在评审阶段，自动化测试会被执行以验证代码更改是否需要返工，这能维持代码的质量水平。在评审通过之后，修改会被合并到中央代码仓库中，这样就做好了部署的准备。小特性的快速迭代能让这个流程得以顺畅运行，避免了因大规模代码修改而对功能造成的破坏。
图1.2 持续集成、持续交付和基础设施即服务组成了一条自动化流水线，让DevOps可以加速软件的测试和部署过程。
1.1.2 持续交付
将软件部署到客户可用的服务中的自动化过程叫作持续交付（CD，Continous Delivery）。DevOps推崇工程师用程序代码来管理基础设施以快速应对变化，而不是手动管理基础设施组件。当开发人员将代码修改合并进软件之后，运维人员在CD流水线上触发更新后的软件的部署，流水线会自动获取最新版本的源代码，对其进行打包并为它创建新的基础设施。如果部署进行顺利，可能在QA团队人工或自动评审之后，该环境就会被提升为新的演练或生产环境。用户将被定向到这个环境，而老环境将被销毁。通过代码来管理服务器和网络的这一过程大大缩短了处理部署通常所需的漫长的等待时间。
1.1.3 基础设施即服务
基础设施即服务（IaaS，Infrastructure as a Service）就是云。它是这样一种概念，一个组织所依靠的数据中心、网络和服务器，有时甚至还有系统，统统都由第三方运营。这些基础设施可以作为服务暴露给运维人员，并且可以通过API和代码进行控制。IaaS是DevOps弹药库中的核心工具，因为它在降低基础设施运营成本方面发挥着举足轻重的作用。可编程的特质将IaaS和传统基础设施区分开来，并且鼓励运维人员编写代码来创建和修改基础设施，而不是手动执行这些运维任务。
内部运维
许多组织倾向于在内部运营它们的基础设施，这样做有各种各样的原因（监管、安全、成本，等等）。需要注意的是，采用IaaS并非意味着将基础设施的管理外包给第三方。组织可以在内部使用Kubernetes或OpenStack这样的平台来部署和运维IaaS，而不是直接在硬件上运行应用，从而享受到这些中间管理层带来的灵活性优势。
本书中我使用了由第三方运营的IaaS系统——AWS（Amazon Web Services），它受到许多组织的青睐，因为AWS帮助它们降低了基础设施管理的复杂性，让它们可以聚焦于核心产品。但是，我提及的大多数基础设施安全概念可以应用于任何类型的IaaS，无论你是自己控制硬件还是让第三方替你控制。
管理更低层的基础设施将带来一系列全新的问题，例如网络安全和数据中心的访问控制，你必须妥善处理这些问题。本书没有介绍这些内容，因为它们不是DevOps独有的问题，但是你应该可以轻易地从一些现有文献中获得帮助。
AWS是最具代表性的IaaS，它将作为我们的示例环境贯穿于全书。图1.3的下半部分展示了由供应方管理的AWS组件，上半部分则是由运营方管理的组件。
CI、CD及IaaS是成功的DevOps策略的基本组成部分。深谙CI/CD/IaaS工作流的组织能以全自动化的方式快速地将软件交付给终端用户，并能够做到一天交付数次。测试和部署步骤的全部自动化保证了将流水线操作所需的人工干预降到了最低，这样在灾难发生时基础设施也是完全可以恢复的。
除了技术上的优势，DevOps还影响了组织文化，从很多方面提升了员工的幸福感。
图1.3 AWS是一个IaaS，它通过承担对核心基础设施组件的管理来减轻运营的负担。图中下面方框内的设备完全由Amazon管理，而运营方管理的是上面方框内的组件。如果是传统的基础设施，所有的组件必须全都由运营方自己管理。
1.1.4 文化和信任
改进工具只是成功的DevOps方法的第一步。随之而来的是文化转变，驾驭DevOps技术并逐渐走向成熟的组织变得底气十足，相信自己有能力为用户带来新产品。组织的信心高涨带来了一个有意思的附带效果——对管理的需求减少了，这是因为工程师被赋予了以最小代价向组织交付价值的能力。一些DevOps组织甚至开始尝试完全没有管理层的扁平组织架构。尽管完全去掉管理层只是适合于少数组织的极端情况，但是减少管理的整体趋势，毫无疑问和DevOps环境的成熟程度密切相关。
那些拥抱并成功运用DevOps的组织通常会更容易招纳并留住人才。我们时常会听到开发人员和运维人员对在缓慢和混乱的环境中工作而怨声载道。开发人员会对需要等待数周才能将补丁部署到生产系统这件事大为光火。运维人员、产品经理和设计师也都不喜欢缓慢的迭代。员工会离开这样的公司，而人才流失会影响产品的质量。更快地将产品推向市场的公司拥有竞争优势，不仅是因为它们可以更快地向用户交付特性，更因为它们通过降低运维复杂度而给工程师带来了好心情。
DevOps告诉我们，更快地交付产品能够让组织更健康、更具竞争力，但软件交付速度的提升可能会增加安全工程师的工作难度。极短的发布周期只给彻底地安全审查留出了很少的时间，而要求组织承担的技术风险比在响应较慢的组织架构中的还要多。将安全融合到DevOps中会带来一系列挑战，首当其冲的就是安全文化的根本转变。