第1章　DevOps诞生与发展

1.1　DevOps概述

DevOps一词来自Development与Operations的组合，是一种重视软件开发人员（Dev）和运维人员（Ops）之间沟通的文化、运动或惯例。通过将人、流程和技术结合起来，DevOps利用自动化的流程来构建、测试、发布软件，使“软件交付”与“架构变更”变得更加快捷、频繁和可靠。DevOps帮助团队提高软件和服务的交付速度，使团队能够更好地为客户服务，并提高其在市场中的竞争力。

简而言之，DevOps可以定义为通过更好的沟通和协作，使开发和运维保持较高的研发效率和文化的一致。

DevOps的诞生是为了填补开发端到运维端之间的信息鸿沟，改善团队之间的协作关系。随着DevOps的发展，产品管理、开发、运维、测试和信息安全工程师均加入其中，形成一套针对多部门间沟通与协作问题的流程和方法。

DevOps并未对任何特定的流程、工具和技术有偏好，也并未规定任何特定的方法和环境。DevOps并不是框架或者方法，实际上只是一系列的原理和实践经验，这些原理和实践经验并不会执行任何特定的程序、工具或技术，而是使用DevOps原理和经验来指导使用这些程序、工具和技术。一个不认可DevOps文化和原理的团队，无论使用怎样的技术和工具，都不能算是真正地实践了DevOps。

1.1.1　DevOps文化

要真正了解DevOps首先要理解DevOps文化。在学习之初，用户需要暂时摒弃市面上各种眼花缭乱的DevOps工具的宣传，应该把握DevOps的本质，这样才能在今后的实践中不被各种复杂的技术和高深的术语所迷惑。在组织层面，团队相关成员之间需要持续沟通、协作和共担责任，打破团队间的孤岛状态，不需交接，也不需等待其他团队的审批，同心协力，保证快速且持续的创新和高质量的交付。

DevOps文化是团队协作的文化，需要团队所有成员的理解和认可，单凭个人是无法实践DevOps的，包括如下。

1.协作的可见性

不同的团队或成员的DevOps流程、优先级和关注点互相可见，有统一的目标和衡量标准。这是一个健康的DevOps文化的标志，也是高效协作的基础。

2.负责范围的转变

团队成员需要参与他们角色对应工作范围之外的阶段。例如，研发人员不仅要对开发阶段负责，还要对软件发布后运维阶段的性能和稳定性负责；运维人员不仅要对软件运行的环境负责，还要对软件的安全性、合规性负责，并且在软件规划阶段就要参与。

3.缩短发布周期

缩短发布周期可以让计划和风险管理更容易，同时减少对系统稳定性的影响，还可以让组织适应和应对不断变化的客户需求和竞争压力。

4.持续学习

DevOps提倡快速迭代和快速试错，融入失败经验，不断改进，从而加速创新并适应市场变化，不断学习，不断成长。

1.1.2　DevOps实践

任何企业的DevOps实践的最终目标都是确保相关人员（包括用户）的期望和需求能有效、快速地开展。DevOps满足用户以下需求和期望：①获得他们想要的功能；②在任何需要时都能获得他们想要的反馈；③更快、更新的功能；④发布的新版本的质量够高。

只有当企业能满足这些用户需求，用户的忠诚度才会高，从而企业的市场竞争力才能得到提升，并最终增强企业的品牌和市场价值。DevOps对企业的顶线和底线有直接影响，企业可以在创新和用户反馈上投入更多，从而持续改变其系统和服务，以保持用户的黏性。

任何企业或者团队在实践DevOps的过程中都会受其所处的行业和领域的影响，所以要把握住DevOps实践的核心原则和核心做法。

DevOps实践的核心原则：①协作机制和沟通机制；②响应变化的敏捷度；③软件设计能力；④快速试错；⑤持续学习和创新；⑥自动化流程和工具。

DevOps实践的核心做法包括：①版本控制；②持续集成（Continuous Integration，CI）/持续部署（Continuous Deployment，CD）；③配置管理；④基础设施即代码；⑤持续监控；⑥持续迭代。

1.1.3　DevOps生命周期

DevOps生命周期（以线性方式描述时，也称为持续交付管道）是一系列迭代式、自动化的开发流程（也称为工作流程），在更大的自动化和迭代式的开发生命周期内执行，旨在优化高质量软件的快速交付。工作流程名称和数量因人而异，通常可归结为6类（如图1-1所示）。

1.规划（或构思）

根据划分了优先级的最终用户反馈和案例研究，以及来自所有内部利益相关方的输入，团队确定下一个发行版中的新功能或特性的范围。规划阶段的目标是通过生成在交付后可实现预期成果和价值的待办工作列表，最大程度提高产品的业务价值。

2.开发

编码环节，开发人员根据待办工作列表中的用户情景和工作项，编码、测试和构建新功能和增强功能。常用的实践组合包括测试驱动开发（Test-Driven Development，TDD）、配对编程和同行代码评审等。开发人员通常使用本地工作站来执行代码编写和测试的“内部循环”，再将代码交给持续交付管道。

3.集成（或构建，或持续集成和持续部署）

新代码集成到现有代码库中，然后执行自动化测试并打包到可执行文件中，以进行部署。常见的自动化活动包括：将代码变更合并到“主”副本中，从源代码存储库中检出代码，自动执行编译、测试，然后打包为可执行文件。最佳实践是将持续集成阶段的输出存储在二进制存储库中，以备后续阶段使用。

4.部署（通常称为持续部署）

（来自集成的）运行时，构建输出部署到运行时环境，通常是执行运行时测试的开发环境，用于验证质量、合规性和安全性。如果发现错误或缺陷，开发人员有机会在任何最终用户看到问题之前拦截并修补任何问题。通常存在开发、测试和生产环境，每个环境都需要逐步“严格”的质量关口。部署到生产环境的最佳实践通常是首先部署到最终用户的子集，然后在产品趋于稳定后，逐步向所有用户部署。

5.运维

如果将功能交付到生产环境描述为“第1天”，那么功能在生产环境中运行就可称为“第2天”。监控功能的性能、行为和可用性可确保功能为最终用户增值。运维确保功能平稳运行，并且服务中没有中断，也就是确保网络、存储、平台、计算和安全态势都正常。如果出错，运维可确保发现事件，提醒适当的人员，确定问题，并应用修复措施。

6.学习（也称为持续反馈）

收集来自最终用户和客户对特性、功能、性能和业务价值的反馈，根据这些反馈，规划下一个发行版中的增强和功能；还包括来自运维活动的任何学习和待办工作项，帮助开发人员主动避免将来再次发生以往错误。这就是规划阶段的“总结”，我们“不断改进”。

除此之外，还有另外三个重要的持续工作流程。

1.持续测试

典型的DevOps生命周期还包含需要在集成和部署之间完成一个单独的“测试”阶段。而DevOps更进一步，可以在各工作流程中执行测试的某些要素，如：在规划中执行行为驱动的开发，在开发中执行单元测试与合规测试，在集成中执行静态代码扫描、CVE扫描和开源代码分析（Linting），在部署中执行冒烟测试、渗透测试、配置测试，在运维中执行混沌测试、合规性测试，在学习中执行A/B测试。测试是一种强大的风险和漏洞发现方法，为产品提供接受、缓解或补救风险的机会。

2.安全

虽然瀑布式方法和敏捷实施在交付或部署后添加了安全工作流程，但DevOps努力从一开始（规划）就整合安全工作流程（以确保能够以最低的代价尽早解决安全问题），并且在整个开发周期中持续整合安全工作流程。这种安全性方法称为“左移”。一些组织的左移工作不甚理想，这也导致了DevSecOps的兴起（后面章节会详细介绍）。

3.合规性（治理和风险）

在开发过程的整个生命周期都能有效进行合规和风险的治理、把控。受监管行业通常必须强制性满足特定级别的可观察性、可跟踪性和可访问性，以表明自己如何在运行时环境中交付和管理功能。这需要在持续交付管道和运行时环境中规划、制定、测试和执行策略。合规性措施的可审计性对于向第三方审计机构证明合规性而言极其重要。

【小结】随着近些年DevOps理念被开发者与团队认可，越来越多的公司开始实践DevOps；同时，越来越多的理念、工具和角色被纳入DevOps的范畴，如敏捷开发、自动化测试、软件安全测试等，已成为DevOps生命周期的一部分，并广泛应用于软件开发实践。