拥抱-DevOps-发布管理-全-

拥抱 DevOps 发布管理（全）

原文：annas-archive.org/md5/f4cc50968d1a83dfcdee3a4331510e52

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

为了简化构建和维护现代应用程序的复杂性，DevOps 工程师这一角色的需求迅速增长。这种思维方式专注于缩小 IT 运维和软件开发之间的瓶颈，其源自精益生产理念。

通过拥抱 DevOps 发布管理，软件开发团队受益于质量检查的整合和将测试、自动化以及质量保证流程提前到软件开发生命周期的做法。然而，发布管理仍然需要监控应用程序和基础设施组件，并管理变更请求和调度。

在本书中，你将了解发布管理的简短历史、什么是 DevOps 发布管理、它的独特之处以及实施它的基本策略。你将学习到 CI/CD 管道如何强制执行良好的 DevOps 发布管理，并了解如何优化这些管道。最后，你将学会如何创建一个跨职能的产品开发文化，从而减少浪费，增加客户价值。由于它在消除团队成员间孤岛方面的有效性，DevOps 发布管理正在成为目前最受欢迎的策略。

本书适用读者

本书面向 DevOps 工程师、软件工程师、项目经理、质量保证测试员和产品经理，他们负责软件产品的开发、质量保证、发布和部署。本书对于学习计算机科学或商业管理的教师、学生和研究人员也具有参考价值。

DevOps 和发布管理在软件开发、项目管理和 IT 运维方面有着紧密的联系。DevOps 发布管理涵盖了监督软件发布和交付周期中的设计、规划、调度、测试和实施等活动。

本书是为那些刚接触 DevOps 发布管理的读者提供的全面介绍。你将学习到将质量控制提前的关键技能，在创纪录的时间内构建高质量的产品。你将获得启动自己 DevOps 发布管理项目所需的知识，并且有信心推动公司的转型。

本书内容

第一章，理解软件开发生命周期，概述了软件开发生命周期（SDLC），这是软件行业创建新软件的程序。这种方法确保软件开发人员以最短的时间构建高质量、低成本的产品。

第二章，发布管理简要介绍，定义了什么是发布管理，它的文化意义以及技术视角。我们还将回顾发布管理的简短历史，了解它是如何随着时间的推移而发展的，包括对任何发布管理模型的标准六个阶段的回顾。

第三章，有哪些不同的 SDLC 发布管理模型？，介绍了发布管理模型，如 ITIL、瀑布模型、迭代模型、V 型模型、螺旋模型、激进式模型、敏捷模型以及 DevOps。

第四章，DevOps 发布管理试图解决哪些问题？，阐述了为什么 DevOps 的特性使其作为一种更优的发布管理方法论，强调了自动化、最小化风险、简化发布流程，并通过跟踪指标和分析关键绩效指标来衡量成功。

第五章，理解 DevOps 发布管理的独特性，讨论了发布管理作为一种整体实践，考虑了价值流中的每一个组成部分。DevOps 通过精心设计的自动化流水线和经过仔细选择的测试和审批过程，整合了 CI、CD、QA、安全性和反馈。

第六章，理解 CI/CD 的基础知识，探讨了 CI/CD，这是 DevOps 发布管理的关键策略。它自动化了传统上需要人工干预的大部分工作，从而实现新软件发布或将新代码推向生产环境。

第七章，技术发布经理的实用流水线，这一章将与本书的其他章节有所不同。你将学习如何构建一个包含简单 Web 应用程序的 Docker 镜像，并使用 GitHub Actions 将其部署到 AWS ECS。

第八章，CI/CD 流水线如何强化良好的 DevOps 发布管理，涵盖了包括管理市场推出速度和 CI/CD 治理、开发团队的分支策略、构建发布流水线以及实施适合 DevOps 发布管理的变更审批过程等主题！

第九章，在发布管理策略中拥抱 DevOps 文化，讨论了如何通过充分的规划和统一的方式发展 DevOps 文化。你将学习如何获得高层领导的支持，从零开始组建 DevOps 团队，并逐步定义促进协作和持续改进的流程。

第十章，领导层和利益相关者的支持是什么样子的，讨论了 DevOps 文化如何要求组织内领导层的坚定支持和积极参与。如果这些人不全心全意地支持并投入 DevOps 项目，这一项目很可能会失败。

第十一章**, 克服 DevOps 发布管理中的常见陷阱，讨论了如何与组织的独特文化、工作风格和软件发布目标保持一致，以避免 DevOps 发布管理中的常见陷阱。如果您观察足够多的 DevOps 导向的公司，您会发现它们在运营过程中会遇到几个常见的陷阱。

附录，包含术语表、章节问题的答案、额外内容以及发布经理在日常工作中使用的常见文档模板。

如何充分利用本书

阅读本书内容需要具备一定的软件开发和产品开发基础知识。不过，拥有 DevOps 实践的基础知识将帮助读者更好地理解书中的练习。对于这些策略的新手，我们会提供相关参考资料。如果您有在敏捷或 DevOps 环境中工作的经验，将有助于您理解本书所涵盖的概念。

如果您正在使用本书的数字版本，建议您自己输入代码，或者通过 GitHub 仓库访问代码（链接将在下一节提供）。这样做可以帮助您避免与复制和粘贴代码相关的潜在错误。

下载示例代码文件

您可以从 GitHub 上下载本书的示例代码文件，链接：github.com/PacktPublishing/Embracing-DevOps-Release-Management。如果代码有更新，它将会在现有的 GitHub 仓库中更新。

我们还提供了其他代码包，来自我们丰富的书籍和视频目录，您可以在 github.com/PacktPublishing/ 中查看。快来看看吧！

使用的约定

本书中使用了多种文本约定。

文本中的代码：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号。例如：“从 GitHub 中，点击该仓库中的 task-definition.json 文件。”

代码块如下设置：

...    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}

粗体：表示新术语、重要词汇或屏幕上显示的词汇。例如，菜单或对话框中的词汇会像这样显示在文本中。例如：“展开 监控，然后开启 使用容器洞察 以启用容器洞察功能。”

提示或重要说明

如此显示。

联系我们

我们随时欢迎读者的反馈。

常规反馈：如果您对本书的任何部分有疑问，请通过电子邮件联系我们：customercare@packtpub.com，并在邮件主题中注明书名。

勘误表：尽管我们已尽最大努力确保内容的准确性，但错误总是难以避免。如果您在本书中发现任何错误，我们将非常感激您向我们报告。请访问www.packtpub.com/support/errata并填写表格。

盗版：如果您在互联网上发现任何形式的非法复制版本，我们将非常感激您提供相关网站或地址。请通过电子邮件联系我们：copyright@packt.com 并附上相关链接。

如果您有兴趣成为作者：如果您对某个主题有专业知识并有意写作或贡献一本书，请访问authors.packtpub.com。

分享您的想法

阅读完《拥抱 DevOps 发布管理》后，我们非常希望听到您的想法！请点击这里直接前往亚马逊书评页面并分享您的反馈。

您的反馈对我们以及技术社区非常重要，将帮助我们确保提供优质内容。

下载本书的免费 PDF 副本

感谢您购买本书！

您喜欢随时随地阅读，却无法携带纸质书籍吗？

您的电子书购买与您选择的设备不兼容吗？

不用担心，现在每本 Packt 书籍都会免费附赠该书的无 DRM 版 PDF。

任何地方、任何设备上阅读。搜索、复制并粘贴您最喜欢的技术书籍中的代码，直接应用到您的项目中。

特权不止于此，您还可以获得独家折扣、新闻简报，以及每天通过电子邮件收到精彩的免费内容

按照以下简单步骤获得福利：

1. 扫描二维码或访问以下链接

packt.link/free-ebook/978-1-83546-185-3

1. 提交您的购买证明

2. 就是这样！我们会直接将您的免费 PDF 和其他福利发送到您的邮箱

第一部分：理解软件开发生命周期及其设计

在本书的第一部分，我们将首先探讨软件开发生命周期（SDLC）以及它为何如此重要。接下来，我们将简要介绍发布管理和常见的发布管理生命周期阶段。然后，我们将深入探索各种 SDLC 发布管理模型的工作原理。尽管本书专注于 DevOps 发布管理，但首先理解 SDLC 及其与发布管理的关系，以及它们在整体项目管理中的位置，仍然至关重要。

本节包含以下章节：

• 第一章，理解软件开发生命周期

• 第二章，发布管理简要介绍

• 第三章，SDLC 发布管理模型有哪些？

第一章：理解软件开发生命周期

软件开发生命周期（SDLC）是软件行业用于创建新软件的程序。该方法确保软件开发人员能够在最短时间内构建高质量、具有竞争力的产品。

SDLC 涵盖了多个阶段，如规划、编写、测试和维护代码。软件工程师遵循软件开发生命周期来构思和开发适用于多个平台的软件应用，包括笔记本电脑、桌面计算机、云基础设施、移动设备、视频游戏系统、自助终端及其他技术平台。“生命周期”这一概念最早在 1950 年代被提出，用以描述创建新计算机系统的几个阶段。然而，它已经广泛应用于涵盖软件生产的所有阶段。

尽管本书关注的是DevOps 发布管理，但首先了解软件开发生命周期至关重要，了解它与发布管理的关系，以及两者在整体项目管理中的定位。简而言之，SDLC 是项目管理工具箱中的一项强大工具。它提高了团队每个人的关注度和效率，最大化了他们的生产力。

在第一章中，您将学习以下内容：

• SDLC 的定义

• SDLC 的七个阶段

• SDLC 与其他生命周期管理方法论的比较

定义 SDLC 并探讨其七个阶段

SDLC 指的是开发团队用来以最优成本效率生产高质量软件的系统化方法。其主要目标是降低风险，并确保所开发的软件超越客户的期望。通过这种方法，您将首先制定一个全面的战略，以指导产品开发，然后将其分解为更易管理的组件，便于安排、完成和衡量。

SDLC 可以理解为一个概念框架，概述了所选方法论所包含的多个阶段，而不是一种方法论本身。也就是说，SDLC 过程在不同的团队和产品中会有所不同。然而，值得注意的是，许多常见的 SDLC 模型在实际应用中共享相同的阶段。这些阶段包括规划与分析、设计、构建、测试、实施和维护/支持。

图 1.1：SDLC 的七个阶段

1. 规划与分析

SDLC 的第一阶段是项目规划阶段，在此阶段，你将收集来自客户和利益相关者的业务需求。该阶段的主要目标是帮助你定义客户所面临的基本问题，并发现合适的解决方案。规划有助于识别开发新系统所需的关键组件，通过运用有计划和系统化的过程来满足项目需求。分析阶段使你能够在开始新的软件开发工作之前获得必要的资源。在此阶段，还需要计算完成项目所需的资源、成本和时间。

为了有效地确定生产范围、优先排序生产项目并制定开发节奏，业务分析师与客户合作，收集需求、确定目标群体，并与行业专家进行咨询。所有这些都是为了编写一份全面的业务规范(BS)文档。不同的组织和团队可能将此文档称为客户需求规范(**CRS*)。需要注意的是，尽管创建 BS 文档被认为是良好实践，但一些开发团队可能选择不使用该文档，而采用不那么正式的方法，正如你将很快发现的那样。

BS 文档的目标是列出客户当前存在的问题，以便程序员能通过软件来修复这些问题。这可以作为一个有价值的工具，帮助团队跳出框架思考如何提升产品。确认软件项目符合业务和利益相关者目标、可行并满足用户需求后，应该将文档交给开发团队。

2. 定义需求

上述阶段至关重要，因为它有助于将你在规划和分析阶段所获得的数据转化为开发团队成员所需的明确定义的需求。定义需求有助于创建多个重要文档，包括软件需求规范(SRS)、用例文档和需求可追溯性矩阵文档，如果需要的话。

根据业务规范文档，开发团队的高级成员与利益相关者和专家合作，规划软件开发项目。该项目可能是开发一个新软件产品，或是提升现有产品的性能。在这个早期阶段识别潜在的困难至关重要。如果发现问题，管理者和开发人员会提出各种解决方案，然后进行展示和分析，以确定最佳的替代方案。

在开发的初步阶段，团队成员就以下内容进行合作，制定全面的计划：

• 项目的意图

• 项目的需求

• 预期问题

• 机会

• 风险

本阶段的主要目标是准确确定项目的功能需求。进行这一必要分析能够确保最终交付的成果与客户的具体需求和期望保持一致，并包含必须采取的积极措施，以确保满足客户的需求和偏好。

简而言之，这个 SDLC 阶段作为一个综合的技术蓝图，用于客户表达他们对项目的期望、需求和要求。通过定义这些元素，您可以确保在设计和开发过程中，软件项目的各个方面都能得到公平的考虑。

3. 设计

设计阶段是将想法转化为具体形式的时刻。初步的策略和愿景将在软件设计文档（SDD）中进一步发展和记录，该文档定义了多个方面，如系统架构、编程语言选择、模板使用、平台选择以及应用安全措施的实施。这也是您可以创建图表和流程图的位置，展示软件如何响应用户活动。有时，设计过程还包括创建最小可行产品或概念验证。产品的预生产版本有助于您想象最终产品的样子。这有助于确保所需调整尽量减少，也有助于团队避免完全重新编写代码。

SDD 在生产过程中将发挥至关重要的作用，尤其是在开发阶段（见第 4 阶段）。开发人员将主要依赖 SDD 作为编写代码的参考。为了减少在早期阶段识别到的潜在问题和风险，您还必须参考 SRS 文档。它作为设计产品的参考点，确保产品在设计时采取措施保护团队免受早期识别的潜在风险影响。

一个展示设计阶段有用性的现实世界例子是，地方和联邦政府机构如何利用这一阶段建立可扩展的框架，这些框架是一致且可重复的。为了实现这一点，SDLC 的设计阶段可能包含由集中管理的部门创建的预先安排的模板和指南，这些内容结构化，用于定义、实施和沟通项目的各个方面。例如，这有助于扩展用于颁发和管理驾驶执照、选民登记卡和图书馆卡的应用程序，这些卡在多个司法管辖区之间是互操作的。特别是在管理资源水平不同、领导风格各异的不同司法管辖区时，这一点非常有用，但它们必须保持联邦制。这种前瞻性思维有助于确定与实际实施相关的成本，或确保最终结果能够服务于所有相关的利益相关者。

在 SDLC 的第三阶段中，需要记住的一点是，最终用户应该有机会审查设计并提出任何对预期系统的修改意见。在这一阶段，你将与团队共同努力，创建最终的技术设计文档，然后进入生产阶段。此时，开发新软件或系统所需的所有必要要求应该已经确定，并且可以创建工作积压清单。

4. 开发

SDLC（软件开发生命周期）的第四阶段是项目真正开始的地方。在这一阶段，程序员、系统工程师和业务开发人员组成团队，开始进行软件开发。此时，通常会创建甘特图或看板，以确保项目工作的进展保持顺畅的节奏。开发团队通常会通过两种方法之一来组织他们的工作：实施冲刺或者作为一个持续的、连续的开发努力。无论采用哪种方法，团队都会尽力尽快完成任务。

重要说明

冲刺：冲刺是开发团队用来完成一定工作量的限定时间。冲刺的持续时间可以从一周到一个月不等，但通常是两周。冲刺的短时间限制促使开发人员优先发布适度的、渐进的改进，而不是发布大规模的变化。因此，程序的调试时间较少，最终用户的体验得到了改善。

持续开发：采用持续开发和敏捷开发的方式有许多相似之处。与其一次性对软件进行大规模的改进，不如通过持续的增量更新，将代码在完成并经过测试后尽早发布给用户。软件开发、测试和向生产环境发布更新都可以通过持续开发进行精简和自动化。

在开发阶段，产品代码按照 SDD（请参见第 3 阶段）编写，以确保产品可以高效地生产。这包括开发团队从零开始构建新系统，或以新的需求和新视角来处理现有项目。这可能包括从现有系统向云端的新系统进行平滑且具有成本效益的数字化转型。

在这个阶段，开发人员将项目拆解成更小的软件组件，这些组件最终将组成完成的产品。为了构建代码，开发人员会使用各种工具和计算机语言。这些工具和语言的选择是根据所构建软件产品的需求来决定的。

一些编程工具可能包括以下几种：

• 集成开发 环境 (IDEs)：

  • Eclipse

  • Microsoft Visual Studio

  • PyCharm

• 版本 控制系统：

  • Git

  • GitHub

  • Gitlab

  • Bitbucket

一些常见的编程语言可能包括以下几种：

• C#

• C++

• Python

• JavaScript

• Go

高层领导在这一阶段的紧密参与对于实现项目目标至关重要，因为 SDLC 的这一阶段可能需要大量时间。必须设定预定的时间框架和里程碑，以确保软件开发人员明确目标，并且你可以监控他们的进度。在这一阶段结束时，大部分的产品代码将完成。

在某些情况下，开发阶段可能与测试阶段重合，此时将进行特定的测试，以确保软件没有重大缺陷。

5. 测试

在不进行充分的测试其功能和特性之前，软件的生产既不可行也不明智；第五阶段专门用于测试。为了确保一切正常工作，质量保证工程师将进行一系列测试，包括代码分析、安全性、集成、性能和功能测试。通过反复测试和分析，可以成功解决缺陷和错误。在系统设计满足客户需求之前，你将需要进行持续的测试。尽管团队进行手动软件测试总比没有测试好，但最好在可能的情况下将所有测试都自动化。

产品测试应由质量保证团队在将软件发布到生产环境之前进行，以确保其功能完备并实现预期目标。在测试阶段，还可以解决用户体验或安全性方面的主要问题。无论如何，适当的测试将确保软件的每个组件都按预期工作。产品开发的最后一步包括验证、确认和用户接受测试。如果产品走到这一步，它很可能已经准备好发布。

包括测试在内，软件应经过正式的质量保证（QA）程序，以认证产品的质量。软件测试通常包括以下几种测试：

• 性能测试：性能测试是一种常用的测试策略，旨在评估系统在特定工作负载下的响应能力和稳定性。此外，它还可用于检查、量化、验证或证实多个其他系统质量特性，包括可扩展性、可靠性和资源利用率。

• 功能测试：功能测试，或称黑盒测试，是一种质量保证过程，通过基于被评估软件组件的文档需求来创建测试用例。功能软件测试的目的是确定系统或其各个部分是否满足预定义的功能需求。通过观察输入的响应来测试功能，通常不会考虑代码的底层结构。

• 安全测试：安全测试通过检测安全问题帮助信息系统保护数据并正常运行。由于安全测试的逻辑限制，测试通过并不意味着系统完美或符合安全标准。安全需求可能包括机密性、完整性、认证、可用性、授权和不可否认性。系统安全需求决定了需要测试的安全要求。安全测试有许多定义和方法，通过建立基础，安全分类法帮助我们掌握这些技术和含义。

• 单元测试：单元测试是一种通过评估离散代码部分或“源代码单元”来验证软件质量的技术，测试对象可以是一个或多个计算机程序模块，以及其对应的控制数据、使用过程和操作程序。

• UI/UX 测试：在用户界面（UI）测试中，测试人员验证屏幕上的元素，包括按钮、字段和标签，是否按预期执行。具有控件的屏幕，如工具栏、颜色、字体、大小、按钮和图标，作为 UI 测试的一部分，用于测试它们对用户输入的响应。UI 测试软件的目的是模拟最终用户与产品或服务的体验。

• 回归测试：回归测试是在进行修改后重新执行功能性和非功能性测试，以确认程序是否仍按预期工作。软件回归是指软件中的一个缺陷，某个以前正常工作的功能突然停止工作。软件更新、功能添加甚至微小的配置调整都可能需要额外的测试，以确保兼容性。由于随着每个缺陷的发现，测试套件呈指数增长，因此回归测试通常会采用自动化测试。

• 用户验收测试：软件开发的最后阶段是用户验收测试（UAT），在这一阶段，最终用户和客户会在实际场景中评估产品，以评估其功能性和实用性。UAT 重点考察软件是否能够在用户的实际系统中正常工作，而非其设计或功能。开发团队必须执行 UAT，因为他们的软件假设在日常工作中可能因为沟通不畅、误解、疏忽或需求变化而不成立。测试人员在实际情况下测试软件，并在 UAT 期间提供反馈，以便开发者在发布前修复任何缺陷。

6. 部署

在测试完成后，产品将发布到市场，但这可能仅仅是在你所在的组织内部。根据商业模式，产品部署可能涉及多个步骤，或者采用许多策略，从一次性发布到滚动发布或两者之间的某种方式。如果产品分阶段发布（如蓝绿部署或金丝雀部署），测试时间将会更多。最终产品的发布或对代码进行进一步调整的需求取决于收到的反馈。部署阶段通常会带来一些未知的、不理想的结果，你应该有所预期。

7. 维护

在第七个 SDLC 阶段，维护和升级被优先考虑。此时，系统可以进行调优以提高性能，并且可以随着时间的推移添加新功能。软件部署将会进行持续监控，以减轻潜在的性能和安全问题。此外，管理员或站点可靠性工程师一旦发现任何漏洞或缺陷，必须及时报告，以便尽快修复。

客户将根据自身的需求以不同的方式使用软件产品；这意味着可能存在需要修复的具体问题。这是因为用户可能会发现开发者和测试人员未注意到的缺陷和瑕疵。为了提升用户体验和提高用户留存率，立即解决和修复这些缺陷至关重要。在某些情况下，这些问题可能需要回到软件开发生命周期的第一阶段。软件开发生命周期的每个阶段，也可能因你在后续版本和升级中希望添加的新功能而重新启动。

一般认为，维护阶段是软件开发生命周期的最后阶段。尤其是在采用瀑布式发布管理的情况下，这一点尤其如此。尽管如此，业界正在向更敏捷的软件开发方法转变，例如 DevOps，其中维护仅仅是进一步增强的迭代步骤。

定义一些常用术语

以下是本书中常见的一些术语及其定义：

• 大爆炸式发布：大爆炸式发布方法缺乏其他发布管理模型中的过程导向特征，不需要提前准备。这一策略的主要焦点是软件开发，它允许程序员跳过规划阶段，直接进入代码生产阶段。

• 滚动发布：滚动发布，通常称为滚动更新，是一种软件开发模型。软件的改进是以持续、渐进的步骤进行，而不是通过离散的版本发布。用户可以随时升级程序以获取最新版本，并且被鼓励经常更新。

• 蓝绿部署：蓝绿部署创建了两个相同的环境。一个环境（蓝色）运行现有的程序版本，另一个环境（绿色）运行新版本。在绿色环境通过测试后，实时应用流量会转移到绿色环境，蓝色环境将被弃用。通过简化回滚过程（如果部署失败），蓝绿部署策略提高了应用可用性并降低了部署风险。

• 金丝雀部署：金丝雀部署是一种逐步且可控的应用发布策略，其中流量在现有版本和新版本之间分配。此方法首先将新版本引入一部分用户，随后再扩大到整个用户群体。通过这种方法，可以在新版本广泛发布之前，先评估更新版应用的可靠性。

在部署阶段结束时，您的最终产品将交付给终端用户。此时，部署工程师会在业务环境中安装软件和/或为用户提供帮助，确保程序能够正常运行。根据您的团队所遵循的 SRLC 类型，您可以自动化此过程并安排部署。例如，在实施单个功能更新的情况下，可以通过将其首先发布给有限的部分客户来执行此过程；这被称为“金丝雀发布”，如前所述。如果您正在开发全新的软件，您可能选择先以 alpha 版本在内部进行发布。稍后我们将简要扩展 SRLC，但该主题被视为超出本书讨论范围的内容。

现在我们已经涵盖了 SDLC 的七个阶段，接下来让我们看看它与其他生命周期管理方法相比如何。

SDLC 与其他生命周期管理方法的对比

如果您熟悉产品管理概念，那么您会知道，SDLC 并不是唯一的生命周期管理程序。以下是一些相关概念以及它们与 SDLC 的区别。

软件开发生命周期与系统开发生命周期的对比

系统开发生命周期是规划和构建信息技术系统的过程。有时，人们会用缩写 SDLC 来指代此过程；你看到了吗？这在指代软件开发生命周期时可能会造成混淆。在系统开发方面，一个系统通常由许多单独的硬件和软件组件组成，这些组件相互协作，执行复杂的任务和计算。只需知道，当你看到缩写 SDLC 时，要注意文献中的上下文线索，以便正确区分你所阅读的是指软件开发还是系统开发。

重要提示

在本书中，我们将把软件开发生命周期称为 SDLC。

SDLC 与系统开发生命周期之间有一些关键区别。SDLC 仅限于软件组件的创建和测试。相比之下，系统开发包括了硬件、软件、人员和流程的设置和管理，这些都是构成完整系统所需的。此外，SDLC 专注于程序本身，而系统开发可能涉及如组织培训和变更管理等活动，这些活动并不总是与软件开发相关联。

SDLC 与发布管理的对比

发布管理是指对 SDLC 的系统化监督和控制。其职责包括监督软件产品开发的各个阶段，即规划、设计、测试、部署和发布。发布管理的加入是 SDLC 的重要补充。发布管理的主要目标是确保开发团队有效地实现业务目标，并生产出高质量的软件。总的来说，发布管理在开发与运维领域之间起着至关重要的中介作用。

SDLC 与发布管理之间存在一些关键的区别。SDLC 的主要目标是降低风险，并确保开发工作有条理地进行。相比之下，发布管理的主要目标是确保开发团队的良好组织，并成功实现业务目标。此外，SDLC 主要集中在新软件的持续集成上，而发布管理则侧重于其持续交付。然而，两者都归发布或项目经理管辖。

SDLC 与 ALM（应用生命周期管理）对比

应用生命周期管理（ALM）是一个综合性的概念，涵盖了软件应用开发的整个过程，从初步的创意生成和设计阶段，到开发、测试、生产、支持，最终直至程序的退役。这个概念与 SDLC 相似，虽然在表面上它们可能看起来有相似之处，但需要注意的是，两者之间存在几个显著的区别。

SDLC 主要侧重于应用的开发阶段，而 ALM 则采取更为全面的方法，涵盖了整个程序的生命周期。有效管理应用开发的各个阶段需要多个 ALM 工具、流程和团队的协作与整合。需要注意的是，一个应用的生命周期可能在更广泛的 ALM 框架下，包含多个 SDLC。

SDLC 与 PDLC（产品开发生命周期）对比

产品开发生命周期是一个全面的过程，涵盖了产品的整个生命周期，从构思一个创意开始，到产品最终停产为止。这个过程包括产品规划、市场调研、产品设计、开发、测试、发布、营销和支持等活动。

SDLC 和 PDLC 之间存在一些关键的区别。SDLC 主要关注软件开发过程，而 PDLC 则主要集中于整个产品的开发。此外，SDLC 包括几个不同的阶段，包括规划、设计、编码、测试和部署。相比之下，PDLC 包含了附加的阶段，如市场调研、产品规划和产品营销。此外，SDLC 旨在开发符合最终用户特定需求的软件。而 PDLC 则专注于创建一个能够满足市场需求并为企业带来收入的产品。

SDLC 与 SRLC（软件发布生命周期）

收集、文档化和验证软件需求是软件发布生命周期（SRLC）的主要目标。收集来自各方的需求、按重要性排序、写入需求规格说明书，并检查其准确性，都是这一过程的一部分。

SDLC 和 SRLC 之间存在一些关键的区别。与 SDLC 相比，SRLC 更侧重于管理软件需求。SDLC 由规划、设计、编码、测试和部署等阶段组成，而 SRLC 则增加了需求引导、分析和验证等阶段。虽然 SDLC 力求创建满足用户需求的软件，但 SRLC 则在编码之前确保这些需求已经明确。

发布管理与变更管理

发布管理和变更管理是两个关键过程，在成功地将软件更新和增强功能交付给客户方面发挥着至关重要的作用。

发布管理和变更管理的领域是相互关联的，尽管它们的范围和目标不同。发布管理的主要目标是监督软件版本的全面交付，而变更管理则主要关注管理构成版本的各种变更。发布管理主要关注软件版本的技术方面，包括发布计划、环境和部署等元素。相反，变更管理则主要处理软件变更的业务方面，包括变更请求、审批和沟通。发布管理和变更管理涵盖了不同的角色和职责，包括发布经理、发布工程师、变更经理、变更分析师和变更审查员。

发布管理是指系统化地组织、协调、评估和实施跨多个环境的软件发布，包括开发、测试、预发布和生产环境。发布管理的主要目标是保证软件发布的及时交付，同时遵循预算限制并尽量减少终端用户可能遇到的任何潜在干扰。新特性、漏洞修复、功能增强和配置更改都是变更管理旨在跟踪的变更类型。变更管理的目的是使变更得到接受、文档化，并与相关方进行沟通，以便它们能对业务及其目标、需求和标准产生最大可能的积极影响。在部署任何修改之前，测试和验证软件系统的任何变更非常重要，这正是变更管理的核心内容。

发布管理与项目管理

发布管理一词用来描述监督软件发布的创建和分发过程，包括其规划、调度、测试和部署。它提高了开发团队交付的软件产品和升级的速度与质量。简而言之，发布管理是确保从开发到预发布，再到生产的顺利过渡的过程。从更广泛的角度来看，项目管理的目标是确保在预先设定的范围内完成特定项目的成功。这包括时间限制、计划、财务和沟通的规划。每当一个产品接收到新版本或更新时，这就算作项目的一部分。

项目管理和发布管理共同提高了团队成功完成项目的几率。发布管理与项目管理相似，都是具有明确结构和一系列阶段的过程，尽管方法本身是独特的。以下是一些项目管理方法的例子：

• Scrum

• 精益

• 六西格玛

• 极限编程（XP）

• PriSM

• PRINCE2

这就是第一章的内容。在这一章中，你了解了软件开发生命周期（SDLC）的定义，并探讨了它的七个阶段。最后，你了解了 SDLC 与其他生命周期管理方法的区别。在下一章中，我们将详细了解软件发布管理，以便理解其含义。

摘要

有了 SDLC 策略的帮助，项目管理变得更有效。管理者、设计师、开发人员和客户都能从这一工具提供的全面基础中受益。SDLC 的七个阶段都是至关重要的，并且相互依赖、相互促进。

在模型的初始阶段，资深成员负责收集需求。同时，IT 专业人员收集在产品生命周期内所需的所有数据和资源。在确定所需信息后，适当的文档将被草拟。随后的阶段包括设计和编码过程，接着是测试阶段，用于评估软件的功能性。最后阶段是部署和维护。团队可以选择使用不同的模型，包括广泛认可的瀑布模型和敏捷方法。对于软件开发来说，遵循 SDLC 至关重要。如前所述，了解 SDLC 的不同阶段是一种有效的方法，帮助产品经理在 SDLC 内部建立跨职能和以客户为中心的活动之间的共同理解和联系。这有助于在更广泛的企业目标、计划和努力中清晰地划分产品。

问题

1. SDLC 的定义是什么？

2. SDLC 的七个阶段是什么？

3. SDLC 和系统开发生命周期之间有什么区别？

4. 软件开发生命周期和发布管理之间有什么区别？

5. SDLC 和应用生命周期管理之间有什么区别？

6. SDLC 和产品开发生命周期之间有什么区别？

7. 发布管理和变更管理之间有什么区别？

8. 发布管理和项目管理之间有什么区别？

9. 蓝绿部署和金丝雀部署之间有什么区别？

10. SDLC 的七个阶段是什么？

第二章：发布管理简介

在软件工程领域，新发布或改进的软件产品被称为发布。这包括与其开发相关的所有程序和工件。

发布是软件开发和工程过程的高潮，它代表了产品的一个迭代版本，既全面又完全功能化。在软件产品向公众发布之前，通常会经过 alpha 和 beta 测试阶段。发布通常用于描述软件的最终、完善版本，尽管它也可以用来描述 alpha 或 beta 版本的首次发布。您也可能会在讨论发布时遇到“启动”和“增量”这两个词。

大多数公司使用顺序号或字母来标记它们的发布版本。术语软件版本控制描述了这种命名约定。每个组织都会一致地应用自己的内部标准，但语义版本控制（semver）是业内广泛使用的标准，规定了这些唯一标识符如何从一次发布到下一次发布演变。

在本章中，我们将定义发布管理，并了解其文化意义和技术视角。此外，我们将回顾发布管理的简短历史，了解它如何随着时间的推移而演变。最后，您将学习任何发布管理模型的标准六个阶段。需要注意的是，瀑布模型是最初的发布管理标准，但使用瀑布模型并非强制性要求。发布管理与您选择的模型无关，并且可以适应许多类型的 SDLC 模型，我们将在第三章中进一步讨论这一点。

本章将覆盖以下主要内容：

• 什么是发布管理，它是如何演变的？

• 解剖发布管理生命周期

什么是发布管理，它是如何演变的？

发布管理是一整套活动，涉及战略规划、构思、调度、严格测试、无缝部署以及有效控制软件发布的过程。此实践的主要目标是通过软件开发团队快速交付关键的应用功能和改进，同时保持已建立的生产环境的完整性、机密性和可用性，从而满足客户需求。

在商业和 IT 的竞争环境中，缺乏质量或功能的产品发布是让竞争对手获得优势的最快方式。现代企业是动态的，各种变化以不同的速度完成。企业需要发布控制和自动化部署来协调所有这些变化，以确保最终产品提供客户所期望的卓越价值。成功的发布管理提高了发布的频率，并减少了质量问题发生的频率，从而使企业能够更快地提供软件，同时减少相关的风险，提高生产力、沟通和合作。

由于这些改进，团队现在能够在比以前更短的时间内持续生成高质量的软件，这使得组织能够更好地应对客户需求或运营环境的变化。标准化和简化开发和运营流程是发布管理的另一个好处。团队建立了可以审计的发布控制，从而形成一个可以提取所有发布内容的集中位置。通过制定标准化、书面的发布流程，组织的成熟度可以进一步提高。如果团队标准化并专注于产品，他们可以从过去的发布中学习，并将这些知识应用到未来的迭代中。

运营和开发人员之间的沟通改进得到了广泛欢迎，因为它减少了意外情况的发生。现在，跨职能团队不必再担心发布后，运营因错过截止日期而被迫修补和祈祷或应急处理，而是能够减少这些问题。这样，团队可以有更多的时间来自动化业务流程或修复开发和生产环境中集成配置的不兼容问题。

定义

让我们快速定义在本书中可能会遇到的一些关键术语：

• 修补和祈祷：在软件开发中，所谓的“修补和祈祷”策略指的是使用脆弱的解决方案，有时被称为“补丁”，来解决缺陷或漏洞，而并没有解决问题的更深层次根源。

  组织普遍采用这种技术来设定严格的截止日期、优先处理其他活动，或弥补资源不足；然而，这种策略可能导致长期的技术债务以及显著的安全隐患。

• 灭火：在计算机科学领域，灭火是指分配资源来解决突发问题。这个词语表示的是调试，而非功能集成。灭火可能涉及在软件开发的产品发布临近时，增加工程师来修复发现的代码问题。

  很多企业已经做好了应对突发状况的准备，但频繁的紧急情况往往表明计划不周、效率低下，以及浪费本可以用于其他地方的资源。全面的灾难恢复规划（DRP）可以预见并或许避免灾难，从而最大限度地减少应急响应。

• 抛到墙外：这是商业术语，指的是完成了项目的一部分后将其交给下一个小组。这句话通常是在两个小组之间沟通很少，或者在新部署前几乎没有时间进行技术简报时使用的。

简而言之，发布管理促进了 IT 公司内部各部门之间的协作。这使得产品分发过程得以进行更全面的改进。

现在，既然你已经理解了发布管理的含义，我们来扩展一下这个话题。在接下来的章节中，我们将回顾发布管理的历史，看看新的模型是如何随着时间的推移出现的，并且如何与当时的当代软件开发理念对接。稍后，我们将通过审视任何发布管理模型应该包括的六个标准阶段来结束本章。

发布管理的简史

软件工程的焦点从基于项目转向基于产品的转变，促使发布管理的重要性日益增加。从发布管理的初期，任务是在基于项目的开发框架内执行的。在这种方法中，软件开发人员将每次发布视为一个独立的项目，而不是一个产品。一旦软件开发完成，通常意味着开发人员在过程中的角色也结束，他们会解散。

随着时间的推移，软件开发的过程逐渐演变，变得更加类似于产品周期，在这个过程中，产品会经历支持、增强和多次重新发布，跨越较长的生命周期。在这个特定的结构中，开发的主要目标不是发布本身，而是发布作为支持和修订活动开始的分界点。由于这种复杂性，阶段协调变得比以往任何时候都更为重要。因此，现代发布管理借鉴了以业务为导向的产品管理理念，其中包括售后支持和增强。

从软件到发布管理的演变

当英国计算机科学家汤姆·基尔本在 1948 年创建第一段软件时，他使用了 8 个工作存储字和 17 个指令字，共计 25 个字。从那时起，软件开发过程已经取得了显著进展。

尽管同事们嘲笑他，1953 年，保罗·尼凯特提出了一个概念：计算机的程序可以与设备的物理组件分开存储。从那时起，这一思想彻底改变了人们对计算的认知：

当我第一次大声说出“软件”这个词时，周围的人都说：“哈？”从一开始，我就觉得这个词太不正式，不敢写出来，甚至说出来也常常让我觉得尴尬。然而，带着带有些许得意的恐惧，我确实在五十年代时偶尔在演讲、讲座和媒体采访中使用过“软件”这个词。

（保罗·尼凯特，《导言：软件时代》）。

在 20 世纪上半叶，当电子数值积分器和计算机（ENIAC）等发明加速了计算机的发展时，软件尚不复杂到需要像软件开发生命周期（SDLC）这样的框架。最初的软件实现中使用了简单的工具，如跳转语句和 if/then 表达式。随着开发模型的需求不断增加，最终导致了 SDLC 的出现，而 SDLC 又受到结构化编程思想的启发。

结构化编程是一种编程范式，通过采用结构化控制流组件，如选择（if/then/else）和重复（while 和 for），以及块结构和子程序，来提高计算机程序的清晰度、质量和效率。1950 年代末，ALGOL 58和ALGOL 60编程语言的出现标志着该领域的一个重要发展。值得注意的是，ALGOL 60 在 1960 年引入了对块结构的支持，进一步增强了其功能。

软件开发方法论，通常被称为SDM，直到 1960 年代才开始实践。系统开发生命周期（SDLC）可以看作是最早公开发布的发布管理方法论和框架，用于构建大型计算机和其他模拟信息系统，早于软件开发生命周期的提出。系统开发生命周期的主要目标是系统地、精细地推进信息系统的开发。这意味着严格且按顺序遵循生命周期的每个阶段，从最初的构思到最终在所采用的特定框架内交付系统。值得注意的是，通过将系统替换为软件，诞生了一种新的 SDLC 形式。它力求成为行业的最终标准，通过详细列出创建和维护软件系统的输入、输出和步骤。

瀑布模型这一术语是在其正式的 SDLC 规范被发明多年后才出现的（你可以在第三章的图 3.2中看到瀑布发布管理模型的六个阶段示意图）。首次描述在软件工程中使用瀑布模型各阶段的报告是由赫伯特·D·贝宁顿（Herbert D. Benington）于 1956 年 6 月 29 日举行的，尽管当时并未使用“瀑布”这一术语。最早的正式、详细的瀑布模型示意图可以追溯到温斯顿·W·罗伊斯（Winston W. Royce）于 1970 年发表的文章，但罗伊斯的文章中并没有使用“瀑布”这一名称。瀑布这一术语据称首次出现在托马斯·E·贝尔（Thomas E. Bell）和 T.A.塞耶（T.A. Thayer）于 1976 年发表的研究论文中。到 1985 年，瀑布发布管理方法被美国国防部在 DoD-STD-2167A 标准中正式规范。美国国防部针对与软件开发承包商合作的标准中指出：“承包商应实施一个包括以下六个阶段的软件开发周期：软件需求分析、初步设计、详细设计、编码与单元测试、集成和测试。”

从 1960 年代 NASA 的水星计划开始，迭代和增量开发（IID）成为瀑布发布管理的最早也是最接近的竞争者之一。部分水星计划团队成员后来成立了 IBM 的一个子公司，负责为航天飞机创建核心的航空电子软件系统，该系统从 1977 年运行到 1980 年。在 31 个月的时间里，该团队进行了 17 次 IID 迭代，每次迭代的持续时间平均为 8 周。他们决定放弃使用瀑布开发方法，因为航天飞机计划的需求在软件开发过程中已知会发生变化。

在 1986 年的研究中，巴里·博厄姆（Barry Boehm）首次概述了螺旋模型，并提供了如今广为人知的示意图，后续有许多出版物采用了这一图表进行讨论：

图 2.1：螺旋发布管理模型（图片来源：static.hlt.bme.hu）

IT 基础设施库（ITIL）始于 1980 年代，响应数据中心的去中心化和地理多样化架构的使用。这种行为导致了流程和部署的差异，进而引发了企业内部 IT 服务管理的不一致或不满意。英国的中央计算机与电信机构（CCTA）认识到将信息技术视为一种服务，并在整个信息技术服务生命周期内使用一致的程序的重要性。因此，CCTA 制定了政府信息技术基础设施管理方法论。到 1989 年，CCTA 发布了 ITIL 版本 1。

V 模型概念在 1980 年代后期同时出现在德国和美国，尽管是独立发展的。美国的 V 模型在 1991 年《国家系统工程委员会》（NCOSE，自 1995 年起更名为 INCOSE）的会议记录中进行了阐述，专门为涵盖硬件、软件和人机交互的卫星系统设计。德国的 V 模型最初由 IABG（位于奥托布伦的研究与开发机构）制定，并与位于科布伦茨的联邦国防技术与采购局合作。这项联合工作由联邦国防部主导。1992 年夏，联邦内政部接管了民用公共权威领域的管理。

Jacobson、Booch 和 Rumbaugh（1999）在其名为《统一软件开发过程》的著作中提出了统一过程的概念。这部开创性的著作首次提出了一个敏捷框架的软件开发方法论。

敏捷发布模型的起源发生在 2001 年，美国犹他州 Snowbird 的一家著名度假村。17 位著名软件工程师聚集一堂，讨论轻量级开发方法论，最终共同制定了敏捷软件开发宣言（即“敏捷宣言”）。2009 年，与敏捷宣言共同作者之一罗伯特·C·马丁（Robert C. Martin）相关的一群人，发展出了一个软件开发原则的扩展，称为软件工艺宣言。该宣言旨在根据职业道德和精通的原则，引导敏捷软件开发的实践。

2007 年，一位名叫 Patrick Debois 的 IT 顾问在意识到开发（Dev）和运维（Ops）团队之间的合作效率不高后，提出了 DevOps 方法论。尽管他一直觉得 Dev 和 Ops 之间的分歧和矛盾令人不悦，但在一个他负责测试的大型数据中心迁移项目中，团队间的不断切换和反复工作令他尤为沮丧。有一天，他完全沉浸在敏捷软件开发的流程中。第二天，他又参与了紧急问题处理，亲身体验了传统运维带来的不确定性。他确信一定有一种更高效的方法。

Andrew Shafer 在 2008 年敏捷大会上组织了一次志同道合者（BoF）聚会，讨论敏捷基础设施。Andrew 原以为没有人会参加这次会议，所以他决定自己不去参加。当 Patrick Debois 出现时，他立刻去找 Andrew，讨论将敏捷基础设施作为让运维像开发人员一样敏捷的解决方案。这就是 DevOps 运动的起点。

在 2009 年的 Velocity 大会上，John Allspaw 和 Paul Hammond 做了一个题为“每天部署 10 次以上 - Flickr 上的开发与运维合作”的演讲，之后这个概念开始在开发团队中获得普及。此次讨论让人们看到了通过采用这些早期的 DevOps 方法，可能实现的各种可能性。此外，Patrick 还组织并主持了 2009 年 10 月在比利时根特举行的第一次 DevOpsDays 大会。此次大会被称为将开发与运维结合的大会，也是DevOps一词首次公开亮相的地方。如今，DevOpsDays 大会已经成为一个在多个地区定期举办的国际性活动。

在下图中，您将看到发布管理历史的时间线。从 1953 年“软件”一词首次提出开始，您可以看到从瀑布模型到 DevOps 的演变。讽刺的是，或许也不那么讽刺，您将发现这两种模型一直被使用，直到今天。一个值得注意的地方是，随着时间的推移，进展的速度是如何加快的，从几十年到仅仅几年。了解过去的历程对于理解现在的成就至关重要。发布管理的历史最终促成了 DevOps 的诞生。了解这一点对于理解为什么 DevOps 已成为软件开发历史上最广泛采用的发布管理模型之一非常重要：

图 2.2：发布管理历史时间线

到目前为止，你已经了解了发布管理的目的及其历史。现在，你知道了新模型是如何随着时间的推移而出现的，以及它们为什么反映了当时的哲学思想。接下来，让我们通过研究发布管理模型应该包括的六个标准阶段来总结本章内容。

解剖发布管理生命周期

发布管理生命周期包括多个不同的阶段：

图 2.3：发布管理的六个标准阶段

这一过程的变动性取决于所选择的发布管理模型、产品设计、团队和组织，因为它们都受到特定项目需求的影响。尽管如此，组织和团队无论规模大小，都必须遵循一套普遍适用的程序，以实现财务可持续性并为用户提供高质量的成果。

现在，让我们看看发布管理的标准程序包括哪些内容。

请求

对新功能请求或现有功能修改的请求是发布管理过程中的第一步。不能保证所有的请求都会导致新的发布。每个请求都需要经过分析，以确定它是否合理，是否可以实施，以及当前版本的应用是否可以修改以适应该请求。

无论你是从零开始，还是想要改善已经建立的产品，了解对你的期望是至关重要的。不要假设你已经知道客户希望在应用程序或相关产品中包含哪些功能和特性。举个例子，客户可能要求你将一项新功能集成到他们的移动应用中。你需要与他们坐下来开会，全面了解他们的需求、愿望和动机。

无论你的目标是什么，确保在进行计划和开发之前充分理解它。如果你有任何疑虑，在继续之前与你的团队或客户进行咨询，以制定出符合需求的合适发布策略。

计划

在你完全理解发布需求后，下一步是计划。为了构建和发布你打算做的内容，你需要进行全面的规划和准备，这些准备工作应基于所有相关方的需求。在技术、截止日期、人员和资源方面，你的准备需要合理且务实。例如，如果你正在开发一个应用程序的新版本进行发布，你需要在各种平台和设备上进行充分的测试，然后才能发布给客户。

如果你与客户保持定期联系，规划就会变得更加容易。项目的进度和最终交付日期可以进行讨论。你不能承诺一个不可能完成的截止日期。在确认截止日期时，要考虑到可用资源（资金、时间和人员）。此外，在发布之前，考虑你将使用哪些技术并进行相应规划是明智的。考虑你的选择是否具备成本效益，是否符合预算，并且是否能充分利用团队成员的才能。选择那些能够帮助你快速且轻松地设计高质量产品并将其推向客户的工具。规划还需要高效地分配和利用现有资源，以防止浪费，并确保产品的高效构建。

你可以选择多种方式来概述你的计划，其中之一是使用发布管理检查清单。在检查清单中，应按大致的时间顺序概述各个角色和责任。如果你的团队查看该清单，他们应该能够轻松地确定当前所处的阶段，以及他们在过程中的任务或角色。为了制定一个稳固的发布计划，与你的开发团队和运营团队召开会议，讨论需求、障碍和克服障碍的策略，包括实现目标的最有效方法。如有疑问，邀请客户参与讨论。

设计与构建

在战略完成后，接下来的步骤是设计和开发产品。根据这些具体需求制定的计划和策略现在可以付诸实践。为了完成这一阶段，程序员需要编写代码，这些代码最终将转化为你计划添加到产品中的特性或功能。

在整个发布周期中，这一阶段可能会反复进行，类似于 DevOps 中的持续开发策略。在开发者完成编写代码后，代码中可能存在许多问题、故障和缺陷，需要进行测试。在最终接受之前，代码将经历多轮测试。所有需要解决和优化的问题列表应该提供给开发者，以便他们能够优先处理待办事项，并生成符合预期的高效软件。帮助解决这一问题的一个方法是使用缺陷跟踪工具，如FindBugs、Eslint和Sonarlint。

测试

如前所述，测试代码是保证没有错误或缺陷的必要步骤，这些错误或缺陷可能会影响软件的功能、速度或安全性。手动测试总比没有测试要好，但在可能的情况下，应实施自动化测试。

功能测试和非功能测试这两个术语有时被误用为可以互换的概念。如在第一章中提到的，实际上可以进行多种类型的测试，通常都归属于这两个类别。当发现问题时，代码会被送回开发人员，以便他们修复问题并重新提交代码进行进一步审查。

用户验收测试是将软件产品发布给最终用户之前的最后一步，在此过程中，客户将验证软件是否符合他们的需求并按预期运行。接下来的步骤取决于用户的验收情况。否则，用户的反馈将用于修订代码，然后再进行进一步测试，最终发布。

部署

在软件开发团队确认产品已经按照规格开发并且没有错误后，他们将准备将其发布到公众或部署给客户。

此外，质量保证（QA）团队将负责执行最终测试，以确保成品符合所有产品发布计划的业务需求和最低标准。然后，管理层或产品负责人将检查该产品，确保它可以发布。

到这一阶段，已完成帮助其他开发人员理解软件并学习如何使用它所需的文档。此外，团队还完成了所有必要的文档，以便将完成的产品交给客户。除此之外，公司还应考虑为消费者或员工提供培训，教他们如何有效地使用新产品。

部署后

无论发布是为内部使用还是为客户开发的，与其相关的任务都超出了部署阶段。无论软件当前的效率和功能如何，定期维护仍然是必要的，以确保最佳性能。

此外，安全问题可能随时发生。一旦发生，这可能会对您的公司及其声誉产生毁灭性的影响。许多不同的因素可能会影响您的软件，导致性能问题、崩溃、安全漏洞、可用性问题等。因此，即使软件已提供给最终用户，您也不应停止监控。您需要抽出一些时间，调查系统的性能、安全性、可用性和稳定性，以便在问题对用户产生影响之前发现并修正它们。

从最初的构想到最终的部署和维护，这就是发布管理过程的样子。

总结

现在我们已经到达本章的结尾，让我们快速回顾一下本课的主要要点。你现在已经了解了发布管理的含义及其历史。

了解你在发布管理过程中所处的位置至关重要。你应该从定量和定性两个角度来审视这个问题。收集一些基本数据，例如平均发布时间、发布类型及优先级、错误数量和延迟发布的数量，是定量分析过程中的重要步骤。这些数据用于确定性能基准和发布管理的当前状态。在信息质量方面，与你的发布管理流程中相关的人员进行沟通，特别是在开发与运维交互的领域，了解他们的看法。他们能够指出数据和统计数字中未明确反映的实际情况。

建立常规的发布周期有助于创造一致性，使你能够掌控发布管理任务和职责。与其从一开始就专注于建立文化，不如先实施轻量级的发布流程。这样，你能够在早期阶段设置发布的基础设施，进行测试，并根据需要进行调整。随着时间的推移，最有效的流程最终会成为你组织的标准。在完成初步研究后，你将能更好地启动更严格的质量标准并提高效率。消除停机时间和回归测试是减少发布对用户影响的两种方式。到那时，你还可以开始考虑规范化和自动化流程，比如测试和验证，这两者都是开发过程中的关键步骤。

真正的协作文化在发布管理中需要时间来成熟，而且它需要一个良好管理的基础设施作为成熟的基础。你可以通过对团队的投资以及投资于发布管理工具和方法，来培养这种文化，使人们能够全面了解发布管理过程的每个阶段。这两种投资都将帮助你建立卓越的文化，并使工作更加可见。

这就是第二章的结束。在这一章中，我们从文化和技术两个角度学习了发布管理的定义。然后，我们简要回顾了发布管理的历史，以及不同模型如何随着时间的推移而诞生。最后，你看到了任何模型应该具备的六个标准发布管理阶段。

在第三章中，我们将深入探讨最常见的发布管理模型的机制。这里需要特别强调的是，如果你不了解 DevOps 之前的发布管理模型，那么几乎不可能完全理解 DevOps 的含义。

问题

回答以下问题，测试你对本章的理解：

1. 是软件开发生命周期先出现，还是系统开发生命周期先出现？

2. 系统开发生命周期和软件开发生命周期有什么区别？

3. “软件”这一术语首次是在何时由谁提出的？

4. 谁被认为是撰写第一个瀑布发布管理模型规范的人？

5. 谁被认为是“瀑布模型”这一术语的创始人，并且这个术语是在什么年份提出的？

6. 任何发布管理模型的六个标准阶段是什么？

7. 谁被认为是 DevOps 方法论的创始人？

8. 第一个 DevOpsDays 活动在哪一年举行，地点在哪里？

9. 结构化编程在哪一年普及并成为主流？

10. 迭代式和增量式软件开发在哪一年首次被使用？

第三章：各种 SDLC 发布管理模型是什么？

软件开发团队可以使用各种框架或发布管理模型来组织他们的工作。这些模型帮助组织实施软件开发生命周期（SDLC），通过不同的策略实现相同的结果。一个发布管理模型包含软件开发人员用来组织工作并交付软件产品或功能的各个阶段。一般而言，每个模型包含以下六个阶段：变更请求、规划、设计与构建、测试、部署和发布支持。

发布管理模型确保根据客户需求生产高质量的软件。为了实现这一目标，创建了各种发布管理方法论，如 ITIL、瀑布模型、迭代模型、V 模型、螺旋模型、大爆炸模型、敏捷和 DevOps，但有一些较不流行的模型不在本书的范围之内。我们来回顾一下最常用的 SDLC 发布管理模型：

• ITIL 模型

• 瀑布模型

• 迭代模型

• V 模型

• 螺旋模型

• 大爆炸模型

• 敏捷模型

• DevOps 模型

ITIL 模型

英国政府的中央计算机和电信机构（CCTA）创建了信息技术基础设施库（ITIL）模型：一套用于 IT 活动的最佳实践，如IT 服务管理（ITSM）和IT 资产管理（ITAM），其起源可以追溯到 1980 年代初期。这些实践的核心理念是将 IT 服务与公司运营的需求对齐。2000 年，CCTA 并入了英国的政府商业办公室（OGC）。

在初期，企业 IT 部门被高级领导视为成本中心，而不是它们所具备的价值增值者。当时，许多公司没有建立获取服务或报告 IT 事件的协议，IT 与业务的沟通也较差。因此，许多公司的领导认为 IT 没有创造价值或达成公司目标。随着企业 IT 部门的逐渐增多，他们意识到必须通过满足业务定义的可衡量结果来证明自身的价值。

随着 ITSM 范式的出现，企业的注意力从 IT部门转移到了 IT服务的管理和履行。ITSM 对于 IT 专业人士来说是新鲜的，他们被视为一个独立的实体，而业务单元则被视为他们的客户。为了服务客户，IT 提供由技术资源和专业知识支持的服务。因此，为了展示价值，IT 必须按照既定的服务水平协议提供这些服务，并满足战略业务需求。

ITIL 指导整个服务生命周期中的 IT 服务管理。其核心是一个框架，用于管理组织的 IT 基础设施，从而实现战略目标、创造商业价值并确保基本的能力标准。公司可以利用这一基准作为未来规划、实施和评估的起点。

正如你现在可能已经推测到的，ITIL 发布管理模型更多地与系统开发相关，而非软件开发。话虽如此，ITIL 被认为是企业环境中最早且最广泛实施的发布管理模型之一。尽管 ITIL 在软件发布管理中是一个特例，但要了解 ITIL 是什么，以及它如何融入整体发布管理生态系统。现在，让我们来看看 ITIL 的两个最新版本：V3 和 V4。

ITIL 3

OGC 在其 IT 服务管理（ITSM）战略上取得了重大进展，并提供了超越 ITIL 版本 2 的深度和全面性的更新指导。ITIL 版本 3 于 2007 年向公众发布，结构上是将服务生命周期划分为五个独立的阶段。这些阶段包括服务战略、服务设计、服务过渡、服务运营和持续的 服务改进。

每个阶段都旨在涵盖服务生命周期的特定阶段，可以总结如下：

• 服务战略：制定更好服务客户的计划。服务战略过程从分析客户需求和市场状况开始，建立 IT 组织要提供的服务以及要构建的能力。最终目标是将 IT 部门的思维方式转变为战略规划和执行的思维方式。

• 服务设计：开发新的信息技术（IT）服务。该过程的广度涵盖了新服务的创建以及现有服务的修改和增强。

• 服务过渡：创建和发布计算机系统。对服务和服务管理流程的变更以协调的方式实施，这是服务过渡职能的另一个职责。

• 服务运营：确保 IT 服务得以良好且迅速地提供。在服务运营过程中，满足用户需求、修复服务故障、解决问题以及完成日常操作任务。

• 持续服务改进：应用质量管理技术深入了解当前和过去的表现。持续服务改进过程的目的是将 ISO 20000 采纳的持续改进概念应用于 IT 过程和服务，以最大化其有效性和效率。

下图展示了 ITIL V3 发布管理模型的各个阶段：

图 3.1：ITIL V3 发布管理模型

这就是我们对 ITIL V3 的介绍。我们同时观察 ITIL V3 和 ITIL V4，因为它们之间有一些显著的差异。值得注意的是，ITIL V4 是一个最近的更新版本，其过程图并没有保留 ITIL 早期版本所著名的传统。ITIL V4 的变化带来了更具灵活性的服务框架，而不再是一个僵化的 IT 服务管理模型。

ITIL 4

自 2007 年以来，ITIL 没有进行过重大修订；因此，ITIL 4 可能是对竞争性服务管理框架如 VeriSM™、SIAM® 和 FitSM 兴起的回应。它是 ITIL V3（也称为 ITIL 2011）的一个更新和扩展版本，能够作为企业进行数字化转型的灵活基础。

ITIL 版本 4 概述了为 IT 支持的产品和服务提供服务的过程框架。文档经过了大量修改，以使其更加易读，并且添加了多个示例。ITIL 4 还考虑了现代软件工程和信息技术管理实践，提供了使用敏捷（Agile）、开发运维（DevOps）和精益（Lean）等方法论在服务管理中的应用指导。最后，ITIL 4 强调它是 服务管理框架（而不是 IT 服务管理），这反映了服务管理最佳实践在 IT 行业之外的广泛应用。

需要记住的是，虽然 ITIL 确实是一种发布管理方法论，但它与系统开发生命周期的相似性超过了与软件开发生命周期的相似性。正因为如此，ITIL 排在我们的列表首位。现在，让我们将注意力转向瀑布式发布管理模型。瀑布式模型是最初用于组织专注于构建信息系统的项目的发布管理标准。瀑布式模型诞生于那个关键时期，当时工程师们正从用开关板和电缆编程计算机过渡到使用穿孔卡片上刻出的逻辑序列。这标志着历史上首次可以独立于物理机器编写和管理程序。

瀑布式模型

瀑布模型是一种将项目阶段按线性顺序组织的方法。这意味着每个阶段建立在前一个阶段的交付成果基础上，并对应于不同的任务专业化层次。这种方法在多个工程设计领域中得到了广泛应用。由于进展大多是单向的（向下，就像瀑布一样），这种方法通常被认为是软件开发中最不具备迭代性和适应性的模型之一。原因在于，团队只能在瀑布过程中向前推进，无法回退。这个不可变阶段的线性进展包括需求收集与分析、系统设计、实施、测试、部署和维护。

瀑布模型是第一个用于软件开发中的发布管理 SDLC。制造业和建筑业被认为是瀑布开发模型的发源地。在这些行业中，高度组织化的环境意味着在制造过程中，进行设计修改会变得极其昂贵。最初在软件开发中实施时，并没有公认的替代方案来进行基于知识的创意工作。

瀑布发布管理方法因其缺陷而遭遇了显著的反对。在客户看到功能软件之前，他们可能并不完全了解自己的需求，这可能导致他们在事后更改需求。这将导致需要重新设计、重新开发和重新测试，从而推高成本。软件工程师和业务开发人员可能缺乏对新软件产品或功能设计过程中可能出现的潜在挑战的预见。在这种情况下，最好重新评估设计，而不是继续执行一个未考虑到任何新发现的限制、前提条件或问题的设计。

每个阶段性的过程在查看其各个阶段及流程图后，能够更好地理解。观察瀑布发布管理模型的图示，确实能轻松理解它的不可变步骤的线性顺序是如何赋予瀑布模型这一名称的：

图 3.2：瀑布发布管理模型的六个阶段

如你所见，瀑布发布管理模型非常适合组织一个庞大的工作，涉及数百甚至数千名开发人员在同一个项目中。现在你已经对瀑布发布管理模型有了基本的了解，你也能很好地理解后续更先进的发布管理模型的概念。

我们接下来将研究的发布管理模型是迭代增量模型，通常简称为迭代模型。该方法通过小步增量的方式，或称为迭代，来构建系统。这个发布管理模型是瀑布模型的最早和最直接的竞争者之一，起源于大约 1960 年。因此，我们将接着讨论迭代增量发布管理模型。

迭代模型

这一技术的概念是通过小步增量的方式，或称为迭代，构建系统，以便软件工程师能够从构建系统先前版本的经验中受益。在系统开发和使用过程中，学习不断发生，关键步骤可能从软件需求的子集的初步实现开始，通过迭代的方式逐步改进，直到整个系统实现。设计的修改和新功能会在每次迭代开发周期后融入系统，如下所示：

图 3.3：迭代增量发布管理模型

该技术具体分为三个步骤：初始化阶段、迭代步骤和项目控制清单。系统的起始点在初始化过程中构建。在开发的第一阶段，我们希望提供给用户一些可以反馈的内容。它应该提供对问题的全面概述和直接的解决方案。在每次迭代开始时都会编制项目控制清单，以记录所有未完成的任务。它包括重新设计当前解决方案的部分内容或添加全新的功能等内容。分析步骤将导致控制清单的持续更新。

迭代的重新设计和实施应该易于理解和应用，无论是在迭代过程中还是作为一个单独的任务添加到项目的控制清单中。迭代方法并不要求设计具有特定的粒度。然而，在关键的迭代项目中，可能会使用正式的软件设计文档来补充代码，作为系统文档的主要来源。迭代的分析基于用户反馈和可用的程序分析工具。这包括对结构、模块化、可用性、可靠性、效率和目标达成情况的检查。项目控制清单会根据研究结果进行更新。

在迭代开发中，您的团队将对软件进行逐步改进和调整，直到其完全功能化。每次迭代应旨在提升整体产品，而不仅仅是产生一个新的功能或组件。迭代式管理风格允许根据需要对项目进行调整，以确保成功。这有助于开发团队考虑任何未预见的方向变化，无论是正面还是负面。

一位合格的迭代项目经理必须能够在项目进展过程中进行这些调整，同时尽量减少对团队的干扰，并关注其他团队成员的反馈，以确保项目的进度和预算可控。此外，问题和困难可以及早识别并修复，从而节省时间和金钱。当您定期提供可行的产品增量时，消费者可以更早地提交反馈，从而产生更符合用户需求的优秀软件。如果产品以迭代和增量的方式进行管理，就不会出现最后一分钟的调整或匆忙满足不切实际的截止日期。

这就是我们对迭代和增量发布管理模型的介绍。如您所见，迭代和增量模型与几十年后出现的敏捷发布管理模型非常相似，我们将在本章后续部分讨论它。现在，让我们换个角度，将重点转向 V 型发布管理模型。

V 模型

V 模型得名于它与字母V的相似性。这个 SDLC 发布管理模型在 V 模型中被分为多个阶段，每个阶段都有自己的专门测试阶段。V 模型的左侧代表验证阶段，而 V 模型的右侧代表确认阶段。V 模型是创建系统过程中各阶段的图示，它用于构建项目管理和开发生命周期的严格模型。下图展示了 V 模型：

图 3.4：V 型发布管理模型

V 模型提供了计算机化系统验证框架中的主要活动及其相关输出的高级概述，有时也称为项目生命周期开发。它指定了在产品开发过程中必须进行的活动和必须生成的交付物。

需求分解和系统规范制定的过程表现为 V 模型的左侧。单独组件的集成和验证表现为 V 模型的右侧。然而，需求首先需要经过验证过程，在此过程中它们会与更高层次的需求或用户需求进行比较。此外，还有一个叫做系统模型验证的概念。你也可以通过“左移”来完成这一过程，这意味着根据团队的操作方式，验证只在右侧发生的说法可能并不准确。

在 V 模型中，时间和开发从左至右推进，且无法倒退。正如图中所示，所有迭代都发生在垂直方向上，要么向上，要么向下在框架的架构中进行。这两个过程的区别在于，验证是根据预定义的技术规范进行的，而确认是根据实际的世界条件或用户需求进行的。你可以通过确保你正在构建正确的东西来验证，并通过确保你在以正确的方式构建它来确认。

螺旋模型

1986 年，巴里·W·博姆创建了螺旋发布管理模型，作为组织软件开发生命周期（SDLC）的一种方法。该模型假设构建一个应用程序是一个可以无限重复的周期，直到达到预期的结果。通过持续监控风险和检查中间产品，螺旋模型显著降低了大型软件项目失败的可能性。

在开发过程中出现的问题可能会对最终产品产生多种潜在影响。如果发生这种情况，你应当为价格上涨、工作量增加以及交付日期延迟做好准备。这些都是可能迅速威胁到公司可持续性的因素。螺旋模型采取的迭代渐进方式，以及常规的风险评估（可以通过原型草图、研究或仿真来实现），旨在要么彻底消除此类事件的可能性，要么至少减少它们造成的损害。螺旋软件开发模型非常适用于大型、高度定制的项目，尤其是客户和开发者将财务管理作为优先事项，或是在高度波动的市场中的项目。与其他传统模型相比，螺旋模型的最大优势是风险分析，这对所有相关方都有益。常规的风险评估对于缺乏经验值且具有较高风险概率的创新技术环境尤为重要。

图 3.5: 螺旋发布管理模型

软件开发项目会持续进行其螺旋模型周期，直到达到最终状态。这个周期主要包括以下四个步骤：

1. 螺旋模型典型周期的第一阶段是确定应与软件开发的各个阶段相关联的目标。增加功能或提升性能就是此类变更的示例。同时，必须明确几个实现选择（例如，设计 A 与设计 B 的对比），并确定框架条件以及所需的开销或时间。

2. 下一阶段是分析各种选择，以目标和框架条件作为权威的参考值。在螺旋模型周期的这一阶段，应识别和分析对软件项目整体开发构成重大风险的不确定性区域。原型设计、模拟、基准测试、分析模型和用户调查是将用于下一阶段的一些工具，这一阶段将开发出最小风险和最高性价比的策略。

3. 在完成全面的风险评估后，软件开发可以继续进行——但始终会存在一定程度的残留风险。例如，如果性能风险、用户界面风险或内部接口控制风险在开发过程中占据主导地位，第一种替代方案就是演化开发策略，在该策略中，项目将被更清晰地定义，并且原型得到优化。在这个策略中，用户界面风险和内部接口控制风险是主导开发过程的关键问题。然后，代码会被创建并多次测试，直到获得预期的结果，为之后的开发过程奠定一个低风险的基础。

演化原型开发

演化原型开发，也称为面包板原型开发，与其他原型策略有所不同。采用演化原型的主要目的是利用系统化的过程构建一个高度可靠的模型，并不断改进它。这一方法基于这样的理念：演化原型作为新实施系统的基础，使得未来的增强和附加需求可以随着时间的推移逐步整合进来。

1. 下一周期将在当前周期结束后立即规划。如果单个周期的目标能够实现，而下一个目标尚未确定，那么这可能是项目的常规延续。另一方面，如果前一阶段的开发存在缺陷，寻找解决方案可能是唯一的选择。当前方法的一个可能替代方案是已经确定的替代方案之一，或者引入一个全新的方法。通过这种方式，你可以再尝试一次，直到实现目标。

软件开发中的螺旋发布管理模型被认为是一种通用的过程模型。四个阶段仅仅是确立了一个周期的基本目标，并不要求每次迭代中都体现出来。它们的顺序并不是由螺旋模型严格决定的。因此，该模型有可能在任何时刻与其他过程模型进行集成。

这就是我们对螺旋发布管理模型的回顾。到现在为止，你已经了解了螺旋软件开发是一种规避风险的模型，主张实施迭代开发技术，并在 SDLC 的每一步中管理风险。接下来，让我们来研究一下大爆炸发布管理模型——一种与螺旋模型截然不同的高风险开发风格。

大爆炸模型

在大爆炸发布管理模型下，软件工程师在没有任何详细准备的情况下，全力投入到编程工作中。换句话说，没有预定的计划，需求是随着发现而逐步实现的。在某些情况下，如果需要调整，可能需要完全重写应用程序。你可以清楚地看到大爆炸模型为何得名。然而，当项目中只有一两个开发人员参与时，这种方法特别有效，正如在学术界或实践中的情况一样。当项目需求不明确且有一个固定的完成期限时，这种技术尤为有用。

大爆炸模型是一种软件开发生命周期范式，它从什么都没有开始，逐步构建起来。我们在规划上花费的时间非常少，也不遵循任何特定的程序。由于不需要任何规划，它是最基础的发布管理方法。需求是在没有太多前瞻性的情况下实时应用的，客户甚至不清楚自己需要什么。该方法的主要目标是尽快开始编码，而不遵循任何特定的结构，并尽快将完成的产品交付给客户。日常开发开始时有一些前提条件，尽管对最终结果知之甚少。接下来，客户与开发团队保持密切联系，以跟踪工作进展。如果结果与预期相符，产品将被授权；否则，将提出不同的解决方案。

简而言之，这种方法论不需要详细规定要求，产品需求在收到后会迅速被理解并执行。该范式的核心重点是编程，因此相比其他发布管理模型，它更容易受到风险的影响。在组件或至少其组成部分完全集成后，测试即可开始。此模型最适合在现有环境中整合前沿技术，分析所做的修改，并具有良好的适应性。

正如你所推测的，这个模型类似于宇宙大爆炸理论。时间、资源和能量的浓缩混合，瞬间产生了一个完成的产品，似乎是凭空而来。下图详细描述了大爆炸发布管理模型：

图 3.6：大爆炸发布管理模型

这就是我们对大爆炸发布管理模型的回顾。到现在为止，你已经理解了发布管理的真正含义。你明白了发布管理可以是怎样的，从最正式到最非正式的形式。接下来，我们将探讨臭名昭著的敏捷发布管理模型。无论你喜不喜欢，敏捷模型在 DevOps 崛起并取代它之前，曾在大约二十年的时间里风靡一时。

敏捷模型

敏捷发布管理模型将 SDLC 阶段分为多个开发周期，团队在每个周期结束时交付增量的软件变更。敏捷方法非常有效，其快速的开发周期帮助团队及早发现问题；然而，过度依赖客户反馈可能导致范围蔓延。敏捷模型非常适合那些随着时间推移需要适应性和灵活性的软开项目。下图展示了敏捷模型：

图 3.7：敏捷发布管理模型

大多数敏捷开发所使用的技术将工作划分为若干小增量。这些增量相比其他发布管理模型（如瀑布模型）需要较少的前期规划和设计时间和精力。这些迭代被称为冲刺，是短暂的活动周期，通常持续一到四周。每个迭代都需要一个跨职能团队的参与，团队会进行所有活动，包括规划、分析、设计、编码、单元测试和验收测试。在迭代结束时，利益相关者会看到一个已经具有功能的产品演示。这降低了整体风险，并使得产品能够快速适应新的环境。

目标是确保每次迭代结束时都有一个可用的发布版本（且 bug 数量较少），尽管每个迭代可能不会产生足够的功能来支持市场发布。当产品以增量方式开发时，相较于在产品最终交付日期临近时发生灾难性失败，它们在每次迭代阶段更具灵活性，可以早期并频繁地失败。可能需要多次修订才能发布产品或新功能。进展的最重要指标是有功能的软件。

采用敏捷方法论的两个主要好处是快速的产品开发和降低风险。因此，通过将产品以较小的增量发布到市场，可以减轻由于产品未能满足消费者需求而产生的风险。

这就是我们对敏捷发布管理模型的回顾。正如您所见，敏捷模型是迭代增量模型的逻辑继任者，同时也是通向 DevOps 发布管理模型的一个重要步骤。因此，接下来我们将讨论 DevOps 模型。

DevOps 模型

DevOps 发布管理模型包括一系列方法论，旨在整合 软件开发（Dev）和 IT 运维（Ops），以促进更快速和更频繁的软件发布。这种软件开发策略结合了沟通、自动化和分析。DevOps 方法论强调交付符合业务目标并满足客户需求的软件。通过利用快速反馈循环、相关的 关键绩效指标（KPIs）和迭代开发策略来实现这一点。虽然 DevOps 包括规划、设计、编码、测试和部署，但该模型的一个显著特点是它如何将持续集成、持续交付、持续测试和持续监控融入到软件开发生命周期中。以下图示展示了 DevOps 模型：

图 3.8：DevOps 发布管理模型

发布管理在很大程度上依赖于精确的报告，以便跟踪需求、风险和障碍。它还确保项目的初始目标和目的在整个软件开发生命周期内都能得到实现。

采用 DevOps 原则自然会带来一个更完善的发布管理框架，进而为交付生命周期每个阶段的有效协作和测试制定行业标准的程序。人们往往将自动化视为 DevOps 中最重要的价值，但自动化应始终聚焦于提升人员的生产力。当人们致力于提高操作效率并减少人为错误的影响时，他们必然会以更高的速度发布可靠的服务。

在 DevOps 文化中整合发布管理使得企业能够实现加速、可靠和成功的软件发布。最终，这一现象有助于提高消费者的满意度，增进开发团队间的合作，并加速企业的扩展。

DevOps 和发布管理在软件开发、项目管理和 IT 运维方面有着密切的关系。DevOps 发布管理包括了对软件发布和交付周期的设计、规划、调度、测试和实施等活动的管理。

已经至少对某个产品进行过一次修改的组织，通常都能深刻理解发布管理在 DevOps 背景下的重要作用。当这一策略得当执行时，它有潜力提升开发、测试和操作过程的效率。此外，这一发布管理策略还能有效减少返工成本、加强协作并促进高质量产品的成功交付。

这提升了组织对发布过程各阶段的监督，从最初的开发到最终的交付。DevOps 发布管理现已成为当新产品推出或进行修改时的现代标准。DevOps 过程可能会因团队的不同、偏好的实践和组织的目标而略有不同。

通过采用 DevOps 发布管理，软件开发团队能够通过更早地进行质量检查、左移测试、自动化和 QA 程序，从而提高软件交付生命周期中的整体效率。由于其在消除孤岛效应、促进团队成员协作方面的作用，DevOps 发布管理正逐渐成为当前最流行的发布管理策略。

总结

我们已经到达本章的结束。到目前为止，我们已经讨论了 IT 行业中最常见的八种发布管理模型。它们分别是 ITIL 模型、瀑布模型、迭代模型、V 型模型、螺旋模型、大爆炸模型、敏捷模型和 DevOps 模型。现在你应该已经了解了每种发布管理模型的各种优缺点，并对选择适合自己项目的模型有了信心。此外，你也已经接触到 DevOps 相对于之前发布管理模型所提供的惊人好处。因此，你对发布管理的历史有了基本了解，并能够根据每种模型的演变，做出明智的结论。

本章已结束，第三章。在下一章中，我们将学习 DevOps 发布管理的独特性。了解这一点非常重要，因为接下来的章节将重点讨论 DevOps 发布管理模型。

问题

请回答以下问题，以测试你对本章内容的理解：

1. 为什么 ITIL 发布管理模型更多地与系统开发生命周期相关，而不是软件开发生命周期？

2. 第一个标准发布管理模型是什么？

3. 迭代和增量发布管理模型中的三个步骤是什么？

4. 在 V 型发布管理模型中，时间和发展的进程走向是什么方向？

5. 螺旋发布管理模型的定义特征是什么？

6. 大爆炸发布管理模型开始新项目时需要的三个关键要素是什么？

7. 敏捷发布管理模型在测试方面的座右铭是什么？

8. DevOps 发布管理模型的定义特征是什么？

9. 在瀑布发布管理模型中，何时可以回溯并返回到之前的阶段？

10. DevOps 发布管理模型的哪个阶段进行测试？

第二部分：DevOps 发布管理的优势

在本书的第二部分，我们将从学习 DevOps 发布管理试图解决的问题开始。接着，我们将学习 DevOps 发布管理的独特性。然后，我们将了解 CI/CD 的基础，它是基于 DevOps 的价值流的核心。最后，我们将探索 CI/CD 流水线如何促进良好的 DevOps 发布管理。本部分的目标是强调 DevOps 发布管理的标志性特征，以便你在进一步学习并成为一名经验丰富的 DevOps 领导者和战术专家之前，具备必要的基础知识。

本节包含以下章节：

• 第四章，DevOps 发布管理试图解决什么问题？

• 第五章，理解 DevOps 发布管理的独特性

• 第六章，理解 CI/CD 的基础

• 第七章，技术发布经理的实用流水线

• 第八章，CI/CD 流水线如何推动良好的 DevOps 发布管理

第四章：DevOps 发布管理试图解决哪些问题？

以今天的标准来看，传统的 IT 组织有着极长的开发周期。在这些过时的公司中，通常需要进行大量的手动测试，才能将软件产品发布到生产环境中。而且，每次代码变更都会给相关方带来极大的压力。在这些组织中，开发团队通常需要等待清理好的环境，或者必须等待批准才能进行任何变更。此外，质量保证（QA）团队可能要等开发人员完成工作后，才能进行测试。这些等待导致了低部署频率（DF）和高变更交付周期（LTFC）。

此外，在传统的 IT 组织中，项目完成后，许多团队成员会离开，几乎不留下文档或知识转移。这使得当新工程师加入团队并尝试支持系统时，面临很大挑战。通常，这会导致在发生关键问题时，平均恢复时间（MTTR）较长。像这些组织通常通过专门的运维团队来管理环境配置，这些团队的唯一任务就是基础设施管理。即使基础设施即代码（IaC）是公司的标准程序，他们仍然会进行手动更改服务器，导致配置漂移。不同环境中的服务器可能会有不同的工件，例如应用程序所需的库，或者相同产品的不同补丁级别。所有这些手动工作会导致低 DF 和高交付周期。

在本章中，我们将探讨 DevOps 发布管理如何通过结合自动化、最小化风险、简化发布过程，并通过跟踪度量标准和分析关键绩效指标（KPIs）来解决这些问题。我们将论证 DevOps 的特点如何使其在云端微服务部署的背景下，成为一种卓越的发布管理方法。

因此，本章将涵盖以下主题：

• 探索自动化测试、部署和变更管理

• 减少潜在风险并加速软件产品的发布

• 精简发布过程，使其标准化

• 改善成功发布的度量标准和关键绩效指标（KPIs）

探索自动化测试、部署和变更管理

当涉及到软件的创建时，大多数现代组织必须应对一些重大障碍：快速部署软件 和 规模化创新。DevOps 方法旨在通过在整个软件开发生命周期（SDLC）中实施自动化来解决这些挑战，其目标是加快交付既可靠又安全的软件。

通过合并自动化测试、自动化部署和自动化变更管理，DevOps 发布管理为运营团队铺平了自动化发布计划的道路。当使用自动化进行发布管理时，管理和交付成功的发布要简单得多，因为它使发布管理成为一个可以轻松重现和重复的过程。这通过实施精心设计的持续集成/持续部署（CI/CD）流水线来实现，在您的组织内部是互操作的，但同样重要的是它们是可靠的。

无可否认，自动化包含持续发布和持续交付的 DevOps 框架是多么复杂。在整个应用程序开发过程中，必须使用全面的测试、广泛的跨团队沟通、先进的工具和工作流程来实现持续发布。

在接下来的小节中，我们将讨论自动化测试这一至关重要的话题，这是 DevOps 理念的生命线。

自动化测试

在 CI/CD 流水线中尽早且频繁地部署自动化测试从 DevOps 的起源以来就成为其重要特征。这包括积极监控生产环境，以防止未检查的问题影响用户。现实情况是，现代应用程序依赖于多个可能故障的工件和服务。除了在流水线中使用静态和动态应用程序分析工具之外，还应在所有开发环境中进行事务性监控，而不仅限于生产环境。通过使用模拟数据和持续监控来运行测试，您可以检测到影响应用程序任何组件的问题，包括第三方软件即服务（SaaS）集成。一些有效的 SaaS 工具包括 Datadog、Dynatrace、New Relic、Snyk 和 Prisma Cloud。

随着您的开发团队逐步完善其 DevOps 实践，他们将希望在整个 SDLC 中实施测试自动化，因为这是释放 DevOps 全部好处的关键。这些好处包括能够更快、更一致地构建、测试和发布。为了提高事件响应（IR），鼓励团队之间的协作，并有效沟通，现在不再可行的是将新代码提交给手动 QA 测试几个小时甚至几天，然后再让软件开发人员得到反馈。QA 团队必须围绕 DevOps 发布管理生命周期调整工作，确保测试用例实现自动化，并且在可实现的范围内具有完整的代码覆盖。环境的配置需要通过使用基础设施即代码（IaC）来标准化，并且部署应当自动且不可变地进行。换句话说，所有的预测试任务，例如基础设施配置、环境配置、后测试任务、清理或相关的、可重复的、日常的事项，都应当实现自动化，并与 CI 的理念保持一致。

自动化测试是 CI 的关键优势，它能节省您的资源，使您能够实现规模经济。首先，自动化测试最大化了在错误进入生产环境之前被发现的可能性。它还通过在检测到缺陷和错误时立即通知您，来加快发布过程。此外，实施 CI 的一个显著优势是，小团队也能成功地完成更重的任务。并行集成允许您快速连续地执行多个自动化测试，每个测试通常只需几分钟，从而进一步减少测试开销。自动化整个开发过程可能看起来令人不知所措，但您可以从自动化一个单一的端到端流程开始，并定期运行它。新的工具和资源使自动化测试比以往任何时候都更容易，且其好处值得投入。自动化测试使您能够消除瓶颈并提高生产力，通常能够提升员工和客户的满意度，并增加公司银行账户中的收入。

自动化测试带来的一个重要推动力是能够以今天数字化市场的速度扩展运营。DevOps 技术在降低风险的同时，能保持一致的质量。这在一定程度上通过将工作分配给多个小型团队来实现，这些团队以自给自足的方式运作，同时又能像一个有凝聚力的部落一样进行协作。这种共同开发风格鼓励团队成员分享个人技巧和想法，同时在作为业务单元（BU）的共同理念下工作。由于自动化测试带来的巨大生产力提升，你将体验到更好的团队协作。你的同事不再需要将大量时间和精力投入到手动测试协议中，反而团队将有更多机会讨论优化策略，或是一起外出享受兄弟般的午餐。由于你选择了 DevOps 文化，你也选择了共同承担质量责任，这种责任感在团队成员中培养了自豪感。现在，你应该能意识到自动化测试已成为 DevOps 的重要组成部分。

DevOps 发布管理可以帮助你提升基础设施和业务流程的可靠性。更重要的是，通过提高测试自动化覆盖率来改进发布的可靠性，生产环境中的问题将变得非常罕见。这些特性总和促成了一个令人振奋的工作环境，团队成员也更喜欢这种工作方式。所有这些 DevOps 发布管理方法的特点都带来了客户的更高满意度。事实证明，更好的可靠性和快速响应客户反馈能提升客户满意度，并鼓励更多人推荐你的公司产品。

自动化部署

从本质上讲，CD 是一个统一的发布过程，包含了自动化构建、测试和部署步骤。其目标是简化将新软件推向生产环境的操作流程。每个企业必须弄清楚其独特的测试套件中，单元测试、功能测试和压力测试的组合方式。为了成功地进行构建和发布候选版本的预部署测试，必须在发布前的预生产测试环境中模拟生产环境条件。

通过使用 CD 流水线，可以将代码更改自动推送到生产环境，CD 流水线是一种自动化工作流，结合了构建、测试和部署。一个工作流阶段的输出成为下一个工作流阶段的输入，依此类推。通过 DevOps 方法，CD 可以通过在每个阶段进行自动化测试和监控来预防错误、功能难题和缺陷。通过这种方式工作，可以在问题进入主分支之前及时发现并解决，从而避免其影响生产环境。

最终结果是，工程团队能够将代码修改实施到主分支，并迅速在生产环境中看到其部署，通常在几分钟内完成。这种软件开发的哲学强调 DevOps 的根本目标，即持续为最终用户交付价值。这一因素也成为许多应用程序和基于网络服务中新特性和系统修改引入的主要催化剂。

一旦实施，CD（持续交付）使企业能够更容易地满足客户期望，并迅速发布软件升级，通常在提交代码更改后的几分钟内完成。然而，采用 CD 可能会与传统的需要花费几天甚至几周时间准备发布软件的方法相比发生巨大的变化。尽管如此，那些投入必要的努力、资金和设备的公司将获得实实在在的好处。以下是一些广泛认可的采用 CD 的好处：

• 完全自动化产品发布的实施：这使企业能够将更多时间分配给软件开发，而不是在发布日之前中断开发活动。

• 应当有更频繁、更小规模的发布：这不仅能使产品开发工作进展得更快，还有助于支持持续改进的范式。

• 与新实现的功能相关的快速反馈循环：组织能够迅速收到关于新特性、升级和代码修改的实时反馈。

自动化变更管理

一个从 DevOps 方法的特别应用中获益匪浅的传统流程是变更管理。许多现有的变更管理方法直接与 DevOps 哲学的基本原则相悖。传统策略引入的官僚主义和审批关卡，要求每次变更都经过多个级别的审批，这几乎确保了更长的发布周期和延迟向客户交付价值。这与 DevOps 哲学相悖，后者强调快速迭代和频繁的客户获益。为了有效实施 DevOps 策略来管理变更，我们必须放弃传统的、封闭的稳定性维护观念。要充分理解变更管理如何在保持一致性的同时促进快速响应和适应性，我们必须扩展我们的视野。我们不会将变更审批过程作为阻碍创新的障碍，而是将其作为加速向客户交付新特性的过程的一部分。

通常，你将与采用 CI/CD 方法的组织打交道，这使得它们能够每天进行多次发布，有时甚至达到两位数或三位数。为了在快速速度下有效实施变更管理，必须将其整合到 CI/CD 流程中。有几种IT 服务管理（ITSM）工具，如 ServiceNow、Jira、Freshservice 和 Zendesk，提供应用程序编程接口（API），使得 CD 管道与变更管理系统之间能够无缝集成。通过利用这些 API，组织可以自动生成变更票据，并通知相关方参与。这一做法保证了每次修改都有一个票据，而不会对部署过程造成额外负担或阻碍。许多企业已经成功地实现了流程结构、协作文化和变更管理工具的融合，为实现稳定的操作环境铺平了道路。

向管道中添加审计日志是一项简单的操作，并且带来了显著的优势。实施审计日志后，任何有兴趣的人都可以查明最近一次修改上线花费了多少时间，为什么它是必要的，谁批准了它，是否所有前阶段的检查项都已经完成。例如，当审计员要求提供文档，证明某个变更在未来遵循了你的流程时，你只需追溯日志记录即可。你可以对所有信息配置精细的访问权限。然而，随着这些优势而来的是重大的挑战，尤其是在需要绕过变更管理门槛，在紧急情况下对生产环境进行手动更改的情况。

这就结束了我们对自动化测试、部署和变更管理如何极大改善传统软件开发实践的探索。在下一部分，我们将讨论 DevOps 如何降低风险并提高开发速度。

降低潜在风险并加速软件产品的发布

软件交付过程通过 DevOps 发布管理得到了卓越的沟通、协调和生产力的促进。Slack、MS Teams、Jira、Confluence、ClickUp、Asana等协作工具促进了优异的沟通，这一点非常重要，因为在当今全球化经济中，各组之间的协作发生在广阔的距离和时区之间。

DevOps 发布管理方法的典型实施包括了诸如 CI/CD 和部署自动化等成熟的工作方法，这些方法大大加快了高质量软件的开发，同时减少了潜在风险。因此，这些因素使企业能够迅速适应市场波动，以更高效的方式满足消费者需求。

在 DevOps 实践特别有用的几个领域中，灾难恢复（DR）尤为重要。自动化流程、实施 CI/CD 以及利用云计算对于保证 99.999%的正常运行时间且不丢失数据至关重要。当灾难恢复计划成为组织 DevOps 管道战略的一部分时，它通常与应用程序本身一起管理，以便定期对两者进行检查。通过在 DevOps 工作流中加入灾难恢复计划，恢复过程实际上被转变为类似于部署应用程序的过程。这不仅减少了错误的可能性，还帮助加速了新软件应用程序的发布。在危机发生时，你的团队可以利用他们在部署方面的专业知识来促进恢复过程。

此外，复制数据的灾难恢复环境也能为恢复工作提供帮助。毫无疑问，用于将应用程序从开发、QA 到生产环境的工具和程序，也可以应用于灾难故障切换和恢复工作。这确保了选择采用 DevOps 的决策同样为灾难恢复（DR）方面带来了有价值的投资。最终结论是：同样的自动化技术，可以用于将应用程序从开发/测试环境过渡到生产环境，也可以用于故障转移和恢复。

这段内容总结了 DevOps 发布管理如何减少风险的潜力并加速软件产品的发布。在接下来的部分，我们将探讨 DevOps 如何通过标准化发布过程最大化自动化的效益。自动化是一个方面，但如果没有优化这些过程，你将失去管道所能提供的最大利益。

精简发布过程，使其变得标准化

通过将发布管理纳入现有的 DevOps 工作流中，发布过程可以得到简化，最终实现标准化。这为公司程序的统一执行设立了先例。建议将 CI/CD 管道的结果记录在发布日志中，并将其汇总到发布管理的故障跟踪产品、源代码管理以及相关工具中。在系统部署后，这些文档对于追踪问题的来源并应用相应的解决方案至关重要。

发布管道一词指的是一系列自动化和手动流程，旨在确保客户能够访问到公司软件产品的稳定和安全版本。发布管道的职责和责任是确保产品改进能够快速、安全地交付给最终用户，从源代码的更改开始，通过开发、测试和发布的过程。持续交付（CD），确保您的代码库可以随时安全部署的过程，与发布管道密切配合。原因在于它们减少了开发人员必须花费在繁琐工作上或修复不可避免的错误上所需的时间。

发布管道最显著的优势是它能在保证稳定性的同时缩短交付新版本所需的时间。如果出现问题，您将有自动回滚程序和防故障机制。总体而言，您的用户将更早获得新功能（或错误修复）。通过发布管道，可预测性和可靠性都得到了提高，开发人员生产力的提升也是另一个优势。开发人员可以避免在事后为自己的行为辩解或重构发布版本，因为内置的审计功能可以减少这些麻烦。他们将有更多时间专注于编写代码（这一活动为业务带来价值），而无需过多担心外部细节。

发布管道充当公司软件分发的协调者。这意味着该系统将根据发布获取的输入和数据自动做出决策。此外，它还将实时解决常见问题，或者在某些情况下，如果发现对客户有不利影响，立即回滚部署。发布管道是根据您公司业务运营的独特需求和管理框架量身定制的。该工具能够提供全面的反馈和有价值的指标，增强对整个发布过程的整体意识；这种可见性是任何其他方式无法实现的。

协调的发布管道的实施促进了准确预测项目结果的能力，并最终验证其成就或不足。运营团队，通常会根据发布速度、效率和效果进行评估，也可以从发布管道中受益。发布管道比脚本化部署更快，对资源的消耗也更小，越来越受欢迎。这是因为它们减少了风险，并在出现问题时加入了自动修正程序，从而减轻了运营团队最难处理和最琐碎的烦恼。

这段内容概述了 DevOps 发布管理如何简化发布过程。在接下来的部分中，您将看到如何量化衡量成功。这些可以用于验证您的流程是否在改进，并向高级管理人员展示价值。

提升成功发布的指标和关键绩效指标（KPI）

通过设定标准，DevOps 发布管理有助于开发出更优秀的软件发布。通过自动化、版本控制和质量控制（QC），开发团队可以深入了解生成更多频繁发布、且失败率较低所需的指标。

无论是在 DevOps 还是在其他任何领域，都有一个道理：无法衡量的东西是无法改进的。DevOps 最有效的方式是团队收集、分析并衡量各种数据，以便实现更快、更高质量的产品交付。这些 DevOps 指标提供了 DevOps 团队控制软件开发生命周期（SDLC）所需的关键信息。DevOps 软件开发中的指标突出显示了管道的效率，并可以及时消除阻碍进展的任何障碍。这些指标可用于监控技术能力以及运营效率。

DevOps 的主要目标是消除开发与运维团队之间的区别，从而促进软件开发人员与计算机系统管理员之间更紧密的协作关系。指标使 DevOps 团队能够客观地衡量和评估协作工作流，并跟踪实现高层目标的进展，例如增强应用性能、加速发布周期和提高质量。

四个关键的 DevOps 指标

通过DevOps 研究与评估（DORA）指标框架，可以有效衡量软件开发、交付和维护的成效。组织可以使用这些指标作为不断改进 DevOps 性能的起点，并实现更好的业务成果，因为它们能揭示哪些团队表现卓越，哪些团队表现较差。DevOps 和工程经理通常能较为清楚地了解团队的表现，但他们更难衡量团队为公司带来的价值，并找出改进的方向。借助 DORA 指标，软件交付性能可以得到客观衡量和优化，且可以证明其对业务的价值。

图 4.1：示例 DORA 指标仪表板

DORA 方法包括四个关键指标，接下来将详细介绍，用于评估 DevOps 的两个基本维度：即速度和可靠性。DevOps 团队的速度通过他们的 DF 和平均 LTFC 来衡量，而 DevOps 团队的可靠性则通过他们的变更失败率（CFR）和恢复服务时间（TTRS）指标来衡量。当这四个 DORA 指标一同分析时，它们为 DevOps 团队的成功提供了基本的衡量标准，并提供了可能需要改进的领域的指示。

LTFC

LTFC 被认为是 DevOps 团队必须监控的关键指标之一。LTFC 的概念不应与周期时间混淆。LTFC 指的是从代码更改提交到主干分支的时刻开始，到该代码更改变得可部署的时刻之间的持续时间，例如，当新代码成功完成所有必要的预发布测试时。

通常，表现卓越的团队倾向于将交付周期量化为小时，而表现不佳的团队则将交付周期量化为天、周甚至月。提高周转时间需要结合使用测试自动化、基于主干的开发、精心设计的反馈回路以及迭代、增量式工作。只有遵循这些原则，开发人员才能迅速评估代码的质量，并在代码发布前修复任何发现的缺陷。当多个开发人员在不同的分支上并行进行重大更改，并依赖人工测试来确保质量时，交付周期不可避免地会膨胀。

CFR

引起问题并需要修复的代码更改的百分比称为 CFR。这不包括在测试中发现并在代码发布之前修复的错误。

高效的团队通常展示出 CFR 位于 0%到 15%之间。较低的 CFR 与使用相同方法（如测试自动化、基于主干的开发和小批量工作）相关，这些方法能缩短交付周期。实施这些流程的结果是，发现和修复错误变得更加轻松。监控和报告 CFR 不仅对于定位和修复问题至关重要，而且还能确保新发布的代码满足所有必要的安全标准。

DF

DevOps 的成功在很大程度上可以通过新代码进入生产环境的频率来衡量。许多专业人士使用交付这一词汇来指代代码更改发布到预生产阶段环境，而使用部署来指代代码更改发布到生产环境。

最优秀的团队能够根据需要随时推出更新，通常一天可以多次更新。表现较低的团队通常只能每周或每月进行一次部署。具备按需部署能力需要配备自动化部署流水线，该流水线不仅包含前述的自动化测试和反馈机制，还减少了所需的手动干预。

MTTR

被称为 MTTR 的指标量化了在部分中断或完全故障后恢复操作所需的时间。无论中断是由于最近的部署、单个服务器故障还是介于两者之间的其他原因，跟踪这一指标都是至关重要的。高效的团队通常能在不到 1 小时的时间内从系统故障中快速恢复。相反，表现较差的团队可能需要长达一周的时间才能完全恢复。

对 MTTR 的重视标志着与传统上强调平均故障间隔时间（MTBF）的做法的不同。这反映了当前程序的复杂性以及它们发生故障的可能性。此外，这还鼓励了不断追求更好的习惯。团队现在不断进行部署，而不是等待发布“完美”以避免任何故障。与其为表面上完美的 MTBF 记录中断寻找替罪羊，MTTR 提倡无责的回顾会议，帮助团队改进上游过程和工具。

周期时间，或产品从团队开始工作到最终发货所需的时间，是另一个需要跟踪的相关统计数据。从开发人员提交代码到代码推送到生产环境所需的时间被称为“开发周期时间”。这个重要的 DevOps 指标对于项目经理和工程经理来说非常有用，帮助他们了解开发流水线的成功因素。这样，他们就能确保团队的工作更符合利益相关者和客户的期望，从而更早地发布产品。

项目经理可以使用周期时间报告来定义 CI/CD 流水线的基础基准，随后可以用来评估未来的操作。当团队优先优化周期时间时，开发人员通常会减少在制品（WIP）的数量，并减少浪费活动的发生。

总结

在你期望有效运用 DevOps 发布管理之前，理解 DevOps 发布管理旨在解决的问题至关重要。阅读完本章后，你应当对 DevOps 生命周期中的许多关键方面有一个基础的了解。你现在明白了在测试、部署和变更管理中融入自动化技术的重要性。此外，你还了解了使用发布管道来减少潜在风险并加速软件产品发布的策略。同时，你现在也明白了为了以标准化的方式简化发布过程，需要采取哪些步骤。最后，你掌握了改进成功发布和客户满意度的度量标准（KPI）所需的基础知识。

在下一章中，你将学习到 DevOps 发布管理与其他发布管理模型相比的独特本质。通过学习 DevOps 发布管理哲学，你将理解它与众不同的关键差异。你将了解为什么 DevOps 是整体的，并且在你的组织中需要文化上的意义。此外，你还将理解 DevOps 用来集成 CI/CD、质量保证、安全性和反馈回路的颠覆性策略。你还将了解到 DevOps 如何将业务团队纳入开发过程的重要性。进一步，你将接触到 Gene Kim 的 三种方式 DevOps 原则。最后，你将了解到传统发布管理方法与 DevOps 的差异。

问题

回答以下问题以测试你对本章的理解：

1. 持续部署和持续发布之间的区别是什么？

2. 审计追踪是什么？它们的好处是什么？

3. 在 DevOps 发布管理生命周期中，自动化测试最合适的阶段是什么？

4. 在 DevOps 发布管理方法中，如何处理变更审批过程？

5. 发布管道的作用是什么？

6. 如何在 DevOps 发布管理方法中融入 DR 策略？

7. ITSM 工具如何自动化变更管理？

8. 四个 DORA 指标是什么？

9. 在 DevOps 发布管理方法中，如何最佳地融入发布日志中的数据？

10. 如果有一个 DevOps 指标是最重要的，那会是哪一个？

第五章：理解是什么让 DevOps 发布管理与众不同

DevOps 文化是全方位的，它涉及到审视价值流的每个环节并对其进行优化。DevOps 的哲学旨在消除孤岛效应或个别团队的孤立工作。因此，拥抱 DevOps 文化的企业提高了端到端操作的透明度。这与许多成熟企业的做法背道而驰，因为这些企业中，个人和团队有着明确的角色和职责，很少进行跨部门协作。

DevOps 的哲学是集体责任，鼓励 IT 人员快速找到解决方案，并始终致力于终身学习。Gene Kim、Jez Humble、Patrick Debois和John Willis，《DevOps 手册》的作者，在书中概述了这些基本原则。员工应该能够将大部分时间用于完善与 DevOps 相关的任务，如基础设施自动化、网络安全、应用监控和补丁修复。持续改进的驱动力是 DevOps 文化的核心。如果您的团队在正确执行 DevOps，高压时刻和职业倦怠是罕见的现象；否则，您的业务单元可能在资金上被严重压缩。

然而，企业领导层通常对风险较为回避，因此当某个流程证明有效时，他们通常会紧紧抓住它，并视而不见。DevOps 团队的任务是根据一套流程优化效率。这也是为什么 DevOps 团队必须与业务开发团队密切合作，确保公司产品的稳定性、性能和安全性。

在本章中，您将深入了解 DevOps 的独特方面，我们将涵盖以下主要内容：

• DevOps 是全方位的

• DevOps 整合了 CI/CD、QA、安全和反馈

• DevOps 将业务团队纳入开发过程

• DevOps 的三种方式

• 传统的发布管理方法与 DevOps 相比如何？

• DocuSign 如何从敏捷转向 DevOps 的案例研究

DevOps 是全方位的

DevOps（开发与运维）倡议是全方位的，与过去的孤立策略不同。DevOps 考虑的是整个价值流和所有相关的人员，而不仅仅是某一个人或其中的某个特定组件。我们通过围绕员工设计我们的系统和流程，颠覆了传统模式。这也是为什么表现卓越的 DevOps 团队能够证明信息技术投资与财务表现之间存在相关性。投资的根本目标是促进和赋能个人，使他们能够改进流程并为自己选择合适的技术。赋能员工直接与提高生产力和增强公司韧性相关联。

DevOps 领域已经经历了显著扩展，其范围超越了单纯的发布和部署过程。在撰写本文时，它涵盖了各类利益相关者，包括产品负责人、项目经理，以及软件开发生命周期的各个方面。这一主要因素促使其作为一种整体方法论不断增长，涵盖了业务运营团队与客户之间的关系，以及产品发布和生产监控的各个阶段。DevOps 发布管理是 IT 行业中的逻辑进展，强调其在提升各行业组织绩效方面的有效性。

DevOps 的实施已经扩展到涵盖企业中的各个部门，包括客户支持、营销、产品负责人、项目经理、程序经理、开发人员、质量保证团队、发布或构建团队以及基础设施团队。DevOps 的主要目标是提高客户满意度并加快交付速度。因此，所有相关方必须全面了解整个过程，包括运营、规划、集成、测试、监控、交付和反馈。高效的流程和工具集成是自动化顺畅交换和执行信息的必要条件。这种方法还使得所有利益相关者能够更有效地为产品的成功和高效实施做出贡献。

DevOps 倡议的成功依赖于许多人有效地协同工作。这意味着组织必须尽可能消除所有信息和执行的隔离。初创公司通常会因为从零开始建立公司运营的优势而采纳 DevOps。然而，最近的宏观经济指标显示，越来越多的大型、成熟的企业正在采纳 DevOps 实践，尤其是为了优化效率、提高软件发布的频率和质量。

DevOps 领域涵盖了广泛的工具，其中很大一部分是源于开源。这样的发展为工程师提供了前所未有的工具选择，可以参与黑客攻关或实验。然而，这一现象通常带来独特的困难，因为过多的工具集可能会在工作流中创建孤立的知识和执行隔离，导致模糊性和浪费。这一现象变得越来越普遍且具有问题性，迫切需要转向提供更优集成和执行能力的解决方案，适用于各种技术。对于这种情况，最佳的做法是使用一个提供广泛集成能力的平台，如 GitLab、GitHub Actions、Plutora，甚至是 Zapier。

为了提供全面的解决方案，从客户需求开始到收到产品反馈，企业需要一个综合集成平台，允许在不同工具之间无缝集成和执行，包括内部的专有工具。这种方法对于成熟企业尤其有用，因为它让他们有自由保留现有的工具和流程投资，同时有针对性地引入新技术。成熟企业可以在不从头开始的情况下管理变革，同时专注于效率、自动化、协作、更高的发布标准和更频繁的发布。

DevOps 发布管理确保所有相关方都清楚哪些功能将会发布以及何时发布。这种方法包括强大的可追溯性功能、分析和仪表板，帮助了解信息和任务执行的从左到右的流动。减少对其他团队的依赖并促进自助服务的一种好方法是紧密集成数据系统、基于 CI/CD 的自助服务终端，以及通过运维专家的支持来自动化日常业务流程。

DevOps 使团队通过更好的端到端可视化和强大的协作方法提高生产力和效率，从而赋能每个团队成员。包容所有人还有一个额外的好处，就是改善了相互信任与合作的氛围。这种方法使得 DevOps 组织能够超越软件开发的构建和发布阶段，渗透到整个软件开发生命周期中。这对于大企业尤其有帮助，因为它保护了现有投资并改善了现金流。它为组织提供了频繁测试新工具和技术的可能性，同时保留那些有效的工具和技术。简而言之，全面性对于加速大型组织的数字化转型非常有利。

现在你已经了解了为什么 DevOps 是一种全面的实践，让我们深入探讨一下它如何不仅仅局限于人员，还要仔细考虑流程和技术。

DevOps 集成了 CI/CD、QA、安全性和反馈

DevOps 是一组消除软件开发与运维团队之间沟通障碍的技术，总体上旨在提高产品交付速度和质量。软件必须符合最终用户和利益相关者的要求和期望，这也是为什么质量保证（QA）是 DevOps 的一个重要方面。然而，将 QA 融入 DevOps 工作流中可能会很困难，因为这需要改变思维方式、公司文化和软件。

关键的是，在开发 DevOps 测试流水线之前，必须设立质量目标和关键绩效指标（KPIs）。了解你的 KPIs 的重要性不言而喻；每个独特的企业都有其自己的 KPIs。将质量目标与业务目标和客户需求对齐是任何公司面临的挑战。与你的团队成员及其他相关方分享质量目标，最好能够明确你想在质量方面实现什么目标，这可以帮助你集中 QA 工作，确保团队成员的步调一致。

如你在上一章中学到的，自动化是 DevOps 哲学的基本原则之一，因为它促进了软件部署的加速和标准化。此外，自动化在测试领域也发挥着至关重要的作用，因其能够减少人为错误、优化时间和资源的使用，并提供及时反馈。值得注意的是，明智之举是最大化自动化在整个测试流程中的应用，涵盖多个类别，如单元测试、集成测试、功能测试、性能测试、安全测试和回归测试。此外，建议使用支持自动化的技术和框架，例如JUnit、Cucumber、Selenium、Cypress、TestNG、SonarQube、Nessus、linters等。

再次强调，集成是 DevOps 的一个重要组成部分，其中测试工具与开发和部署系统的兼容性和互操作性至关重要。通过这种方式，建立一个贯穿整个软件开发生命周期的连贯且不间断的测试流水线是切实可行的。建议将测试工具与监控和报告技术（如 Splunk、Grafana 或 ELK）结合使用，以收集和分析有关软件质量和性能的数据。当然，使用具有更强追踪能力的综合 SaaS 产品也是不错的选择。通过将测试工具融入工作流程，你将提高测试过程的效率、透明度和团队成员之间的协作。

在 DevOps 的背景下，反馈起着至关重要的作用，因为它加速了问题的识别和解决，提高了流程效率，并使得从过去的错误中学习成为可能。建议在测试流水线的每个阶段都融入反馈循环，从代码审查到生产部署都不例外。积极推动从多方获取反馈，包括团队成员、消费者和利益相关者，都是值得提倡的做法。实施专门设计用于简化反馈收集和管理的技术和平台，如 GitHub、Bitbucket、Confluence、Jira、Slack 或 Teams，尤其具有显著的好处。实施反馈循环有望培养一种持续发展和创新的文化。

你可能听说过一个常用的流行词shift-left。在软件开发中，采用shift-left 方法意味着在流程的早期阶段尽早开始测试，而不是等到最后才进行。通过这样做，你将能够更快地发现和修复软件缺陷，减少不必要的返工和浪费，并提供更高质量的软件。当你选择 shift-left 方法时，你必须做的一件事是尽早将质量保证团队融入到整个过程，并将他们纳入计划、设计和开发阶段。简而言之，如果你shift left，你可以提高测试的成功率、有效性和覆盖范围。

像计划、编码、构建、测试、发布和部署等阶段通常会包含在 DevOps 流水线中，但它们之间的区别有时可能会变得模糊。当采用被称为DevSecOps的策略时，DevOps 发布管理生命周期中的每个阶段都会受到一套独特的安全标准和评估的影响。让我们讨论将 DevSecOps 集成到 CI/CD 流水线中时执行的安全检查：

• 计划：在项目开发的初期阶段，进行全面的安全分析并制定战略计划非常重要。需要确定许多因素，这些因素决定了测试将如何进行，包括具体的位置，并考虑这些活动将如何影响交付时间表。一个方面是使用威胁建模来检查可能的安全风险并制定对策。另一种方法是从一开始就主动将安全性融入到产品设计中。这意味着要尽早做出关于数据卫生和其他安全措施的重要决策。

• 编码：DevOps 发布管理模型的编码阶段是制定鼓励防御性编程的指导方针，并帮助开发人员立即应对安全和合规问题的理想时机。处理可能存在风险的代码区域（如内存缓冲区内的操作、NULL 指针引用，或其他输入验证、反序列化不可信数据等一般性标准）可能会纳入此类别。此外，建议使用 linting 工具来标记编程错误、漏洞、风格错误和可疑构造。同时，不要忘记在版本控制仓库中添加安全控制，以增强密码和 API 密钥的安全性，或防止对代码的未经授权修改。

• 构建：通过在构建阶段包括自动化安全检查，典型的管道可以在源代码到达主分支或生产环境之前检测到漏洞。例如，您可以执行 静态应用程序安全测试 (SAST) 工具，如 SonarQube、SAST-Scan、Snyk、Prisma Cloud 等，来分析代码。如果工具识别出任何漏洞，构建将会停止，并会发送一份报告通知团队管道失败的结果。这些操作允许开发人员在继续之前立即解决问题。

  此外，为了发现软件依赖中的漏洞并跟踪代码库中的开源组件，管道还应包括 软件组成分析 (SCA) 工具。这些技术共同高效地识别代码漏洞，从而确保它们在部署到生产环境之前得到修复。市场上有许多此类工具，包括商业工具和开源工具，它们专门设计用于审查当今最流行的编程语言。

• 测试：DevOps 从业者通常会建立一套自动化测试用例，旨在通过开发过程中的强质量保证协议来实施。这些测试用例是用于确认软件应用程序预期功能的一系列条件或操作的文档，可以通过手动或使用自动化工具如 Selenium、Cypress、Playwright、Puppeteer、Taiko、Appium、Espresso 和 XCUITest 来执行。为了管理测试过程的时间表和结果，您应使用如 BrowserStack、Testiny、JIRA 和 Xray、LambdaTest、Pivotal Tracker、TestRail、Kualitee、TestCollab、Zephyr 等测试用例管理工具。这些工具管理并跟踪在管道测试阶段识别的任何问题。构建基本单元测试以检查安全漏洞，例如程序如何处理无效或意外输入，是该过程的标准部分。

  此外，通常会结合应用程序安全检查，这些检查会在程序运行时扫描其漏洞。通过将安全措施与功能性并行实施，测试阶段变得更加全面。在应用程序测试过程中，动态应用程序安全测试（DAST）技术被用来主动测试正在运行的应用程序是否存在安全漏洞。常见的工具包括Acunetix、Appknox、Checkmarx、Detectify、Intruder、Rapid7和Veracode 动态分析等。这些工具旨在识别通常与用户身份验证、授权、跨站请求伪造、缓冲区溢出、SQL 注入、API 相关端点以及其他多种漏洞相关的问题。如你所见，这里列举的质量保证工具实在太多，无法在本书中一一详述。你需要与团队合作，评估这些工具，确定哪些工具与贵组织的工作方式和战略目标最为契合。

• 发布：在发布阶段，安全分析工具用于进行自动化安全测试和渗透测试。工具如Astra Pentest、Burp Suite、Metasploit、Nessus和OWASP ZAProxy被用来识别在之前阶段可能未发现的潜在问题。某些组织还遵循最小权限原则，确保个人和工具只被授予执行其职责所需的必要资源，绝不多给予。

• 部署：在成功执行早期测试后，必须继续进行安全基础设施的交付或为最终部署构建生产环境。在部署阶段，确保代码只有在通过每个前阶段的安全检查后才部署到生产环境。一个明智的做法是对应用程序代码和底层基础设施应用额外的自动化测试，作为额外的安全保障，以防在生产环境中部署了未经授权的代码更改，无论是故意还是无意。这可以帮助识别和解决生产软件中的运行时安全问题，无论在什么情况下。

• 操作与监控：在 DevOps 流水线的操作与监控阶段，组织通常依赖应用程序和基础设施指标来检测任何可能表明存在安全事件的异常活动。当发生安全事件时，日志记录、监控和警报可以帮助识别问题、评估其影响并协助恢复。

拥抱 DevSecOps 需要文化上的转变，使得安全成为所有参与软件开发生命周期的利益相关者的基本考虑因素。为了实现这一目标，组织通常会实施新方法并建立一个 DevSecOps 工具链，在整个软件开发生命周期中集成自动化安全检查。

以 DevSecOps 为中心的工具扩展了现有的 DevOps 方法，如 CI/CD、自动化测试实践、系统监控和简化的配置管理，通过无缝集成以安全为重点的工具和技术。接下来，我们将探讨在 DevSecOps 工具链的背景下，区分其作为 DevOps 整体实践下一个独特子集的关键要素。

就以 Webhook 为中心的安全策略而言，任何 DevSecOps 方法的主要目标是通过触发预提交和合并 Webhook 的自动化检查，主动识别和解决代码问题。组织可以选择部署多种类型的评估，具体如下：

• 分析源代码：SAST 是一种通过分析静态源代码（即在程序未运行时）来发现潜在漏洞的方法。

• 分析应用程序漏洞：DAST 通过将软件部署到沙箱环境中来工作。动态应用程序扫描技术可以监控软件对已识别漏洞的反应。

• 秘密扫描：有时，秘密信息会出现在提交中，无论安全政策多么严格。通过将秘密扫描工具嵌入到软件开发者的 IDE 中作为插件，或者在版本控制平台（如 GitHub）中直接分析（如果此功能可用），可以在提交之前识别秘密。此外，许多秘密扫描产品与 SCA 工具兼容，这些工具用于识别任意代码库中的开源软件依赖项可能存在的漏洞。

• 运行时应用程序自我保护（RASP）：运行时验证工具或 RASP 会持续监控并检测在生产环境中运行的应用程序所面临的直接威胁。通常，它们会提供实时报告，指示是否发现漏洞以及发现漏洞的具体位置，并附带时间戳。

就配置管理而言，采用基础设施即代码（Infrastructure as Code）是 DevSecOps 实现消除系统配置不确定性的常见方式。自动化配置文件扫描、版本控制的基础设施和自动化服务发布都可以通过 Docker、Terraform 和 Ansible 等工具实现，这些工具使用另一种标记语言（YAML）语法编写声明式配置文件。

• 编排基于容器的微服务：为了更好地处理复杂的云原生应用，公司在某些情况下可能会选择采用微服务架构。为了安全且高效地做到这一点，你需要容器编排平台来管理多个容器，并根据需要进行扩展或缩减。为了管理容器之间的通信，容器编排技术（如配置管理解决方案）通常使用 YAML 文件格式来进行配置。这些配置也可以使用安全扫描工具进行分析，以检测和修复漏洞。

• 监控和报告：这一测量过程包括记录应用程序和基础设施层级的所有信息，是 DevSecOps 工具包中最直接却极为有效的组成部分之一。顶级工具在问题发生时能立即提供洞察，并且具备强大的报告系统，能够在早期阶段检测问题。如果外发数据从意外端口发送，识别潜在的安全问题可能会变得非常困难。没有合适的监控和报告，就很难发现此类事件。

我们经常在不小心的情况下编写安全漏洞，同时将含有安全漏洞的开源软件库导入到我们的项目中。每天都有很多程序员在编写代码，而手动审查往往跟不上进度。这正是 DevSecOps 真正发挥作用的地方。它确保我们的软件交付物始终得到自动化的安全保障。

为了验证你的团队每次提交的代码，你可以使用持续交付管道来实现持续一切的理念。你的持续管道将从增加自动化安全检查中受益，这些检查提供早期警告通知，并且能够在软件交付生命周期的任何时刻轻松发现安全漏洞。许多持续安全技术能够与组织的成长相匹配，无论是大规模还是小规模的组织。

在 DevOps 中，人员和文化与工具和流程同样重要。如果你想实现质量目标并为客户提供价值，你需要与不仅仅是你团队中的同事，还要与跨职能协作的其他团队进行合作。你还应该努力建立一个注重信任、开放和责任的文化。这种文化应该是一个每个人都为质量贡献并承担责任的环境。除此之外，你还需要激发一种学习文化，让每个人都愿意获取新的知识、技术和方法。通过与你的团队进行协作，能够建立一个展现出高效交付速度和敏捷性的 DevOps 组织。

现在你已经理解了 DevOps 如何全面地融合人员、流程和技术，让我们进一步扩展这一主题，讨论如何将非技术团队成员（如业务部门）的反馈和合作纳入其中。

DevOps 将业务团队融入到开发过程中

DevOps这个术语不仅仅指允许你将应用程序持续部署到生产环境中的技术流程和工具——它的范围远不止于此。如前所述，DevOps 是一种全面的战略，组织的每个层级都需要认识到 DevOps 方法论的合法性。为了确保 DevOps 融入每个项目，销售和营销部门需要将其作为工作流程的固有组成部分，并且必须严肃对待。同样，将有效的 DevOps 实践应用于多个部门也是至关重要的。这确保了未来负责项目的团队成员可以在已建立的框架内开展工作。

DevOps 原则应贯穿于产品生命周期的各个阶段，从开发到维护。这些原则考虑到了生产过程中的每一个步骤，带来了从价值流的开始到结束的文化转变。当公司实施 DevOps 时，它会在整个公司内产生波动效应，因为这是一种思维、行动和存在的方式，必须渗透到每个文化层级。这涉及到打破信息孤岛，营造一种合作氛围，这种氛围远远超出了传统组织中典型的工作环境。诚然，转向 DevOps 可能具有挑战性。为了成功实现这一转变，培训至关重要，且需要高层管理的强有力支持。

换句话说，DevOps 文化所特有的紧密合作和持续反馈不应仅限于开发、测试和运维部门。否则，业务部门将陷入一种境地，即推动和销售团队无法交付的成果。这就是为什么与其他部门（如会计、营销和销售等）保持联系，并确保他们了解进展是如此重要。为了实现提高效率、降低成本和提升质量的目标，涉及整个生产线至关重要。例如，销售部门无法与产品交付团队隔离开展合同工作，因为产品交付团队可能在不知情的情况下生产缺乏需求或背景的功能性软件增量。公司内所有利益相关者必须具备共同的视角和深入的意识，以便协调客户需求与当前的交付能力。

需要强调的是，仅仅设立如DevOps 工程师和DevOps 主管等职位，并开发 DevOps 培训与认证计划，并不足以提供足够的知识或经验。DevOps 的概念可以理解为一种文化范式，而不仅仅是存在着一些孤立的个人或团队从事工具开发或在各自领域进行协作。这意味着组织内的所有个人都共同参与统一的 DevOps 方法论的采用和实施。DevOps 哲学要求组织中的每个人都按照其原则和指导方针行事。

具备资质的 DevOps 教练的支持对于将公司转型为 DevOps 导向的组织至关重要。这一转型通过采用包括系统思维在内的全面战略来实现，并优先考虑客户对高质量产品和服务的需求。

现在，你已经考虑了 DevOps 发布管理如何将业务单元纳入开发过程中，让我们稍作调整，讨论一下DevOps 的三种方法，这完全是关于发现更有效的方式，以更快的速度为公司增加价值。

DevOps 的三种方法

DevOps 的三种方法，来源于Gene Kim的书籍《DevOps 手册》，包括三个基本概念，阐述了指导组织有效拥抱 DevOps 文化并实施必要变革的原则、哲学、流程、程序、实践和规范性措施。如果你的组织刚刚接触 DevOps，DevOps 的三种方法是一个很好的起点，因为它们是哲学性的而非技术性的。

第一种方法 – 流程/系统思维

注意力集中在整个系统的性能上，而非某个特定工作领域或部门的表现。这可以是一个大部门，如开发或 IT 运维，也可以是一个小的贡献者，如站点可靠性工程师或软件开发人员。这里特别强调了由信息技术实现的各种收入来源。值得注意的是，工作需求的创建标志着一个新任务的开始——例如，由业务或 IT 部门产生的任务，之后会进入开发阶段，并为特定的 IT 运维环境量身定制。在这一点上，客户将以服务的形式获得价值，这标志着价值交付过程的一个迭代的结束。

如果正确遵循第一条路径，可以确保缺陷不会传递到生产的后续阶段，局部优化不会导致公司范围的停机，流程将不断改进，并且系统的全面理解将持续追求。已经开始但尚未完成的工作量被称为在制品 (WIP)。如果 WIP 很多，这表明您在进行多任务处理，这几乎总会减慢工作的流程。您应该减少批次大小以限制 WIP。

第一条实践包括以下内容：

• 持续集成

• 持续交付

• 持续部署

• 价值流映射 (VSM)

• 看板

• 约束理论 (TOC)

价值流映射

价值流映射是一种精益管理技术，用于分析现状并设计交付产品或服务的活动序列的未来状态。价值流图是一个图形工具，展示特定过程中的所有关键阶段，并有效地测量每个步骤消耗的时间和量。价值流映射直观地描述了物理资源和数据随着操作序列的推进而移动的过程。

价值流映射的目标是发现并消除或最小化价值流中的“浪费”，从而提高特定价值流的效率。消除浪费的目的是通过建立更有效的流程来提高生产力，从而便于识别浪费和质量问题。

TOC

TOC 是一种管理方法，将任何可控系统视为由于最小数量的约束而无法更多实现其目标的方法。在 TOC 中，始终存在至少一个约束。TOC 采用聚焦过程来发现这些约束，随后重新组织业务的其余方面。TOC 运用广泛使用的短语“链条只有最弱的环节才是强的”。因此，组织和流程容易因“弱”个体或组件的存在而失败或中断，后果可能会损害整体结果。

第二条路径 – 放大反馈循环

DevOps 的第二条路径专注于创建快速反馈循环，使您能够快速构建安全、功能丰富的系统，以此来满足客户的喜爱。无论您是否喜欢，软件的复杂性都是不可避免的。即使是看似微不足道的改动，也可能造成巨大的影响。当我们没有及时反馈时，就会在因果之间造成鸿沟。错误可能被悄悄引入，并且可能要到后来时才被认识到，这时候需要的时间和资源来修复这些错误已经增加。

虽然看起来有些矛盾，但让更多人关注一个问题并不总能带来更好的解决方案。当我们将决策过程远离工作执行地时，审批流程的效率会降低。实施第二种方法的结果包括意识到并响应内外部消费者的需求，减少所有反馈环节的长度，同时增强其影响力，并在需要的地方整合知识。

以下实践包含在第二种方法中：

• 自动化测试

• 生产变更的同行评审

• 监控和 通知实践

• “一目了然”仪表盘和 状态更新

• 生产日志

• 过程度量

• 事后分析

• 共享 值班轮换

• 变更、事件、问题和 知识管理

第三种方法——持续实验和学习的文化

第三种方法的核心理念是建立一种文化，鼓励两条 distinct 原则。第一是持续的实验、采取经过深思熟虑的风险，并从这些经历中获得知识。第二是认识到，唯有通过实践和有意义的重复，才能实现精通，这两者同样必要。

在缺乏信任的工作环境中，事件往往伴随着一种反复出现的指责和愧疚模式。自然，这会妨碍个人和整个组织获取知识和技能。对错误的惩罚威胁成为个体保持在熟悉、舒适环境中的动力。这种环境通常被称为舒适区，其特点是通过避免压力来减少遇到挑战或复杂情况的可能性。在追求知识和理解的过程中，个体通常被建议避免进行实验、探索新概念或提出推测性问题。在这种背景下，个人通常会选择隐藏失败，而不是承担责任，以避免承认错误。因此，在当今社会，个体通常表现出较少的倾向去表达自己的想法或提出创新的解决方法。创新往往受到个体或群体的抵制，这是一种悲剧。追求进步需要进行实验并接受风险，即使这意味着进入比之前更多的风险领域。我们必须具备足够的技能，以便能够修复因我们突破极限而导致的不稳定问题。

实施第三种方式的结果可以总结为：投入时间改进日常工作，培养奖励团队冒险精神的常规，并通过偶尔在系统中产生缺陷来追求更高的弹性、效率和专业水平。

以下实践包括在第三种方式中：

• 实验 和学习

• 计划-执行-检查-行动（Deming 循环）

• 改进卡塔

改进卡塔

根据丰田卡塔（Toyota Kata），管理是一种系统性的努力，旨在通过有效地协调人员的能力，实现期望的条件。

改进卡塔（Improvement Kata）是一种系统化的方法，用于以富有创意、有意义且有指导的方式，从当前状态过渡到理想状态。该模型分为四个部分：

1. 进行雄心壮志或轨迹的审视。

2. 理解当前状态。

3. 精确定义未来的目标状态。

4. 逐步向理想状态迈进，揭示并解决沿途遇到的任何困难。

改进卡塔与那些旨在预测轨迹并集中于执行的方式不同，它利用在过程中获得的发现。采用改进卡塔的团队在努力实现理想状态的过程中，获取知识并根据获得的见解调整他们的方法。

这三种方式与当代技术关系不大。它们的核心是发现更有效的方式，以更快的速度为公司增加价值。这将我们带回信息与通信技术（ICT）的基础，即态度、行为和文化：

图 5.1：DevOps 的三种方式（图像灵感来自 Gene Kim，《The Three Ways: The Principles Underpinning DevOps》）

前面的插图展示了DevOps 的三种方式。从上到下分别是：流动/系统思维、反馈循环的增强，以及持续实验和学习的文化。

现在你已经了解了让 DevOps 发布管理独特的突出特点，让我们通过讨论 DevOps 发布管理与传统发布管理方法和工作流的对比来结束本章。

传统的发布管理方法与 DevOps 相比如何？

规划大规模发布需要更多的工作量和风险，这是传统方法的常见重点。在较长周期和较少发布的情况下，复杂性往往会迅速增加。在这种环境下，你将面临严格的最后期限和一大堆附加任务。大规模发布可能会很壮观，但它无疑是一种效率低下的生产方式。然而，DevOps 采用了不同的策略；较小的发布更易于管理，因为它们更简单易懂并且便于测试。如果情况没有按计划发展，损失也较小。从本质上讲，DevOps 使得公司能够通过更快速、更轻量的发布方式迅速适应客户需求的变化。

在管理任何形式的开发时，传统方法通常会使用规划和调度系统。开发周期通常涉及许多环节，尤其在使用传统方法时，调度通常是一个特别艰巨的挑战。DevOps 方法论的基础是频繁和增量的软件发布原则，以及专门团队利用自动化技术。这种方法显著提高了调度过程的效率。重点通常会集中在短期规划上，通常是针对接下来的几周。这将使你对团队时间的合理分配有更高的敏感度。此外，专门团队的建立有助于高效协调，消除了将个人分配到不同角色中的需求。

传统方法通常会对新产品版本或升级的预期发布大肆宣传。当企业采用传统方法时，会在单一发布上投入大量的精力和资源，增加了失败的风险。在这种情况下，工程师往往会在主要发布前花费大量时间独立工作，这通常被称为“高压时期”。开发人员为这个发布准备了数周，甚至数月，现如今他们正在进行最后的努力，修复可能出现的任何问题，以确保按时发布。另一方面，DevOps 团队并不会每次发布新版本或升级时都举办盛大的庆祝活动，而是采用更短、更规律的开发周期。由于自上一个开发周期以来所需的工作量较少，因此发布的风险大大降低。自动化测试的使用确保了他们的环境是一致且可靠的。只有当 DevOps 确信过渡将成功时，才会将产品版本推广到下一阶段。值得注意的是，通过完全摆脱发布窗口的概念，DevOps 使得将新功能更快投入生产成为可能。

在过去准备发布时，通常需要多个人参与，收集所有必要的信息和数据，最终生成一份冗长的报告，并呈交给高层管理。在许多情况下，冗长的报告代表着瓶颈，因为读者无法确定哪些信息最为重要，或者这些报告在他们收到时是否仍然具有相关性。相比之下，当在以 DevOps 为中心的团队中进行自动化操作时，您可以迅速汇总新的信息并有效地做出响应。这意味着您不必浪费时间坐下来翻阅多页数据。如果将收集应用程序数据的任务委托给以 DevOps 为导向的团队，您可以确保该团队的每个成员都能更好地了解与当前任务相关的信息和数据。这不仅最小化了获取信息所需的时间，还减少了获得管理层批准的时间。

此外，采用传统方法的组织通常避免承担任何不必要的风险。由于文化围绕着员工尽一切可能避免对公司造成损害，这些员工承受着巨大的压力，确保一切完美无缺。然而，实际上，任何事物都无法达到完美的巅峰。DevOps 培养了一种与传统方法大相径庭的文化。团队接受了早期识别失败的文化，承认挫折的不可避免性。因此，建立了一个强大的框架和系统化的方法，通过持续测试、渐进部署和自动化来促进可控的失败。DevOps 团队接受这样一种观点：失败发生得越早，其后果越小，最终的恢复也越快。

值得注意的是，传统策略采用了按性价比计费的模型，评估在最少财务投入下可以完成多少工作。采用这一策略存在几个风险，最显著的是，在保持相同工作能力的情况下，降低成本是相当棘手的。这也是许多使用传统策略的企业频繁将运营外包的原因。DevOps 极大地扩展了这一效率的概念，提出了“流”的概念，因为新应用的开发时间应该是战略性度量的标准。这促使团队分析周期时间，以发现浪费的领域并估算真正的生产力。这使得开发人员能够专注于那些能为客户带来最大价值的活动。

使用传统方法时，每个个体完成他们分配的工作后，再将其交给价值链中更远的同事。在这种情况下，他们会过于关注按时完成任务，而忽略了确保他们的工作在实际条件下的可用性。当采取这种方法时，质量往往会受到影响，而没有人对此负责。与此相反，DevOps 强调建立一个跨职能的组织，在这个组织中，所有成员共同承担任务成功完成的责任。由于高质量软件的生产是团队的共同目标，所有成员将就什么才算工作完成达成一致。他们不再因细节问题而焦虑，而是受到更大图景的激励。

DocuSign 从敏捷到 DevOps 的转型案例研究

DocuSign 是电子签名和数字交易管理的先驱。很少有创新能够像 DocuSign 在数字化转型时代那样，深刻影响协议的制定、签署和管理方式。DocuSign 的产品管理历史，以消除障碍、发明创造性解决方案，并不断适应客户日益变化的期望为特征。这家创新公司由 Tom Gonser 创立，他为一种彻底改变全球商业实践的解决方案铺平了道路。

在本案例研究中，我们将揭示 DocuSign 如何从一个敏捷型企业转变为一个 DevOps 强大的企业。

DocuSign 的起源

DocuSign 的故事始于 1990 年代末，当时，具有远见的企业家兼熟练的软件工程师 Tom Gonser 识别出了传统协议签署方式中的不足和复杂性。在互联网日益强大的背景下，Gonser 对繁琐的纸质流程感到恼火，并梦想着一种数字化的替代方案，能够彻底改变企业和个人履行及传递协议的方式。

在共同创始人 Court Lorenzini 和 Eric Ranft 以及其他人的帮助下，Tom Gonser 于 2003 年创立了 DocuSign，旨在通过将传统的合同签署方式转变为一种在线流程，来革新这一传统方式，使之更加简化、安全和快速。他们的目标是开发一个系统，使个人和公司能够从全球任何地方进行数字签署，从而摆脱受限于纸质文件和地理限制的束缚。

凭借决心和对互联网颠覆性潜力的坚定信念，Gonser 和他的团队建立了平台技术的基础，利用算法加密和电子签名技术，确保数字合同的合法性和有效性。在成立的短短几年里，DocuSign 凭借其早期的成功和用户友好的界面，迅速在电子签名行业崭露头角。

向 DevOps 转型

DocuSign 自成立以来，一直秉持敏捷开发方法。然而，向 DevOps 流程的转型证明是相当具有挑战性的。考虑到他们的业务性质——处理合同和签名——持续集成和交付带来了显著的挑战。他们的整个业务依赖于交换签名和批准的复杂交易过程，而从软件开发的角度来看，这个过程非常难以测试。如果发生任何错误，比如错误的批准归属，这将对他们的业务构成重大威胁。为了提高现代开发的效率，他们采用了一种被称为应用程序模型（简称mock）的高效策略。具体来说，他们使用了一个针对内部 API 的 mock。这个工具提供了一个模拟的端点并返回模拟响应。通过这种方法，DocuSign 能够将应用程序测试方法与事件管理无缝集成，并通过与真实世界交易高度相似的模拟进行彻底的应用测试。

DocuSign 产品团队遇到的障碍

DevOps 发布管理生命周期中最重要的部分之一是持续集成。这是将新功能和更新的代码添加到并与原始代码库合并的阶段。在这个过程中，我们通过单元测试找出并修复代码中的错误，并适当地更新源代码。让我们来看看 DocuSign 开发团队面临的独特挑战，并发现他们是如何克服这些挑战的：

• 关于合规性和安全性的法规：DocuSign 运营的领域涉及机密文件和法律合同，因此必须应对与不断变化的合规性和安全性要求相关的困难。产品经理负责监督全球立法领域的复杂事务，确保平台遵守不同的行业合规标准、法律框架和语言复杂性，同时维护数据安全。

• 在复杂性面前改善用户体验：数字签署文档是一个至关重要的过程，它提出了一个相当大的挑战——如何在不失去功能性和安全性的情况下简化这一过程。产品管理必须小心权衡，努力在提升客户体验和处理机密文档、验证其合法性之间找到平衡。

• 与集成和互操作性相关的难题：DocuSign 产品管理面临的挑战是实现无缝集成，并与其他公司开发的各种平台和应用程序兼容。这是因为组织使用了大量的数字化解决方案。DocuSign 需要做的最重要的事情之一就是确保能够轻松集成到其用户已经部署的工作流程和系统中。

DocuSign 的开发人员通过创建一个基于事务模拟的定制内部测试框架，成功地在组织内建立了 DevOps 发布管理的原则。这使得团队能够应对一个高度挑战性的任务，即在复杂的应用程序中执行自动化集成测试，该应用程序具有复杂的审批流程、安全的图形界面以及强加密的 API 交易，并且这些都在 CI/CD 流水线中进行。通过这些创新测试策略的成功，DocuSign 能够迅速成熟其商业模式，增加了新的产品线，并保持其作为行业主导的电子签名产品公司的地位。

总结

本章结束于第五章。此时，您已经牢牢掌握了 DevOps 发布管理独特性的含义。你了解了 DevOps 是一种整体实践，在制定解决方案或改进整体系统时，考虑到价值流的每个组件。DevOps 的独特之处在于它将 CI/CD、QA、安全性和反馈整合在一起。通过使用精心设计的自动化流水线和精心挑选的测试与审批流程，DevOps 发布管理与其他发布管理模型相比，具有独特优势。DevOps 理念中至关重要的特点之一是将业务团队融入开发过程。你还探讨了DevOps 的三种方式这一重要概念，这一概念由Gene Kim（《DevOps 手册》的作者）普及。此时，你已经准备好区分传统的发布管理方法和 DevOps 方法。

在下一章中，我们将回顾 CI/CD 的基础知识。今天的发布经理必须精通 CI/CD 流程、DevOps 和自动化部署技术。你需要理解 CI/CD 流水线的运行方式，并能够在早期阶段识别问题，这对于 DevOps 发布管理至关重要。

问题

回答以下问题，以测试你对本章内容的理解：

1. DevOps 的三种方式是什么？

2. Shift-left是什么意思？

3. 什么是紧密反馈回路，为什么它们很重要？

4. 为什么消除孤岛效应或个别团队的孤立工作对于组织的成功至关重要？

5. 什么是 DevSecOps？

6. 为什么像DevOps 工程师和DevOps 总监这样的职位称谓是一个误区？

7. 如何通过使用 DevOps 发布管理来减少对其他团队的依赖？

8. 什么是冲刺期，DevOps 是如何避免它的？

9. DevOps 的主要目标是什么？

10. 拥有一个全面的工具集成平台有什么重要意义？

第六章：理解 CI/CD 基础

持续集成和持续交付（CI/CD）是 DevOps 发布管理的关键策略。它自动化了大多数传统上需要人工干预的步骤，这些步骤通常用于生成新的软件发布或将新代码推向生产环境。CI/CD 包括集成测试、单元测试、回归测试以及构建和部署阶段。基础设施即代码也可以集成到 CI/CD 流程中，自动化云基础设施的供应，也可以包括本地虚拟基础设施的供应。通过 CI/CD 流水线，软件开发团队可以对代码进行更改，随后自动进行测试、推送以进行交付，并在任何环境中部署。如你所见，CI/CD 大幅减少了停机时间，确保发布速度更快，版本之间一致性更高，且发布频率更高。真是革命性的！

你可以根据需要定制流水线来完成各种任务，即使这些任务与发布软件无关。这可能包括为业务部门生成报告，在非高峰时段关闭未使用的基础设施并在下一个工作日前重新启动它们，使用生产数据刷新开发数据库，对网络基础设施执行自动化渗透测试，自动旋转 IAM 密钥、SSL 证书等！关于 CI/CD 有很多很棒的信息，但对于本书的主题，提到它是必须的。

在第六章中，你将学到以下内容：

• CI/CD 的基础

• 持续集成（CI）是什么

• 持续交付（CD）是什么

• 持续测试是什么

• Capital One 的 DevOps 转型

到本章结束时，你将学习到 CI/CD 的核心原则、赋予它生命的理念，以及实现它的基本策略。虽然本章不会深入探讨 CI/CD 的技术实现，但你将了解到一些战术策略，帮助你成功实现 CI/CD，并介绍一些工具，帮助你达成目标。

CI/CD 的基础

CI/CD 是当今软件行业的生命线，推动着新程序的快速创建和分发。消除集成和交付瓶颈的工具对于任何 CI/CD 流水线的顺利运行至关重要。团队需要统一的一套技术来协作高效地完成项目。源代码控制、测试工具、基础设施修改和监控工具只是可以与这个框架统一的 SDLC 元素中的一部分。

通过架构良好的 CI/CD 流水线，企业可以迅速应对消费者需求和技术进步的新趋势。相比之下，采用传统开发策略的团队通常需要较长时间才能实施客户请求的变更或融入新技术。此外，当公司意识到需要转型时，消费者需求可能已经发生变化。这个问题通过 DevOps 发布管理得到解决，因为它使用持续集成和持续部署，这是一种比持续交付略为高级的版本，我们将在后面更详细地讨论。

什么是 CI/CD 流水线？

CI/CD 流水线简化了将软件或基础设施作为代码进行交付的过程，确保从源代码到生产部署的顺利过渡。可以将其视为代码发布的必要步骤序列。

CI 是持续集成（Continuous Integration）的缩写，而 CD 是持续交付（Continuous Delivery）或持续部署（Continuous Deployment）的缩写。流水线的概念涉及自动化交付工作流的各个阶段，包括构建、测试、交付和部署。通过自动化和控制交付过程的每个阶段，CI/CD 流水线的所有优点得以释放。这有助于最小化人为错误，并确保每次发布的一致性。

CI/CD 流水线通常作为代码进行配置，因此广泛被称为流水线即代码。为了方便流水线的运行，通常会使用 CI 服务器及其相应的构建代理。根据所使用的产品，构建代理可能被称为runner。通常，构建代理以虚拟机的形式出现，可以自托管、完全定制，并且需要定期维护。另一方面，如果你使用的是商业 SaaS 产品，你可以使用 SaaS 提供商提供的 CI 服务器和构建代理，但在定制化以及添加软件或插件时可能会有一些限制。

容器也可以用于促进创建一致的构建环境，减少维护静态构建代理的需求。在这种情况下，CI/CD 流水线的每个阶段都可以在针对其特定需求量身定制的容器中独立运行。此外，流水线还可以利用容器编排提供的各种优势，包括不可变性和按需扩展。

架构良好的 CI/CD 流水线基础设施应该设计为接受参数，能够在任意环境中产生可重复的结果。它们也具有适应性，考虑到存在消费者需求但现有的 DevOps 解决方案未能满足的场景。在这种情况下，可以快速识别解决方案，进行分析、开发，并在相对较短的时间内将其部署到应用环境中——所有这些都不会中断应用的正常开发流程。

此外，CI/CD 还允许即便是微小的变更也能迅速部署到最终产品中，从而加快了对用户请求的响应时间。它不仅解决了用户的关切，还让他们了解设计和创建过程。用户会注意到随着更新的推出，产品在不断改进，解决了 bug 并添加了新功能。与更传统的方法（如瀑布模型）相比，后者直到开发过程的最后阶段才会让用户参与，DevOps 发布管理促进了整个产品生命周期中的持续反馈和完善。

不同的项目在 CI/CD 管道中需要不同的复杂度和步骤数。一个潜在的管道可能采用多阶段部署方法，其中软件作为容器分发到一个跨多个云环境的 Kubernetes 集群中。相反，另一个管道可能采用更直接的方法，涉及构建、测试和部署一个作为 .jar 文件运行在虚拟机上的应用，并通过代理服务器进行访问。在这个示例中，这两个管道的目标都是自动化软件交付过程。

本质上，建立一个架构良好的 CI/CD 管道基础设施对于充分发挥 DevOps 发布管理所带来的所有好处至关重要。在下一部分中，我们将深入探讨持续集成的话题。内容将包括 CI 的含义、如何为你的组织选择合适的 CI 工具、示例管道语法以及功能比较。

什么是持续集成（CI）？

现代软件开发如果没有持续集成（CI）是无法实现的。现代软件的创建通常涉及来自不同地区的众多开发人员的协作，每个开发者专注于产品的某个特定组件、功能或方面。为了将一个完整的产品发布出来，必须将所有这些代码更改合并起来。然而，手动合并所有这些更改极其不实际，而且是一项痛苦的工作，当多个开发人员并行工作时，代码更改之间不可避免地会发生冲突。然而，持续集成鼓励开发人员持续将代码推送到同一个版本控制系统（VCS），提供了一种解决这一问题的绝妙协同效应。通过使用 CI，你可以持续提交、构建和测试团队的代码，这对于 DevOps 发布经理来说是一项至关重要的策略。如果你的团队经常测试新代码，他们将在缺陷深入软件之前就能够捕获并修复这些缺陷。

虽然对于 CI 可以使用哪些工具没有硬性要求，但许多团队倾向于使用如 Jenkins、GitLab CI 或 GitHub Actions 等持续集成服务器。随着新代码更改的提交，持续集成服务器会监督一切，并充当裁判。每当开发者在代码库中提交工作时，CI 服务器会自动运行一系列测试并记录结果。做出更改的开发者通常会在提交后不久收到一封包含测试结果的电子邮件。这非常关键，因为它使得开发者能够在最短时间内解决潜在问题。

在经过自动化测试后，更新的代码可以获得批准，创建新的构建并在质量保证（QA）和预生产环境中进行额外测试。如果所有质量检查都通过，代码可以合并到主分支，并发布新的版本。单元测试和集成测试通常作为持续集成过程的一部分进行，以确保代码更改不会导致稳定性问题。此外，持续集成是集成静态应用安全测试（SAST）的理想场所，将应用程序安全性提前到开发周期的开始阶段。所有这些测试自动化确保了对代码所做的任何更改在推广到生产之前都经过充分验证。

增加提交频率的另一个好处是，个别贡献者可以在早期阶段主动发现并解决合并冲突，减少其发生的频率，甚至完全避免它们。此外，集成更小的工作增量是避免一次性提交大量更改并遇到神秘错误的有效方式；开发者将会产出更少的代码，合并的行数也更少。这使得识别和解决代码中的 bug 和缺陷变得更加高效，将所需时间从几个小时减少到几分钟。

为你的操作选择合适的 CI 工具

在为团队的操作选择合适的 CI/CD 工具时，你有很多选择。评估你独特的需求和偏好至关重要，因为每个工具都有其优缺点，这可能会影响你的成功。无论你偏好开源选项、人工智能功能、本地解决方案、峰值可扩展性，还是广泛的定制功能，你都可以找到适合你需求的工具。

在为你的团队评估各种 CI/CD 工具时，你应该考虑以下核心因素，以便做出最终选择：

• 本地部署与云部署：评估工具是否提供基于云的和/或本地（托管）解决方案，并选择最适合你项目需求的选项。

• 开源与闭源：考虑 CI/CD 工具与开源项目的兼容性，并评估它与项目目标的契合度。

• 测试集成：建议选择一个具有用户友好界面并且配置容易理解的 CI/CD 工具，以减少与设置相关的困难。

• 设置和配置的简易性：你应该选择一个具有用户友好界面且配置易于理解的 CI/CD 工具，以减少设置过程中的复杂性。

• 构建环境兼容性：考虑工具与项目环境和编程语言的兼容性，以简化集成过程。

• 学习曲线：建议考虑开发人员在设置和配置构建及部署工作流时可能面临的学习曲线，以便更好地支持他们。

• 付费计划功能：为了应对项目的增长，建议检查付费计划（如果有）中现有和新提供的功能，包括分配的每日构建次数、运行时分钟数、用户数量以及私有仓库数量等。

• 版本控制系统兼容性：确保你验证 CI/CD 工具是否能够与您首选的版本控制系统或源代码管理平台顺利集成，从而实现高效的源代码管理和交付。

让我们深入了解三款行业领先的 CI/CD 工具，帮助你评估哪一款最适合你的企业。首先，Jenkins 是一个非常著名的 CI 服务器，已经存在了很长时间，提供了许多插件，具有一些新竞争者所没有的功能。另一个与 GitHub 仓库优雅集成的强大工具是 GitLab CI。别忘了 GitHub Actions，它提供了一个简单易懂的工作流程。

Jenkins

Jenkins 是一个知名且高度可定制的开源 CI/CD 工具，几乎可以自动化所有工作。Jenkins 使用 Java 编程语言开发，并且是开源的，采用 MIT 许可证发布。该软件提供了一个全面的功能范围，可以简化多个任务，包括构建、测试、部署、集成和发布软件。Jenkins Server（主服务器）软件兼容 Linux、macOS、Windows 和 Unix 操作系统。除了通过本地安装包安装外，Jenkins 还可以作为独立的 Docker 容器运行，或者在任何安装了Java 运行时环境（JRE）的机器上运行。

Jenkins Master 负责监督和协调整个构建过程，充当仲裁者。它作为配置设置、作业定义和元数据的中心，拥有完全的控制权。在这里可以安装各种插件，扩展 Jenkins 的功能和能力，例如集成Atlassian JIRA或SonarSource SonarQube。此外，Jenkins Master 提供了一个易于使用的基于 Web 的界面，用户可以与 Jenkins 互动，设置作业并跟踪构建进度。

然而，多个 Slave 节点充当系统中勤奋的工作者。在 Master 的直接监督下，它们执行分配的任务。通过将任务分配给多个 Slave，可以通过并行处理更快地完成构建管道。此外，Slave 可以在不同的机器上进行配置，包括各种操作系统和环境。得益于这种灵活性，Jenkins 能够满足各种构建和测试需求。

此外，Jenkins 团队还开发了一个名为 Jenkins X 的子项目，它专注于在 Kubernetes 中轻松运行管道，几乎不需要额外的工作。Jenkins X 无缝结合了 Helm、Jenkins CI/CD 服务器、Kubernetes 以及其他多个工具，提供一个简化的 CI/CD 管道，采用了预设的最佳实践，例如使用 GitOps 来管理环境。

Jenkins 语法示例

现在，让我们通过一个 Jenkins 管道的示例来实际理解它的语法以及如何配置！在Jenkinsfile文件中，正在构建一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker 注册表：

图 6.1：示例 Jenkinsfile – 配置构建 Docker 镜像的管道

GitLab CI

在所有可用的 CI/CD 工具中，GitLab CI/CD 脱颖而出，成为最新且最受高度评价的选项。该产品是一个自托管的持续集成工具，社区版完全免费使用。

它包括一系列功能，如 git 仓库管理、问题追踪、代码评审、维基和活动流。公司通常选择将 GitLab CI/CD 安装在本地，并将其与组织的 Active Directory 和 LDAP 服务器连接，以确保安全的授权和认证。使用 GitLab 社区版的一个明显缺点是没有任何形式的客户支持。如果遇到问题或需要项目帮助，无法像 Premium 版和 Ultimate 版那样提交工单并请求帮助。

从社区版升级到 Ultimate 或 Premium 版本后，你将能够访问客户支持服务，并且可以使用许多有利的安全功能，例如双因素认证、先进的安全扫描以及代码合规性审计工具。此外，你还可以使用各种辅助工具，包括推送规则、DORA 指标跟踪、燃尽图、安全扫描 IDE 集成和动态应用安全测试（DAST）功能。通过利用高级监控功能（如性能指标和系统健康检查），你还可以确保你的项目始终稳定运行，并避免额外的风险。

GitLab 服务器负责检测触发事件，这些事件会启动一个或多个管道。当一个新的管道开始时，GitLab 服务器会决定哪些任务（在你的 .gitlab-ci.yml 文件中定义）需要执行，并根据需要跳过某些任务或将它们排队。然后，这些任务将按正确的顺序分配给可用的 Runner。

前述图中所示的 GitLab 架构包括以下组件：

• 提交（Commit）：提交是对文件或代码所做更改的记录，就像你在 GitHub 仓库中看到的那样。

• 任务（Jobs）：任务是 GitLab 管道需要执行的单独任务，例如部署应用程序。每个任务都有一个名称，并包含一个脚本。每个脚本按顺序执行，确保每个任务在进行下一个任务之前都已经完成。

• 阶段（Stages）：阶段用于清晰地区分不同的任务，标志着管道在每个步骤中的进展。这有助于明确任务的执行顺序。例如，阶段可以包括测试、构建和部署。

• 管道（Pipeline）：管道是一组完整的阶段，每个阶段由一个或多个任务组成。GitLab 提供了多种管道选项，如基础管道、合并管道、父子管道和多项目管道。

• Runner：Runner 是负责执行 CI/CD 管道的活动组件。你可以选择在本地设置自托管的 GitLab Runner，或者使用 GitLab 提供的运行器，作为其 SaaS 产品的一部分，托管在 GitLab.com 上。

• GitLab 服务器：GitLab 服务器负责托管和管理你的管道配置。你可以在本地设置自己的 GitLab 服务器实例，也可以使用托管在 GitLab.com 上的 SaaS 版本。

GitLab CI 语法示例

让我们通过一个 GitLab CI/CD 管道的示例，来实际了解它的语法以及如何进行配置！在 .gitlab-ci.yml 文件中，构建一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker Registry：

图 6.2：示例 GitLab gitlab-ci.yml 文件 – 配置用于构建 Docker 镜像的流水线

GitHub Actions

GitHub Actions 是一个用于持续集成和持续部署的工具，作为 GitHub 流程的一部分。它可以用于将代码更改集成并部署到第三方云应用平台，也可以用于测试、跟踪和管理代码更改。GitHub Actions 兼容各种第三方 CI/CD 工具、Docker 容器生态系统以及其他自动化技术。

GitHub Actions 通过事件驱动触发器无缝地将自动化集成到 GitHub 的软件开发生命周期中。这些触发器是可以指定的事件，范围从创建拉取请求到在代码库中构建新分支等多种操作。GitHub Actions 的自动化通过位于代码库 .github/workflows 目录中的 YAML 文件进行管理。这些工作流定义了自动化过程，其概念类似于 Jenkins 中的 Jenkinsfile 文件或 GitLab CI/CD 中的 .gitlab-ci.yml 文件。

每个工作流由几个核心概念组成：

• 事件：事件是启动工作流的定义触发器。开发者可以配置它们以搜索一个或多个触发器，然后根据需要进行调整。此外，事件还可以配置为在 GitHub 上指定代码库中的指定代码分支上执行。

• 作业：作业由一系列在单个运行器上执行的顺序任务组成。每个任务在自己的虚拟机（VM）中运行，并与其他任务并发执行，除非另有声明。

• 步骤：步骤是一个独立的操作，用于在作业中执行命令。这些步骤可以是动作或 shell 命令。作业中的每个步骤都在同一个运行器上执行。

• 动作：动作指的是在运行器上执行的命令，它是 GitHub Actions 的基本组成部分，GitHub Actions 也因此得名。

• 运行器：运行器作为 GitHub Actions 的服务器。程序积极监控可用任务，按并发方式执行它们，并提供关于进度、日志和结果的更新。运行器可以托管在 GitHub 上，也可以托管在本地自建的服务器上。GitHub 托管的运行器使用 Ubuntu、Linux、Windows 和 macOS 作为底层操作系统。

使用 GitHub 原生的 CI/CD 工具的主要优势在于其简单性。如果你已经在 GitHub 上托管项目，你可以利用内置的 CI/CD 工具，因为它与代码仓库完全集成。CI/CD 管道可能相当复杂，涉及用于测试应用程序、集成测试、容器平台和应用平台等组件的多种工具。GitHub Actions 通过提供与 NodeJS 和 Docker 的无缝集成，简化了整个过程。特别地，它使你能够快速选择所需的依赖版本，并轻松地将代码连接到所需的环境和部署平台。与其他自动化工具和功能不同，GitHub Actions 不仅限于测试、构建和部署的典型应用。相反，它提供了自动化任何 webhook 的灵活性。

GitHub Actions 工作流语法示例

现在，让我们通过一个 GitHub Actions 管道的示例来深入理解它的语法以及如何配置它！在 GitHub Actions 的Workflow文件中，正在构建一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker 注册表：

图 6.3：GitHub Actions 工作流示例——配置为构建 Docker 镜像的管道

现在我们已经对这三种工具的语法差异有了基本的了解，接下来让我们对这三种 CI 工具的功能进行比较。

三种 CI 工具的并排功能对比

以下表格提供了 Jenkins、GitLab CI/CD 和 GitHub Actions 这三种行业领先 CI 工具的功能和优点的并排对比。所提供的信息旨在帮助你根据自己的独特需求和偏好评估哪种工具最适合你的操作。

特性	Jenkins	GitLab CI/CD	GitHub Actions
本地部署（自托管）	是	是	仅限 Runner
基于云	否	是	是
开源	是	是	否
闭源	否	是	是
测试集成	是	是	是
安装和配置简易性	困难	中等	容易
构建环境兼容性	Linux, Windows, macOS, Unix	Linux, Windows, macOS	Cloud SaaS
语言支持	任何现代语言	C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, TypeScript 等	C, C++, C#, Java, JavaScript, PHP, Python, Ruby, Scala, TypeScript
学习曲线	困难	中等	容易
付费计划功能	否	是	是
VCS 兼容性	GitMercurial (hg)Subversion (svn)Perforce (p4)ClearCaseMicrosoft TFS	Git	Git

表 6.1：Jenkins、GitLab 和 GitHub Actions 的功能对比

代码集成、自动化构建和集成测试是持续集成的三大支柱。持续集成过程的最终目标是生成一个可部署的工件。这标志着我们对持续集成及其工具的探讨结束。在下一部分，我们将讨论持续集成的对立面——持续交付。

什么是持续交付（CD）？

持续交付（CD）指的是自动准备代码变更以发布并部署到生产环境中的过程。持续交付是 DevOps 发布管理的重要组成部分，通常与持续集成（CI）一起使用。

即使在软件开发生命周期（SDLC）的最后阶段，开发人员也能借助 CI/CD 流水线和版本控制系统（VCS）成功地部署大多数产品代码版本。持续交付使程序员能够在将代码发布给客户之前，使用多种视角（不仅仅是单元测试）自动测试代码变更。通过这种方式，开发人员可以对他们正在部署的构建工件的质量有信心，因为这些工件已接受严格的测试，并符合行业标准。API 测试、负载测试、功能和 UI 测试、集成测试、合规性测试等，都是你通常会在此阶段执行的合适测试类型。

因此，软件开发人员能够在新软件发布之前快速评估是否存在漏洞和缺陷，以便允许其访问生产环境。值得注意的是，持续交付通常包括多阶段部署的执行，其中工件会经历不同阶段的过渡，包括 QA、预发布、预生产，最终到生产。通常在每个阶段都会进行额外的测试和验证步骤，以确保交付工件的可靠性和合法性。发布后的验证程序和部署监控可以（并且应该）被实施，以进一步增强软件发布的可靠性和弹性。

持续交付不仅承担了部署应用程序的责任，还包括进行配置修改、监控应用程序性能，并确保其持续维护。这就是为什么在流水线设计中构建灾难恢复（DR）变得至关重要。因为持续交付有潜力通过包含如基础设施管理等运营职责，扩展其功能范围。这些任务可以通过专为此目的设计的基础设施即代码（IaC）和配置即代码（CaC）工具来实现。

什么是基础设施即代码（IaC）？

在技术领域，基础设施一词通常与物理组件相关，如机架服务器、网络系统和数据中心。然而，随着云计算的普及，基础设施已经超越了其物理限制，转变为可以快速创建、修改和废弃的虚拟服务和环境。在这个新时代，如何高效、可靠地管理和提供这些动态资源，已经成为一个重大挑战。这时，基础设施即代码（IaC）概念变得尤为重要。IaC 工具已成为解决这些挑战的关键，通过允许通过代码管理基础设施，而不是依赖手动过程。这种方法简化了构建和维护虚拟 IT 基础设施的过程，提高了一致性，最小化了错误风险，并实现了轻松的自动化和可扩展性。

正因为如此，理解幂等性概念在 IaC 中的重要性。在执行 IaC 部署时，它确保目标环境的配置始终一致，无论其初始状态如何。也就是说，幂等性可以通过两种方法实现：自动配置当前目标，或者丢弃它并从头开始创建一个新的目标环境。

幂等性

数据管道中的幂等性指的是能够多次执行相同操作，而结果不会超出初始应用的变化。这个特性确保了在分布式系统中的一致性和可靠性。

值得注意的是，基础设施即代码（IaC）已成为解决配置漂移问题的主要解决方案，无论是在发布流水线还是虚拟化部署环境中。至关重要的是，如果没有 IaC，团队将需要手动分别管理环境和部署配置。以这种方式操作时，随着时间的推移，每个环境不可避免地会发展出自己独特的配置，而这些配置无法自动复制。因此，由于不同环境（如开发、质量保证、预发布和生产环境）之间的不一致，可能会导致部署问题。由于依赖手动过程，基础设施管理和维护可能会变得具有挑战性，容易出错，并且难以监控。

配置漂移

信息技术系统配置随时间逐渐变化的现象被称为配置漂移。漂移通常是在没有适当文档或批准的情况下对软件、硬件或操作系统进行修改时无意发生的。它可能会影响系统某一部分或整个系统的安全性和效率。应用程序故障、停机时间、开发周期延长、IT 服务请求激增、安全漏洞、审计罚款、合规性失败等，都是配置漂移的直接后果。

相反，基础设施即代码（IaC）利用了 DevOps 方法论和版本控制的优势，能够高效地定义和部署各种基础设施组件。这包括网络、虚拟机、负载均衡器、DNS、无服务器部署、身份访问管理等。你可以将 IaC 理解为软件定义的基础设施。类似于相同的源代码始终生成具有相同功能的二进制文件，IaC 模型也始终生成相同的环境进行每次部署。IaC 在当代 DevOps 实践中起着至关重要的作用，并且是持续交付的重要组成部分。通过使用 IaC，DevOps 团队能够通过标准化的方式和资源无缝协作，高效地在大规模上部署应用程序及其相关基础设施，确保速度和可靠性。也许最好的地方是，IaC 文件可以存储在 Git 中，且易于审计。

为了实现这一目标，IaC 精简了配置过程，并通过使用声明性代码（如 YAML、JSON 和 HashiCorp 配置语言（HCL））表示期望的环境状态，确保了一致性。发布流水线消耗 IaC 文件，并应用环境描述和版本化配置模型，设置高度可靠的目标环境，从而消除了由配置不一致或缺少依赖关系引发的运行时问题。关键在于，这使得团队可以对源代码进行编辑，而不是直接对目标进行修改。

有几个流行的工具已经被开发出来，用于自动化这些任务。在接下来的子章节中，我们将详细介绍四个最常见的工具：Terraform、Pulumi、Ansible 和 Puppet。

Terraform

Terraform 是一个强大的基础设施即代码工具，允许你使用易于理解的 HCL 配置文件定义云端和本地资源。这些文件可以进行版本控制、重用和共享，使其成为管理基础设施的便捷选择。你可以应用精简的工作流程，准确地建立并控制基础设施在其生命周期的每个阶段。

Terraform 被设计用于管理各种组件，从低级别的计算、存储和网络资源，到高级别的 DNS 条目、Kubernetes 集群和 SaaS 特性。Terraform 无缝集成了流行的持续集成和持续部署系统，如 GitLab、GitHub Actions 和 Jenkins。借助这个解决方案，你可以优化部署和管理基础设施的整个过程，快速从代码推向生产环境。

Terraform 采用基于插件的架构，与各种云提供商（包括 AWS、Google Cloud 和 Azure）无缝对接。每个提供商都包含一组独特的插件，使 Terraform 能够有效地处理其资源。Terraform 处理用 HCL 编写的配置文件，并生成一个资源的依赖关系图，标识需要创建或修改的资源。然后，它会执行一个计划来创建或修改必要的资源，以实现预期的状态。Terraform 包括一个状态文件，用于保持当前基础设施的状态。

Terraform 的工作流极其简单，只有三个步骤就能有效管理任何类型的基础设施：写、计划、应用。Terraform 的三步流程是管理任何类型基础设施的最简单工作流之一。它允许用户根据自己的具体需求和实施风格定制工作流。为了说明 Terraform 的工作原理，让我们看看一个示例 Terraform 计划，该计划可用于在 AWS 中创建一个 EC2 实例：

图 6.4: 示例 Terraform 计划 - 配置以提供 AWS EC2 实例

Pulumi

Pulumi 是一个前沿的基础设施即代码（IaC）平台。它利用流行的编程语言，如 TypeScript、JavaScript、Python、Go、.NET、Java，以及标记语言如 YAML，并结合它们各自的生态系统，与云资源无缝互动。Pulumi 的综合平台无缝集成了可下载的 CLI、运行时、库和托管服务，以便部署虚拟基础设施。这种灵活的组合可以有效地进行云基础设施的配置、更新和管理。

用流行编程语言编写的 Pulumi 程序概述了云基础设施的组成。添加新基础设施时，您只需将资源对象分配为符合基础设施所需状态的属性。这些属性可以用来管理资源之间的依赖关系，并且如果需要，能够导出到堆栈之外。

Pulumi 平台由多个组件组成：

• Pulumi 软件开发工具包（SDK）：它为每种资源类型提供绑定，可以由提供商管理。该资源为用户提供了必要的工具和库，以便有效地定义和管理跨不同提供商和平台的云资源。

• 命令行界面（CLI）：它允许您部署云应用程序和基础设施的更新。它还记录了团队的更新，包括贡献者和时间戳。

• 部署引擎：部署引擎计算出将您的基础设施当前状态与程序指定的目标状态对齐所需的操作。

程序存储在项目中，项目是一个包含程序源代码及执行指令的目录。完成程序后，你可以从项目目录使用 Pulumi CLI 执行Pulumi up命令。该命令允许你创建一个独立且可定制的程序实例，称为堆栈。堆栈作为用于测试和实现应用程序更新的各种部署环境。例如，你可以创建并测试独立的开发、暂存和生产堆栈。

这是一个演示概念的示例程序。它创建了一个名为web-sg的 AWS EC2 安全组，包含一个入口规则，并创建一个使用该安全组的t2.micro大小的 EC2 实例。EC2 资源需要安全组的 ID 来使用它。Pulumi 通过使用安全组资源上的输出属性名称来实现这一点。Pulumi 深入理解资源依赖关系，能够优化并行处理，并在创建堆栈时保持正确的顺序。

最后，服务器的 IP 地址和 DNS 名称作为堆栈输出导出，便于通过 CLI 命令或其他堆栈轻松访问。

图 6.5：示例 Pulumi 代码 – 配置为提供 AWS EC2 实例

Ansible

Ansible是一个开源配置管理工具，提供了一个简化的服务器自动化框架，使用 YAML 定义。由于其简化的基础设施需求和用户友好的语法，Ansible 作为一个配置管理工具获得了极大的普及。

与其类别中的其他工具（如 Chef 或 Puppet）不同，Ansible 不需要在远程节点上安装任何专用软件（代理）。控制机器配置了 Ansible 软件，使其能够通过标准 SSH 协议与节点通信，Python 被用于执行远程指令。

任务是你可以使用 Ansible 剧本自动化的最小操作单元。剧本通常包含一系列任务，服务于一个目标，例如设置 Web 服务器或将应用程序部署到远程环境中。Ansible 按剧本中定义的顺序执行任务。在自动化某个过程之前，例如设置 LAMP 服务器（Linux、Apache、MySQL、PHP），你需要评估哪些手动步骤是必要的，以及它们完成的顺序。然后，你可以确定需要哪些任务以及可以使用哪些模块在更少的步骤中实现目标。

此外，Ansible 提供了一系列预构建的模块，简化了自动化常规服务器操作的过程。这些模块涵盖了广泛的任务，包括包安装、用户管理、文件操作、权限处理和服务管理。

为了说明 Ansible 如何工作，让我们看一个示例 Ansible 剧本，它可以用于在 AWS 中创建一个 EC2 实例：

图 6.6：示例 Ansible 剧本 – 配置为提供 AWS EC2 实例

Puppet

Puppet 是一个配置管理工具，利用其自身的声明性语言来描述基础设施的状态。Puppet 的语言旨在高效地处理 IT 基础设施的每个生命周期阶段，包括任务如供应、修补、配置和操作系统与应用组件的管理，适用于数据中心和云基础设施。

Puppet 专门设计用于处理类 Unix 系统和 Microsoft Windows 系统的配置。为此，用户分配系统资源及其状态，使用 Puppet 的声明性语言或 Ruby 领域特定语言 (DSL)。通过这种方式，基础设施配置存储在被称为 Puppet 清单的配置文件中。执行时，Puppet 工具会将 Puppet 清单编译成一个特定于系统的目录，其中包含资源及其依赖项。然后可以将该目录应用到目标系统，并将 Puppet 执行的结果报告给用户。

Puppet 通常遵循客户端-服务器架构。在这种情况下，客户端被称为代理（agent），而服务器通常被称为主控（master）。此外，它也可以作为一个独立的应用程序，从命令行执行，方便进行测试和基本配置。Puppet Server 通常安装在多台服务器上，而 Puppet Agent 则安装在所有需要管理的机器上。通过这种方式，Puppet 代理与服务器通信以获取配置指令，然后进行部署。代理会在目标系统上实现配置，并及时向服务器发送详细的状态报告。值得注意的是，机器能够作为守护进程（daemon）运行 Puppet 代理，这可以定期安排为 Cron 作业运行，或者根据需要手动执行。

为了说明 Puppet 如何工作，让我们看一个示例 Puppet 清单，它可以用于在 AWS 中创建一个 EC2 实例：

图 6.7：示例 Ansible 剧本 – 配置为提供 AWS EC2 实例

基础设施即代码（IaC）与配置即代码（CaC）之间有什么区别？

尽管 IaC 和 CaC 之间存在相似之处，但它们也有显著的差异。如前所述，IaC 主要用于部署虚拟基础设施，包括服务器实例、存储设备和网络组件，以及任何额外的资源和权限。相比之下，作为代码的配置工具则在此基础上跟进，配置和定制操作系统、应用程序配置以及在使用 IaC 工具生成基础设施后监控设备。这项活动用于自动创建精确符合客户或业务特定需求和目标的计算系统。这两种自动化工具各具独特优势，适合在特定用例中使用，或者一起使用。

为了帮助你理解其差异，这里有一个类比。基础设施即代码可以看作是使用工具来建造一座办公大楼，而配置即代码则是一套用于为办公大楼配备设备和资源的工具，这些设备和资源是企业完成实际工作的必需品。

值得注意的是，在集成基于云的部署时，软件开发人员可以轻松且经济实惠地创建多个测试环境并对其进行迭代。历史上，在本地部署环境中工作时，动态创建测试环境要困难得多，但现在这种情况已经不复存在。巧妙的是，计算机硬件制造商，如 HP、Dell 和 SuperMicro，已经在其产品设计上做出了许多改进，使本地体验现代化。如今，大多数机架式服务器的固件中嵌入了 API，并与市场上常用的 IaC 和 CaC 工具进行了本地集成。这使得本地硬件具备了类似于其云竞争对手的功能，使其能够在竞争激烈的市场中保持相关性。

持续交付管道

合法的 CD 管道的主要特点是它能够在软件生命周期的任何阶段促进软件部署。换句话说，设计良好的 CI/CD 管道基础设施应确保任何版本的应用程序都可以轻松部署到指定的测试、预发布或生产环境中，只需几次点击鼠标，并具有绝对的幂等性。此外，开发团队应能够及时获得来自任何环境中自动化测试的反馈，并应利用这些反馈来促进产品改进和提高运营效率。

持续交付管道有五个主要阶段：

图 6.8：持续交付的五个常见阶段

该图展示了持续交付策略中最常见的五个阶段：提交、测试、构建、预发布和部署。正如你所看到的，这个周期被设计得尽可能短，从新的代码更改提交到版本控制，再到它在生产环境中部署的时间间隔最短。除此之外，还包含了多个验证步骤，以确保最高的质量。这包括构建代码的能力，这本身就可以视为一种测试形式。

值得注意的是，在以产品为中心的公司中，比在以服务为主的公司中更容易实现持续部署工作流。原因在于服务公司需要为每个客户量身定制解决方案，而产品公司则专注于狭窄的价值流范围。

持续交付与持续部署的区别

在 DevOps 发布管理的背景下，持续交付和持续部署这两个术语表示了自动化的两个层级。

通过持续交付，减少了手动部署新代码的需求，从而节省了时间和资源。首先，编写代码，然后自动测试，接着批准，最后推送到一个仓库，其他工程师可以访问。当代码完成后，运维团队可以迅速获取并轻松地通过自助功能将其部署到生产环境。

该图展示了持续交付与持续部署流程的区别：

图 6.9：持续交付与持续部署

正如你所看到的，有一个决定性特征区分了这两者：部署到生产环境。在持续交付中，必须在允许新的代码更改部署到生产环境之前执行人工批准步骤。而在持续部署中，自动化测试承担了这个角色，因此不需要人工干预。

通过将持续交付的自动化扩展到软件开发生命周期（SDLC）的下一阶段，持续部署可以帮助减少运维团队的工作量，加快应用程序的交付。任何辅助的软件发布流程通常也会被自动化，从而减少或消除人工干预的程度。例如，可能会设置一个持续部署管道，在将新版本提交到 Git 仓库并部署到生产环境后，自动进行部署，以便客户能够尽早使用。

连续部署比持续交付更难实施，因为它在将授权的软件产品部署到生产环境时完全消除了任何人工干预的需求。这意味着，为了实现真正的连续部署，您的自动化测试必须丰富、可互操作和可扩展。

GitOps 如何与持续交付结合

GitOps 与 DevOps 之间存在一些显著区别。也许最重要的方面是，GitOps 更加强调使用自动化和工具来有效管理和分发代码修改。相反，DevOps 更加强调促进团队成员之间的有效沟通和协作。另一个区别是，GitOps 广泛与诸如 Kubernetes 等容器化技术同时使用，而 DevOps 可应用于多种其他类型的应用部署。

GitOps 是 DevOps 更广泛领域内的一个专业领域，其核心是利用 Git 仓库来有效管理基础设施状态和应用部署。GitOps 与 DevOps 的一个重要区别在于，Git 仓库在应用和基础设施部署状态的管理中充当单一权威数据源。因此，Git 仓库类似于账本或者说类似于区块链的概念。

另一个关键要理解的事情是，GitOps 在其主要实施方法中严重依赖拉取式部署。在传统的 DevOps 方法中，连续集成和连续交付流水线是由外部事件触发的，例如当新代码推送到应用程序仓库时。与此不同，GitOps 通过拉取式策略保持应用程序的实时性，通过将当前部署的应用程序状态与版本控制仓库中声明的理想应用程序部署状态进行比较。如果检测到两者之间的任何差异，GitOps 操作者将更新实时基础设施，使其与指定仓库中声明的配置相匹配。

聪明地，拉取式部署使得在出现问题时轻松将不稳定的软件部署回滚到已知的最后稳定版本成为可能。此外，拉取式技术是声明性的，使得实施蓝/绿和金丝雀部署等高级部署策略变得轻松。

蓝/绿部署

蓝/绿部署生成两个相同的环境。一个环境（蓝色）运行现有的程序版本，另一个环境（绿色）运行新版本。在绿色环境上通过测试后，实时应用流量被定向到那里，并且蓝色环境被弃用。通过简化部署失败的回滚，蓝/绿部署策略提升了应用程序的可用性并降低了部署风险。

由于 GitOps 部署是不可变的，因此可以轻松地重置到任意或未记录的修改到实时基础架构上。它强制执行 Git 日志中所有更改的完整审计轨迹，并帮助避免可能导致系统状态不一致的直接集群更改。

金丝雀部署

金丝雀部署指的是一种逐步和受控的应用发布策略，其中流量被分配给现有版本和新版本。该方法首先将新版本引入到一小部分用户中，然后再将其部署到整个用户群体中。通过采用这种方法，可以在广泛分发给消费者之前确定更新版本应用程序的可靠性。

什么是持续测试？

到目前为止，你应该已经牢牢掌握了自动化测试的重要性，至少基于对该主题的多次提及。强调自动化测试对 DevOps 发布管理的重要性是不容忽视的。

持续测试是 CI/CD 更广泛背景下的一种实践，有助于贯穿整个开发生命周期提高软件质量。通过精心策划的自动化测试策略，持续测试确保软件开发团队获得实时反馈，使他们能够尽早消除尽可能多的潜在风险和缺陷，涵盖整个软件开发生命周期。此外，团队成员将得到充分装备，持续获取有关其产品及其改进方式的新见解。

然而，在组织中实施持续测试并不是一项简单的任务，因为你必须制定一个测试策略，以确保变更能够顺利推进，而不会触发任何误报。就像持续部署一样，实施持续测试比听起来要复杂得多，因为它们是相辅相成的。传统上，软件测试是在代码编写完成后首次进行，然后交给质量保证团队独立测试。当在代码中发现错误时，错误会被返还给开发人员以进行修正。在开发周期较慢时，这种测试模型在一定程度上是可行的。然而，在如今快速发展的环境中，这种模式不仅充满挑战、繁琐，而且容易导致中断和人为错误。相反，当今的组织要求快速交付高质量的产品，因为这是客户在竞争激烈的数字市场中所期待的。如果资源允许妥善实施，那么在以 DevOps 为中心的组织中，没有比持续测试更好的方式了。

持续进行测试的价值就在于此。如果在将代码添加到仓库后立即进行测试，错误可以在更多工作进行之前被发现并修复。这样就不需要在未来做出针对 bug 修复的代码修改，因为这些错误的存在本可以在一开始就避免。在我们这个现代化时代，开发者甚至可以从直接安装到本地集成开发环境（IDE）中的自动化测试插件中受益，例如 Eclipse、Microsoft Visual Studio 和 PyCharm。这使得开发者能够在编写代码时，及早发现和修复问题，而不需要等到代码被提交到版本控制之前。

面向客户的软件质量保证需要彻底的端到端测试，以确保整个系统都能被有效地测试，这将帮助你验证你的应用程序是否按预期表现。端到端测试要求使用真实的数据和环境，以获得最可靠的结果。使用模拟数据（这些数据代表了真实生产环境中的数据）时，你将更有能力发现并修复代码中的问题。利用这些信息，你可以通过在现实测试环境中进行模拟，了解应用程序在真实世界中的表现。顺便提一句，这一理念是实现金丝雀部署的核心思想，即在生产环境中将一小部分用户暴露于经过验证的预发布版本。

有效的持续测试需要同时进行持续集成和持续交付。在测试过程中，许多步骤，如代码构建、部署和分析，都可以借助 CI/CD 工具来自动化。使用 CI/CD 和 DevOps 发布管理时，新特性和错误修复可以更快发布，同时仍能保持高质量标准。密切关注测试结果和用户反馈，确保你的软件不断改进。这些数据将帮助你发现流程中的问题，并做出必要的调整来改进它们。保持高质量的软件需要在时间的推移中维持对测试结果的高质量意识。

在接下来的部分中，我们将通过案例研究来探讨金融机构 Capital One 如何在进行 DevOps 转型时充分利用 CI/CD。

Capital One 的 DevOps 转型

2010 年，Capital One 认识到客户偏好在线和移动银行。鉴于此，执行领导层决定增强公司的技术能力，并建立一种能够吸引并培养具有协作开发能力的高技能技术人才的文化。谨慎起见，Capital One 优先招聘了这些优秀人才，并确保他们与深刻理解业务需求的相关决策者密切合作。不久之后，公司便开始采用敏捷软件开发技术，这最终成为实施 DevOps 发布管理的基础。

迅速响应客户反馈一直是 Capital One 的首要关注点。因此，DevOps 成为了开发团队实现加速开发和部署周期的合乎逻辑的选择。在 2012 到 2020 年间，Capital One 经历了一系列转型：

• 采用敏捷实践

• 创建自动化测试用例

• 使用 CI/CD 自动化部署和测试

• 将运营迁移到公共云服务提供商

通过这些改进，银行转型为一个拥抱开源解决方案和快速交付周期的组织。2020 年，Capital One 创下历史，成为首家将其所有传统本地数据中心迁移至公共云服务提供商的美国银行。

Capital One 的 DevOps 转型策略

尽管最初只有少数员工，Capital One 的目标是建立一种公司范围的 DevOps 方法。随着时间的推移，该公司实施了以三阶段方法为架构的 DevOps 计划。

图 6.10：Capital One 的三阶段 DevOps 转型

创建跨职能团队

Capital One 开始通过为公司内两个旧有应用程序分配专门且多才多艺的 SWAT 团队来实施 DevOps。这些跨职能团队慷慨地实施了配置管理和关键功能的自动化，并优化了这两个应用程序的工作流。随后，每个团队继续负责其指定应用程序的交付过程。这个策略在 Capital One 的另外四个应用程序中得到了重复实施，之后管理层鼓励公司其他开发团队也采纳这些新发现的最佳实践。

值得注意的是，Capital One 能够建立共同目标，得益于跨职能团队的存在以及在 DevOps 旅程初期卓越的领导力。同时，对于开发人员和运维团队来说，掌握必要的 DevOps 技能，以影响他人并在整个组织中传播文化，也是非常有益的。

利用微服务架构

与其他在互联网泡沫时代存在的公司一样，Capital One 在架构技术栈时使用了单体设计。随着时间的推移，他们的项目开始扩展，因此必须考虑未来的需求。结果，该银行投入了更多资源，深入研究了微服务架构及其在公司中的适用性。

在 Capital One，主要目标是提高交付速度，同时保持高质量标准。开发团队选择使用自动化部署，以符合他们已建立的质量标准。他们为软件部署和生产环境的修改制定了严格且明确的规则。

Capital One 的团队在其管道交付中实现了不可变的阶段：

• 实施有效的源代码控制管理

• 实施安全的应用程序和二进制数据存储地点

• 实施强健的特权访问管理和授权

• 确保定期执行质量和安全检查

每个应用程序团队必须在将其代码发布到生产环境之前，满足这些要求。最终，Capital One 因为实施微服务架构而获得的好处如下：

• 非对称的服务部署

• 无限可扩展的应用程序

• 高可用性

• 职责和责任的逻辑分离

• 改进的错误处理

在 AWS 上构建按需基础设施

在收到了客户反馈后，Capital One 的产品经理将精力集中在提升银行和金融服务的质量上，以为客户提供卓越的体验。正是由于这个原因，该公司采纳了云优先策略，且其架构师将新开发的应用程序迁移到云端。

Capital One 的开发团队通过以下亚马逊网络服务工具获得了宝贵的用户洞察，并能够更快地做出响应：

• 虚拟私有 云（VPC）

• 简单存储 服务（S3）

• 弹性计算 云（EC2）

• 关系型数据库 服务（RDS）

使用 Jenkins 自动化交付管道

Capital One 采用了一系列管道来彻底扫描和测试其代码，确保公司内部的高质量标准。此外，还进行了类似的程序以确保快速交付。代码更新经过自动化测试的全面流程，包括集成测试、单元测试、安全扫描和质量检查。在代码成功通过所有测试后，发布会通过管道自动部署。通过确保服务不中断，用户可以享受无缝体验，而团队则可以轻松部署更新。

开发团队使用了 Jenkins，一个广泛使用的工具，用于创建持续集成和交付管道。通过这种方法，Capital One 避免了从头开始创建自己的集成过程。基于 Jenkins 的管道高效地将整个开发过程分解为多个阶段，并进一步将它们分为其他步骤，如应用程序构建、集成测试和部署。值得注意的是，Capital One 使用了加速创建 Jenkinsfiles 的模板工具，以加速各种应用程序的开发。

Jenkins 使 Capital One 精简了软件交付流程，提高了运营稳定性，并为开发人员提供了更好的整体体验。

Capitol One 的 CI/CD 管道治理

Capital One 旨在实现一种无畏发布的文化，以促进创造性思维。然而，这也需要采取一种思维方式，要求个人对他们所做的决策和在软件交付中的角色负责。著名战略家和 DevOps 传播者 Tapabrata “Topo” Pal 及其团队在 Capital One 实施了清洁室开发的概念。他们将这一概念修改为适用于软件开发生命周期，以拥抱一种勇气和责任感的文化。

清洁室

“清洁室”一词指的是一个经过设计的空间，它能将空气中的颗粒物浓度保持在极低水平。它具有活跃的净化功能、良好的隔离性和优秀的污染控制。这类房间通常是所有纳米级过程（包括半导体制造）和科学研究所必需的。为了保护室内处理的材料，灰尘和其他空气中的有机物，如蒸发的颗粒，必须远离清洁室。

一套明确的指南，用于在发布前保证代码质量，可以视为公司虚拟开发清洁室的标准。这些政策涵盖了诸如定位和注册每个产品管道、审核和检查每个版本的代码、限制对生产服务器的访问等程序。简单来说，清洁室方法强调的是预防缺陷，而不是消除缺陷。最终，Capital One 利用清洁室模型来检测和解决不同产品管道中的问题，从一开始就确保了质量。毕竟，一分预防胜过一磅治疗。

以下插图完整描述了 Capital One 的“清洁室”DevOps 发布管理方法。这个过程从开发阶段开始，在该阶段，应用程序代码保存在版本控制管理中。接着，采取一系列安全措施，如限制对二进制文件的访问，并包括静态代码分析。本节的重点是确保编写的代码在完整性、机密性和可用性方面得到妥善存储。

清洁室过程的下一阶段是测试阶段。此步骤确保质量保证程序的端到端可追溯性，从将功能测试活动与各自的用户故事关联开始。接下来，产品负责人与开发团队紧密合作，确保所有关键测试都得到执行并妥善记录。

清洁室过程的最后两个阶段包括实施和监控。在这些步骤中，生产过程旨在达到最佳性能，包括测试部署脚本、批准更改、审核回滚程序、冻结源代码以及限制对自动化过程的访问控制。最后，发布版本被切割并部署到生产环境，并进行适当的应用程序监控。请看一下整个过程的图示：

图 6.11：Capital One 的清洁室发布方法

实施混沌工程

即使有多个访问控制和保护措施，软件部署有时仍会变得混乱。云故障可能是不可预测且无法避免的，在某些情况下，如可用区停机，可能会带来风险。有人可能会说，持续交付也带来了持续混乱的可能性。Capital One 有一支专门的团队，致力于解决这个具体问题。没有人希望不小心自动化自己的毁灭。

传统方法往往难以预见由复杂请求模式、不可预测的数据条件等引发的每一种可能的故障情景。在 2017 年，Capital One 从 Netflix 获得灵感，推出了自己版本的混沌工程。

公司实施了一种名为“Cloud Detour”的工具，用以评估他们构建的应用程序的弹性。在这一阶段，开发团队故意将关键任务应用程序暴露于各种故障场景进行测试。这有助于开发出能够保证足够弹性并作为强大灾难恢复演练的解决方案。

将安全原则嵌入到 DevOps 工作流程中

起初，Capital One 遵循了一种劳动密集型且耗时的安全认证流程。然而，公司很快意识到加强容器环境的安全性对于增强加密以及提升企业内所有系统服务的整体安全性至关重要。

因此，Capital One 将自动化安全检查集成到其 DevOps 流水线中。这加速了对容器和虚拟机镜像中配置错误和漏洞的评估。DevOps 团队迅速获得了漏洞管理和政策合规工具的 API 权限，这些工具可以被集成到 CI/CD 流程中。这使得他们能够进行必要的测试，获取报告，并在无需安全团队介入的情况下启动纠正措施。

我们可以从 Capital One 的 DevOps 转型中学到什么？

正如你所看到的，从研究 Capital One 如何实现其 DevOps 转型中，我们可以获得很多宝贵的见解。在诸多改进中，有些尤为突出：

• DevOps 转型可能需要较长时间。以 Capital One 为例，他们从 2010 年开始，直到 2020 年才达到了成熟阶段。那整整十年。准备好在收获成果之前投入如此长的时间周期。毕竟，他们称其为“旅程”是有原因的。

• 速度在满足用户不断变化的需求中至关重要。通过内部团队协作和流程自动化，你正是可以实现这一目标。

• 采用 DevOps 实践并促进团队合作可以激发创新文化和持续实验的氛围。采取“快速失败”的心态将帮助你迅速找到切实可行的解决方案。

• 实施持续监控实践可以帮助你的组织在实现卓越成果的同时，还能具备可扩展性，即使你的流程最初进展缓慢。

• 集中化的交付工具简化了每个团队技术栈的开发和管理，消除了各自为政的需求。最小化冗余工作并促进资源共享，从而最大化效率。

• 云基础设施允许灵活利用资源。因此，你可以轻松地扩展并适应不断变化的需求，无需受到限制。

• 彻底检查所有当前的开发流程，并建立一个质量标准以实现最佳结果。然后，简化质量控制流程，以减少人为错误并促进 DevOps 合规性。

总结

本章结束了 第六章。在我们的讨论中，你已经从发布经理的角度了解了 CI/CD 的基本知识。你现在掌握了持续集成如何激励开发人员不断将代码推送到源代码控制库，将他们的工作统一为一个发布版本。接下来，我们回顾了为什么持续交付是持续集成的强大伴侣。然后，我们研究了持续交付管道的所有适当阶段，并讨论了它与持续部署管道的区别。此外，你已经了解了 GitOps，这是一个现代 DevOps 策略，通过引入基于拉取的部署策略，增强了持续部署的概念。最后，我们探讨了持续测试，这是任何以 DevOps 为中心的软件组织的首要质量保证策略。

在下一章中，你将学习如何构建一个包含简单 web 应用程序的 Docker 镜像，该应用程序部署到 AWS EC2，使用 GitHub Actions。

问题

回答以下问题，以测试你对本章的知识掌握情况：

1. CI/CD 管道是否可以用于自动化除了发布和部署软件所需活动以外的其他任务？

2. 为什么软件开发团队需要一套统一的技术工具，以达到最高生产力？

3. 增加提交频率的好处是什么？

4. 什么是持续集成服务器，它的功能是什么？

5. 持续交付与持续部署的主要区别是什么？

6. 持续交付管道的五个主要阶段是什么？

7. 什么是 GitOps，它与 DevOps 有何不同？

8. 自动化测试和持续测试有什么区别？

9. 软件开发人员在代码提交之前，检测和修复代码中的 bug 或缺陷的最佳方法是什么？

10. 金丝雀部署与持续测试有什么共同点？

第七章：面向技术发布经理的实用管道

本章与本书的其他章节略有不同。在本章中，您将学习如何构建一个包含简单 Web 应用程序的 Docker 镜像，该镜像使用 GitHub Actions 部署到 AWS ECS。

本次练习涉及的测试包括HTML 扫描、NodeJS 扫描、凭证扫描和依赖扫描。除了静态应用程序安全测试（SAST）外，管道还使用了 OWASP ZAProxy，这是一个动态应用程序安全扫描工具。通过这些质量检查，确保正确实现文档对象模型（DOM），检查代码中的已知漏洞，并主动检查已部署应用程序在云端的安全漏洞。

完成此任务的策略将分为两部分。首先，您将学习如何配置所需的 ECS 基础设施。其次，您将学习如何配置 GitHub Actions 工作流，以便测试、构建并将 Docker 容器部署到 ECS。通过这两个练习，您将成功掌握当代应用程序交付中使用的基本概念。

本章将涵盖以下主要主题：

• 审查管道代码

• 配置 AWS 基础设施

• 配置 GitHub Actions 工作流

在进行本章包含的练习之前，您需要先审查 GitHub Actions 工作流文件。在最底层了解 CI/CD 管道是您完全理解其执行的所有操作的唯一途径。了解这些细节确保您能获得必要的上下文，以保证软件的安全和快速发布。这也使您做好准备，能够向领导和相关方清晰地传达每一步操作。仅仅从高层次理解管道如何运行，对 DevOps 发布经理来说是不够的。

您可以在github.com/PacktPublishing/Embracing-DevOps-Release-Management/blob/main/.github/workflows/aws.yml找到完整的 GitHub Actions 工作流文件。

以下是本章练习所用的 GitHub Actions 工作流脚本的简化版本：

...    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        # Build a docker container and
        # push it to ECR so that it can
        # be deployed to ECS.
        docker build . -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG -f chapter07/Dockerfile
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT
    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TASK_DEFINITION }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.build-image.outputs.image }}
    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true
...

现在，您已经有机会查看此 GitHub Actions 工作流中的管道代码，并且对每个步骤及其执行的工作有了基本的了解。接下来，让我们开始实现一个完整 CI/CD 管道所需的第一组活动：配置云基础设施。

配置 AWS 基础设施

为了确保尽可能广泛的受众能够完成本练习，我们将使用 ClickOps 在 AWS 中配置所有必要的基础设施。ClickOps 是指使用提供商的原生 Web 控制台手动配置云资源的过程。顾名思义，这一过程需要通过键盘和鼠标输入所有必要的信息。ClickOps 被广泛认为是 DevOps 世界中的一种反模式，主要因为它比使用 基础设施即代码（IaC）更低效、更容易出错。然而，对于那些不知道如何编写脚本、写代码或使用命令行界面的人来说，它非常有用。

前提条件

为了完成本指南的这一部分，您需要确保以下前提条件得到满足：

• 您必须拥有一个有效且状态良好的 AWS 账户（console.aws.amazon.com/console/home?nc2=h_ct&src=header-signin）。

重要

请注意，通过遵循本指南，您将在操作过程中为所创建的资源支付 Amazon Web Services（AWS）的费用。直到所有资源被终止前，您将继续被收费。

强烈建议在完成本指南后终止所有这些资源，以避免未来继续被收费。

• 您的 AWS IAM 用户拥有有效的访问密钥。有关如何创建 IAM 访问密钥的更多信息，请参阅 管理 IAM 用户的访问密钥：docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html。

• 您的 AWS IAM 用户必须被授予必要的角色，以便能够在 AWS 中配置 ECS、ECR 和 VPC 资源。有关更多信息，请参阅 基于身份的 AWS 策略示例 ECS：docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_cluster_policies。

• AmazonEC2ContainerRegistryFullAccess、AmazonEC2FullAccess 和 AmazonECS_FullAccess 策略。除了成为 AWS 账户中的管理员用户外，这些就是您在跟随本指南时所需要的全部权限：

注意

授予完全访问权限（如我们在这里所做的）由于安全原因并不是最佳实践。我们仅在本次演示中做出例外，以便让不熟悉 IAM 的初学者更容易通过此过程。因此，强烈建议在完成本次操作后，移除 IAM 用户的这些权限。

图 7.1：您的 AWS 用户所需 IAM 策略示例

上述截图显示了完成此练习所需的 AWS IAM 策略（前面提到过）。您必须将这些策略添加到所选的 IAM 用户。可以通过 AWS 控制台中的添加权限菜单来实现此操作。有关此过程的帮助，请查阅有关身份管理策略的官方 AWS 文档：

• docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html

• docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_cluster_policies

步骤 1 – 分叉仓库

按照以下步骤分叉仓库：

1. 点击分叉框中的下拉箭头并选择创建新分叉。或者，访问github.com/PacktPublishing/Embracing-DevOps-Release-Management/fork：

图 7.2：在 GitHub 中分叉仓库

图 7.3：确认此仓库的新分叉

1. 在分叉仓库页面上，指定所有者值并选择创建分叉。

步骤 2 – 创建默认 VPC

在继续之前，请注意，在同一地区内创建多个默认 VPC 是不可能的。如果您不小心删除了默认 VPC，则可以创建一个新的。然而，重要的是要注意，无法恢复先前删除的默认 VPC，也无法将当前非默认 VPC 指定为默认 VPC。

要通过 AWS 控制台建立默认 VPC，请按照以下步骤操作：

1. 通过访问console.aws.amazon.com/vpc/进入 Amazon VPC 控制台。

2. 从导航窗格中选择您的 VPC：

图 7.4：创建默认 VPC

1. 选择操作，然后创建默认 VPC。

2. 选择创建默认 VPC选项。请在确认信息后关闭该消息：

图 7.5：确认您的新默认 VPC

步骤 3 – 在默认安全组中创建 HTTP 规则

每当向安全组添加规则时，它会自动应用到所有与该组关联的资源。

要通过 AWS 控制台建立新的安全组规则，请按照以下步骤操作：

1. 通过访问console.aws.amazon.com/vpc/进入 Amazon VPC 控制台。

2. 从导航窗格中选择安全组：

图 7.6：访问安全组菜单

1. 选择所需的安全组。

2. 选择操作，然后选择编辑 入站规则：

图 7.7：编辑默认安全组的入站规则

1. 选择添加规则，然后按以下步骤操作：

   • 对于类型，请选择HTTP协议。

   • 对于来源类型（入站规则），请执行以下操作以允许流量：

     • 选择IPv4 任何位置以允许来自任何 IPv4 地址的传入流量（入站规则）。完成此操作后，将自动为 0.0.0.0/0 IPv4 CIDR 块添加规则。

     • 请提供此安全组规则的简短描述：

图 7.8：向默认安全组添加 HTTP 规则

1. 选择保存规则。

第 4 步 – 创建一个 ECR 注册表

开始使用 Amazon ECR，在 Amazon ECR 控制台中设置一个仓库。Amazon ECR 控制台提供了逐步指南，帮助您创建初始仓库。在开始之前，请确保您已按照Amazon ECR 设置指南中概述的所有必要步骤操作：docs.aws.amazon.com/AmazonECR/latest/userguide/get-set-up-for-amazon-ecr.html。

要通过 AWS 控制台建立镜像仓库，请按照以下步骤操作：

1. 仓库是 Amazon ECR 中 Docker 或Open Container Initiative (OCI)镜像的存储位置。在与 Amazon ECR 交互时，您需要提供仓库和注册表位置，以指示镜像的目的地或来源。

   您可以通过访问console.aws.amazon.com/ecr/来访问 Amazon ECR 控制台。

2. 为确保本练习顺利进行，强烈建议您选择us-east-1地区：

图 7.9：选择正确的 AWS 地区以操作 un

1. 选择开始。

2. 在可见性设置下选择私有。

3. 为确保本练习顺利进行，强烈建议您选择embracing-devops-release-management作为您的仓库名称值。

重要提示

注意显示在 ECR 仓库名称开头的 12 位数字。这是您的 AWS 账户号码，您将需要它来完成本指南中的后续步骤。

或者，您可以浏览您的AWS 账户页面以获取您的 AWS 账户号码：console.aws.amazon.com/billing/home?#/account。

1. 对于标记不可变性，请选择保持禁用状态：

图 7.10：建立 ECR 仓库（注册表）

1. 选择推送时扫描来启用该仓库的图像扫描功能。如果 ECR 仓库启用了推送时扫描，每当有推送请求时，它将自动开始扫描图像；否则，用户必须手动启动扫描过程。

2. 对于KMS 加密设置，选择禁用它：

图 7.11: 完成 ECR 仓库创建过程

1. 选择创建仓库。

第五步 – 创建 ECS 集群

通过用户友好的 Amazon ECS 控制台，可以轻松创建一个 Amazon ECS 集群。

在继续操作之前，确保你已经完成了设置 Amazon ECS的前提步骤（docs.aws.amazon.com/AmazonECS/latest/developerguide/get-set-up-for-amazon-ecs.html），并为所选的 IAM 用户分配了正确的 IAM 权限。更多详细信息和帮助，请参考文档中的集群示例部分（docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_cluster_policies）。

Amazon ECS 控制台通过创建 AWS CloudFormation 堆栈，提供了一种简便的方法来生成 Amazon ECS 集群所需的资源。

要通过 AWS 控制台建立 ECS 集群，请按照以下步骤操作：

1. 通过访问 console.aws.amazon.com/ecs/v2 来进入 Amazon ECS 控制台。

2. 为确保本次操作顺利进行，强烈建议选择us-east-1区域。

3. 从导航窗格选择集群。

4. 从集群页面选择创建集群：

图 7.12: 建立 ECS 集群

1. 在 embracing-devops-release-management 作为集群名称，以确保此次操作顺利进行。

2. 展开基础设施，然后选择AWS Fargate（无服务器）：

图 7.13: 将 ECS 集群配置为 AWS Fargate（无服务器）

1. 展开监控，然后切换启用容器洞察来启用容器洞察。

2. 展开标签，然后配置标签以帮助识别你的集群。

3. 要添加标签，选择添加标签并执行以下操作：

   • 在密钥字段中输入密钥名称

   • 在值字段中输入值名称

4. 要删除标签，选择标签键和值右侧的删除：

图 7.14: 对 ECS 集群基础设施进行标签标记

1. 选择创建。

第六步 – 创建 ECS 任务定义

你可以通过控制台或编辑 JSON 文件来创建任务定义。

要通过 AWS 控制台 JSON 编辑器建立任务定义，请按照以下步骤操作：

1. 为确保此操作顺利进行，强烈建议你选择us-east-1区域：

图 7.15：选择正确的 AWS 区域进行操作

1. 首先，在你 fork 的仓库中编辑 ECS 任务定义 文件：

   1. 在 GitHub 上，点击此书仓库中的 task-definition.json 文件（github.com/PacktPublishing/Embracing-DevOps-Release-Management/blob/main/chapter07/task-definition.json）。

   2. 从 task-definition.json 文件页面，点击铅笔图标以编辑文件：

图 7.16：在 GitHub 文本编辑器中编辑 ECS 任务定义

1. 定位到表示你 AWS 账户 ID 的两个占位符，它由 12 个连续的“X”字符组成：

图 7.17：定位到 AWS ID 占位符

1. 用你实际的 AWS 账户 ID 替换两个占位符，并选择提交更改：

注意

你可以浏览你的AWS 账户页面以获取 AWS 账户号码： https://console.aws.amazon.com/billing/home?#/account。

图 7.18：用你的 AWS ID 替换占位符

1. 在提交确认菜单中，添加有意义的提交信息，并选择直接提交到 主分支：

图 7.19：在 GitHub 文本编辑器中提交你的更改

1. 然后，选择提交更改。

2. 通过访问 console.aws.amazon.com/ecs/v2 进入 Amazon ECS 控制台。

3. 从导航窗格中选择任务定义。

4. 从创建新任务 定义页面的菜单中选择使用 JSON 创建新任务定义：

图 7.20：使用 JSON 创建新任务定义

1. 在 JSON 编辑器窗口中修改你的 JSON 文件。

   复制之前编辑的 task-definition.json 文件，并将其粘贴到 JSON 编辑器框中：

图 7.21：复制你之前编辑的 task-definition.json 文件

注意

如果 JSON 编辑器框中已有内容，在粘贴自定义的task-definition.json文件之前，请确保先将其删除。JSON 编辑器框必须为空，才能将task-definition.json文件的内容添加进去。

图 7.22：确认并创建 ECS 任务定义

1. 选择创建。

第 7 步 – 创建 ECS 服务

控制台支持快速创建和部署服务。

通过 AWS 控制台建立 ECS 服务，请按照以下步骤操作：

1. 为确保本练习顺利进行，强烈建议选择us-east-1区域：

图 7.23：选择正确的 AWS 区域进行操作

1. 通过访问console.aws.amazon.com/ecs/v2，进入 Amazon ECS 控制台。

2. 从导航窗格中选择集群。

3. 在集群页面，选择要在其中创建服务的集群。

4. 从服务选项卡中选择创建选项：

图 7.24：为 ECS 任务创建新 ECS 服务

1. 在部署配置部分提供关于应用程序部署的详细信息：

图 7.25：配置新 ECS 服务的启动类型

1. 在计算选项下，选择启动类型。

2. 在应用类型下选择服务：

图 7.26：命名和配置 ECS 服务

1. 在任务定义区域，选择您希望应用的版本和系列。

2. 为确保本练习顺利进行，强烈建议在服务名称下选择embracing-devops-release-management。

3. 要指定期望任务，输入要在服务中启动和管理的任务数量。

4. 对于网络，默认的 VPC 及其关联的网络配置应自动填充到字段中。然而，确保配置与以下内容相似：

图 7.27：选择默认 VPC 进行网络配置 – 公共 IP！

1. 为资源打标签是定位云基础设施的好方法，特别是在创建了数百或数千个资源之后，打标签特别有用。

   要为 ECS 服务添加标签，展开标签，然后配置标签以帮助识别服务和任务。

2. 要添加标签，选择添加标签，然后执行以下操作：

   • 在密钥字段中输入密钥名称。

   • 在值字段中输入值名称。

3. 要移除标签，选择标签键值对右侧的移除选项。

4. 选择创建。

这标志着本指南的第一部分——AWS 基础设施的配置——的结束。在这一部分中，你已配置了支持第二部分指南中概述的 CICD 流水线操作所需的基础设施，即配置 GitHub Actions 工作流。

让我们简要回顾一下你迄今为止的成就：

• 你已经确保你的 AWS IAM 用户已分配必要的权限，以便能够在你的 AWS 账户内配置所需的云资源。

• 你已经确保你的 AWS 账户配备了默认 VPC 及相关的默认网络资源。

• 你已经修改了默认 VPC 中的默认安全组，以便它包含一个 HTTP 规则。这是为了允许用户通过 80 端口访问你的网页应用，我们将在本指南的第二部分进行部署。

• 你已经创建了必要的ECS 注册表，用于存储由 GitHub 工作流生成的 Docker 镜像。我们将在本指南的下一部分进行配置。

• 你已经创建了必要的ECS 集群，用于托管由 GitHub Actions 工作流生成并部署的 Docker 容器。我们将在本指南的下一部分进行配置。

• 你已经创建了必要的ECS 任务定义，它将管理你的网页应用部署的操作活动。这确保了网页应用部署在所有适当配置下运行，并能在遇到意外的系统问题时保持弹性。

• 你已经创建了与配置的 ECS 任务定义关联的必要ECS 服务。这是为了确保所需的网络基础设施已经搭建好，以便用户能够从本地网页浏览器访问在 ECS 中运行的网页应用。

在本指南的下一部分——配置 GitHub Actions 工作流——你将学习如何配置 GitHub Actions 工作流。在这一部分中，你将启用必要的后端设置，学习如何配置输入参数并将秘密信息注入构建过程中，了解如何启动流水线运行并分析构建日志。最后，你将学习如何访问部署到 ECS 中的网页应用，并验证它的存在。

配置 GitHub Actions 工作流

如果希望成功运行 GitHub Actions 工作流并实现成功的部署，则需要进行多个配置。主要的配置项是输入参数，它们以变量和密钥的形式存在。值得注意的是，密钥与变量几乎完全相同，唯一的区别是，密钥在日志中会被掩码，且配置完毕后不会对任何人可见。成功启动流水线运行后，您可以查看日志输出，验证任何问题、失败和成功。最后，您将能够看到在 AWS EC2 中运行的功能性 Web 应用程序。

先决条件

要完成本阶段的指南，您需要确保拥有一个有效的 GitHub 账户（github.com/），并且账户状态良好。

步骤 1 – 配置所需的 GitHub 仓库变量和密钥

配置 GitHub Actions 后端是一个简单的过程，但了解需要关注的内容会有所帮助。在此步骤中，您将为此仓库启用 GitHub Issues，这样如果在构建过程中标记到问题，流水线可以自动提出问题。关键的是，我们还将配置流水线变量和密钥，以便在运行过程中可以将其注入到流水线中。这是 DevOps 中的标准技术，允许相同的 CI/CD 流水线脚本在多个环境中运行，并根据每个用例的独特设置进行配置，包括您的！

为了建立所需的 GitHub 仓库变量和密钥，请按照以下步骤操作：

1. 在 GitHub 中，导航到 embracing-devops-release-management 仓库：

图 7.28：导航到您分叉仓库中的设置菜单

1. 为此仓库启用 GitHub Issues：

图 7.29：为您的分叉仓库启用 GitHub Issues

1. 在仓库菜单的 Security 部分，导航到 Secrets and variables 选项：

图 7.30：访问 GitHub Actions 的密钥和变量选项

1. 然后，选择 Actions。

2. 在 Actions 密钥和变量 菜单中，选择 Secrets 标签。

3. 然后，选择 新建 仓库密钥：

图 7.31：向 GitHub Actions 仓库添加密钥

您需要为 GitHub Actions 工作流提供在您的 AWS 账户中配置资源的权限。为此，您需要提供 AWS 访问密钥，以便在流水线中运行 AWS CLI 操作。

1. 为您的 AWS 访问密钥 ID 创建一个新的仓库密钥，然后按照以下步骤操作：

   1. 在 AWS_ACCESS_KEY_ID 中。

   2. 在 Secret 字段中，输入您的 AWS 访问密钥 ID 的值。

   3. 选择 添加密钥：

注

密钥是你在仓库、组织或环境中设置的环境变量。通过 GitHub Actions，你可以将你提供的密钥集成到你的工作流中。如果你故意在工作流中包含密钥，那么 GitHub Actions 将在管道运行过程中读取该密钥。

图 7.32：将 AWS 访问密钥 ID 添加为管道密钥

警告

GitHub 会自动从作业生成的任何日志中删除对密钥的任何提及。建议不要故意将密钥发布到日志中。

1. 为你的 AWS 秘密访问密钥 ID 创建一个新的仓库密钥：

   1. 在AWS_SECRET_ACCESS_KEY中。

   2. 在Secret字段中，输入你的 AWS 秘密访问密钥的值。

   3. 选择添加密钥：

图 7.33：将 AWS 秘密访问密钥添加为管道密钥

1. 在Actions 密钥和变量菜单中，选择变量标签。

2. 然后，选择新建 仓库变量：

图 7.34：向 GitHub Actions 仓库添加变量

1. 为你的ECR_REGISTRY创建一个新的仓库变量。

2. 在XXXXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com中作为你的 ECR 仓库地址。

注意

别忘了在输入文本框时，使用你自己的 AWS 账户 ID，填入完整的 ECR 仓库地址。

存储和重用非敏感配置信息的一种技术是通过变量。变量是保存配置信息的好方法，例如编译器标志、用户名和服务器名称。执行你工作流的 runner 负责插入变量，这些变量可以在操作或工作流阶段的命令中创建、读取和修改。

1. 选择添加变量：

图 7.35：填写 GitHub Actions 仓库变量的示例

警告

默认情况下，变量会在构建输出中显示未掩码的内容。如果你需要对敏感信息（如密码）进行更高的安全保护，请使用密钥。

1. 输入管道成功运行所需的其他仓库变量。

2. 重复步骤 11中提到的过程，直到所有剩余的仓库变量都已添加：

图 7.36：所有必要的管道变量示意图

以下表格包含所有必需的变量名称及其建议值：

变量名称	变量值
ECR_REGISTRY	XXXXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com
MY_AWS_REGION	us-east-1
MY_CONTAINER_NAME	embracing-devops-release-management
MY_ECR_REPOSITORY	embracing-devops-release-management
MY_ECS_CLUSTER	embracing-devops-release-management
MY_ECS_SERVICE	embracing-devops-release-management
MY_ECS_TASK_DEFINITION	./``chapter07/task-definition.json

表 7.1：一个包含所有必要变量的实用图表

注意

确保在为 MY_ECS_TASK_DEFINITION 设置的值前面加上 ./。这是一个必要的文件系统路径，是 GitHub Actions 获取 task-definition.json 文件并在管道中使用它所需的有效语法。

步骤 2 – 启动 GitHub Actions 工作流

终于到了执行管道的时候。这是关键时刻，我们将完成我们设定的目标。按照以下步骤来启动 GitHub Actions 工作流并将你的 Docker 容器部署到 ECS：

1. 导航到 GitHub Actions 菜单：

图 7.37：访问 GitHub Actions 菜单

1. 选择 I understand my workflows, go ahead and enable them：

图 7.38：启用 GitHub Actions 使用权限

1. 从 All workflows 菜单中，在 Actions 下选择本次练习的工作流，并选择 Deploy to Amazon ECS：

图 7.39：导航到 Deploy to Amazon ECS 工作流菜单

1. 在 Deploy to Amazon ECS 工作流菜单中，选择 Run workflow，然后点击 Run workflow：

图 7.40：启动 GitHub Actions 工作流运行

上面的截图展示了你在本次练习中配置、构建并部署的 Deploy to Amazon ECS GitHub Actions 工作流的主菜单。在这里，你可以启动新的工作流运行，并查看当前和之前的工作流运行历史。

在管道运行启动后，会在该 GitHub Actions 工作流的构建历史中新增一条记录。当工作流运行时，构建历史中该条记录左侧会显示黄色指示器。管道完成后，如果构建失败，黄色指示器会变为红色；如果构建成功，则变为绿色：

图 7.41：一个正在运行的 GitHub Actions 工作流

步骤 3 – 分析部署日志

在此步骤中，我们将仔细审查在上一步骤中运行的 GitHub Actions 工作流的构建日志。此管道中有三个主要阶段。第一阶段进行静态代码分析测试。第二阶段将 Web 应用程序构建成 Docker 镜像。最后，最后阶段进行动态应用安全测试，以评估部署到 ECS 后的容器。所有这些活动将在完成后记录在 GitHub Actions 构建日志中。

一旦 GitHub Actions 工作流启动，点击管道阶段以查看失败、问题和成功的日志！

图 7.42：构建历史区域中单个工作流的详细菜单

如下截图所示，管道已分为两个主要阶段：测试和构建与部署。然而，需要注意的是，在管道的构建与部署阶段，在部署完成后和管道阶段结束之前，会进行动态应用安全测试。你可以访问每个阶段的详细信息和历史记录，以查看与每个阶段相关的构建日志：

图 7.43：检查工作流的不同管道阶段

每个管道阶段的图形表示非常方便，可以快速评估其状态并通过职责的逻辑划分进行组织。在这个仪表盘中，你可以快速查看谁触发了管道、与更改相关的 Git 提交、管道运行的时间以及结果产生了多少工件，所有信息一目了然！当你查看单次管道运行时，这些信息足够有用，但当你在历史记录中解析数百个或数千个构建日志时，这些信息使得理解变得更加容易。

以下截图显示了与 GitHub Actions 工作流的测试阶段相关的活动。正如你所看到的，包括由不同工具进行的两个 SAST——HTMLTest 和 SAST SCAN。两个测试一起检查代码库并尝试识别与 DOM、NodeJS、JSON、YAML、软件依赖项以及源代码中存在的凭证相关的潜在问题。如果所有测试通过，GitHub Actions 工作流的测试阶段将以绿色勾号结束，管道将继续进入构建与部署阶段：

图 7.44：管道中运行的 SAST 扫描示意图

以下截图展示了 GitHub Actions 工作流中的应用构建阶段。在 构建与部署 阶段，配置了 AWS 凭证，web 应用被构建并标记为新的 Docker 镜像，然后将新的 Docker 镜像发布到 ECR 仓库（注册表）。接着，更新 ECS 任务定义，以反映新的 Docker 镜像标签。最后，新的 Docker 容器被部署到 ECS：

图 7.45：GitHub Actions 工作流中的构建与部署阶段

图 7.46：准备在 ECS 中部署新构建的 Docker 镜像

如下图所示，应用程序已经部署并运行在 ECS 中。随后，在工作流运行期间执行了一个自动化脚本，动态捕获 web 应用的公共 IP 地址，并将其作为环境变量存储在 shell 中。这个过程是通过 AWS CLI 完成的，并且在 GitHub Actions 运行器上执行。捕获 IP 地址后，它会作为 OWASP ZAProxy 扫描器的目标，进行 DAST 扫描。如果 OWASP ZAProxy 检测到任何问题，会自动在仓库中打开一个新的 GitHub 问题以供人工审查：

图 7.47：在工作流中运行 DAST 扫描

如下图所示，OWASP ZAProxy 已完成扫描，扫描结果显示在构建日志中。在 GitHub Actions 工作流中的所有操作完成后，管道会清理构建环境，并取消设置所有使用过的机密和环境变量。此时，GitHub Actions 运行器将被优雅地停用：

图 7.48：查看 OWASP ZAProxy web 应用扫描结果

步骤 4 – 观察在 AWS ECS 中运行的已部署应用程序

现在 GitHub Actions 工作流已经完成，web 应用已部署到 ECS，让我们打开浏览器窗口，查看我们的成果。

你可以通过两种简单的方法获取正在运行的 web 应用的公共 IP 地址：

1. 查看部署日志后，你可以找到用于扫描运行中 web 应用的 IP 地址，这个 IP 地址是在使用 OWASP ZAProxy 进行自动扫描时获得的：

图 7.49：查找已部署 web 应用的公共 IPv4 地址

1. 打开 AWS Web 控制台，获取 ECS 服务的 IP 地址：console.aws.amazon.com/ecs/v2：

注意

别忘了选择正确的 AWS 区域，确保你的 ECS 集群已部署在该区域。

图 7.50：在 AWS 中导航到 ECS 集群菜单

1. 导航到你的 ECS 集群：

图 7.51：访问你的 Web 应用的 ECS 集群

1. 点击与 Web 应用部署相关的 ECS 任务：

图 7.52：导航到你的 Web 应用的 ECS 任务菜单

1. 点击与你的 ECS 任务部署相关的当前部署哈希值：

图 7.53：访问你 ECS 任务的最新版本

1. 在公网 IP标题下查找，以获取你的 Web 应用的公网 IP 地址：

图 7.54：查找你的 Web 应用当前的公网 IPv4 地址

1. 如果一切顺利，并且你的 GitHub Actions 工作流已成功运行，你应该能够浏览 Web 应用并亲自体验。以下截图展示了你在用 Web 浏览器访问 Web 应用时应该看到的内容：

图 7.55：在 AWS ECS 中浏览你的 Web 应用！

你部署到 ECS 中的 Web 应用是一个简单的网站，使用 Bootstrap 网页框架构建。

总结

这结束了第七章。在这一章中，你已看到一个简单的 CI/CD 流水线代码示例，该代码作为 GitHub Actions 工作流编写。在接触到 CI/CD 流水线语法后，你现在对流水线的构成方式以及如何进行版本控制有了基本的理解。这意味着你具备了阅读、编写和理解流水线文件的能力，并能够确定每个步骤中执行的活动。此外，你还了解了如何使用 ClickOps 配置 AWS 基础设施。凭借这些基础知识，你可以提升自己的技能，并朝着更先进的基础设施部署策略——即基础设施即代码（IaC）迈进。不仅如此，你还获得了配置 GitHub Actions 后端所需的基本知识。因此，通过这些活动，你现在可以准备涵盖 DevOps 发布管理原则（如测试、构建和将应用作为 Docker 容器部署到云中的端到端工作流）！最后，你还获得了撰写附带软件发布的有用文档（包括更新日志）的基础知识。

在下一章中，我们将讨论 CI/CD 流水线如何促进良好的 DevOps 发布管理。主题包括平衡 CI/CD 治理与市场速度、制定团队的分支策略、构建发布流水线，并实现适合 DevOps 发布管理的变更审批流程。

资源

要深入了解本章所涉及的主题，请查看以下资源：

• docs.aws.amazon.com/AmazonECS/latest/userguide/getting-started-fargate.html

• docs.aws.amazon.com/AmazonECS/latest/userguide/create-container-image.html

• docs.aws.amazon.com/AmazonECS/latest/userguide/get-set-up-for-amazon-ecs.html

• docs.github.com/en/actions/deployment/deploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service

• earthly.dev/blog/github-actions-and-docker/

问题

回答以下问题，测试你对本章内容的掌握情况：

1. 什么是 GitHub Actions 工作流？

2. 什么是 ClickOps？

3. 什么是 AWS 访问密钥？

4. 什么是 AWS IAM 策略？

5. 什么是 GitHub 仓库的 “fork”？

6. 什么是 AWS 安全组？

7. 什么是 ECS 集群？

8. 什么是容器镜像仓库？

9. 什么是环境变量？

10. 什么是 README.md 文件？

第八章：CI/CD 流水线如何执行良好的 DevOps 发布管理

到目前为止，您已经了解到 CI/CD 是 DevOps 的一个关键方面。可重用的、专为目的而建的 CI/CD 平台通过提高效率、简化工作流程来最大化每个开发者的时间价值。CI/CD 通过成为自动化、测试和协作的汇聚点，提高了组织的生产力。额外的 DevOps 增强功能，如左移和创建更紧密的反馈循环，帮助企业消除隔阂、有效扩展，并比其他发布管理方法更快地实现业务价值。

如今的发布管理人员必须精通 CI/CD 程序、DevOps 和自动化部署技术。他们需要能够在早期识别问题，并理解 CI/CD 流水线的运作方式，这对于 DevOps 发布管理至关重要。在本章中，我们将讨论 CI/CD 流水线如何执行良好的 DevOps 发布管理。我们将涵盖的主题包括管理市场速度和 CI/CD 治理，开发团队的分支策略，构建发布流水线，实施适合 DevOps 发布管理的变更批准流程等等！

在本章中，您将了解以下主题：

• 理解 CI/CD 治理

• 分支策略

• 发布流水线

• 变更管理

理解 CI/CD 治理

在 DevOps 发布管理中实施治理需要建立一系列旨在在 CI/CD 基础设施内创建监督机制的程序。这种范例通常包括访问控制管理、合规政策、自动化测试和手动审查检查点的混合。DevOps 治理的主要焦点是推进运行安全目标，并建立全面的框架，监控、批准和记录所有修改，以确保可追溯性。

要熟悉CI/CD 治理，您必须全面了解 CI/CD 流水线的运行方式。正如您在前一章学到的那样，CI/CD 流水线涵盖了一系列自动化工作流、系统和方法，专门设计用于从开发者工作站开始，将新代码快速、可靠地交付到生产环境。这使开发人员更容易接收并响应来自最终用户的输入。显然，利用设计良好的 CI/CD 流水线基础设施，可以避免许多通常与软件交付相关的风险。值得注意的是，与一次性进行大规模努力相比，CI/CD 鼓励开发团队以更小、更轻的批次提交软件更新。

因此，与 DevOps 发布管理相关的快速开发节奏可能会导致在有效管理治理和降低安全风险方面的困难。仅以一个例子来说，在生产过程中使用开源软件是开发团队常见的关注点。如果没有适当的审计、分析和自动化测试，你将无法预测何时及是否会有漏洞影响到源代码中的关键依赖项。

OWASP Top 10 CI/CD 安全风险

CI/CD 已成为现代软件工程实践的关键组成部分。不幸的是，CI/CD 的使用也带来了一些安全漏洞，这些漏洞需要谨慎考虑。在本节中，我们将介绍OWASP Top 10 CI/CD 安全风险（owasp.org/www-project-top-10-ci-cd-security-risks/），这是对威胁任何组织 CI/CD 管道基础设施的最常见安全风险的全面研究。

开放 Web 应用安全项目（OWASP）是一个全球公认的非营利组织，致力于提升 Web 应用的安全性。OWASP 坚持的一个基本原则是，提供自由可获取且易于访问的资源，所有这些资源都可以通过其官方网站获得。提供的资源种类繁多，包括书面文档、专业工具、教学视频和互动论坛等。

OWASP Top 10 CI/CD 安全风险如下：

• 流程控制机制不足（CICD-SEC-1）

• 身份和访问管理不足（CICD-SEC-2）

• 依赖链滥用（CICD-SEC-3）

• 被污染的管道执行（CICD-SEC-4）

• 基于管道的访问控制不足（CICD-SEC-5）

• 凭证管理不足（CICD-SEC-6）

• 不安全的系统配置（CICD-SEC-7）

• 第三方服务的无监管使用（CICD-SEC-8）

• 不当的构件完整性验证（CICD-SEC-9）

• 日志记录和可视化不足（CICD-SEC-10）

你可以在OWASP Top 10 CI/CD Security Risks | OWASP Foundation. (**n.d.)（owasp.org/www-project-top-10-ci-cd-security-risks/）找到这个列表。

《OWASP Top 10 CI/CD 安全风险》的详细内容过于广泛，无法在本章中完全涵盖。请参考本书后面的附录，了解这些十大安全风险的详细分析，并学习如何实施保护措施防范这些风险。通过熟悉这些风险并实施建议的对策，你将更有信心提升你所在组织的 CI/CD 管道基础设施的安全性。

市场速度与治理之间的权衡

CI/CD 使得快速开发和发布周期成为可能，但全面的安全检查、手动审查和批准程序可能会极大地拖慢进度。在理想的情况下，安全检查和合规性评估应该以既有目的又不显突兀的方式融入软件交付生命周期中。调和 CI/CD 治理与效率之间的任务可能会带来一些不必要的困难，因为过于宽松的治理方式可能会导致代码质量下降和安全风险增加，而过于严格的治理则可能阻碍部署过程并抑制创新。

为了优化生产力并防范潜在风险，制定明确的政策和程序，并严格执行其遵守，具有不可估量的价值。有效的软件开发策略应当包含确保优秀代码质量和最小化安全漏洞的协议。其中一些实践可能包括代码审查、自动化测试和一键部署批准。通过实施这些措施，你可以建立质量门槛来评估代码变更，并防止未经授权的代码引入，这是一项主要的安全风险。定期审查和更新治理标准对于确保团队始终与组织目标保持一致至关重要。

三种常见的 CI/CD 治理路径

经验丰富的 DevOps 团队采用三种显著的治理模型来管理其应用程序部署和 CI 基础设施。这些模型在它们治理的方面上有所不同，具体包括基础设施代码、部署工具链和提供的云资源：

• 中央模式库治理模型是一个有价值的资源，提供了一个经过精心策划的部署模板集合。这些模板旨在供应用团队在部署过程中重用。通过使用中央模式库，团队可以受益于经过精心选择和组织的预开发模板，便于访问和实施。这使得应用程序的部署更加高效和一致。另一种理解该治理模型的方式是，它通过将决策权归还给独立的开发团队，从而去中心化了决策权，这些团队围绕一个经过预批准的流程集统一行动。

• CI/CD 即服务治理模型是一种软件开发实践，提供了一个标准化的工具链供应用团队使用。此服务使代码变更的无缝集成和交付成为可能，确保开发过程的顺利和高效。通过提供可重用的工具链，CI/CD 即服务使应用团队能够简化工作流程并增强开发环境中的协作。另一个适合描述该治理模型的术语是服务目录。

• 集中管理的基础设施治理模型指的是一种系统，在该系统中，应用团队可以部署由中央运维团队管理的云资源。这种安排使得资源部署和管理的过程更加简化，因为监督和维护这些资源的责任是集中的。通过实施这种方法，组织可以确保高效利用云资源，同时在各个应用团队之间保持一致且标准化的基础设施。另一个适合与这一治理模型相关联的术语是DevOps 卓越中心。

常见的 CI/CD 治理障碍

在 CI/CD 治理方面，找到速度、稳定性和可靠性之间的正确平衡可能是一个挑战。这些只是你可能会遇到的一些常见问题。另一个挑战是团队在更大规模上管理 CI/CD 流程和系统的能力。其原因在于企业公司拥有大量员工、复杂的组织结构和庞大的代码库。这些因素导致了特定的需求和要求，这些需求和要求在这些类型的公司中是独特的。

理想的治理架构优化了基础设施能力与业务需求的对齐，同时为最终客户提供尽可能高的价值。IT 组织可以利用治理模型作为实施企业标准、引入新技术和执行默认监管要求的有效工具。值得注意的是，确保治理模型与业务架构对齐是企业架构师的责任。

创建治理模型的最佳实践包括可扩展性和可重复性。当一个治理模型为一个组织建立时，这个过程可以被复制并应用到多个产品和服务上。治理模型所管理的项目必须是可量化的，以便能够进行合规性检查、可用性监控和性能优化。治理模型还应涵盖所有可能的基础设施能力组合，以及不同的部署要求。因此，创建云治理模型的目标是可扩展性，意味着治理模型可以根据市场需求或目标受众的需求进行扩展或缩小。它应该促进服务的水平和垂直扩展的透明集成。治理模型还应具有适应性，考虑到最终用户不断变化的需求以及对 IT 基础设施的影响。

必须牢记，除非同时考虑商业视角和 IT 视角，否则创建优化的云治理模型是不可能的。在开发 CI/CD 治理架构时，组织通常会面临以下四个常见挑战中的至少一个。这些挑战反映了各种不同的考虑因素。

工具的泛滥

CI/CD 治理模型的实施常常受到组织技术架构复杂性的阻碍。在大多数情况下，开发团队倾向于使用各种不同的编程语言、框架、生产力工具和结构系统。然而，工具的泛滥给实施统一的治理实践和流程带来了挑战：

图 8.1：展示可用的庞大 CI/CD 工具选择的图示

这种困境常常导致工具瘫痪的状态，软件工程师在不满现有技术基础设施的同时，还担心转向其他解决方案可能带来的时间、精力投入以及潜在挑战。产品负责人最终可能会对高估的时间预估表示不满，并质疑为何需要多个冲刺来开发某个特定功能的合理性。

用户访问控制和授权

访问和授权管理是许多企业面临的主要障碍。必须拥有一套合适的工具来自动化这一过程，以便确保正确的人员在需要时能够访问相关信息。有一些工具可以帮助治理和管理用户访问控制，但并非所有工具都能提供必需的细粒度授权管理功能。

自动化已消除了许多手动安全分析检查的需求。现在，管道完整性用于简化职责分离的要求。需要明确区分维护管道基础设施的团队和使用该基础设施的团队。你可以设置源代码控制工具，使得只有负责 CI/CD 管道基础设施的工程师才能对基础设施组件和/或配置和模式进行更改，从而有效地分离每个小组的责任。例外情况应尽量少见，且必须获得授权、记录并在发生时进行严格监督。

系统访问管理

对许多公司来说，确保 CI/CD 工作流中使用的各个系统之间网络连接的安全性是一个典型挑战。使用个人访问令牌作为密码的替代方案和一次性的临时令牌是确保安全性的两个重要策略。还有补充软件和服务，能够程序化地轮换秘密和刷新凭证。

攻击者利用糟糕的凭证管理实践，找到暴露的凭证并使用它们来未经授权地访问系统。一旦提取完成，攻击者会继续验证凭证的有效性。通常这是从被入侵或一次性机器进行，以避免检测。一旦攻击者获得必要的凭证，他们就可以未经授权地访问计算机系统或服务。攻击者访问敏感信息、发出命令或执行其他恶意行为的能力取决于与被损害凭证相关联的权限和授权级别。

可追溯性

可追溯性和审计性在受严格监管的行业通常是强制性的。然而，无论您的监管地位如何，追溯性都是必不可少的。其目的是能够确定预期在最终产品中看到的特性是否确实存在于软件中。在安全漏洞事件中，这一点至关重要。

要实现理想的流水线，CI/CD 生态系统及其各个组成部分必须无缝地工作，不得有任何中断。同时，有必要全面记录所有元素（如代码、脚本、测试以及开发和测试标准）的存在情况。必须记录和定期更新每个元素的目的、创建者、依赖关系和关联性。您必须确保此记录存储和管理在源代码控制下。

创建企业级 CI/CD 治理模型

CI/CD 治理没有单一的标准格式。这是因为每种模型都是根据支持的公司或组织的具体要求、法规、合规标准和行业规范进行定制的。然而，大型企业可以实施一些方法来创建和维持强大的端到端 CI/CD 治理战略。在制定或执行您的 CI/CD 治理标准审计时，考虑本节中突出的技术。

映射 CI/CD 系统和流程

创建 CI/CD 流程和系统的可视化表示有助于全面了解完整的 CI/CD 管道。这有助于识别安全最容易受到威胁的具体阶段。此外，这也有可能揭示出额外的选项，以改善你的流程、基础设施和安全态势。完成这项任务的有效方法是生成被称为价值流图的内容。价值流映射应包括 CI/CD 流程、基础设施和工具，以便你能够充分理解转换的关键点，并在业务的控制、合规要求和行业法规之间建立联系。这样做使你能够优化当前的流程，建立治理模型，并为公司准备接受审计。增加流程的可见性是观察如何改进它的最快方法之一：

图 8.2：一个通用的价值流图示例

上述图形代表了在精益生产背景下的一个通用价值流图示例。尽管价值流映射通常与制造业相关联，但它也被广泛应用于物流和供应链管理、服务导向行业、软件开发、产品开发、项目管理等多个领域。

价值流映射的目标是发现并消除或最小化在业务流程中发生的浪费活动，最终提高特定价值流的整体效率。减少浪费的目标是通过简化流程并使其更容易发现质量差或过度浪费的情况，从而提高产出。

欲了解更多关于价值流映射的信息，请参考本书后面的附录。

声明式地表达 CI/CD 管道

通常称为管道即代码（pipeline-as-code）的技术涉及通过代码定义 CI/CD 管道。这个过程始于采用声明式技术，其中包含配置文件的使用，并且与版本控制系统一起使用效果最佳。将 CI/CD 管道声明式地作为代码表达的一个优势是能够整合控制、门控和流程，例如治理实践和程序，并在多个环境中一致地应用它们。此外，这还可以帮助建立审计追踪，使你能够验证是否符合治理标准。最后，通过声明式地作为代码表达 CI/CD 管道，你将能够更好地为灾难恢复（DR）场景做好准备。

定义明确的角色和职责

检查你早些时候绘制的价值流图的步骤，确定每个团队和与之交互的个人的角色和职责。这是设计 CI/CD 治理模型的最有效方法。请注意，开发人员负责代码的开发，最好不要让他们同时负责构建和维护 CI/CD 管道。这将在你决定为每个需要访问底层系统的团队成员提供多少授权，以及你需要采用哪些协议来确保组织治理的良好性时，提供巨大的帮助。

定期审计访问和授权控制

管理权限和访问并不容易，但你必须这样做。使用身份提供者（IDP），如 Azure Active Directory，你可以建立一个统一的权威来源来管理用户身份和权限。你应该识别出最有价值的资源，并将它们作为基础设施的重点，无论你使用的是哪种技术栈。

给予团队灵活性

无论你采取多少预防措施，人们仍然会创建自己的工具、脚本和自动化系统。实施保护措施以避免这种情况，或者使人们能够以透明且合规的方式构建自己的工具和实例，是良好的 CI/CD 治理的重要方面。实现这一点的最有效方法是为员工提供执行其职责所需的自由，并定期进行流程审查，以识别在哪些方面需要额外的自由，或者相反，增加形式化管理。创造性的自由是打造一个真正投入的员工队伍的最佳方式。

大力投资自动化测试

高效的 CI/CD 治理模型的一个关键要素是包括合适的测试套件，特别是能够帮助团队进行左移的自动化测试，或者尽早优先考虑安全性和功能性，尽早在软件开发生命周期（SDLC）中进行优先处理。我们强烈建议，从 SDLC 开始的第一天起，快速且具成本效益的测试应当被优先考虑。这类测试必须在非常短的时间内完成——足够短，以至于工程师不会被激励去切换任务并在其他项目上进行多任务处理。如果测试失败，开发团队应该立即意识到，以确保问题不会被忽视或遗漏。随着 SDLC 的逐渐成熟，测试要求应该变得更加具体。可追溯性是考虑自动化测试实践时的另一个重要因素。如果你能识别出故障点，你将能更快地诊断问题并找到解决方案。

标准化代码评审

实施强有力的 CI/CD 治理需要创建一个系统，使得个人无法随意编写代码、启动构建过程，并在未经额外验证措施的情况下部署代码。这意味着每个修改必须至少获得两个人的批准。需要注意的是，并非所有修改都必须获得第二个人的批准。在某些情况下，依赖自动化测试可以提供足够的保证以继续进行。不管选择何种策略，必须在组织层面建立并明确规则，以确保团队遵循统一的实践和流程。目标是提高开发人员发现并解决代码问题的成功率，减少缺陷的引入，并确保符合核心项目规范。因此，这可以提高开发工作的整体生产力和效率，帮助团队加速向客户交付卓越的软件。

在部署策略中设置环境规则

一个需要遵循的核心原则是建立环境一致性，并且能够在涵盖构建、测试和交付层的各个阶段无缝跟踪进展。引入某一环境的条件性而忽略其他环境时，必须考虑潜在的后果，因为这是一个不好的做法。保持环境一致性将加速每个环境中软件测试的过程，即使生产环境包含其他环境中没有的独特条件。

建议使用配置文件的声明式语法将环境视为输入参数。在 CI/CD 流水线中，这是一个成功的做法。将环境参数化为代码有助于确保从开发到发布的所有前提条件都是标准化的。此外，参数化还将使你的 CI/CD 系统更容易维护，从而避免创建过多的流水线。

防止未经授权访问 CI/CD 流水线基础设施

为了防止未经授权访问你的系统和代码，CI/CD 流水线中涉及的所有系统必须安全集成。

在所有情况下，应应用最小权限原则。授予用户、工具和服务的访问权限应保持在最低限度。通过这样做，你可以确保组织的最隐私信息和系统不受窥探。此外，必须对任何私人信息进行加密。如果可行，使用一次性令牌，它们只能使用一次，并且在每个任务完成后自动轮换。

您应始终使用静态应用安全测试（SAST）工具对所有依赖项进行定期安全测试。这些测试应覆盖从您的 CI/CD 过程到代码库以及容器等基础系统的所有内容。一些工具可以集成到 CI/CD 流水线中，对代码库进行自动扫描，检测到任何已知的安全漏洞，并在检测到漏洞时通知相关团队。一些例子包括SonarQube、Fortify、CheckMarx和Veracode。

最后，定期进行安全检查。这些审核的目的是提供建议，加强您组织的整体安全姿态，并记录任何发现，可能包括任何问题或漏洞。通过保持安全测试和组织有序，您将能够很好地应对组织中的安全事件。

监控 CI/CD 流水线的性能

评估 CI/CD 流程性能的关键指标通常包括部署频率、变更的引导时间、恢复服务时间和变更失败率。测量这些指标可以帮助组织识别其更广泛的 CI/CD 工作流中潜在的瓶颈或低效。此外，它们可以用来监控治理政策和流程对向客户部署新代码的影响。

使用专业监控工具，如SigNoz、Datadog或New Relic，是跟踪您的 CI/CD 流水线效果的一种方法。尽管这些工具揭示了流水线整体性能的模式，但它们单独并不足够。如前所述，应建立 DORA 指标来监控您的流水线、治理政策和程序的效果。这些指标提供可观察的信号，综合考量可以更全面地展示流水线和整个系统的健康状况。

审查和定期更新 CI/CD 治理流程

为了建立有效的评审委员会，建议从多个职能领域的人员组成委员会，包括开发、安全、运营和 IT 团队。首先，进行全面分析当前的政策和流程，以识别任何缺陷或可以改进的地方。然后，召集评审小组，基于各自领域的专业知识，征求对现有政策和流程的意见。接下来，修改现有政策和流程，纳入评审小组提供的意见。建议彻底评估所做的修改，以确保它们与公司特定需求的一致性。最后，通过有效地将详细信息传达给受影响的团队来执行实施过程。必须系统地监控和评估新实施政策的效果，同时为必要时进行修订做好准备。

由于 CI/CD 的治理以及对公司最重要的优先事项会随着时间的推移发生变化，定期评审应成为公司支持成功的最重要职能之一。有效的 CI/CD 治理保证了所有发布的代码都具有高质量、安全性，并且可以追溯到源头。

DevOps 发布管理治理的目的是设定政策和程序，确保你们组织的 CI/CD 管道基础设施高效、安全，并符合行业标准和法规。在组织层面，企业通常在实施合适的工具、流程和程序来有效控制 CI/CD 工作流时遇到困难。尤其是在公司刚开始制定治理模型时，这种情况尤为明显。归根结底，这一切都归结于规模：在企业层面，涉及的人、工具、系统和用户更多，这使得有效的治理更加困难。

然而，当团队遵循既定流程并有效实施 CI/CD 方法时，就能更有保障地确保所有发布的产品都符合必要的标准和质量要求。此外，这些产品还会附带必要的标签，以便将来在需要时进行追溯。因此，初期投资的重要性也随之增加。

这就是我们关于 DevOps 发布管理治理的讨论总结。现在你已经熟悉了OWASP Top 10 CI/CD 安全风险、市场速度与治理的权衡、CI/CD 治理的常见路径、常见的 CI/CD 治理障碍，以及如何创建治理模型。

在接下来的部分中，我们将讨论 DevOps 发布管理中的一个备受争议且同样重要的方面：分支策略！这一点经常被忽视，我们将讨论四种最常见的软件开发分支策略的重要性，并学习何时以及如何应用它们。

理解分支策略

现代版本控制系统大多数都支持分支，分支是从核心代码库衍生出来的独立工作流。版本控制系统中主分支的命名可能有所不同，可能有 master、mainline、default 或 trunk 等称谓，具体取决于所使用的系统。开发人员可以从源代码创建分支，从而使其能够与源代码独立运作。

分支的实践促进了开发团队之间在统一代码库内的无缝协作。当软件开发人员开始在版本控制系统内创建一个分支时，会生成代码库的副本，捕捉到代码在特定时刻的状态。对分支所做的修改不会影响团队内其他开发人员，但这种模式无疑具有优势。然而，分支不一定要独立存在。通过分支，开发人员可以无缝地整合其他程序员所做的更改，进行协作开发，涉及多种特性，同时确保他们的分支与主分支紧密对接。

分支策略的成功实施将在构建有效的 DevOps 工作流中发挥关键作用。DevOps 发布管理的许多关键目标是提供快速、优化和高效的工作流程，同时确保最终交付物的完整性和卓越性。软件开发团队所采用的分支策略以及他们如何处理每个新特性、升级或修复应由精心规划的分支策略进行管理。这样做将通过让软件工程师一次专注于处理单一特性，避免影响其他部分或干扰其他团队的工作，从而简化发布过程。

选择分支策略

在选择分支策略的过程中，应该充分考虑用户需求和项目要求。这个选择受多种因素的影响，包括创建过程、规模以及开发人员的偏好。你在 DevOps 流水线中使用的分支策略会受到不同因素的影响，例如 CI/CD 集成的可用性。如果某些分支策略与 CI/CD 不兼容或使其实施更加困难，那么在以 DevOps 为中心的组织中使用这些分支策略就不是一个好主意。

定义一个有效的分支策略能为开发过程提供一条清晰的进展轨迹，从原型修订开始，一直到最终的生产部署。这种方法使开发人员能够生成有序的工作流，从而促进良好的发布管理。如前所述，拥有明确的分支策略的一个关键优势是支持并行开发，这种策略可以提高每个开发人员工作流的效率，而不会引入太大的障碍。分支策略还可以与许多 DevOps 技术和工作流进行无缝集成，以高效的方式进行操作。对于高级团队来说，分支策略还为使用 GitOps 工作流进行部署提供了可能。使用分支策略最为人熟知的优势之一是它能加速发布周期。总之，在考虑选择哪种分支策略时，并没有适用于所有人的“一刀切”方法。

常见的 DevOps 分支策略

现在你对分支策略有了更深入的了解，并且明白了团队使用分支策略的目的，我们来看看当前软件工程团队常用的几种分支策略。本节将重点介绍当今 DevOps 发布管理中最常见的四种分支策略：Gitflow、GitHub Flow、基于主干的开发和 GitLab Flow。

Gitflow

master 和 development 两个分支在整个开发生命周期中都会被维护。development 分支也被称为 长生命周期 分支：

• master：这是主要分支，所有生产环境的代码都存放在此分支中。develop 分支中所做的修改会合并到 master 分支，并在代码准备好发布时用于部署过程。

• development：变化、成长、演化。develop 分支是进展的地方。这个分支包含了所有的预生产源代码，其他分支完成的工作会立即合并到 develop 分支。

图 8.3：Gitflow 分支策略的图示

软件开发人员在开发过程中会创建许多不同的分支，以满足各种应用需求。develop 分支作为初始起点——它是生成软件产品的基础。

其他分支也是类似产生的。例如，在软件开发过程中，通常使用 feature 分支来简化新功能的开发。这些分支直接从 develop 分支分出，不涉及其他任何内容。

如果有紧急的生产问题需要快速解决，将开发一个热修复分支进行响应。每个分支都有从 master 分支（也叫 main 分支）fork 的能力。这些分支必须与 master 和 develop 分支进行合并，以确保更改的一致集成，并避免冲突。为了简化生产发布过程，release 分支收集所有最新的 bug 修复和功能。新分支将是 develop 分支的子分支，最终将合并回 master 分支。

Gitflow 的优点包括易于实施的、各自具有特定功能的分支，每个分支都通过明确的命名系统进行管理。这种方法对于管理多个生产代码迭代特别有利。

Gitflow 的一个缺点是，你再也无法阅读 Git 历史。此外，master/develop 的分割在开发中并非总是必需的，且在与某些 CI/CD 工具集成时可能会遇到挑战。此外，它不建议用于需要保持最新的单一工作版本的情况。最后，根据项目的规模，这种方法可能使源代码管理变得过于复杂。

下面是 Gitflow 的总结：

• master 包含你的分布式生产代码，并带有标签。

• 只将 hotfix 和 release 分支合并到主分支（最好是 release）。

• 功能分支将被合并到 develop 分支。

• 发布分支仅包括 bug 修复，不包括新功能。如果需要开发新功能，应将其合并到 develop 分支，而不是 release 分支。

GitHub 流程

GitHub 负责这一策略的起源，旨在提供一种简单且不干扰的方式来管理开发过程。当只维护一个主分支的源代码时，GitHub 流程按以下规则管理该过程：

• master 是主分支，其他分支都从它分出来，并将新代码合并回该分支。master 分支中的所有内容，有时也叫 main 分支，应该随时准备部署。

• 任何修改（无论是功能还是 bug）都需要在从 master 分支继承的一个新分支中实现，并且该分支的名称应该能够描述开发过程。你应当将代码更改提交到 feature 和/或 bug 分支，并定期推送这些更改：

图 8.4：GitHub 流程分支策略的图示

一旦feature或bugfix分支的开发完成，你需要创建一个拉取请求（pull request），以便对代码进行评估。在代码经过检查和验证后，它需要在同一分支中进行测试，然后才能合并回master分支。用户现在应该能够在达到这一点后，直接部署包含最新更新的master分支。

GitHub flow 的优点包括它相对容易理解，且具有直观的工作流。此外，这种方法能保持一份干净、易读的 Git 历史记录。你还可以轻松地将其集成到 CI/CD 流水线中。此外，GitHub flow 非常适合仅需要保留单一生产版本的情况。

GitHub flow 的一些缺点包括它过于简化，且与基于发布的软件开发不兼容。此外，GitHub flow 不适用于需要同时维护多个不同软件版本的情况。如果分支在合并到master分支之前没有经过彻底的测试，这可能导致生产环境的代码不可靠。

主干驱动开发

在主干驱动开发中，开发者需要每天至少一次将自己的代码修改直接集成到共享主干（master）中。共享主干保持在一个始终准备好发布的可部署状态。开发者编写的代码可以在从该主干分支拉取代码后，推送到本地仓库，并最终推送到共享主干：

图 8.5：主干驱动分支策略的图形表示

release分支被视为源代码的快照，它们是从创建时并准备发布的那个时间点拍摄的。这意味着，在主干驱动开发中，release分支永远不会被维护。由于这种集成发生得非常频繁，开发者可以立即监控彼此的代码变化，并在发现问题时立即做出响应。

规模化主干开发

主干驱动开发的衍生版本，规模化主干开发，遵循类似的模式，但它为大型企业级开发团队提供了更易于使用的设计。

与主干开发的区别在于，在完成构建并确保功能测试成功后，较小的团队可以直接将他们的变更提交到共享主干。而对于规模化主干开发，开发过程可以划分为短生命周期的feature和bugfix分支，适用于员工较多的组织。在创建feature或bugfix分支后，开发人员将持续提交代码到这些特定的分支，并且可以通过拉取请求和自动化测试验证这些代码，然后再将其合并回共享主干。规模化主干开发使开发团队可以同时做到两件事：

• 在不对主分支造成太大压力的情况下进行扩展

• 实现对每个变更更高水平的监管和监督：

图 8.6：规模化主干开发分支策略的图示

值得注意的是，规模化主干开发使用特性标志来控制在共享主干中发生的开发活动，每当准备发布时，通过这些特性标志，开发团队可以在构建过程中选择性地启用或停用代码的某些部分，并将仅必要的代码发送到生产环境中。通过这种方法，团队可以直接从主干发布，并为每个提交打上版本号标签。值得一提的是，如果发布中出现了 bug，则可以从以前的提交中生成一个release分支，并将修复代码合并进去。这种分支方式最适合那些熟练掌握源代码管理的开发团队。

主干开发的一些优势包括以最纯粹的形式使用持续集成（CI），开发人员不断保持主干的最新状态。主干开发是一个非常适合 CI/CD 流水线的选项，这些流水线的工作流更简单，有利于自动化测试的实施。此外，主干开发能够减少周期时间并加快开发人员的反馈。因此，代码的修改更容易被察觉。对于那些较少频繁的迭代，它们让你的团队更容易监控所有的变更，同时也降低了代码冲突的风险，提高了整体代码质量。

基于主干的开发的一些缺点是由于开发者直接在共享主干（master）上工作。缺乏经验的开发者可能会发现这种技术令人畏惧。此外，由于功能标志管理不当，可能会出现一些挑战。另一个缺点是它增加了错误创建的风险，因为回归测试并不是每次合并时都会进行。此外，采用这种分支策略需要开发团队等待更改通过测试流程和自动化构建后才能进行合并。值得注意的是，从更传统的方法（如 GitHub flow）过渡过来可能会比较困难。

总体而言，基于主干的开发促进了协作、敏捷性和更快速地交付高质量的软件。你可以轻松实现一个稳固的 CI 文化，并利用功能开关为自己带来优势。此外，通过遵循这一方法论，你将能够更有效地响应客户需求，并拥有更易于管理和改进的源代码。无论团队规模或项目复杂度如何，使用基于主干的开发能够提升团队协作，加快上市时间，并改进编码实践。

GitLab Flow

GitLab Flow 将面向特性的开发原则和功能分支与问题跟踪结合起来。这一方法与 GitHub flow 方法论相似，但与其他工作流不同的是，它包括了一个独特的生产分支，用于管理部署到生产服务器的代码。此外，建议建立一个pre-production、staging或release分支，作为staging环境的代表，在这里你可以推送代码进行最终测试后再部署。换句话说，你需要至少三条主线：

• master：这是每个人使用的本地开发环境的主线。

• staging：这是生产环境之前的最终测试环境，master分支会在这里进行集成。

• production：在生产环境分支上，staging中的代码会通过标签进行合并。如果没有使用 staging 分支，那么就是从master分支进行合并：

图 8.7：GitLab Flow 分支策略的图示

如前所述，在 GitLab Flow 的背景下，软件开发过程发生在三个不同的环境分支中。这些分支作为验证和测试代码的指定空间。一旦代码经过必要的审查并被认为适合，它就会合并到其他分支，从master分支开始。这个迭代合并过程会持续，直到代码最终合并到生产分支，标志着它准备好部署。让我们详细看看上述三个环境分支的细节。

主环境作为所有开发活动的主要场所。开发人员为他们当前正在处理的特性或修复创建不同的分支，然后将这些分支集成到master（主）分支中。接着，新的代码变更将进行额外的评估和自动化测试。一旦新特性和修复被认为准备好发布，源代码将从master分支合并到pre-production（staging）分支，这是生产的初始阶段。然后，上述代码将进一步测试，并最终合并到production分支以进行部署。

生产指的是创造商品或服务的过程。在集成了生产就绪的代码后，便可以将此分支直接部署到生产环境中。这个分支专门为该特定环境而设，且只包含经过充分测试并认为适合部署到生产环境的代码。

GitLab Flow 的一个优点是，通过实施 GitLab，能够有效地分离不同的开发环境，确保每个分支的状态保持干净。此外，该软件无缝地融入了 CI/CD 流水线。简而言之，GitLab Flow 通过优化 DevOps 生态系统中的工作流，增强了 GitHub Flow 方法。GitLab Flow 的另一个好处是，Git 历史更加容易访问且可视化组织。

GitLab Flow 的一个缺点是需要协调多个环境分支，这会增加工作量，并且可能导致实现困难。如果管理不当，开发分支可能会变得纠结和混乱。由于其灵活性，你必须仔细考虑如何使用它，这使得它比想象中更不易使用。确保你的团队成员都了解你打算使用的可选分支。

GitLab 是 Gitflow 和 GitHub flow 之间的一个优秀且成熟的折衷方案，因为它比 Gitflow 简单，但比 GitHub flow 更全面。得益于其可选的分支，它足够灵活，能够满足你独特的需求，并在 CI 环境下表现出色。在 GitLab Flow 的文档中，GitLab 提供了一套全面的指导，涵盖了从重置你的仓库到编写有效提交信息的所有内容。无论你的团队决定采用哪种方法，通读一遍文档都是个不错的主意。

如何选择分支策略

迄今为止提到的所有分支策略都经过了测试并且得到验证，是管理源代码的不错选择。然而，每种方法都有独特的优缺点，你不应盲目选择其中一个，而是应该做出评估。

例如，在 DevOps 流程不断发展的背景下，标准的 Gitflow 可能不是最佳选择。这里提到的其他解决方案都在努力增强 Gitflow 并使其现代化，以便与敏捷的 DevOps 流程兼容。因此，像往常一样，你需要决定一个理想的策略，既符合你所有的需求，又适用于你独特的业务运作。在做出这个决策时，考虑客户、公司和你的团队非常重要。

分支策略的最终目标是将每个团队成员对代码库所做的更改，组织并整合成一个统一的发布。然而，协调所有这些更改不仅仅是编写代码。比如，一个新的发布必须以某种方式进行部署，这时发布流水线就派上用场了。

探索发布流水线

发布流水线是一个工作流程或一系列步骤，旨在确保最近交付的代码能够迅速实施。从根本上说，一个构建良好的发布流水线使得生产环境交付变得快速、简便且可靠。

发布流水线的具体阶段因组织和产品而异，但它们通常是线性顺序执行的。值得注意的是，较复杂的流水线设计可能包括可以并行执行的步骤。近年来，这种趋势变得更加流行，原因不仅是并行处理所带来的战略优势，而且因为当代的工具已足够先进，可以使这一功能更容易实现，而无需大量编写脚本。

通常，发布由某个事件触发，例如代码提交，尽管也有一些情况下，发布可能会明确启动或提前安排。你也可能希望将流水线的执行自动化，直到某个特定里程碑，例如预生产测试的结束，然后再进行人工授权，部署到生产环境中。例如，在受监管严格的行业中，可能希望将手动触发作为完成条件，尽管流水线过程是自动启动的。

在大多数情况下，拥有一个合适的发布流水线将是你团队的交付策略组合中，决定每周部署一次和每天多次部署之间差异的关键。但关键问题是，发布流水线在持续集成（CI）、持续交付（CD）和持续部署之间的关系是什么？在我们回答这个问题之前，必须理解发布流水线的所有组成部分，包括支持它的相关基础设施。接下来的各部分将详细概述发布流水线的每个元素。

任务

任务指的是在详细层次上完成的特定活动。在发布流水线的上下文中，一个阶段内任务的顺序对于整个过程的成功完成几乎没有影响。在控制流程时，应将阶段作为关卡，将任务作为在其中执行的活动。

至少，你的发布流水线必须包括以下任务：

• 提供基础设施：指的是分配和配置必要的资源，以建立和运营各种应用程序和服务。这可能需要为测试目的创建新的虚拟环境，或涉及验证测试环境的正确配置，甚至安装和激活必要的服务，例如 web 服务器。

• 应用部署：这是需要获取打包好的软件并将其部署到指定服务器基础设施中的发布过程，伴随必要的环境特定配置调整。

• 软件测试：指的是进行自动化测试并传播相应结果的过程。此外，你还必须提供在测试执行结果不理想时，将某个阶段标记为失败的能力。

• 淘汰基础设施：无论结果如何，在完成流水线各阶段后，应该进行此操作。现在，团队普遍采用 Kubernetes 集群来操作不可变容器实例中的短暂流水线阶段。这种策略的关键优势在于，容器实例能够在完成分配任务后优雅地终止所有未保留的资源。

发布管道中的某些任务可能需要异步处理，这要求管道能够适应多种相关情况，例如这里提到的情况。举个例子，考虑一个需要在云端创建服务器实例的应用发布管道。在基础设施配置开始和随后的应用部署或测试之间的时间段内，需要大约 1 分钟的过渡时间。这段时间窗口用于充分准备环境，以支持发布管道接下来的任务，避免竞争条件。

工件存储

代码更改通常会启动发布过程，最终提供所需的基础设施和交付的软件工件。在这个过程中，可能需要根据每个环境的相关要求定制软件包，使其与环境兼容，然后进行部署。因此，工件的仓库是发布过程的基础，例如 jFrog Artifactory 或 Sonatype Nexus Repository Manager。

工件存储的需求是促进离散工件版本的管理。关键在于确保与单个构建和随后的发布相关联的工件是不可分割的，并且与其他任何发布完全分开，避免任何形式的混杂或相互干扰。

在前几年，实现这一目标是通过建立一个网络共享来完成的，这个共享专门用于促进构建和发布过程。在这个共享中，每个构建都会分配一个独特的文件夹，以确保组织的一致性。在发布管理方面，工件的持久性至关重要，无论选择哪种方法——使用数据库、采用特定方法论，甚至选择将所有数据存储在对象存储中，比如 S3 桶或 Azure Blob 存储。

配置存储

另一方面，配置存储是一个存放各种值的仓库，这些值在不同的构建/发布配置中提供一致性。例如，你的 CI/CD 流程和应用的构建配置数据可能会作为一组键/值对存储在配置存储中。通常，这些配对会作为环境变量或输入参数注入到构建环境中，虽然作业完成的信息也可以包含在内。常见的值包括连接字符串、API URL、特定环境用户、权限等关键信息。

发布管道还需要能够在管道的每个对应阶段提取特定于给定环境的必要配置。一旦提取，配置应被用来促进配置和部署过程。值得注意的是，通过使用适当的值来引用相同的参数，管道代码可以实现复用，具体取决于环境。值得强调的是，配置存储最终将包含一部分生产环境配置，即使它仅限于基础设施的细节。因此，您的配置存储必须加强安全措施和加密协议。

日志记录

在 DevOps 中，内建的理解是，在执行管道时如果出现问题，至关重要的是要仔细检查日志，确定准确的问题所在，并找出障碍的根本原因。市场上有几款流行的日志聚合工具，其中包括 Splunk、ELK Stack 和 Loggly，仅举几例。在一个由多个动态组件构成的复杂系统中，强烈建议建立一种有效的日志聚合机制，以便提高意识并迅速进行分析。

为确保适当的文档记录，所有日志条目至少应包含应用程序名称、管道阶段、构建编号和时间戳。满足这些要求后，您使用的任何额外方法来表示日志条目完全是主观的。最基本的系统可能只是将它们全部汇总并使其可搜索，但更先进的构建管道系统会提供一个图形化的管道执行展示，同时允许深入查看它们生成的日志。

工作流执行

工作流引擎有助于将通常由 IT 驱动的手动工作流转变为由人类和软件共同管理的过程。这使得信息流的路由和导向、任务分配以及协作渠道的建立成为可能，从而优化资源利用。这个过程的底层机制因具体实现而异，但过程的执行是必不可少的。无论是复杂的 bash 脚本还是托管的工作流引擎（如 Jenkins），任务必须以逻辑和有序的方式执行。

部署与发布的区别

到现在为止，您可能会想知道部署管道和发布管道之间的区别，因为这两个术语通常是互换使用的。然而，部署和发布确实是不同的！部署是将软件从一个受控环境迁移到另一个环境。另一方面，发布是一个精心策划的软件更改集合，旨在让最终用户体验。

下面是部署和发布之间的一些关键区别：

• 软件发布是一组将在生产环境中交付的更改，而部署则是将从一个受控环境构建的代码迁移到另一个环境的过程。

• 通常情况下，发布会频繁地在生产环境中更新。相反，部署是软件开发生命周期（SDLC）的最后阶段，并且在所有环境中执行。

• 从统计学角度来看，发布版本更容易将有缺陷的版本、错误和软件问题暴露给最终用户。相反，部署发生在生产环境和开发环境中，用户永远不会看到这些环境。

• 发布代码可能还没有准备好进入生产环境，而部署代码则是生产就绪的。

• 软件发布对用户可见，而部署可以在基础设施中的任何目标环境中运行。

换句话说，业务合理性是区分部署和发布的决定性特征。通常，发布管理更倾向于作为一种面向业务的活动，而非纯粹的技术活动。发布安排的决策背后的理由往往受到业务战略的影响，特别是在收入生成和投资组合管理方面。

考虑到涉及的不同环境，可以明显看出，部署并不一定意味着用户能够访问已经实现的功能。某些组织可能会将发布与生产环境的部署阶段同时安排，而其他组织则选择推迟，直到公司做出最终决定。这意味着新功能可能已经批准在生产环境中发布，但直到未来某个时间点部署后，用户才能访问这些功能。

此时，你已经了解了拥有一个合理的分支策略的重要性。一个适合团队工作流的良好分支策略，能够帮助你逻辑性地组织各种软件更改，使得发布新版本变得更加直接。你也已经了解了什么是发布管道以及如何实现它。然而，在这些变化同时发生的情况下，如何以理智的方式进行管理呢？展示你团队辛勤工作的最佳方法是什么？答案就是拥有合理的变更管理实践。

理解变更管理

数字服务遵循一个必须管理的生命周期，大多数组织通过一套专门的变更管理流程来完成这项工作。这些行动通常作为缓解变更可能对运营和安全产生负面影响的第一道防线。

为了促进整个系统的变更实施，变更管理方法通常涉及从外部评审者或变更控制委员会（CCBs）获得批准。为了验证合规性要求，合规经理和安全经理在很大程度上依赖变更管理流程来认证实体的合规性。因此，必须根据详细记录维护所有变更的汇总日志，以明确认证构建和发布过程以及其他任何合规要求。最值得注意的是，许多行业监管要求通常要求提供证据，证明所做的任何修改都已得到适当授权，并包含发生时间的时间戳。

根据 2019 年发布的DevOps 现状报告中的研究结果，实施变更审批的最有效方法是在开发过程中通过同行评审进行。这种方法应通过自动化来强化，早期检测、避免和修复不良变更，确保在软件开发生命周期（SDLC）中尽早解决问题。持续测试、CI、谨慎监管、强大的可观察性以及补充策略提供了早期和自动化的检测、更高的可见性以及快速的反馈。此外，公司还可以通过更好地沟通当前已建立的流程，并帮助团队轻松地导航这些流程来提升绩效。高层管理人员应亲自去现场查看实际的工作执行情况，理解流程，了解工作内容，提问并学习。

当所有团队成员都对变更审批流程有全面的操作认知时，绩效会得到提升。接下来，我们将讨论如何务实地实施以 DevOps 为中心的变更审批流程。

实施变更审批流程

降低与实施变更相关的风险并满足监管机构设定的要求是遵守变更审批流程的两个最重要原因。职务分离是一个常见的跨行业监管要求，规定任何对流程的变更必须由非流程原始创建者的人员审批。这确保了没有单个个人对整个流程拥有完全控制权。

实现这些结果的传统方法是将提议的变更提交给外部小组进行审批，如变更控制委员会（CCB）或变更咨询委员会（CAB）。然而，DevOps 研究与评估小组发布的研究表明，这些方法对软件部署的速度产生了负面影响。此外，关于正式的外部审查程序能导致较低变更失败率的观点并没有得到数据的支持。这些繁琐的方法增加了生产系统暴露于风险的可能性，从而增加了变更失败率，因为它们减缓了交付过程，导致开发人员更不频繁地发布更大批量的工作。DevOps 研究与评估小组对数据的分析证实了这一理论的有效性。

相反，团队应该专注于角色的分离，这可以通过同行评审来实现。此外，管理软件开发的平台应被用来记录审查、评论和批准过程。此外，你应该利用自动化、持续测试、CI、监控和可观察性，快速发现、避免和纠正任何不良变更。最后，考虑将你的开发平台视为一种产品，当正确使用时，它能够使开发人员快速获得关于其变更对多个方面（如安全性、性能和稳定性）以及缺陷的影响的反馈。

你的目标应该是使管理变更的标准程序既快速又可靠，足够在紧急情况下使用。在这种新视角下，CCB 或 CAB 仍然在持续交付范式中扮演着重要角色，涵盖了简化团队沟通和协作过程的内容。此外，CCB 应该促进团队通过流程改进活动来提升软件交付表现，例如举办内部的黑客马拉松。最后，领导层应该对需要在竞争优先事项之间取得平衡的战略商业决策提供意见，例如在市场速度和商业风险之间做出选择，或获得公司高层的支持。

CCB 的新角色是战略性的。将细致的代码审查委派给实践者，并实施自动化流程，使领导和管理人员能够将时间和精力集中于更具战略性的工作。领先的软件下载组织的策略体现了从守门人到流程架构师和信息灯塔的这一转变。

实施变更审批的障碍

对变更控制委员会（CCB）过度依赖，以纠正缺陷和批准变更，是当今最常见的错误之一。选择通过 CCB 进行监督通常会导致额外的等待和不幸的沟通问题。虽然 CCB 在传播变更信息方面是有效的，但许多跨时区工作的团队可能会无意中对新变更或政策的意义产生误解。掩盖审批流程的低效是企业常犯的另一个错误。这意味着，当所有变更都经过统一的审批流程时，变更审查的低效就会显现，无法让个人为那些由于风险或截止日期差异而需要特别关注的变更分配足够的时间和精力。

另一个企业常犯的错误是缺乏对持续改进计划的投资。为了提升变更管理流程的绩效，必须关注关键绩效指标，如交付时间和变更失败率。这就要求为团队提供合适的工具和培训，以帮助他们有效地通过流程：

图 8.8：克服 DevOps 变更管理中的障碍

最后，增加不必要的流程是许多公司反复犯的常见错误。通常，企业会在软件制造阶段遇到稳定性问题时，实施额外的程序和更严格的授权协议。实际分析表明，采用这种方法很可能会由于对交付时间和批量大小的影响，进一步加剧问题，从而产生负面反馈循环。与其这样做，不如将资源投入到逐步提升变更管理流程的效率和安全性，并视其为并行进行的两项工作。

改善变更审批流程的方法

为了改善变更审批流程，重点实施自动化测试并使用同行评审流程，在提交前评估所有变更。另一种改善变更审批流程的方法是开发自动化工具，尽早检测出问题，包括回归问题、性能问题和安全漏洞，一旦代码变更提交后立即发现。此外，定期进行分析，以识别并突出显示高风险变更，并在发现时迅速进行进一步调查。

此外，将验证步骤移入开发平台是一个良好的实践。这有助于你的团队研究整个变更过程，寻找瓶颈，并确定潜在的解决方案。与其在软件交付过程中手动检查安全规则，不如在平台和基础设施层以及开发工具链中实施这些规则。

根据 2019 年的 DevOps 状态报告 中提出的研究结果，改善软件交付性能可能只是通过更好地沟通现有流程，并帮助团队高效地导航它。这对软件交付性能有积极影响，即使最终目标是摆脱传统的、正式的变更管理流程。出色的表现源于团队中的每个人对必须遵循的程序有清晰的意识，以便批准实施变更。这表明他们对通过审批流程以最短时间完成变更充满信心，并且他们知道所有常见变更类型所需的流程。

总结

这标志着 第八章 的结束。阅读并理解本章内容后，你应该已经在脑海中有了一个可靠的蓝图，可以在开始进行治理、分支策略、发布管道和变更管理的开发与实施工作时加以参考。

正如你所看到的，通过设计你的 CI/CD 基础设施来自动执行这些原则，你最小化了人为错误和过度劳累的风险。这一点不容忽视，因为我们并不是在替代或淡化组织中的治理、分支策略、发布管道和变更管理。相反，我们是将这些内容 融入其中。这意味着这些职责仍然需要像以前一样彻底实施和执行，但通过可以在 CI/CD 管道配置中实施的各种监督机制。

在下一章中，我们将讨论可以帮助你在组织的发布管理策略中培养 DevOps 文化的有效策略。

问题

回答以下问题，以测试你对本章内容的掌握：

1. 每一种 OWASP Top 10 CI/CD 安全风险 是什么？

2. CI/CD 治理的三种常见路径是什么？

3. 映射 CI/CD 系统和流程的意义是什么？这个过程用什么术语来描述？

4. 目前开发团队使用的四种最常见的分支策略是什么？

5. 基于主干的开发 和 扩展主干开发 之间有什么区别？

6. 本章中描述的四种分支策略中，哪一种促进了 功能驱动 开发？

7. 发布管道和部署管道有什么区别？

8. 工件存储和配置存储有什么区别？

9. 为什么外部 CCB 和 CAB 在 DevOps 发布管理中经常被视为反模式？

10. 为什么将验证步骤移入开发平台被认为是良好的实践？

第三部分：在您的组织发布管理战略中培养 DevOps 文化

本书的最后一部分，我们将从理解什么是 DevOps 文化以及如何在您的组织中成功地发展 DevOps 文化开始。接下来，我们将重点讨论从领导层和利益相关者那里获得支持的关键方面。最后，我们将探讨如何通过调查一些可以应对这些成长痛点的方法，克服 DevOps 发布管理中的常见陷阱，帮助您的组织成为下一个成功案例。

本节包含以下章节：

• 第九章，在您的发布管理战略中拥抱 DevOps 文化

• 第十章，从领导层和利益相关者获得支持的表现是什么样的

• 第十一章，克服 DevOps 发布管理中的常见陷阱

第九章：在你的发布管理策略中拥抱 DevOps 文化

当 DevOps 的交付成果被用来定义成功时，可能很难获得高层管理的支持和预算支持。如果高层管理者不了解 DevOps 为他们的客户带来的真正价值，这种情况尤其明显。相反，管理层可能会把 DevOps 误认为是利润的负担，试图为其存在寻找理由，而不是把它视为价值的倍增器和长期战略。在这种情况下，高层可能会试图减少对团队的投资，而不是帮助你增加改善客户体验所需的能力。因此，DevOps 领导者必须建立 DevOps 文化，并通过以客户为中心的结果来定义成功。

构建 DevOps 文化需要周密的规划和统一的方法。首先，获得高层领导的支持，然后组建 DevOps 团队。一旦你的团队成立后，逐步定义流程，并培养协作与持续改进的文化。别忘了提供培训和支持，并庆祝成功的成果。

本章中，你将学习以下内容：

• 更快和更便宜不一定意味着更好

• DevOps 不仅仅是工具和流程

• 采用 CALMS 方法

• 培养 DevOps 思维需要时间

更快和更便宜不一定意味着更好

在 DevOps 发展过程中，某个时刻，似乎突然间，我们成为了一个为所有事情进行成本效益分析的文化。这样做，我们违反了经典的公理：你只能同时满足三个约束中的两个：范围（质量）、时间（速度） 和 成本（低成本）。这就是所谓的项目管理三角形或三重约束，它表明这三个约束中的任何一个发生变化，必然会影响其他两个；你必须选择其中两个并在第三个上做出妥协。我们往往会引入一些新工具，并试图说服他人它将如何加速进程、节省成本，或者为我们腾出更多时间去做更有意义的任务。然后，我们会发现如果我们通过添加另一个新功能或能力来扩展这个新工具，它能够提高质量，并承诺与现有流程相比，它将带来更可靠的结果：

图 9.1：三重约束图解

在大多数科技公司中，这些论点很容易取胜，因为通过将计算出的节省金额乘以有帮助的团队成员数量，就能得到一个看似合理的结果。然而，发现一个变化的实际效果是一种滞后指标，因为预测新流程在现实条件下的结果极其困难。正因如此，DevOps 文化鼓励持续实验和持续学习。有时候，你永远无法确定一个新的改变是否会奏效，除非先让它经历一段时间的检验。当然，关键在于准确知道何时一个新变化不起作用，并且是时候改变方向了；这既是一门艺术，也是一门科学！

然而，围绕新工具实施的潜在效益有多大，来为其成本辩护，的确很容易构建一个故事。现实是，你无法从这些投资中获得任何竞争优势，因为你的竞争对手也能进行同样的投资。在这种情况下，你认为自己正在取得的任何收益，实际上是不可持续的。相反，你只是在通过与竞争对手保持平行而站稳了脚跟。遗憾的是，这类投资的决策往往是由高层管理人员单独做出的，并且通常只考虑狭窄的利益群体。在这种情况下，开发人员常常被牺牲，作为“成本削减措施”的替罪羊。

既然我们已经强调了三重约束的含义及其对软件开发的影响，接下来我们来讨论一些策略，帮助你平衡质量、速度和成本之间的竞争优先事项。让我们首先关注创建新软件的最重要方面：质量。

永远不要在质量上妥协

由于当前世界形势的变化，企业比以往任何时候都更加需要削减开支。鉴于预算限制在很大程度上影响着大多数领导者的决策过程，剩下可以谈判的因素就是产品（或服务）的质量或产品的速度。

基于客户在竞争激烈市场中的期望，你不应妥协于质量。当你放松质量标准时，不仅会损害产品的形象和整体可靠性，还会在后期维护阶段以额外的成本反噬你——特别是在维护阶段。简单来说，任何通过放松质量标准、没有认真设计产品而省下的前期成本，都会在未来以巨大的规模回头威胁你的产品和服务的成功。现在我已经表明了我的立场，作为专业人士，我们必须在严苛的财务约束下交付高质量的产品和服务。这让我们只剩下最后一个选择：速度（velocity）。

显而易见，实现最佳速度和卓越标准在很大程度上依赖于你的团队与商业目标和已知需求的对齐程度。此时，应该清楚地意识到，在它们的最大潜力下同时实现这两个目标并不现实。然而，你有机会在不完全削弱其中任何一方的情况下，创造一个可接受的平衡。正如之前强调的，质量保证（QA）测试在实现这些相互竞争的优先事项之间的平衡中至关重要。通过实施 QA 和软件测试，同时与 DevOps 发布管理结合，你可以实现更快的市场渗透，同时优化产品的价值。因此，必须在整个 SDLC 中无缝集成自动化质量保证方法，确保它们始终得到适当的关注。随着公司发展，努力进行持续测试，以显著提高产品的质量。这不仅会让你的客户感到满意——它还将维持他们对你业务的忠诚。效率可以让你快速进入市场，但确保高标准则能确保持久的成功和客户的满意。花些时间为你组织的独特需求和持续盈利能力发现完美的平衡。

以下是一些能让实现这一目标更成功的要点：

• 在启动项目时，必须从一开始就建立一个全面的QA计划。这种前瞻性的做法确保了有效评估和验证项目交付成果所需的资源到位。在将 QA 规划纳入项目初期阶段时，建议避免无有效理由忽视最佳实践。

• 自动化测试是一种宝贵的实践，特别是在执行回归测试时。通过采用自动化测试，软件开发团队可以将时间用于新特性开发，而自动化测试则处理验证现有功能的过程。这种方法确保了先前实现的功能在整个软件开发生命周期（SDLC）中保持完好且可用。

• 并行测试是一种技术，涉及同时运行多个脚本，而非按顺序执行。这种方法可以大大缩短执行各种类型测试（包括单元测试、冒烟测试、回归测试和跨浏览器测试）所需的时间。通过利用并行测试解决方案，组织可以优化测试流程，实现更快速、更高效的结果。

• 结对编程，也称为双人编程，是一种协作的软件开发技术，其中两名程序员在同一工作站上共同处理同一个任务。这种方法不同于传统的代码审查，后者通常是一个程序员在编写代码之后审查另一个程序员的代码。结对编程的目标是通过发挥两个人的优势和专业知识，提高生产力和效率。通过共同工作，程序员可以在更短的时间内实现传统单独编程的相同好处。

• 测试驱动开发（TDD）是一种软件开发方法，提供了减少市场发布时间的可行解决方案。通过将测试过程从开发后活动转变为开发阶段的一个组成部分，TDD 提供了一种有益的替代方案。这种方法强调在编写实际代码之前先编写测试，以确保代码满足指定的要求并通过测试。通过采用 TDD，开发者可以简化开发流程，及早发现并修复问题，最终加快将产品推向市场的时间。

通过使用这些建议，你的项目可以有效地调和低成本、快速和高质量之间的冲突目标，从而超越这两者之间的分歧。自然地，你必须在项目规划的初期阶段考虑对项目的整体影响。

项目时间表是可以协商的。

在大多数情况下，项目时间表是可以协商的。客户期望、市场压力、内部财务目标以及与竞争对手的对标是常见的非合理截止日期来源；在某些情况下，它们可能会影响到整个项目。通过确保期望的正确对齐，项目或改进计划的排程和组织过程变得更加简化。这使得在不需要将客户最初预期成本翻倍的情况下，有可能在一半的时间内交付预期的成果。通过确定交付优质项目的理想时间框架，同时遵守受限的速度，你可以优化应对这一挑战的方法。这可以有多种解释，超出了本书的范围。

然而，在实施这一平衡时，必然会出现一些权衡。在某些情况下，它可能会妨碍产品团队在频繁且快速的迭代中交付产品，并根据精确的客户需求量身定制。此外，将速度与质量相协调会限制团队迅速优先处理变化需求的能力。一个常见问题是使用较大的队列，这可能导致与管理积压、机会成本和复杂性增加等因素相关的技术债务的积累。然而，在这种情况下仍然存在希望，通过简化运营框架的过程，可以明显看出，影响团队效率的主要限制因素是队列的大小。接下来的阶段需要你调查一些方法，例如看板（Kanban），来改善瓶颈所在的区域。目标是增加可扩展性，同时遵守之前阐明的质量和低成本限制。

DevOps 中的感知问题

当被问及时，许多技术高管会承认，他们对 DevOps 发布管理计划的进展感到失望。在这种情况下，他们至少将 15% 或更多的工程预算花费在与其核心业务模式无关的事项上，而他们并没有看到足够的费用合理性。这些高管最初投资于 DevOps 转型的原因是为了提高创新性、独特性和竞争优势。另一个对这种感知产生负面影响的因素是，大多数业务高管不清楚为什么 DevOps 如此难以理解，或为什么其实施成本如此之高。

经过进一步调查，一位训练有素的眼光可以迅速判断，DevOps 本身并没有真正的问题。换句话说，多个因素限制了这些高管在 DevOps 工具上的投资所能实现的商业价值，以及他们的软件和 DevOps 工程师的生产力。这些因素包括速度、成本、人员配置和认知。此时，关键绩效指标如部署频率、交付时间、恢复的平均时间（MTTR）、缺陷率和客户满意度有助于衡量 DevOps 实践的影响。

在速度方面，具有讽刺意味的是，DevOps 有时被视为减慢软件开发速度的瓶颈，影响那些仅仅在努力跟上客户需求的运营团队。多个因素影响着这些努力的生产力流动，但在许多情况下，对进展或现实结果的可见性不足是感知延迟的主要原因。为了提升交付速度，团队必须首先通过收集数据和指标来获得他们的 DevOps 表现的可见性。通过改善可见性，团队可以将他们的表现与市场上其他团队或组织进行比较，最终目标是识别交付管道中的低效环节。

关于费用，部署云应用相关的总运营成本有时未能满足高管们的期望，他们认为采用 DevOps 将会提高效率、速度和成本效益。如果 DevOps 占据了预算的四分之一以上，DevOps 可能会被归咎于预算预期和实际支出之间的偏差。原因在于，当 DevOps 团队将大量宝贵时间用于处理紧急事务或手动构建和更新部署环境时，他们无法有效地优化成本或应对新出现的问题。这是因为他们没有足够的时间同时完成这两项任务。为了优化开发工作，建议投资于强大的 DevOps 实践，特别是通过尽可能引入自动化来简化操作。这将有助于解决执行和管理这些协议所带来的费用和复杂性问题。

雇佣团队的成本是制定策略时需要考虑的另一个因素。由于合格的 DevOps 技术人员成本高昂且稀缺，可能很难在短时间内迅速扩展团队以应对日益增加的需求。即使是那些幸运地拥有合格 DevOps 员工的公司，也必须投资于招聘工作和提供晋升机会。此外，这些公司通常需要应对高员工流动率，这使得需要更多的没有经验的员工来响应客户需求。

公众对你们的业务、产品和服务的印象应该是另一个需要考虑的因素。许多公司高管误以为开发和发布云原生应用程序应该比实际情况更直接、更省时且更便宜。软件开发者、消费者和公司高管可能由于缺乏对 DevOps 发布管理实践的经验，尤其是如果他们观察到像 Google、Capitol One 和 Etsy 这样的受人尊敬的公司如何处理云原生应用程序的交付时，会产生这种印象。

几乎每个人似乎都认为将软件应用程序交付到云端会很容易，但很少有人理解在将云软件分发做到像著名的 FAANG 股票公司那样简单和自动化时需要付出多少努力。然而，几乎所有较小的软件即服务（SaaS）提供商都无法拥有足够的资本进行与这些大公司同等规模的投资。尽管如此，具有突破性潜力的创新产品和服务将变得更加便宜并且更易于实现，并将不时进入市场。每天，新的革命性解决方案，如 Kubernetes，都在不断诞生，极大地赋能所有利益相关者。

FAANG 股票公司

五家著名的美国科技公司——Meta（前身为 Facebook）、Amazon（AMZN）、Apple（AAPL）、Netflix（NFLX）和 Alphabet（GOOG）——在金融圈中被简称为“FAANG”。截至 2022 年第一季度，五只 FAANG 股票的总市值超过了 7 万亿美元，使它们不仅在消费者中非常受欢迎，也是全球最大的公司。

所有 FAANG 股票都属于标准普尔 500 指数，并在纳斯达克交易所交易。作为市场的广泛反映，市场的波动与标准普尔 500 指数的走势一致。在 2023 年 8 月，FAANG 股票的市值约占标准普尔 500 指数的 20%。当你意识到标准普尔 500 常被用作整体美国经济的代表时，这个比例非常惊人。

这就是我们对三重约束的探讨以及你可以用来应对质量、速度和成本竞争优先级的策略总结。正如你所见，这些因素对公司盈利能力、稳定性和文化有着重大影响。接下来，让我们讨论为什么 DevOps 不仅仅是工具和流程。剧透——DevOps 发布管理中最重要的一个方面是人！

DevOps 不仅仅是工具和流程

这可能是一个不太受欢迎的观点，但依赖工具并不会将你的 DevOps 计划带向成功。那些取得卓越成果的 DevOps 团队，首先注重通过人和流程解决挑战，然后通过使用工具来提高工作质量，而不是采取相反的做法。

这种目光短浅的观点可以通过购买某些东西来说明，购买的初衷是提高团队生产力，最终导致流程改进。更明智的做法是将资源分配给方法论，例如 DevOps 发布管理，然后获得资源和教育，影响更多的利益相关者。这个例子中的反复缺陷是，人们总是专注于他们的技能。在这种背景下，普遍的看法是，一个人的价值由他们对所有工具和流程的理解程度来定义。令人难以置信的是，许多 IT 公司的领导人提出担忧，认为现有员工缺乏所需的技能，因此招聘外部人员被视为唯一的解决办法。在这种情况下，高层管理将员工视为去人性化的齿轮，参与到单纯以利润为驱动的机器中。在这种情况下，专业人员被简化为人力资本，仅仅是一个聚集了技能的集合体，提供的工作范围狭窄，且无法看到他们与价值流其他部分的关系所创造的价值。

表现卓越的团队首先克服了 DevOps 转型背后的人员挑战。这包括找到一种方式，以最适合团队整体工作流程的方式实施 DevOps 发布管理的标准特征。具体来说，包括 CI/CD、自动化测试以及详细的监控和分析等核心要素。没有任何组织可以选择一种通用方法来应对 DevOps 实施中的障碍，但高效团队之间的共同点揭示了一些显著的趋势。区别高效团队和低效团队的决定性特点是专注于提升团队成员技能的做法。这可能包括为同事提供某些认证的奖励，或者提供在线教育资源的访问权限，类似的方法也是有效的。公司不能忽视沉浸式学习的方法，因为这些投资比那些没有采用这种方法的公司更为成功：

图 9.2：一个 DevOps 团队在协作工作

组织可以建立内部社区，推动教育并提高对员工或产品线调整的韧性。这有助于识别广泛的内部冲突，促进更具合作性的环境。高效的团队利用实践社区，由少数专注的专业人士组成，他们有共同的兴趣，通过持续互动不断提升技能。此外，高绩效团队通常会参与草根 DevOps 活动，并开发概念验证来解决公司独特的挑战。团队成员可以通过实践培训更好地理解同事的责任，而战术策略可以通过内部小组讨论和新闻简报来制定，成功故事也能得到分享。成熟的 DevOps 采用者努力避免知识孤岛，并致力于加强软技能，如有效地分享信息，以便能够继续开放合作。

在整个组织内推广知识非常重要，使其对每个人都能访问。高度成功的 DevOps 团队会努力提供指导机会，提升软技能，并采用一系列相关方法。

本节故意简明扼要，特别是为了避免稀释优先考虑依赖于团队成员以实现成功结果的核心观点——不仅仅是在 DevOps 中，而是在任何项目中。现在我们已经做出了这个重要的区分，接下来我们将研究文化、自动化、精益、衡量与共享（CLAMS）方法。这个战略框架将提升你团队成员的个人成功，帮助他们实现最大的潜力。这一策略的副作用是显著增强你业务实现战略目标的能力。这种协同效应是 DevOps 方法的标志，它源自所有利益相关者之间的互惠互利关系。

采用 CALMS 方法

CALMS 是一个概念框架，用于促进 DevOps 团队、职能和系统在组织内的无缝集成。CALMS 框架提供了计算机科学领域的成熟度模型，帮助管理者评估组织实施 DevOps 的准备情况。它使管理者能够识别需要改进的领域，从而实现准备工作。值得注意的是，CALMS 方法归功于Jez Humble，他是《DevOps Handbook》的共同作者之一。

CALMS 框架的 DevOps 包含五个基本原则：

• 文化：这包括集体问责制的主流理念。

• 自动化：团队成员积极寻找机会实施自动化，简化和优化各种流程，同时拥抱持续交付。

• 精益实践：与同时处理多个任务不同，专注于一次处理较少的任务。精益强调通过可视化工作来提高协调和协作。特别需要注意的是，管理队列长度和等待处理的任务积压非常重要。

• 衡量：这一点至关重要，因为它可以收集有价值的信息，确保全面了解操作环境。这些机制使得数据能够系统地收集，从而有助于更深入地理解各个过程和系统。

• 共享：开发和运维之间共享简单的沟通渠道促进了持续的双向对话。这些沟通渠道旨在促进 DevOps 团队之间的持续合作：

图 9.3：CALMS 方法在 DevOps 中的 infographics

CALMS 框架有时被视为 IT 服务管理（ITSM）的替代方案，后者是一种为组织开发、交付、管理和增强 IT 利用的战略方法论。ITSM 是与 信息技术基础设施库（ITIL）常常相关联的框架。一些 IT 管理员认为 ITSM 过于僵化，因此与 DevOps 实践存在不兼容的情况。CALMS 框架通常被视为有效管理并调和这两种不同策略之间差异的一种方式。

文化

尽管 DevOps 是基于运维人员和开发人员之间的增强沟通，但最初并不要求这两个小组与业务之间进行合作。然而，在文化层面，CALMS 模型旨在确保整个组织都认同实施 DevOps 的原因以及与该工作相关的期望。

CALMS 模型强调技术的根本目的，即实现预期的结果。它突出了一个观点：技术应该仅仅用于支持和促进业务运作，而不是仅仅为了跟上最新的技术进展。在 DevOps 转型的初期阶段，促使业务、开发和 IT 运维团队之间的合作至关重要，这有助于获得对实施新项目管理和交付实践的广泛支持。

为了确保持续项目的资金和支持，这些项目将在长期内产生回报，这种合作需要建立在与业务团队的非技术性对话基础上。技术团队必须向业务方明确能力、成本和时间表的参数，并确保这些认知是准确的。

自动化

如果没有引入自动化实施 DevOps 是不可取的，因为它会降低过程的效率和效果。然而，值得注意的是，低质量的自动化会在没有充分考虑的情况下强行进行更改，这可能会进一步加剧规划不周带来的负面后果。虽然 DevOps 强烈与持续开发和交付方法相关，但同样重要的是采取措施，以防止因测试不足而部署有缺陷的代码。CALMS 框架提倡实施一个强有力的测试制度，该制度不会对 DevOps 工作流造成显著延迟。

提前实施自动化往往会产生适得其反的结果。在 DevOps 实施的初期阶段，你应该坚持手动流程，随着相关团队逐渐适应 DevOps 方法论的复杂性，逐步引入低风险的自动化。等到 IT 人员对组织内采用的工具有了更深的理解，风险降低后，团队应当进阶使用更复杂的自动化工具。

精益

为了减少自动化可能对性能造成的不利影响，必须在企业内部建立对精益的共同理解，精益原则源于 20 世纪 80 年代的精益生产理念。尽管精益软件开发主要强调提高效率和减少浪费，但要注意，采取捷径并不符合精益方法论的原则，反而会引入可避免的风险。

精益方法要求你为组织确定一个适当的风险概况，明确你希望通过 DevOps 项目实现的成果，并消除任何不利于实现这些成果的程序。这个过程应该是学习和迭代的过程，其中一个项目中学到的经验应当被运用到其他项目中。举例来说，应该识别、记录并移除那些导致不良结果的过程部分，以便在后续项目中避免。

类似地，任何导致挑战的行动都应被视为学习机会，而不是重复犯同样的错误，希望能取得不同的结果。这种学习通常会在 DevOps 转型初期的几个项目中发生得最快，因为这是发现并消除最多浪费的最佳时机。

测量

为了有效采用 DevOps 方法论，组织必须认识到使用度量和监控工具的重要性，以便洞察正在进行的过程和结果。如果不利用这些分析手段，转向 DevOps 的学习潜力将无法被激发。为了有效监控关键绩效指标（KPI）和预期结果，必须建立以业务需求和目标为中心的工具。在商业领域中，有必要采用能够有效衡量成功的度量。这些度量应该包括财务指标和必要能力的评估。通过采用这种全面的方法，组织能够以与业务的总体目标和目标一致的方式来确认他们的进展和成就。

在采用 DevOps 方法论的初期阶段，组织将遇到一个范式，其中监控和衡量作为识别和定位问题区域的有价值工具。通过建立基线并将度量和监控纳入持续改进的演变，可以加速企业的 DevOps 之旅。

分享

这包括确保所有参与 DevOps 过程的各方保持意识，通过持续提供实时信息和关于正在进行的活动和事件的更新。大多数 DevOps 工具都包含反馈回路，涵盖了操作和开发团队，通常还会扩展到支持人员。

然而，必须牢记，所执行的行为通常是服务于企业的。IT 团队负责确保业务保持对当前事件的了解，以及项目的预期结果。这将我们带回到协作步骤，强调 CALMS 系统遵循的是一个循环过程。

采用 CALMS 进行 DevOps 时需要牢记的事项

为了确保 CALMS 模型的成功实施，必须采取循环的视角。如果忽视将CALMS视为一个循环过程，必然会导致实施失败。这个概念围绕着知识的不断获取以及提升组织对 DevOps 方法论的运用。推荐的改进应该一开始展现出显著的规模，并随着组织及其 DevOps 能力的提升，逐渐转向较小的、增量式的变化：

图 9.4：将 CALMS 方法描述为一个循环过程

需要注意的是，CALMS 是一个框架，而非工具集合。在 DevOps 领域，遵循 CALMS 原则的组织被赋予了在选择集成到 DevOps 流水线中的工具时的灵活性。上述工具包括来自 Atlassian 和 HashiCorp 等知名供应商的产品，以及 Git、Puppet 和 Jenkins 等开源 DevOps 工具。考虑到这一点，值得重申 DevOps 强调以人为本，而非工具优先的原则。

CALMS 框架虽然本身具有价值，但不应视为替代其他能够有效提升 DevOps 领域控制水平的开发哲学和系统。敏捷方法论，例如 Scrum 和 Kanban 等方法，提供了建立一致且强健的 DevOps 实施框架。总体而言，CALMS 框架作为评估公司 DevOps 实施成熟度和效果的有力工具。

现在你已经理解了 CALMS 方法的战略重要性，以及如何利用其灵活性来协同工作流程，让我们来讨论 DevOps 思维方式。采纳 DevOps 思维方式要求团队理解 DevOps 的长期和即时优势，并且意识到他们可能需要改变自己的过程、视角和耐心，以适应实现这些成果所需的时间。

培养 DevOps 思维需要时间。

重要的组织变革应 ideally 分阶段进行，否则可能会产生抵抗或混乱。快速挑战群体思维可能会导致一种叫做文化冲击的强烈体验。

拥抱 DevOps 文化需要获得来自各个层级个人的共识和支持，包括开发人员、系统管理员、安全专家以及高管等。团队必须理解 DevOps 的持久和即时优势，并且他们可能需要看到过程中的变革。确保这些变动得到充分文档化并有效沟通给所有相关人员。除非同事们认同 DevOps 的基本原则，包括效率、适应性、持续学习和统一性，否则生产力可能会受到负面影响，甚至会有更多不良后果。

已经采用敏捷方法论的组织是实施这一文化转型的理想环境。在 DevOps 领域，团队倾向于采取响应性和主动性措施，而非迟缓和被动的方式。DevOps 文化强调优先考虑客观的改进，而非主观和自我中心的做法。培养以团队为先的精神对于提高生产力和项目各阶段的整体进展至关重要。虽然转型可能不会立即发生，但预计结果会是无可否认的有利。

一个常见的误解是认为文化可以从一开始就启动或建立。与一些人的观点相反，值得注意的是，从内部发展文化具有重要意义。然而，普遍认为文化在许多情况下可以视为滞后指标。操作实践的变化会导致文化的改变。团队工具集的变化也有可能引发文化的转变：

图 9.5：保持耐心——建立 DevOps 文化需要相当长的时间

改变文化需要大量时间，因为它需要转变观点和策略，使其能够有效工作。尽管个人可以立即开始使用新工具，但组织可能需要数年时间才能在其实施中看到任何成熟度的体现。事实上，一些公司自 2016 年或更早就开始实施 DevOps，并认为自己仍处于不成熟的状态。

文化的发展不是刻意的构建，而是一个自然和自发的过程。所讨论的现象逐渐显现出来，是各种人类互动及其后续变化的累积结果。这些变化通过获得以前无法获得的新操作能力来促进，并且相应地授权去探索这些能力。

但并非每个人都持这种观点。根据一些顾问和实践者的说法，若从文化目标出发，能更容易看到程序、方法和工具集需要如何改变。然而，由于组织优先级、竞争力量、消费者期望、内部动态和技术的变化，即使有周密的过渡规划，转变也可能会发生。

无论公司采用何种策略来培养软件工程师和运营人员之间的协作文化，都必须认识到，任何技术手段在初期都会产生缓慢的效果。文化转型是一个渐进的过程，通常起始于普通人在本地层面的努力。一个有效的策略是识别出工程社区中的杰出大使，并支持他们在同事中推广这一事业。

实现 DevOps 成功需要全面理解，没有一种单一、简单的方法可以实施组织变革。文化转型面临重大挑战，因为不同企业和利益相关者的市场需求、行业考虑、资源限制以及对变革的接受程度各不相同。本书为启动开发与运营整合过程提供了宝贵的建议。然而，每个组织必须独立确定其独特的文化框架，以实施成功的 DevOps 转型措施。

总结

这标志着第八章的结束。此时，你已经清楚理解为什么更快和更便宜并不总是意味着更好。你还知道，DevOps 不仅仅关乎工具和流程——它首先关乎人。此外，你已经了解了 CALMS 方法，这是一种促进 DevOps 团队、职能和系统在组织内无缝集成的概念框架。最后，你现在应该能够清晰地阐述为什么发展 DevOps 思维需要时间。实现 DevOps 旅程的成熟状态可能需要数月甚至数年的时间。

在下一章，你将学习从领导和利益相关者那里获得支持的样貌。你将了解到为什么 DevOps 文化必须展现出高度的耐心、信任、道德和赋权。你还将发现为什么围绕员工和技术投资的紧密战略对齐至关重要。最后，你将学习如何将客户反馈融入你所做的每个决策中。

问题

回答以下问题，测试你对本章内容的理解：

1. 项目管理三角形的三个元素是什么？

2. 削减产品质量会带来什么后果？

3. 配对编程包含哪些内容？

4. 精英 DevOps 团队首先关注的是什么？

5. 问题

6. CALMS 缩写代表什么？

7. 哪些敏捷方法与 CALMS 框架互为补充？

8. 精益工程实践的核心原则是什么？

9. 成功地拥抱 DevOps 文化需要从谁那里获得共识和支持？

10. 为什么文化转型会面临重大挑战？

第十章：从领导层和利益相关者那里获得支持是什么样子的？

建立一个强大的 DevOps 文化需要组织中领导层的坚定支持和积极参与。如果这些人没有全心全意支持并投入到 DevOps 项目中，项目很可能会失败。毫无疑问，以协作和沟通为核心的文化的形成依赖于有效的领导力。领导者在创造一个消除障碍、积极鼓励跨团队协作的环境中起着至关重要的作用。组织的领导者需要充当 DevOps 的布道者，积极倡导 DevOps 的原则和优势。他们必须有效地传达实施 DevOps 发布管理的理由以及它对所有利益相关者的潜在好处。

与此同时，领导层在尝试仅仅基于从文献中获得的理论知识实施 DevOps 时需要保持谨慎。DevOps 是一个动态的、迭代的过程，经历着持续的增长和演变。为了让领导层能够培养出合适的文化，他们必须意识到这需要大量的培养和毅力。DevOps 方法论或任何一个 DevOps 团队都不是完全相同的；相反，它是一个针对特定组织、以解决方案为驱动的方法论。领导者应当为自主团队的蓬勃发展铺平道路，提供他们成功所需的工具，并认识到何时应当退后一步，允许团队作为受尊敬的专业人士执行他们的工作。

在本章中，您将学习以下内容：

• 在人员和技术上的投资要精巧对接

• 为什么授权、道德、信任和耐心被高度重视

• 提供团队自主权、所有权和共同责任

• 使客户反馈成为每个战略的核心

在人员和技术上的投资要精巧对接

在技术、人员和决策投资方面，所有业务单元，包括董事会和 CEO，必须具有强大的战略一致性。实现成功的 DevOps 转型需要建立关键绩效指标（KPIs）来充分衡量成功，并促进更加开放和诚实的公司文化。利用数据客观地支持你的决策是推动公司文化发展的最佳方式，这种文化中权力下放、伦理、信任和耐心都受到高度重视。作为组织中的领导者，你必须为团队提供自主权、责任感和共享的责任。同时，你必须理解在所有面向解决方案的倡议中将客户放在首位的重要性，并积极寻找将客户反馈融入每个决策的方式。组织文化、领导力和流程的所有方面都应遵循这些原则。

在进行 DevOps 转型时，变革应从高层推动，同时也应从基层开始。没有自上而下的支持，文化变革是不可能实现的。然而，直到变革在最小的可能层面得到实施，它才会在整个企业中扩展。通过在团队层面实施 DevOps，团队能够展示可能性，识别障碍并克服它们，同时在问题仍然较小且可以在初始阶段管理时解决它们。有效的转型往往不是通过一次性的大规模实施来完成，而是通过持续进步的过程来实现。

在任何 DevOps 转型中，正是 DevOps 团队为一切后续工作奠定了基础，而组织领导层则充当他们的助力。每个小组在开发和发布卓越软件的潜力与他们作为团队协作的效果成正比。所有团队成员必须准备好共同工作并进行良好的沟通。为此，所有参与者，包括开发人员、测试人员、运维人员和安全专家，必须树立一种优先考虑协作以实现共同目标的心态。

虽然前沿技术显然不是有效团队合作和成功的 DevOps 转型所需的唯一因素，但它是必要的。例如，DevOps 发布经理需要像 Atlassian Jira 这样的工具来实现端到端的问题追踪，或者像 SigNoz 这样的工具来进行全面的应用监控。为了确保 CI/CD 操作的成功，所有团队成员必须能够访问能够最大化其对交付过程贡献的资源。同时，团队成员还需要像 Slack 这样的资源，以便进行直观的沟通，协同工作环境。

在组建工具和技术时，需要考虑的一个重要因素是确保实施的系统能够提供显著的自动化水平。如果缺乏全面的自动化，团队成员将不得不执行大量的手动和重复性操作。这可能会妨碍操作效率，引入错误，并导致部署环境之间的差异。一个值得注意的例子是名为 Snyk 的安全工具。它会对你的代码、开源依赖、容器镜像、基础设施即代码（IaC）配置和云环境等多个方面进行自动化漏洞测试。Snyk 还提供有价值的上下文、优先级和修复选项。自动化促进了操作的标准化，并使团队成员能够将精力集中在改进和创新上，从而提高软件质量、加快交付速度，并提升职业满足感。

成功的一个领先指标是各级商业高管能够充分理解技术及其应用者的重要性。最睿智的 CEO 们知道，他们在投资人力和技术方面所做的选择，都会对客户的繁荣以及现有和未来的商业模式产生重大影响。考虑到新技术堆栈和工具频繁进入市场，并且这种变化可能对团队成员产生影响，这可不是一项轻松的任务。简而言之，最成功的高管提供了一个全方位的商业视角，涵盖了人员、流程、信息和技术。

既然我们已经讨论了有效对齐组织的重要性，那么接下来我们来关注一个极为重要的责任——赋能你的团队。

为什么赋能、伦理、信任和耐心是高度重视的

每一个优先考虑 DevOps 发布管理的成功公司，都会由领导力推动强大的企业文化。这些文化围绕着责任感、持续学习、团队合作和实验等价值观展开。文化具有强大的影响力，通常决定了哪些人员被招聘以及他们被分配到哪些团队。在 DevOps 领域，存在着一种文化趋势，推动通过有意义的工作实现组织内的重大影响力。在这些情况下，失败不被视为损失，而是向发现正确解决方案的进程迈进。

值得注意的是，DevOps 文化的特点是显著的耐心、信任、伦理和赋能，同时对浪费、低效决策和官僚主义的容忍度较低。所有领导者必须秉持的一个基本美德是培养对新想法的开放性和尊重，无论这些想法看起来多么不拘一格。

在 DevOps 环境中的沟通

在 DevOps 环境中，成功沟通的关键是团队成员之间在各个层次上的相互尊重和信任。这要求尊重互补和对立的个性特征。每个人都应得到信任和尊重，无论他们的文化背景、个人经历、学习方式、解决问题的能力、教育或工作经历如何。当团队成员在互相支持和鼓励的氛围中一起工作时，他们会逐渐建立信任，尽管这需要一些时间。

幸运的是，团队成员通过教育和培训计划有机会相互建立尊重和信任。他们可以学习更加体谅地倾听彼此，并通过练习正念来克服人际争执。例如，员工需要感到在工作场所中受到领导的尊重和重视。如果员工看到上级没有给予同样的尊重，他们就不太可能相互以尊严对待。没有团队能够在不断指责或未能认可成员贡献的氛围中茁壮成长。必须在组织的各个层面融入相互尊重和信任的文化。

作为 DevOps 工程文化的一部分，团队必须掌控之前由其他部门处理的任务。拥有将变更推向生产环境的权限要求工程团队确保通过在流程中实施控制措施来保证测试、风险管理和升级方法的到位。从一开始，控制就必须是流程的一部分，领导层必须支持这一点。自动化是一个巨大的福音，但数字化日常繁琐、耗时的活动只是拼图的一部分。目标是重新思考控制的实施方式，使其在流程中自然发生，而不是依赖外部力量的推动，从而消除瓶颈、官僚主义和象牙塔。

公司长期以来依赖基于审计的控制框架来建立信任，目标是通过使用检查表和审计来提升质量、保证、安全、合规性和风险降低。DevOps 发布管理方法则有所不同；自动化在 DevOps 文化中发挥着至关重要的作用，帮助促进自动化流程在商业和技术领域的采用、接受和整合。在这些公司中，自动化并不被视为风险，而是作为一种战略优化方法，为职业发展和提升提供了机会。领导层可以信任产品团队通过使用自动化控制功能来关注组织范围的概念和标准。建立信任需要时间，但当团队合作并通过小规模试点展示成功后，通常会迅速实现。有了这种信任，产品团队将能够在不危及公司安全或彼此和谐的情况下，做出正确的改变。

理解为什么建立信任是成功的关键

改变企业文化是一项艰巨的任务，这也许可以解释为什么最初优先考虑自动化和监控活动会更为方便。实施 DevOps 的最大挑战之一就是改变公司文化。你必须与那些可能需要调整根深蒂固的习惯的人合作，这些习惯经过了很长时间的培养，可能跨越了几十年。或许正是这些习惯使他们取得了如今的成就，并赢得了尊重。建立一个以自主和赋能为核心的新组织文化，需要花费大量时间，尤其是通过改变习惯来实现这一点。事实上，几乎不可能预测确切的时间或完成日期。

幸运的是，大多数专业环境中的个体倾向于独立工作。他们欣赏能够做出独立选择的能力。他们有强烈的愿望提升自己的技能，并在工作中找到意义。那么，问题是：我们如何实现这一目标？你可以采取哪些步骤来确保公司文化与当代企业的需求保持一致？信任在促进你的 DevOps 转型中扮演着至关重要的角色。

在本节中，我们将讨论缺乏信任会给你的组织带来的结果。帕特里克·兰乔尼在他的书《团队的五大功能障碍》中指出，缺乏信任是众多组织问题的根本原因：

图 10.1：团队的五大功能障碍，帕特里克·兰乔尼著

例如，在Bold Ventures LLC公司，一个缺乏信任的公司中，个人往往会避免面对冲突。员工避免参与具有挑战性的讨论和决策，可能是因为害怕发声。因此，未积极参与决策过程的个人可能不会全力以赴地投入到商定的目标中。像他们决定而不是我们决定这样的说法，常常被用来强调在决策过程中缺乏积极参与。因为这是他们的选择，而不是这是我们的选择，同事们避免为自己不专注的事务负责。最终，如果员工没有参与决策过程或后续的行动，他们可能不会把公司业绩放在首位。

没有信任的组织最终会浪费宝贵的资源。尽管聘用了聪明的员工并提供了具有竞争力的薪资，Bold Ventures LLC仍然难以充分发挥整个劳动力的潜力。在前面的例子中，由于团队已完全自动化了他们的 CI/CD 流水线，因此部署非常简单且迅速。尽管高水平的自动化带来了显著的效率提升，但公司文化却禁止他们对生产系统进行任何修改，除非通过正式的审批流程。

你无法为信任定价。无论我们是否体验到信任，我们都会意识到它的存在或缺失。杜安·C·特威博士在 1993 年发表了一篇关于这一主题的开创性文章，标题为《信任的构建》。在文章中，特威博士将信任定义为“与某人或某物进行无防备互动的准备状态。”

根据特威博士的观点，构建信任只有三个主要组件：

• 信任的能力由你之前的经验对你当前准备和能力的累积影响所决定，这些能力使你能够在信任他人时承担风险。

• 能力的感知指的是你对自己和同事在当前情况下有效完成必要任务的能力的评估。

• 意图的感知指的是你能否感知到行动、言语、方向、使命和决策是否由有利于双方的原因驱动，而不是单纯为自己服务的动机驱动。

虽然信任对每个人来说都是主观的，但信任文化则关乎整个企业。DevOps 发布管理为检验特威博士的信任概念提供了一个绝佳的机会，可以发现逐步提升开发、运维及公司其他团队间信任的微小却重要的机会。要实现这一点，贵公司的文化必须具备以下特征：

• 进行清晰直接的沟通

• 增强人际互动

• 承诺履行义务

• 强调主动倾听的重要性，而非过度讲话

• 定期分享知识

• 鼓励参与和反馈

• 承认错误

• 尊重彼此的成功

成功的 DevOps 转型需要深入理解文化，并建立基于信任的组织结构。寻找其他方法，在你的组织中培养一种准备好与某人或某物进行无防备互动的状态的文化。努力通过与开发和运维团队开展开放透明的对话，增强信任、能力和意图。通过这样做，你可能会惊讶地发现，自己能够多么迅速地开始建立一个有意义和可信赖的工作环境。

DevOps 组织的领导者需要软技能

在许多领导职位中，人际管理技能常常被低估或忽视。在某些情况下，初创公司中会出现这样一种现象：选择首席技术官或工程负责人时，往往仅根据个人的资历或技术能力来做决定，而很少考虑到他们的人员管理能力或是否愿意承担此类角色。经常会出现这样的情况，DevOps 团队的领导者是根据他们在软件开发中的成就来任命的。然而，这些人往往在必要的非技术性素质上存在不足，包括有效的沟通、冲突解决和协作能力。

自然地，在 DevOps 领导层中，拥有软技能至关重要。这些技能包括批判性思维、项目管理等多种能力，并结合足够的情商。这些技能使 DevOps 领导者能够有效地激励、激发和留住由智能工程师组成的团队。为了有效领导团队，领导者必须能够辨识团队成员的优点和不足。此外，领导者还必须展现出主动倾听的能力，并具备影响他人的能力。通过这样做，领导者可以创造一个培养团队成员成长与发展的环境，从而帮助他们取得成功。在这个职位的背景下，一个显著的挑战是技术能力和人际交往能力的最佳组合，这需要在两者之间找到微妙的平衡。

遗憾的是，软技能在大多数软件工程师的培训和职业晋升中并未得到应有的重视。历史上，这些技能曾被视为可选的，而非各自职位的基本前提。随着时间的推移，软件工程公司更多地强调技术技能的获取和掌握，忽视了这些关键的沟通技能。因此，其他一些能够将软件工程师提升到更高层次的关键方面也被无意义地忽视了。具体来说，焦点常常被偏离了软技能的培养，而这些技能在培养领导能力方面起着重要作用。然而，这个问题比看起来更为复杂，因为许多雇主宣称，大多数大学毕业生在学术期间并未获得这些必备的软技能。幸运的是，在我们所处的现代社会中，关于软技能的认知已经发生了变化，尤其是在招聘新工程人才及其在组织中的重要性方面。

既然我们已经将焦点放在了所有 DevOps 领导者应具备的关键软技能上，接下来我们进一步探讨。在下一部分中，我们将探讨赋予团队成员对工作有个人责任感的价值。这需要在让团队负责的同时，也给予他们自由，让他们对自己负责。

提供团队自主权、责任感和共同责任

DevOps 领导者可以通过促进团队的责任感和培养团队合作来赋能团队。然而，关键是要认识到理解和维持每个项目适当的强度程度的重要性。为了防止精疲力尽和敌意，领导者必须具备对实际工作条件、背景以及所需战略方法的全面运营意识。领导者必须知道何时战略性地利用高强度的冲刺，何时应当克制并重新分配资源。换句话说，领导者必须在使用现有资源时做出明智的决策，并考虑到同理心。

在 DevOps 团队中培养自主性、责任感和赋能感是领导者能够为建立一个充满信任、尊重和同理心的氛围所做的最关键的工作之一。团队成员应该能够在充分的自主权下开展工作，以便能够尽可能高效和有效地完成任务。尽管这并不意味着他们可以随心所欲地做任何事情，但它意味着他们可以决定如何提供符合项目整体目标的软件。

在理想的 DevOps 组织中，团队的每个成员都参与到应用程序生命周期的每个步骤，从规划和设计到测试和部署。每个人都关心结果，并且知道他们将从应用程序的高效和快速交付中受益。例如，开发人员不应将发布工作推给运维人员，然后就此袖手旁观。从战略上讲，成功的关键是赋予团队自由和责任，让他们找到如何有效交付应用程序的方法，同时避免复杂的审批流程，避免拖慢运维进程。

随着 DevOps 团队在迈向自主性并承担更多项目责任的过程中，团队成员应逐渐培养对整体运作的高度集体责任感。在当代软件工程的背景下，领导层必须消除开发和运维之间的孤岛现象。相反，必须培养一种深刻的理解，承认这些领域的相互依赖性及其共同致力于实现最佳结果的承诺。为了实现这一点，整个团队必须深刻理解并欣赏客户需求。与此同时，他们还必须全面了解成功开发所需的技术元素。这种各方之间的相互欣赏和理解对于任何项目或事业的成功至关重要。

为了培养集体责任感，领导层需要引导团队远离指责导向的政治，而应专注于以协作努力为基础的有效问题解决和流程优化。在协作工作的框架下，团队成员必须意识到他们各自角色和任务之间错综复杂的相互依赖关系。至关重要的是，要理解在工作中任何失误或错误都可能波及整个团队，影响每个相关人员。同时，必须营造一种氛围，鼓励探索新流程和技术，质疑现有的方法论，而不是因失败的恐惧而退缩。当每个人共同承担某个特定任务的风险时，他们也同时承担了确保最佳结果的责任，同时避免敌对情绪。

既然我们已经强调了在 DevOps 团队中推动自主性、责任感和授权文化的重要性，那么接下来让我们进一步强调这个主题。在下一部分中，我们将讨论如何将客户反馈置于团队每一个行动的核心。

将客户反馈作为每个策略的核心

反馈循环在促进现代交付方面起着至关重要的作用。为了建立消费者与 DevOps 发布管理之间的连接，您应该优先考虑用户交付需求，通过增强并缩短反馈循环的时长来优化这一过程。每个 DevOps 流程都应力求实现更快速的响应时间和不间断的发布周期，这些都应由用户需求和使用模式驱动。利用反馈循环将增强您的数据驱动决策过程，使您能够在准确性和快速适应更广泛的事件、因素及需求方面达到前所未有的水平。在这种新的反馈循环驱动的分析背景下，勇于探索和好奇的人将成为创造价值的领导者。

什么是反馈循环？

系统思维的一个基本原则以及贵公司成功的关键组成部分是理解并正确应用 DevOps 反馈循环。作为领导者和 DevOps 专家，您的主要目标应是尽可能减少开发和 IT 流程之间的摩擦。然而，理解反馈循环对公司流程的影响是促进这两个业务组之间积极合作的第一步。尽管如此，在 DevOps 领域中，反馈循环是一个常被误解的概念。什么是反馈循环，它是如何运作的？

根据《美国遗产词典》，反馈可以描述为“将部分输出返回到过程或系统的输入，尤其是用来保持性能或控制系统或过程的作用。”（《美国遗产词典》条目：反馈）。另一方面，循环被描述为“某物具有形状、顺序或运动路径，并且是圆形或弯曲回自身的。”（《美国遗产词典》条目：循环）。因此，反馈循环被定义为“控制系统中允许反馈和自我修正的部分，并根据实际输出和期望或最佳输出之间的差异调整其操作。”（《美国遗产词典》条目：反馈循环）。这个定义是通过结合这两个概念得出的。简单来说，反馈循环是对团队、系统和用户功能的自我评估，衡量标准包括定性和定量分析。

行业内部人士和 IT 大咖一致认为，反馈循环有助于保持对优先事项和项目目标的关注，确保开发过程保持正轨，不偏离目标。将之前提到的两个 DevOps 业务领域联系起来，就是这个框架的唯一目的。实现一个流程，其中一个单元的变化触发另一个单元的变化，进而又触发第一个单元的变化，实际上就是这个目标的实现。正因如此，企业可以快速而准确地以数据驱动的方式做出所需的调整。在信息技术领域，利用反馈循环收集数据并建立持续的信息流将带来大规模的有意义增长。

你可以将客户反馈循环分为四个不同的组件：

• 收集客户反馈

• 分析客户反馈数据

• 应用反馈并以此为测试的起点

• 保持客户关系并收集后续反馈

实施 DevOps 反馈循环的一个重要理由是有效地弥合软件功能与客户期望之间常常存在的鸿沟。在这种背景下，反馈循环可以定义为最大化变更效果的系统化方法。接下来，我们将讨论一些实际的技巧，帮助你收集客户反馈，并将其纳入决策过程。

以 DevOps 方式收集客户反馈

客户支持与 DevOps 的融合已经成为思维方式的一个关键变化，由于其独特的复杂性，这要求在客户支持领导力方面采用全新的方法。换句话说，客户支持与 DevOps 的融合是卓越成果的催化剂。重点不再单纯是产品的快速开发和部署，而是确保其持续的最佳性能并提供卓越的客户体验。这不仅仅是解决问题，更是采取主动措施，确保客户体验始终保持出色，尤其是在快速发展的技术面前。

历史上，客户支持曾被认为是一种应急响应，主要是在问题发生后进行干预。然而，DevOps 发布管理的出现彻底改变了这种关系。如今，客户支持的角色包括主动确保可用性、稳定性、沟通和性能。它涉及到在问题发生之前预测潜在问题和障碍，并能够无缝适应当代企业不断变化的环境。客户希望获得无缝的全渠道体验，能够通过公司的网站、聊天机器人、实时聊天、互动语音应答、人工语音客服、电子邮件、短信、应用内嵌入或其他通信渠道，甚至可能是所有这些渠道与公司进行互动。客户希望获得流畅且不中断的体验，其中每个通信渠道都能了解他们的情况和过去的互动，免去他们重复陈述个人信息和问题的麻烦。

建立跨孤立通道的连接并在这些通道之间传输客户端数据所需的技术框架相当复杂。例如，互动语音应答（IVR）通道不仅需要一个 IVR 语音门户，还需要 VoiceXML 应用程序、语音识别、文本转语音以及 IP 电话。要在 IVR 系统和其他通道之间建立连接，通常需要将其与客户关系管理（CRM）系统、用于屏幕弹出功能的计算机电话集成（CTI）系统、电子商务应用程序以及其他相关组件连接，这些组件通常都托管在云端。尤其是 IVR，常常依赖于过时的技术，这些技术脆弱且容易损坏。将过时的技术与不同的通信平台集成是一项巨大的挑战。

然而，在 DevOps 环境中，开发和运维之间的无缝集成使得客户支持的性质发生了显著变化。如今，客户支持在产品生命周期的每个阶段都扮演着至关重要的角色，包括开发、部署及其后续阶段。DevOps 与客户支持常常使用不同的术语进行沟通。开发人员讨论 CI/CD 的概念，而支持团队则关注服务级别协议（SLAs）和客户满意度。客户支持主管有责任充当中介，将技术术语转化为以客户需求和偏好为中心的语言。通过培养互相理解的文化，可以确保 DevOps 的决策与客户需求保持一致。

服务级别协议（SLAs）

服务水平协议（SLA）是一个合同，概述了服务提供商和客户之间的责任和期望。服务提供商和服务用户就服务的具体方面达成一致，例如质量、可用性和责任。SLA 最重要的方面是确保服务按合同条款交付给客户。

为了实现这一目标，DevOps 环境中的客户支持领导力不仅需要深入的技术知识，还需要其他技能。对人性化部分的深刻理解对这一点至关重要。当对客户和团队成员都充满同情心时，就能培养出一种信任与协作的文化。这是关于赋予人们对自己行为负责并提出创新解决方案的能力。这要求视角的转变，心态的变化，以及现有最佳实践的重新调整。

正如反复提到的，自动化是围绕 DevOps 环境中效率的基石。除了适用于开发和运营外，这也适用于客户支持。然而，必须在客户支持操作的背景下，深思熟虑地实施自动化。不可否认，自动化通常用于处理常规操作和收集数据，之后你可以利用这些数据帮助团队专注于更复杂的问题和高影响的活动，例如为客户提供个性化和富有同情心的帮助。记住，在现代社会中，人性化的接触非常重要。

通过实施自动化监控和警报系统，你可以在问题影响消费者之前发现问题。应为客户提供自助服务选项，定期操作应自动化，事件管理应简化。目标是预见客户的需求，并在客户甚至还未意识到之前满足这些需求。

将客户反馈纳入决策过程

利用度量和实时监控来获取有关客户体验的宝贵见解。客户满意度（CSAT）、平均解决时间（MTTR）和净推荐值（NPS）是应评估的重要绩效指标。通过采用数据驱动的方法，你不仅可以评估绩效，还能确保每个决策都有实际结果的支持，并且重要的指标能够指导持续改进。

与之前的其他方法相比，DevOps 发布管理最显著的特点之一是它能够结合消费者的反馈以及将其他系统（如监控系统）整合到价值链中的能力，这使得它在行业中创造了一个独特的定位。收集到的反馈有助于弥合软件功能与客户期望之间的差距。除此之外，它还提供了关于如何提高产品构建质量和功能集的有益见解，这最终将改善其实用性、可靠性，最终提升公司业绩。

值得注意的是，反馈循环在持续测试的过程中尤其重要。为了正确进行持续测试，仅仅生成自动化测试是不够的。更重要的方面是测试结果的可见性以及如何利用这些结果来改进当前的流程。为此，有必要在软件开发生命周期的不同阶段收集有关应用程序性能的详细反馈，从开发阶段开始，一直到生产后阶段。有效地实施反馈机制对于获取全面和详细的反馈至关重要。

因此，反馈循环使得产品最终用户如何使用它的假设与仔细改进现有工作流程以更好地满足终端用户需求的过程有所区别。利用大量可用的数据来推动重要的转型。持续审视这些数据，寻找模式并确定可能的提升产品和服务的机会。这不仅仅是解决问题，更是关于提升整体客户体验。

摘要

本章结束于第十章。到此为止，你已经理解为什么在以 DevOps 为中心的组织中，授权、伦理、信任和耐心被高度重视。同时，你也明白了在人员和技术上进行精准投资的重要性。你还理解了在公司 DevOps 旅程中，给予团队自主权、责任感和共同责任的重要性。最后，你知道为什么将客户反馈作为业务战略的核心至关重要。

虽然每个企业没有通用的解决方案，但优先考虑 DevOps 的高管们会利用必要的组织变革，重新评估结构、人员配置、成功的衡量标准，以及团队成员之间的任务和责任分配。即使是一些基本的领域，比如商业流程的专业知识、商业财务，以及像自动化工程、站点可靠性工程、流程负责人和产品经理等新兴角色，在一个以 DevOps 为中心的高度训练组织中也变得无处不在。除了许多有效领导者在其领导下的组织中培养的其他实质性特征外，本章讨论的这些特质通常出现在最成功的领导者身上。在高层决策领域，每个领导职位的人都必须明确他们的目标，并随后识别出最适合的 DevOps 策略来实现这些目标。

在接下来的最后一章，我们将探讨如何克服 DevOps 发布经理今天面临的最常见陷阱。我们将讨论如果没有一个深思熟虑的变更管理过程，可能带来的后果，为什么不遵循发布检查清单是不可取的，以及 DevOps 发布管理中的十大常见陷阱。

问题

请回答以下问题，测试你对本章内容的理解：

1. 建立一个强大的 DevOps 文化需要什么？

2. 在尝试仅基于什么来实施 DevOps 时，领导层需要保持谨慎？

3. 在任何 DevOps 企业中，哪些特质被高度重视？

4. 最成功的高管在一个以 DevOps 为中心的组织中提供了什么？

5. 技术领导者和工程师常常忽视哪些具体技能？

6. 在理想的 DevOps 组织中，团队的每个成员都参与什么？

7. 为了促进集体责任感，领导层需要做什么？

8. 什么是反馈循环？

9. 每个 DevOps 领导者应该在决策过程中纳入哪种反馈？

10. 反馈循环是什么将关于产品最终用户如何使用它的假设与什么区分开来？

第十一章：克服 DevOps 发布管理中的常见陷阱

关于 DevOps 发布管理方法，存在一种广泛的误解。事实上，一种解决方案可能对某个特定客户有效，但对另一个客户可能并不理想。每个解决方案都必须与组织独特的文化、工作方式和软件发布目标相契合。如果你观察足够多的以 DevOps 为核心的组织，你会发现它们在运营过程中会遇到几个常见的陷阱。大多数组织最终会浪费大量的时间和金钱，在不断的试错过程中艰难地调整他们的 DevOps 策略。尽管这是 DevOps 之旅中常常不可避免的一部分，但让我们探讨一些可以帮助你规避这些成长的烦恼的方法，从而带领你的组织成为下一个成功案例。

在第十章中，你将学习以下主题：

• 拥有精心设计的变更管理流程

• 遵循发布清单

• 探索 DevOps 发布管理的 10 个常见陷阱

拥有精心设计的变更管理流程

变革管理策略是一种有意识的方法，它使领导者能够有效地引导公司度过变革，同时减少干扰和预料之外的结果。

尽管目标可能涉及改变组织，但在大多数情况下，实现成功的关键因素是能够有效地引导个体度过变化过程的能力。当现有的商业计划无法继续为组织的成功做出贡献时，企业通常会追求变革。创新的做法是提升利润率并在动态的企业环境中保持竞争力所必需的。根据组织的长期目标，每个变革项目都有其独特的特点。效率、绩效以及更优流程的发展可能是你变革项目的重点。创新可以是渐进式的，例如为现有产品添加新功能，或者是革命性的，例如开发一整条新的产品线。

无论变革规模多小或多大，你的员工和公司流程都可能会经历一定程度的干扰。即使是最具善意和必要的改革，也可能带来意外的后果。随着变革的规模和复杂性的增加，方法论策略的必要性也随之增长，相关的风险也随之加大。因此，拥有一种系统化的变革方法，并引导员工顺利度过变革过程，是至关重要的。

没有精心设计的变更管理方法是一个常见的错误。没有变更建议委员会或某种变更控制委员会，任何发布管理计划都无法算完整。它们主要负责帮助公司进行客观的风险和影响评估。当它们相互配合时，有助于发现部署过程中可能未被发现的技术依赖关系。建立一致的处理项目变更请求的程序，并跟踪其批准和实施，将极大地促进变更管理流程的发展。建议贵组织实施标准化的变更提案和变更 管理日志：

• 变更提案概述了所提议变更的性质和规模，作为变更管理程序的初始阶段。在启动变更提案时，需提供对变更背后理由、预期结果和影响、所需时间和资源以及任何其他需要评估的因素的全面分析。贵组织的变更提案文档应提供额外空间，以便包含描述性细节，并设置专门的部分来计算费用和记录预期的收益。

• 变更管理日志是记录特定修改的发起人、请求的日期和时间、变更请求的当前状态、其重要性等级及解决细节的书面记录。为了获得更全面的记录，建议加入修改的性质和后果等额外细节。保持详细的变更管理日志的其他原因是为了便于组织和检索关键数据，从而有效地优先处理、解决问题，并为未来参考以前的变更请求提供便利。

有效地管理变更不仅仅是创建并传达一个有说服力的愿景。它不仅仅依赖于拥有一个明确定义的变更模型。组织变更的失败往往归因于高级管理人员和变更领导者对员工心理和组织文化的理解不足，而非变更过程本身。

接下来将介绍四个导致变更管理计划失败的严重因素，并提供基于数据的建议以解决这些问题。

员工必须理解变更管理计划的理由。

在开始任何组织变革之前，必须彻底审视促使这种变革的潜在原因。回答这个问题应该是简单的；你只需要解释组织转型背后的原因以及员工参与转型的必要性。令人惊讶的是，许多员工对领导和雇主引入的管理举措背后的动机不清楚。

平均而言，在任何组织中，只有 1/6 的员工能够理解其组织战略背后的理由。换句话说，根据这一统计数据，85%的员工不清楚为何会发生变化，这些变化的意义是什么，或者自己参与的意义是什么。从这个角度来看，这种情况令人震惊，但如果你在自己所在的组织中进行类似调查，结果很可能会得出相似的结论。值得注意的是，这些变革举措的主题涉及多个领域，如经济学、市场、竞争因素等。关键是：通常，未能理解其组织战略背后目标的人远多于那些始终或经常理解的人。让我们改变这一点！

如果没有理解组织变革管理背后的基本原因，个人就不会倾向于改变自己的行为。如果一家公司表面上看起来蒸蒸日上，大多数理性的人可能会觉得没有理由进行任何形式的变革。然而，最糟糕的是，大多数高层管理者并不是随意启动新的变革举措。组织变革管理是大多数领导者经过深思熟虑的事情，可能已经考虑了几个月。

高管们可能一直在关注市场动态、跟踪前沿技术的发展，或留意行业会议上的重大进展。几个月以来，大多数高管已经在思考变革管理举措的为何，无论细节如何。然而，在宣布新的变革举措时，许多高管往往忽视了传达他们在经过的认知过程，这一过程使他们认识到组织内变革的必要性。

虽然领导者可能会记下一些笔记或做一个简短的报告来概述他们的想法，但很少有这些文件能够反映出背后几个月的深思熟虑、探究和竞争性研究。因此，现有的变革管理活动往往没有被普通员工很好地理解。坦率地说，大多数变革管理过程过于强调描绘变革努力的未来目标状态，而对实现这一目标所需的变革管理过程的理由却关注得不够。

每个组织变革计划的成功取决于你能否清晰简洁地阐述其背后的理由，直到最微小的细节。

高层管理人员通常在舒适区之外运作，而其他人则…

高层管理人员与普通人有什么不同？大多数人可能会说是因为他们的工作和个人生活之间缺乏平衡；也许是因为他们更有雄心、更聪明，或者更幸运。事实是，在大多数情况下，原因并不在于这些。相反，这是一种风险容忍度与变革准备度的结合。本质上，典型的首席执行官（CEO）是变革的热情推动者，而正是这种勇气定义了他们的个性。

对人性有一定了解的人不会感到惊讶的是，少于三分之一的人愿意承担具有挑战性或大胆的变革。一般来说，人们倾向于避免变革，或者做出小的变革，这些变革带来的影响也较小。总共有 45%的高层管理人员做出了别人认为大胆或有远见的变革。相反，只有 27%的一线员工属于这一类别。也就是说，与一线员工相比，首席执行官更有可能发起大胆的变革行动，比例高出 66%。

个人在公司中的层级地位与其参与大胆和冒险计划的倾向之间存在明确且强烈的相关性。直接与客户打交道的员工和管理者更倾向于保持现状，即便他们接受变革，也会更加谨慎。在引领变革时，执行官往往是敢于冒险的人，他们受到不确定性、大梦想和激烈行动的驱动。雄心勃勃的人在动态环境中表现最佳。一般来说，他们喜欢承担重大任务，并乐于开创新的方法。这使得他们比组织中的普通员工更热衷于变革管理。

这个观点对每一种变革管理方法都至关重要。如果组织的高层领导是变革倡议的发起人，他们更有可能支持变革工作或计划。然而，需要注意的是，CEO 或变革经理可能缺乏认识到他们的视角与那些直接与客户和其他一线工作人员打交道的绝大多数人的视角有很大不同。简而言之，高层管理人员更可能对担任变革经理的角色感兴趣，而那些在一线工作的员工则更倾向于满足于现状。

领导者没有坦诚面对他们所面临的困难

变革管理的一个显著特点是，在经历失败的公司中实施变革相对更容易，而在已经成功的公司中则更加困难。原因很简单：对于一个陷入困境的公司来说，按部就班已经不是一种选择。当一个公司显然正在失败时，为什么还要继续以相同的方式运营？或许，讽刺的是，变革领导者喜欢与那些有强烈紧迫感的功能失调公司打交道。

然而，在繁荣的组织中，当员工已经取得成功时，询问实施组织变革的理由是合理的。对于外行人来说，当一个组织已经取得显著成功时，质疑为何需要变革管理计划似乎是合理的。毫无疑问，即使是最繁荣的公司也会遇到障碍；没有任何公司是完美无缺的。问题出现在领导者不愿意就他们所面临的困难以及这些障碍如何影响业务进行公开和诚实的讨论时。

只有 35%的 CEO 会持续或定期沟通他们所面临的挑战，而且随着问题的严重性增加，这一比例会更高。这表明，大约 66%的领导者忽视了在变革管理过程中公开沟通挑战这一至关重要的做法。选择渐进性变革管理方法的领导者相比选择革命性方法的领导者，更不倾向于公开沟通困难。渐进的变化倾向使得他们减少了广泛讨论公司问题的可能性。

另一方面，也有领导者在错误的信念下行事，认为如果他们讨论组织面临的困难，那么他们会被认为是悲观或消极的。然而，这完全是错误的。公开讨论困难并不是一件负面的事情；这只是诚实和坦率的表现。员工对展现出这一特质的领导者有着相当大的敬佩。

成功的变革举措需要一个强有力的推动力；没有强有力的理由，任何组织都不会进行转型。如果公司积极寻求实现转型变革，那么对于一个具有挑战性的推动力的需求将变得更加重要。有效的变革管理模型强调，当组织面临必须解决的重大问题时，变革将进展得更快、更顺利。然而，如果你提出的变革与具体、紧迫且可触及的问题没有直接联系，你应该预期会遇到强烈的反对。

员工的气质对变革具有抵触情绪

组织文化，包括员工个性，是一个很少被讨论的成功组织变革的预测因素。

在职场动态中，有五个主要的驱动力促使个体采取行动：成就、权力、归属、安全和冒险。这五种驱动力在塑造和影响职场中的人类行为方面起着至关重要的作用。研究表明，约 33%的员工具有较强的归属动机。此外，另外 20%的参与者表现出显著的安全动机倾向。

由归属动机驱动的个体寻求与他人的积极关系和接纳。这些人倾向于选择有较多个人互动的工作，注重团队合作，并在团队中表现出色。问题出现在组织实施突然的变革时，这让人感到不舒服，导致归属关系的解体、关键团队成员的离开，以及曾经紧密团结的团队分崩离析。如果将归属动机的个体纳入变革咨询委员会，他们可能更容易从反对者转变为关键利益相关者。然而，安全动机驱动的个体寻求在工作、任务和薪酬方面的稳定性和可靠性。他们看重保障，倾向于长时间留在同一公司、职位或部门。高安全感的个体在面对变革时经常感到焦虑，他们不倾向于接受转型性、极具破坏性或颠覆性的变革。

在某些情况下，值得注意的是，并非所有公司都拥有以安全感和归属感为驱动力的大量员工。相反，也有一些组织由那些追求冒险并成为公司内部变革催化剂的个体组成。对于那些注重社会文化并优先考虑一致性和可预测性的公司来说，转型变革过程可能特别具有破坏性。如果公司的主要利益相关者主要受安全感和归属感的驱动，那么这种情况可能会带来重大挑战。

你可能在想，如何判断你的企业文化是否以归属感和安全感为驱动。观察一下那些似乎能激励员工的因素。如果他们非常重视团队合作、与同事保持社会关系并且喜欢花很多时间面对面交流，那么他们很可能有强烈的归属感驱动力。如果他们在行动之前倾向于深思熟虑，当面临模糊不清的情况时感到焦虑，并且偏好那些定义清晰的工作和项目，那么他们很可能具有较强的安全感驱动力。

现在我们已经讨论了为什么设计周密的变更管理流程如此重要，接下来让我们进一步展开这个主题。在接下来的部分，我们将讨论遵循软件发布清单的重要性。结合这两种策略，可以确保你保持组织性，并且能够充分传达你的团队为整个组织带来的价值。

遵循发布清单

发布管理中常见的挑战之一是遵循发布清单，这是一个常被忽视的重要任务。发布清单中的信息至关重要；一些示例包括：确保所有组件已准确标记为发布，已建立清晰的回滚计划，并且用户文档已更新。为了你的便利，本书的附录中包含了详细的发布清单作为参考。作为发布经理，即使你在某天工作效率不高或在产品创建过程中受到干扰，发布清单依然是一个可靠的信息来源，帮助你保持专注并确保进度。

为确保最佳的用户体验（UX），必须在每个发布检查清单中加入相关问题。这样可以确保每次发布都能为最终用户的体验提供卓越的价值。确保软件产品准备好发布的一个好方法是，确保发布检查清单中包含发布前和发布后的活动。这应包括发布前的最终审查、测试和发布包创建，发布后的任务则包括更新文档、通知最终用户以及监控应用程序性能。在 DevOps 的背景下，软件发布检查清单通过确保每次发布都经过充分测试，从而通过可靠的流水线验证其最佳可行性，加速了产品交付的过程。

在发布新软件应用程序时，显而易见，有许多因素需要仔细考虑。最重要的是要记住，这些问题以及评估每次发布的标准是完全主观的。为了有效地应对不同的环境，构建一个全面的问题集非常重要。这些问题将作为获取与每个特定环境相关的必要信息和洞察的宝贵工具。通过遵循满足每个独特产品或业务需求的定制化检查清单，可以实现成功的发布。严格遵循检查清单，软件发布可以迅速完成，且避免昂贵的错误或延误。

然而，需要注意的是，任何完整的最终标准清单必须包括发布的各个方面，特别是性能、安全性和可用性。永远不要忘记，做得彻底总比草率行事好。在发布软件之前，确保其符合您的检查清单中列出的行业标准。当您完成整个项目后，您不希望意识到在过程中忽视了某个问题。您的用户会非常感激您这样做。

最后，为了保证顺利的发布周期，有必要确定支持团队是否了解任何可能导致最终用户困惑的功能。一个熟练的支持团队对于任何产品的实施都至关重要，软件也不例外。如果支持人员接受了充分的培训，并且对应用程序的功能有全面的理解，那么客户遇到的挑战的频率和严重性将大大降低。通用的回应很少能令客户满意，因此应计划在所有可用机会中为每位客户提供个性化支持。

确保他们能够访问尽可能多的相关信息，以为他们的成功提供支持。这不仅能确保发布周期的顺利进行，还能防止工程师和产品经理在未来处理重复性的问题。一个很好的做法是从发布清单本身提取支持材料；这能确保你的支持文档和发布过程一样全面。通过这样做，你可以优化流程，确保开发团队和客户以最小的努力获得他们需要的信息。为了改进这一过程，定义软件发布的关键元素是非常有帮助的。

成功的发布远远不止是遵循清单

软件发布清单可以定义为一个精心组织的任务和项目的汇编，开发和运维团队遵循这些项目以确保软件产品的顺利发布。该清单充当了一个详尽的手册，涵盖了软件开发生命周期（SDLC）的各个方面。从本质上讲，它作为导航指南的替代品，帮助团队通过受控和高效的方法应对软件部署的复杂性。

然而，关于软件发布清单，有一个相当重要的警告：它到底是什么，它应该如何使用，以及不应该如何使用。清单本质上只是一种组织你本来就应该采取的行动的方式！明确一点，发布清单应该跟随你正在执行的工作，而不是引导它。关键点是，你必须避免成为一个专注于勾选框而非创新和优化的组织。否则，你的运营将变得枯燥、停滞、缺乏创意且缺乏竞争力。

为了避免成为一个“勾选清单”的组织，你的软件发布清单必须是团队共同努力的产物，涉及多方人员。软件工程师、质量保证（QA）专家、系统管理员和项目经理都是团队中必不可少的成员。为了确保发布清单全面且有用，每个团队成员必须贡献自己独特的观点和看法。

接下来是一个列出了九个至关重要的活动的清单，这些活动是你的软件开发团队应该一直在进行的。值得注意的是，这些项目应当在你的发布清单中有所体现。

代码审查与 QA

从全面分析你的代码开始制作清单。代码审查是防止潜在问题的主要手段。它们能够捕捉软件缺陷、提高代码质量，并确保遵循编码标准。通过实施 QA 程序，代码审查为强大的发布奠定了基础。实际上，遵守代码标准并使用版本控制系统（VCS）是良好编码实践的重要组成部分。

功能测试的目的是确保所有功能和能力按预期执行。无论是自动化测试还是人工测试，功能测试都能确保你的产品满足所有标准，并提供积极的用户体验。换句话说，这是确保你的软件按预期运行的最后机会。功能测试清单通常确保每个功能都经过规格验证，测试所有用户交互，并验证错误处理和恢复方法。

用户界面和 UX 测试

留下好印象很重要，而用户界面（UI）和 UX 测试能帮助你在软件中做到这一点。用户幸福感的一个重要因素是具有吸引力和易于使用的设计。探索 UI/UX 测试如何改善软件的视觉吸引力和可用性。一般来说，在测试 UI 或 UX 时，你应该关注设计组件是否一致，导航是否简便，以及在不同设备上的响应性如何。

在软件开发中，UI/UX 设计阶段通常包括几个关键阶段。与后台软件开发和 SDLC 类似，UI/UX 开发通常也包含类似的概念，如前期设计阶段和设计研究阶段，以及初步草图、线框图、可视化和切图。如果这些 UI/UX 项目与你的项目相关，确保将其列入发布清单。

兼容性测试

如果你在多种设备、操作系统和浏览器上进行测试，你的程序将始终按预期工作。了解兼容性测试的各个方面，并理解为什么它对吸引更多用户使用你的产品和品牌如此重要。作为兼容性测试过程的一部分，你应该评估应用程序在各种设备上的表现，如笔记本电脑、台式机和移动设备，也要评估它在操作系统上的表现，如 Linux、macOS 和 Windows。别忘了还要在四大主流浏览器（Chrome、Firefox、Safari 和 Edge）上测试你的 Web 应用程序。显然，这些项目都应该包括在发布清单中，以确保顺利发布和满意的客户。

安全性测试

保护用户数据并确保程序的完整性至关重要。安全测试能够发现缺陷和弱点，保护你的程序免受潜在的网络威胁和数据泄露。通过分析安全测试的各个方面，了解它如何帮助你赢得客户的信任。进行渗透测试、验证数据加密算法，并确保安全的身份验证和授权过程，这些都是安全测试的一部分。发布检查单中一定不要遗漏这些内容，也不要忘记包括你自己独特的安全需求。

回归测试

确保近期的修改没有对现有功能产生不良影响。回归测试是一种检测和解决变更意外副作用的过程，确保软件的整体稳定性。了解回归测试作为软件发布保护措施的作用。你的回归测试检查单应包括评估项目，如测试用例、自动化重复测试场景，以及验证与早期版本的向后兼容性。

文档审查

开发人员和最终用户都必须拥有完整且最新的文档。确保你的文档准确地反映了最新的修改和功能。考虑文档在确保用户体验尽可能无缝中的重要性。文档和审查过程应遵循最佳实践，包括保持版本化文档、提供清晰简明的说明，以及在每次发布时更新文档。将这些内容也包括在你的发布检查单中。

部署准备

在准备部署时，你应确保基础设施、服务器和数据库都已准备好与新版本良好兼容。这个阶段能够确保平稳过渡，减少停机时间。理解部署准备的复杂性及其在成功发布中的作用非常重要。验证服务器和基础设施设置、检查数据备份和恢复过程，以及在低流量时段规划部署，都是部署准备检查单上的重要内容。

回滚计划

随时准备好备份计划。在发布后出现问题时，必须有明确的方法将更改回滚到以前的状态。这样，一旦需要回滚到早期版本，你可以轻松实现。了解如何制定一个可靠的回滚计划，并明白它为何是任何发布策略中不可或缺的一部分。回滚计划的标准组成部分包括与利益相关者的沟通策略、在模拟环境中测试回滚过程，以及识别关键回滚检查点。在灾难恢复（DR）事件中保持回滚策略有效的最佳方法是为其创建一个检查清单。

性能测试

性能测试是你发布检查清单中不可或缺的一部分。确保你的软件在不牺牲速度或功能的情况下，能够应对预期的负载是此步骤的目标，这需要评估软件在各种场景下的表现。如果性能问题得不到解决，你的品牌声誉、用户满意度和可用性都会面临风险。

性能测试的重要性有很多原因。首先，用户满意度至关重要。一个缓慢或不可靠的系统会让用户感到沮丧，进而对你的软件产生负面看法。性能测试还可以帮助识别潜在的瓶颈，防止在高峰期出现意外崩溃，并确保业务连续性（BC）。更重要的是，在开发过程中解决性能问题比在发布后处理它们更具成本效益。

评估软件应用性能的方法包括以下几种：

• 负载测试：软件在轻负载和重负载下的响应能力，以确保它能够处理预期的用户量

• 可扩展性测试：验证软件在应对增加的负载需求时的可扩展性，确保无论用户数量多少，软件都能高效运行

• 峰值测试：检查系统在用户流量急剧激增或波动时的响应方式

• 耐力测试：确定系统是否能够在长时间内保持稳定，并评估其在持续负载下的表现

• 并发测试：分析软件在多个并发用户同时进行处理时的响应能力和性能

当你在软件部署的复杂环境中航行时，你会发现一份全面的软件发布检查清单是你最好的朋友。尽管清单上的每一项都有助于你发布的整体成功，但性能测试作为确保用户满意并让你的产品长期保持良好状态的关键环节，尤为突出。将这些方法纳入你的性能测试策略中，将提升软件的整体成功和可靠性，同时改善用户体验（UX）。

采用系统化的方法来完成软件发布清单，为无错误、高效且无缝的发布打下基础。在下一部分，我们将讨论 DevOps 发布管理中的十大陷阱。通过学习他人所经历的困难，你将能够顺利踏上掌握 DevOps 发布管理的道路。

探索 DevOps 发布管理中的十大常见陷阱

DevOps 发布管理是一种具有变革意义的方法。几乎所有行业的企业都越来越普遍地实施 DevOps，以为团队提供完成更具挑战性任务所需的时间和自主权。采用 DevOps 发布管理策略可以激励你的工程团队，并将产品开发工作引导到更好地满足客户需求的方向。另一方面，每当你采用一种新技术时，总会有可能面临重大挑战。

每当你尝试改变业务的基本性质时，问题和障碍是不可避免的。每一次转向 DevOps 都会带来一系列独特的挑战，团队必须克服。关于变革，很难预测并规避可能出现的每一个潜在挑战。然而，本章旨在为你提供应对 DevOps 发布管理中最常见陷阱的必要知识，并为解决这些问题提供有效的策略。在考虑实施 DevOps 实践时，必须具备对涉及元素的充分了解以及有效优先排序的直觉。与任何 DevOps 发布管理的实施一样，组织必须始终将人的因素置于首位，其次是流程，最后是技术。

缺乏领导层支持

大多数高管都有过未能成功引导组织进行与组织文化相悖的变革倡议的经历。虽然这可能听起来令人惊讶，但事实是，超过三分之二的所有组织变革倡议都以失败告终。

当努力试图颠覆整个现有的企业文化时，失败率显著增加。看到其中四分之三的尝试以失败告终并不奇怪。对于组织而言，文化是根深蒂固的，并随着时间的推移在一代代员工的更替中延续。改变一个组织的文化并不是改变组织的第一步，而是最后一步。

拥抱 DevOps 动态

从事 DevOps 转型的领导者必须深入理解该方法论的独特动态。将 DevOps 实施到组织中是一个复杂的过程，涉及的内容不仅仅是采用新的技术实践和工具。正如 Gene Kim 在《凤凰项目》中解释的那样，采纳《三大原则》的组织会获得显著的优势，这使得成功的可能性更大。我们在第五章中讨论过，这意味着从一个孤立部门的文化转向一种注重效率和适应性的思维方式，重点是持续创造和交付价值。

历史告诉我们，文化变革一直是采用 DevOps 发布管理实践的一个重要障碍。它已成为许多组织在进行这种转型时阻碍 DevOps 采用的主要原因。关于文化转型挑战的研究广度导致了一个明确的观察结论：采纳 DevOps 方法论本身就伴随着较大的风险，并且容易遭遇潜在的挫折。

一种可能的解决方案是保持现状，避免迈向文化转型的艰难旅程，而这通常伴随着 DevOps 计划的实施。上述策略所面临的问题在于，DevOps 的涵盖范围远远超出了仅作为一种适用于技术人员的方法论或框架。在当代社会，组织面临着持续不断的内部和外部影响，这些影响有可能在大范围内塑造其文化。这些影响因素包括新竞争者带来的市场颠覆、全球经济波动、地缘政治不稳定、货币波动、劳动力人口结构的变化以及技术的迅猛发展等。这些力量既为组织带来了有利的前景，也可能带来挑战。

在这种特定背景下，迅速适应和创新的能力已经成为一种基本的组织资产。当成功实施 DevOps 时，会在系统开发过程、技术和文化方面带来丰硕的成果。这些变化对促进组织敏捷性至关重要，而敏捷性又使得企业能够在当今动态市场中获得竞争优势。上述因素使得将产品或服务推向市场所需的时间减少，减少了浪费性的活动，提高了整体质量，并引入了新颖和革命性的产品与服务。

在启动 DevOps 举措时，领导者和变革推动者面临的固有困难，是如何找到克服这些障碍的途径，并在采用 DevOps 原则、方法和文化时，战略性地提升成功的可能性。

高效的领导力至关重要

成功应对与文化变革相关的障碍，在于企业高层领导所采取的领导方法。

你的初步目标应该是深入了解导致大多数组织变革举措失败的关键因素。大量研究指出，多种变量导致了在各种场景中次优结果的出现。这些变量包括不充分的规划、对变革的制度性抵抗、低效的沟通和不切实际的期望。最主要的考虑因素通常与公司成员对变革的反应方式密切相关。按顺序列出的三项最高优先级的因素如下：

1. 对变革的抵抗：指的是个人或团体对采纳新想法、新技术或新流程的自然倾向，通常表现为怀疑、恐惧或维持现状的愿望。

2. 低变革准备度：指的是个人或组织对于接受和适应新思想、新流程或新技术的抗拒或缺乏准备的状态。这种准备不足可能会妨碍进展和创新，因为它为实施必要的变革设置了障碍，可能源自各种因素。

3. 员工参与度低：指的是员工未能充分参与、激励或投入到工作中。这种参与度不足可能对员工和整个组织产生负面影响，导致生产力下降。

拥有这种新的理解后，重要的是开始探索提升组织内部个人有效适应和接受变革能力的策略。大量的日常观察表明，领导者如何行使领导职能、与他人互动，极大地影响了员工对变革的反应——是否友好。

在过去近四十年里，有关成功领导行为的文献一直围绕着变革型领导理论展开，该理论由詹姆斯·麦格雷戈·伯恩斯（James McGregor Burns）首创。关于这一主题的学术出版物数量，远超历史上任何其他替代领导理论的出版物数量。根据伯恩斯和其他学者如詹姆斯·维克托·唐顿（James Victor Downton）的研究，成功的变革型领导者具有以下四个主要特征：

• 智力激励：除了质疑现状，变革型领导者还激励追随者创新。领导者鼓励人们探索新的方法和教育机会。

• 个性化关怀：变革型领导力是一种领导风格，涵盖了对个别追随者提供支持和鼓励的行为。变革型领导者优先建立支持性关系，通过保持开放的沟通渠道，鼓励追随者自由表达他们的想法，并使领导者能够及时确认和欣赏每个追随者的独特贡献。

• 鼓舞人心的激励：变革型领导者拥有明确的愿景，并能够有效地传达给他们的追随者。领导者有能力激励并鼓舞追随者，培养共同的激情和动力，以实现共同的目标。

• 理想化影响力：在领导力的背景下，变革型领导者承担着作为其追随者榜样的责任。追随者表现出对领导者的信任和尊敬，这使他们模仿领导者的行为，并将领导者的价值观视为自己的：

图 11.1：变革型领导力的四个关键原则

对于负责当前和未来 DevOps 转型的公司高层管理人员，额外的研究显示了两个关键结论。首先，采用特定的变革管理策略不如激励追随者积极支持组织整体变革那样有效。更重要的是，变革型领导力包含的是可以教授和学习的实践。

领导力是成功的秘密成分

组织可以通过实施培训、辅导和指导计划来提高 DevOps 和其他变革项目成功的可能性。这些计划旨在培养组织内现有和未来领导者的变革型领导力能力。通过投资这些计划，组织可以采取切实可行且经过验证的措施，增加其努力成功的概率。成功的 DevOps 领导者在远见、真实性、个人发展和创造力方面展现出显著的品质。他们赋能团队并鼓励去中心化决策。

这一点具有显著的影响。领导者运用领导技能的方式在成功管理与采用 DevOps 实践相关的文化转型这一挑战性过程中的作用至关重要。组织所选择的领导风格直接影响其成员对流程、技术、角色和意识形态重大变化的反应。

当从业人员积极参与、充满动力、拥有授权并得到支持，且处于一个有利的环境中时，成功实现 DevOps 转型的可能性会显著增加。这种环境的特点是，领导者提供清晰的愿景，以诚实和真实性为领导原则，并培养信任文化。

以为 DevOps 主要是关于工具

DevOps 发布管理的实施在很大程度上依赖于各种工具的使用，这些工具的目的是加速任务的完成，并促进不同团队之间的协作，从而改进软件开发和运维过程。选择合适的工具在这方面具有重要意义。正如本书中广泛讨论的那样，DevOps 方法论涵盖了广泛的工具，包括源代码和版本控制管理工具、持续集成/持续部署（CI/CD）工具、沟通与协作平台以及监控工具。值得注意的是，这些工具已经非常多，而且随着时间的推移不断增加。

相反，过多地投入时间和精力去选择最佳工具（应该注意的是，这样的工具实际上并不存在），并随后为团队提供培训以便其使用，这是一项徒劳的努力。尤其是在所选择的工具未能准确地复制你期望的工作流程时，这一点尤为明显。我们这里举的假设工具通过运用巧妙的策略和偶尔的手动操作，的确有可能完成它被选中的任务。然而，这种方法可能会导致比必要的更加繁重且令人沮丧的用户体验（无论是对于内部人员还是外部人员），常常导致工具的使用受到限制。

DevOps 的核心在于消除障碍，并优化为客户交付价值的过程。在问题解决的领域中，重要性不在于使用的单一工具，而在于识别和缓解痛点。比这一切更为重要的是，运用这些工具并解决这些挑战的人才和创造力。任何高层管理人员都应当知道自己成功的关键所在。

但为什么我们 需要工具？

工具在 DevOps 发布管理中至关重要，原因有多种。它们帮助我们高效解决复杂问题、自动化任务并提高生产力。工具通过提供预定义的算法、库和框架，提供一种系统化的解决问题的方法，从而简化了开发过程。它们还通过提供版本控制系统（VCS）、集成开发环境（IDEs）等，促进开发人员之间的协作。根据工具的既定定义，任何有助于成功完成特定任务的物体或设备都可以被归类为工具。在自然界中，甚至像棍子或石头这样的普通物体也能作为工具来完成特定目标。

然而，当你只有一把锤子时，一切看起来都像钉子，因此 DevOps 工匠的工具箱中需要有各种各样的工具。随着我们技能的不断提升，将会有新的资源和方法提供给我们。然而，工匠的注意力更多地集中在最终产品上，而不是过程本身。工具本身仅仅是达到目的的一种手段；拥有更多、更好的工具只能提高你作为一个有能力的人的效率。

企业选择工具的关键在于其具体的流程。为了识别最适合您组织的工具，必须全面了解现有的流程流程。需要确保该流程已经最大化地优化。接下来，下一步是评估不同的工具，并选择与优化后的流程兼容的工具，且需要最小化定制。在 DevOps 和流水线管理的背景下，考虑不同工具的兼容性非常重要。此外，某些工具可能在流程的某一小部分非常有效，但与另一种对更重要的流程至关重要的工具不兼容。因此，专门针对特定领域的理想工具，在考虑 DevOps 和整个流水线时，可能并不适用。这被称为局部 优化问题。

最终，最好是提前设计好理想的流程，然后选择能够有效自动化或补充这些流程的工具，并且实现这些工具时几乎无需人工干预。

将 DevOps 和 CI/CD 视为相同的概念

DevOps 发布管理涵盖了自动化构建流程和基础设施，但其范围不仅限于 CI/CD。DevOps 和 CI/CD 虽然相关，但在计算机科学、项目管理或二者结合的领域中，它们是不同的概念。DevOps 可以被看作是一个全面的软件开发和部署方法，类似于一辆自行车的车轮。在这个类比中，CI/CD 可以看作是车轮的一根辐条，在促进整个系统平稳运行中起着至关重要的作用。

DevOps 的成功取决于关键利益相关者之间的有效协作，这与任何行业中的高效团队类似。在软件工程领域，开发工程师和运维人员之间的协作对于整个开发生命周期至关重要。这种协作跨越多个阶段，包括设计、开发和生产支持。DevOps 是一种文化范式，涵盖了整个软件开发生命周期，超出了软件开发人员和运维人员的角色。它以一组行为为特征，促进这两个传统上分离的职能之间的协作与整合。

在 DevOps 发布管理的背景下，软件开发、部署、信息安全、QA、发布管理和相关学科的整合，形成了一个统一的实践集合。需要明确的是，使用 CI/CD 并不能证明一个公司成功应用了 DevOps 实践。

组织中缺乏明确的 DevOps 概念，导致采用过去效率低下的模式，其中开发、QA 和系统管理团队各自为政。没有掌握 DevOps 基本原则的团队，即有效沟通、无缝协作和透明化实践，无法如期推进工作。

理解关键差异

CI/CD 是一组开发方法论，旨在促进代码修改的快速且可靠部署。DevOps 是一整套概念、方法论、程序和技术，旨在促进开发和运维团队之间的协作，以优化产品开发。尽管这两个概念是相互关联的，但它们具有不同的特征。简而言之，以下内容适用：

• CI/CD 包括一系列开发方法论，旨在促进代码修改的快速且可靠部署。

• DevOps 包括一系列概念、方法论、程序和技术，促进开发和运维团队之间的协作，以优化产品开发。

在当今的商业环境中，任何技术驱动型组织要想实现最佳的运营效率和卓越的产品质量，必须认识到 DevOps 和持续集成/持续交付（CI/CD）的重要性。在国际上，开发团队依赖 CI/CD 实践快速且一致地交付代码改进。相反，DevOps 原则鼓励开发和运维团队之间的协作，以优化产品开发的各个方面。

让我们进一步阐明 CI/CD 与 DevOps 之间的根本区别。

DevOps 与 CI/CD 的范围

持续集成（CI）是软件工程中的一项基本原则，倡导团队成员定期整合各自的工作。在软件开发的背景下，遵循这一方法论的实践者努力频繁地将更改整合到代码库中，通常是每天甚至每小时进行一次。在传统的环境中，集成是一项昂贵的工作，需要不同工程组之间进行大量的沟通。为了克服这一障碍，CI 提倡使用自动化的测试和构建工具。这种自动化的最终目标是发展出一个软件定义的生命周期。通过减少集成所需的工作量，成功的 CI 帮助团队更快地发现和修复集成错误。

类似于持续集成（CI）优化构建和测试软件的过程，持续交付（CD）增强了软件应用程序打包和部署的效果。采用 CD 的组织能够有效地协调整个软件开发生命周期（SDLC），涵盖设计、构建、打包和部署等环节。这种方法有助于实现软件定义的生产方式，旨在最大限度地优化成本效益和自动化。

在最佳状态下，CI/CD 允许快速地将更新后的软件部署到生产环境中。这促进了 DevOps 文化的发展，使得软件开发生命周期（SDLC）为用户提供更多的反馈机会和更多的创意空间。

DevOps 和 CI/CD 的目的

CI/CD 将应用程序的所有代码更新整合到一个统一的代码库中，随后进行自动化测试。这个过程保证了产品的全面开发，并精心准备它以进行部署。CI/CD 的主要目标是促进产品更新的快速、简化和自动化部署。此外，这一过程还减少了产品缺陷，从而提高了用户的平均满意度。总的来说，强大的 CI/CD 流水线能够提高软件开发的速度和质量，为运维和产品开发团队提供益处，提升企业及其客户的整体业务价值。

DevOps 发布管理是一种旨在解决许多组织面临的共同挑战的方法：在创建新软件的过程中，操作、开发及其他团队之间缺乏协调与合作。由于协作不足，沟通鸿沟和缺乏合作通常会导致重大障碍和昂贵的挫折。通过将 SDLC 中的各个要素整合起来，DevOps 发布管理旨在简化这些工作。DevOps 通过推动更加灵活、简化且富有成效的软件开发过程来实现这一目标。通过在团队之间培养和维持共享文化，DevOps 能够轻松促进共通业务流程的采用，并整体提高协作水平。

DevOps 和 CI/CD 的个人利益

实施 CI/CD 流水线有许多优势，包括以下几点：

• 由于自动化测试，生产环境中引入的错误较少。

• 在开发周期初期解决集成问题，简化了发布构建过程。

• 因为开发人员在构建失败时会立刻收到通知，所以他们需要切换任务的频率大大减少，从而节省了时间。

• 由于 CI 服务器能够在几秒钟内运行数百个测试，因此测试花费的资金更少。QA 团队现在可以将他们的时间和精力投入到更重要和更有价值的任务中。

• 减少团队在准备发布时花费的时间，简化了软件部署。

• 随着发布频率的增加，端到端反馈循环变得更有效。

• 通过轻松做出小的变更实施决策，简化了迭代过程。

接受 DevOps 发布管理有多个优势，如下所示：

• 增强了敏捷性、自动化、协作、效率和质量

• 及早发现并解决错误和 bug

• 最小化市场时间（TTM）

• 增强的投资回报率（ROI）

• 提高了用户满意度

• 减少了对齐错误和沟通失误的风险

强大的 DevOps 文化促进了团队之间的协作，使他们的努力朝着共同的商业目标对齐，而不是各自孤立的部门。自动化测试和持续反馈与敏捷原则相结合，能够加速开发并让错误管理变得轻松。当 DevOps 过程得到正确实施时，它带来了多个好处，包括提高产品质量、增强用户满意度和增加盈利能力。

将质量视为事后考虑

产品、服务、员工和声誉中的质量是每个企业都渴望的目标，但实现这一目标并不容易。将其作为公司口号、在线发布、在休息室展示有关它的聪明引语，甚至在员工手册中专门列出相关内容，都很容易做到。然而，要让质量文化真正渗透到组织中，它必须渗透到每位员工的意识中。

为了实现这一目标，企业需要采用全面的质量战略。同行推动的方式、高层支持、丰厚的奖励，以及涉及公司所有方面，特别是人员、流程、产品和服务的包含，都是成功的关键。

值得注意的是，某些公司可能会持续生成开发代码，但在每个阶段的管道中未纳入必要的质量检查。CI/CD 管道虽然能够快速发布软件，但可能无法带来高价值的成果。为了优化性能，关键是优先考虑速度的同时确保维持所需的质量水平。在实施 DevOps 实践时，必须评估管道中每个阶段提供的质量方面，并在有利的情况下实施局部优化技术。存在许多低开销的方法可以在管道中添加质量检查，做到这一点将有助于长期的回报，因为它能在早期发现有问题的代码。

幸运的是，大多数开发工程师基本理解“左移”的概念，这有助于通过在流程早期发现错误来节省时间和成本。通过采用以早期缺陷检测为优先的 DevOps 文化，领先于竞争对手。确保你的管道在整个过程中都具备成熟的质量检查点，这将使你能够更快地发布更好的软件。在构建成熟的管道时，纳入以下各类质量阶段是至关重要的：

• 代码覆盖率

• 静态代码分析

• 单元测试

• 集成测试

• 基础设施验证

• 部署后测试

通过从一开始就将这些质量检查纳入其中，你可以极大地提升 CI/CD 管道的成熟度和价值。

启动战略质量管理计划时，请记住以下七点：

• 阐明你的基本原则和卓越标准：通常最困难的部分是弄清楚你要追求的质量是什么。描述公司对质量的定义时，尽量做到详细；否则，你的定义将显得模糊，永远无法付诸实践。在提供具体的质量度量示例后，务必关注自己的进展。

• 避免将合规性作为首要关注点：许多公司认为，通过达到如国际标准化组织（ISO）、健康保险流通与问责法案（HIPAA）、健康信息信任联盟（HITRUST）、国家标准与技术研究院（NIST）、现行良好制造规范（cGMP）、通用数据保护条例（GDPR）等行业标准的合规性，他们就展示了对质量的承诺。然而，他们没有抓住这一主题的本质。通过优先考虑质量，合规性自然会跟随。合规性可以类比于单纯关注通过考试的成绩。虽然它帮助公司克服了某些障碍，但并没有充分准备公司建立持久的卓越文化。

• 向所有同事宣传质量管理：虽然许多公司确实有专人负责质量控制（QC）和质量保证（QA），但质量管理应该是每个人的责任。员工应当在没有报复担忧的情况下，能够自由地提供反馈和建议以提升质量。此外，质量战士应当有机会实施他们的想法，并在其努力取得积极成果时得到认可。

• 通过自动化简化过程：质量过程对公司运营的影响是显而易见的，但实现这些效果可能是一个漫长且复杂的过程。确保质量过程得到遵循，文档保持最新和准确，并且仪表板能够在质量问题变得无法控制之前及时提醒你。这通过自动化的质量管理系统（QMS）更加容易实现，该系统整合了跨部门的数据。在系统处理质量流程时，经理们可以专注于创新和核心业务，而不是应对紧急情况和 P1 事件。

• 让数据引导决策和行动：虽然建立真正的卓越文化似乎是一项主观技能，但实际上它涉及大量的科学原理。质量应当由数据引导，数据可以识别问题领域、预测模式并帮助监控进展。

• 持续衡量在制品（WIP）：设定明确的目标并配有可衡量的指标是任何质量改进计划的第一步，无论是新的生产过程、扩展的产品特性，还是修订的安全测试标准。接下来，向客户、员工或供应商等利益相关者征求意见，以评估项目的执行情况。

• 将持续改进作为你的目标：在交付应用程序并收集利益相关者反馈后，确保过程不会在此结束是至关重要的。真正的质量程序本质上是动态的，必须持续适应以应对不断变化的需求和要求。通过不断提升自己的标准，你可以确保质量成为文化的一部分，而不仅仅是针对特定问题的临时解决方案。

将质量作为组织文化内在组成部分而非短期应对问题的方式的公司，能够获得诸多优势，如减少安全事件、减少回滚发布的情况以及更少的声誉损害。然而，只有当企业采取全面和一体化的方式时，质量才能真正成为其独特的品牌。曾有智慧的人说过，你做一件事的方式就是你做所有事情的方式。

缺乏仪表盘和报告，或者报告过多

高效的软件开发需要各团队之间清晰和开放的沟通，这至关重要。所有个人和团队必须有共同的理解和知识，确保没有人被排除在外或落后于他人。有效的仪表盘能够促进利益相关者的支持，并提升整个过程的效率。

可惜的是，这一关键元素在许多 DevOps 倡议中往往没有得到足够的重视。高质量的仪表盘和报告常常被忽视或未受到充分考虑。随着失败的积累，发现根本原因变得更加困难，公司开始意识到需要更多的资源来推动决策过程。

高效的仪表盘和报告，通过开放性，能不仅提升决策质量，还能使团队紧密监控开发周期的各个阶段，从而促进流程的优化和管道的改进。当问题出现时，正如它们不可避免地会出现的那样，这些问题将不再被忽视。而且，当你训练员工如何正确记录和报告时，帮助每个人追根溯源，这意味着未来的失败会更少。

如果管道中的特定阶段持续出现较高的失败率，能够看到这些阶段的情况将有助于优先调查这些失败的根本原因。这些反馈循环对于在 DevOps 和管道实施中取得成功至关重要。通过实施有效的仪表盘和报告，你不仅可以减少时间和成本，还可以通过交付更优质的软件来提高客户满意度和用户体验。定量数据和统计数字具有很强的说服力，许多机构已经开始采集多种指标。

然而，人们可能会陷入过度追求仪表板和指标的状态，这通常被称为仪表板和指标黑洞。尽管收集基础数据本意良好，但这个过程可能迅速变得繁琐且耗时。更糟糕的是，在这种过度执着的心理状态下，你很可能最终会失去最初的焦点。收集数据的主要目的是帮助公司做出明智的决策，并实施旨在改善指标的战略，而不是为了创建外观吸引的仪表板。

实现这一目标的一种方法是专注于收集DevOps 研究与评估（DORA）指标，并为团队提供便捷的访问方式。此外，可以为每个团队建立商定的程序，专门提高数据质量。通过采用集中的战略，这些团队可以开始采纳工程最佳实践，从而促进 DevOps 文化在公司内的建立和融合。

选择错误的指标来衡量项目成功

尽管 DevOps 的优势在于更快的交付，团队仍需保持谨慎，因为加快的节奏可能对产品质量产生不利影响。拥有一套明确且可量化的 DevOps 指标，可以有效地监控项目的进展和卓越表现。

DevOps 提供了高度的适应性，并且可以轻松地根据任何组织的具体需求进行定制。首先，明确你希望通过实施 DevOps 解决的问题，并概述你组织的 DevOps 转型的具体特征。然后，确定你的组织在实施 DevOps 时可能面临的潜在障碍，并将其作为衡量指标的依据。为你的独特组织选择合适的 DevOps 指标，将帮助你评估自己的成就水平。

除了技术性指标外，还需要在 DevOps 的背景下考虑选择商业指标。这些指标在有效传达 DevOps 项目投资回报率（ROI）给关键利益相关者方面起着至关重要的作用。为了有效地衡量和评估绩效，至关重要的是仔细选择那些专注于期望结果的指标，并且与商业优先事项保持一致。例如，当主要商业目标是提高组织流程的效率时，建议使用专门衡量成本的指标。

什么是 DevOps 指标？

企业需要投入大量时间、金钱和资源来进行 DevOps 转型。这包括重新评估从工具到沟通和培训的各个方面。为了有效地定义目标、提高效率并监控进展，必须具备评估 DevOps 指标和性能基准的能力，而且这种评估要既清晰又准确。

在启动 DevOps 项目时，确定哪些 关键绩效指标（KPIs）能够帮助克服企业独特的挑战非常重要。DevOps 的 KPI 应该能够展示转型对公司价值和影响的全面体现。为了对未来的流程和技术做出明智的决策，必须有准确的性能指标来衡量当前工作的价值。

有效 DevOps 指标的特征

为了更好地了解 DevOps 项目或团队的表现，以下是五个能够反映高质量 DevOps 指标的特征：

• 可测量性：为了确保一致性和可比性，指标应具有标准化的值，并在较长时间内保持不变。

• 可操作性：对指标进行长期的综合分析应能够揭示出系统、工作流程、策略等领域潜在的改进空间。

• 可靠性：为了确保测量的准确性，必须防止团队成员以任何方式操控或影响结果。这能够确保测量结果客观、公正，不受任何故意偏见或扭曲的影响。

• 可追溯性：这些指标不应仅仅是对一般问题的简单提及；相反，它们应直接指向根本原因。

• 相关性：这些指标必须设计成能够衡量对企业整体运营和成功具有重要意义的因素。

避免跟踪那些不能提供有意义洞察或不促进软件开发和运维过程整体改进的 DevOps 指标，例如以下这些：

• 非 DevOps 指标：例如，衡量流量负载的指标更适合那些采纳 Scaled Agile Framework（SAFe）的组织，而不是专门设计用来衡量 DevOps 发布管理成功的 DORA 指标。

• 无意义的指标：指标应该设计为促进和增强团队合作。虚浮的或浅显的指标显示你能做某事，但它们并不能真正展示公司运作得多好。有时，无能的领导者会要求团队提供无意义的指标，以掩盖他们的经验不足或疏忽。例如，由于在重构过程中代码可能会被完全丢弃，且有时更少的代码对组织更有利，像每周编写的代码行数这样的指标就变得毫无意义。除非每次构建都能显著改善最终用户体验，否则每天构建的数量是毫无意义的。

• 有争议的指标：当只有顶尖表现者被认为是赢家，而其他人都被视为输家时，预测团队内外的有效沟通与协作变得具有挑战性。避免创建那些会引发轻蔑或争斗的指标，如衡量失败的构建次数或致命错误数量。团队可能会过于专注于提高这些指标，而忽视识别实际问题并共同合作解决它们。

六个关键 DevOps 指标和六个关键客户满意度指标

在 DevOps 发布管理中，评估性能和进展对于组织至关重要。为此，六个关键指标已经成为重要的衡量标准。这些指标作为评估大多数组织内 DevOps 实践的有效性和效率的尺度：

• 交付时间：为了衡量完成时间，团队需要明确任务的开始和结束时间。从提交代码到将其部署到生产环境的每个步骤，都需要是可量化的。实现这一目标的一种方法是充分利用自动化测试和集成过程；另一种方法是缩短整体部署时间。

• 部署频率：自动化部署管道、API 调用和手动脚本只是衡量部署频率的一些方式。由于并非每次部署都会推进到生产环境，因此这个指标更多关注管道的技术性能，而非发布频率。失败的部署会整体影响客户满意度，但更频繁的部署可以减少相关的错误。

• 变更失败率：在评估 DevOps 项目时，重要的是要同时衡量成功率和失败率，尽管提高速度是其中一个目标。客户的不满有时是未能确保变更一致地发布到生产环境的结果。随着部署次数的增加，如果关键绩效指标（KPI）显示更高的失败率，就该放慢速度，调查管道中的问题。

• 平均恢复时间（MTTR）：这个指标衡量组织从故障中恢复所需的时间，是 DevOps 框架的一部分。该指标对企业至关重要，因为它显示了团队应对中断并快速恢复常规运营的能力。以分钟和小时为标准计量单位，但有时也需要使用天数。如果你希望缩短解决问题的时间，就需要正确的应用监控工具以及运营和开发人员之间的紧密合作。

• 客户工单量：这个指标衡量客户的满意度。在许多情况下，最终用户是第一个注意到缺陷和错误的人，而不是测试人员。之后，他们会联系客户服务，提出他们的疑虑。因此，应用质量的一个关键衡量标准是被标记为问题或缺陷的客户工单数量。工单数量较低表明应用程序很稳健，而较高的数量则表明存在质量问题。

• 缺陷逃逸率：无论 DevOps 流水线多么优秀，缺陷总是会发生。流水线的开发或测试阶段通常是发现这些缺陷的最佳时机。然而，即使它们通过了测试，用户仍然可能会发现这些缺陷。缺陷逃逸率可以定义为在部署前后发现的生产问题的百分比。它帮助识别软件开发过程中的薄弱环节，指出漏洞容易被忽视的地方，并建议改进产品和过程保障的方法。

DevOps 项目为组织提供了显著的优势，但其实施涉及复杂性和可观的成本。DevOps 指标在评估 DevOps 团队表现和评估实施 DevOps 实践的有效性方面起着至关重要的作用。这些指标提供了对 DevOps 倡议在任何规模或成熟度的组织中整体表现和影响的宝贵洞察。

在我们继续前进之前，必须花一些时间回顾衡量客户满意度的关键指标。虽然这些指标在严格意义上与 DevOps 是两个不同的领域，但它们将帮助你作为领导者和发布经理取得成功，无论在什么样的背景下。这些指标适用于内部和外部客户。例如，你可能正在开发一个内部产品，目的是帮助其他部门提高工作效率。或者，你可能正在开发一个传统意义上的软件产品，面向外部客户：

• 顾客满意度 (CSAT) 分数：测量 CSAT 分数包括进行一项调查，要求顾客在互动或购买后对他们的体验进行评分。你一定见过这种调查，它通常在你完成任务或购买后出现，询问你的体验。这项调查通常包括一个评分尺度，可以是数字或表情符号形式，涵盖从负面到正面的各种体验。根据反馈，CSAT 分数可以在 0%到 100%之间变化。

计算 CSAT 评分

计算 CSAT 分数的方法是：将收集到的有利回应总数除以调查总回应数，再将结果乘以 100\。这将得出你公司 CSAT 分数。最终结果是与你公司做生意的满意消费者的百分比。

• 净推荐值 (NPS)：NPS 是一个常用的指标，通常使用 1 到 10 的评分标准，用于评估客户对品牌的忠诚度和热情。它提供了关于客户满意度和他们推荐你公司业务的可能性的洞察。

确定 NPS

评分为 9 或 10 的顾客通常被称为推广者。他们对你的公司已经形成了强烈的忠诚感，并热衷于向他人推荐你的公司。评分为 7 或 8 的顾客通常被称为中立者。他们对公司忠诚度不能视为牢不可破，因此在面对更好的选择时，他们可能会考虑与竞争对手做生意。评分为 7 或以下的顾客被视为贬低者。他们对你的公司缺乏忠诚，可能会公开表达对公司不利的观点或意见。

• 顾客努力分数 (CES)：CES 是一种衡量顾客在与公司互动时所付出努力程度的指标。这些互动可能包括使用公司产品和服务所需的努力程度，或客户服务代表解决顾客问题的难易程度。

  建议发送调查问卷以测量客户在最近一次与客户服务互动后所花费的努力程度。你可能会考虑实施 CES 调查，以评估顾客对每个客户服务代表的满意度。这将使你的客服团队能够进一步提升表现，并确保你的公司继续致力于提供卓越的客户支持。

测量 CES

CES 的测量包括提问一个问题，回答会根据 1 到 7 的尺度进行评分，其中 1 表示对该陈述的最大反对。

CES 指标通过表示同意的客户比例来确定，表明公司有效地帮助解决了他们的问题。当客户从不同意或中立状态转变为同意时，建立客户忠诚度变得更加可行。

• 客户流失率（CCR）：CCR 是公司客户停止使用其服务的百分比。它也叫做流失率。通常的量化方式是计算在特定时间段内取消订阅的公司客户的百分比。它也代表在特定时间范围内辞职的员工百分比。为了让业务扩大客户基础，增长必须超过流失，尤其是在客户流失方面。

计算 CCR

客户流失率公式是(流失客户 ÷ 时间段开始时的总客户数) x 100。

• 客户健康评分（CHS）：CHS 是评估客户是否保持忠诚或流失到竞争对手的最有效指标。这些持续的客户留存统计数据对客户经理和支持人员特别有价值，因为它们提供了关于客户流失可能性和程度的洞察。

计算 CHS

与大多数 SaaS 指标不同，CHS 没有预设的算法。然而，CHS 的计算方法将是特定于您的组织和产品的。不过，计算客户健康评分时有五个主要步骤：

1. 定义您的客户的健康水平。

2. 选择用于预测的度量指标。

3. 建立一个评分分配系统。

4. 将您的消费者数据分为不同的细分群体。

5. 展示您的 CHS 的图形表示。

• 客户生命周期价值（CLTV）：CLTV 是一个定量衡量指标，表示一个客户在与您的业务关系期间所产生的预期收入总额。

计算 CLTV

将客户价值与平均客户生命周期相乘。要确定 CLTV，您可以通过将平均购买值与平均购买次数相乘来找到客户价值。获得平均客户生命周期后，可以通过将其与客户价值相乘来计算 CLTV。

这里是公式：

• 计算客户价值是通过将平均购买值与平均购买次数相乘来完成的。

• 计算 CLTV是通过将客户价值与平均客户生命周期相乘来完成的。

在推进 DevOps 的过程中，把其他人甩在身后。

在你的组织内部实施 DevOps 实践的理由在塑造组织文化的基础方面起着至关重要的作用。在农业领域，寻找肥沃的土壤是一项基础性工作。肥沃的土壤是指具有必要的营养和物理特性，能够支持植物的生长和发展，而这项工作通常需要评估多个因素。在 DevOps 转型的背景下，如何有效地沟通、展示和说服关键利益相关者 DevOps 的重要性至关重要。如果做不到这一点，可能会导致对这一举措的怀疑，并且容易抓住任何机会证明它的失败。在一个不利的境地中行动是不可取的，特别是当你开始一个别人预期你失败的旅程时。

为了获得成功，获得所有人员的全面参与和支持非常重要，包括那些对 DevOps 表示怀疑或质疑的人。值得注意的是，工程师通常是最容易持怀疑态度的群体。在行业中工作了十年或二十年后，他们见证了无数新思想和新方法的出现和消失。他们很容易把 DevOps 看作是解决相同重复问题的“失败方法”。如果执行不当，DevOps 无疑会成为另一种失败的工作方法。因此，您和您的团队必须向其他人展示 DevOps 的可能性，并鼓励他们以一种包括所有人的方式参与其中。

在说服高管时，利用数据并强调加快软件交付的潜力。然而，工程师需要理解 DevOps 如何提升他们的工作满意度。展示 DevOps 与业务需求之间的关联，以及它在整个软件交付过程中如何减少障碍。确保不要过度宣传或夸大这一概念。遇到 DevOps 挑战是不可避免的，因为 DevOps 不是万能药，它需要在初期投入大量的努力来建立持续学习的文化，在这种文化中，工程师可以自由犯错并推进自己的职业生涯。

一旦你的组织达到了一个关键点，许多人开始接受 DevOps 概念，你就可以自信地向前推进，知道你的组织及其成员完全支持这一转变。

朝着共同的愿景和目标努力

一个高效运作的 DevOps 团队的特点是其成员拥有统一的视角，与组织的整体目标保持一致。团队成员应当深入理解公司战略目标，以提升他们在开发和实施应用程序过程中的决策能力。组织的领导层在有效传达这一愿景和帮助团队成员意识到其雄心的期望轨迹方面发挥着至关重要的作用。通过朝着共同的愿景努力，团队为在各自的项目上合作并有效沟通奠定了更加坚实的基础。

对集体愿景来说，集体对具体目标的意识同样重要。这些目标不仅涵盖组织层面，还包括团队和项目层面。此外，它们还可以包含 DevOps 本身的目标，涉及不同的团队和广泛的软件项目。DevOps 团队应避免管理冲突的优先级和相互竞争的目标的负担。再次强调，组织的领导层在有效传达不同层面的目标以及共享整体愿景方面扮演着至关重要的角色。

反对变革

一些关键利益相关者和员工可能会觉得转向 DevOps 令人恐惧。为了避免给人一种颠覆性的感觉，尽量将其框架定位为对现有开发方法的改进，因为这正是 DevOps 发布管理所带来的价值。

从潜在角度来看，向个人提供建议的行为可能会引发接收者的负面反应。成功的 DevOps 转型需要一个平滑且渐进的过程。个人可以通过逐步调整和认识到 DevOps 在促进开发过程中的多样化作用来接纳 DevOps 文化。在一个小规模的全栈项目中整合 DevOps 实践，是开始 DevOps 转型的值得称赞的策略。

在亲身体验到好处后，团队自然会倾向于采纳新的操作流程。因此，大家将一致同意过渡到新的 DevOps 生态系统，且不熟悉感将逐渐减弱。

从旧有基础设施和设计转向微服务

尽管过时的应用程序和过时的基础设施在长期以来一直对业务有益，但复杂的架构堆栈可能会在短期内引发问题，并在长期内造成灾难。如果你过于依赖已经有效的旧系统，你可能会在竞争中落后，并且可能会面临不稳定的挑战、缺乏有经验的支持工程师，以及相比于更高效、更现代化的替代方案，运营成本更高。

基础设施即代码（IaC）和微服务架构是实现持续创新未来的关键组成部分。通过采用这些方法，软件开发生命周期（SDLC）得以转型和现代化，使企业能够迅速适应不断变化的市场，并实时满足不断变化的消费者期望。

通过采用微服务架构并迁移到云原生环境，你可以提升研发操作的效率。为此，必须具备对自动化、配置管理和持续交付（CD）过程的深入理解，才能有效管理与微服务架构和先进交付策略相关的增加的操作负荷。

单体架构向微服务架构迁移的局限性

没有一个普遍适用的答案可以应用于所有情况，同样的原则也适用于微服务。虽然由于其众多优势，微服务的设计可能看起来很有吸引力，但你的软件可能更适合使用单体架构。因此，首先评估是否确实有必要从单体架构迁移到微服务架构是至关重要的。

当从单体架构过渡到微服务架构时，必须意识到这一过程可能需要大量时间和前期投入。虽然这种架构的长期成本效益是明确的，但需要注意的是，为每个微服务分配资源来组建团队、搭建基础设施和存储数据是必要的。迁移过程的持续时间与必须分配的资源数量直接相关。

在讨论迁移时间时，需要注意的是没有适用于所有情况的普遍平均时长。该过程的持续时间可能会有显著差异，完成时间从 6 个月到 5 年不等。项目时间线的持续时间受两个因素的影响：项目的复杂性和单体系统更新的频率。这些更新对迁移过程起到约束作用。

在将遗留应用程序迁移到微服务的过程中，需要注意的是，单体应用程序将继续运行。在软件开发的背景下，面对漫长的迁移过程时，建议定期更新单体系统，以维持市场地位。然而，如果可能的话，建议避免进行此操作。

为了保持高效的运营，有必要在单体和微服务版本之间建立和谐的共存关系。这对于防止冗余数据、确保各个组件之间的可靠通信以及减少潜在错误至关重要。处理这一任务的责任主要由迁移团队承担，因为它涉及多个技术方面。要实现从单体架构到微服务的成功迁移，关键是要验证所选的专家是否具备必要的技能和专业知识。

由于每个项目的独特性，其迁移过程需要采取不同的方法，这可能并不完全符合现有的理论原则。DevOps 发布管理领域的专家必须具备适应性，并全面了解各种概念，包括对相关部落知识的熟悉，以便为每个迁移项目制定最佳的开发策略。

在讨论从单体架构到微服务架构转换的复杂性后，我们现在将探讨这种转型的理想路线图。

单体到微服务迁移路线图

向微服务过渡的过程不仅仅是一个简单的系统适配。该过程复杂且需要大量时间。它涉及重大变化，比如重新组织团队、选择新的系统和工具等。因此，拥有一个明确的路线图是非常重要的，这将有助于各种修改的顺利整合。

在管理多个具有不同业务需求的项目时，需要为每个项目制定个性化的路线图，以促进向微服务的过渡。以下路线图提供了一个概述这一转型的通用框架：

1. 绘制微服务图：设计新架构的初步步骤是共同识别并选择将被纳入系统的微服务。微服务通常根据其特定功能进行组织，每个微服务被分配一个明确的责任，以执行特定任务。

   为了适当划分应用程序并防止微服务部分或完全重复，你需要查看单体应用程序中可能具有相似功能的组件，并将其移除。大多数单体应用程序都有能力被划分为更小的组件。这个过程的有效性和精确性取决于你的团队的熟练程度和专业知识。

2. 配置基础设施：为了建立一个稳健高效的计算环境，建议寻求经验丰富的 DevOps 工程师的帮助。这些专业人士拥有定义关键组件的必要知识和技能，例如数据库、通信协议、云基础设施和数据同步方法。一旦这些元素得到明确的定义，DevOps 工程师将继续相应地配置并建立计算环境。

3. 定义并划分团队：在微服务架构的背景下，通常会将每个开发人员分配到具体的微服务上负责。团队也可以是跨职能的，这意味着在必要时，团队可以与多个服务同时协作。

   另一种策略是根据复杂的程序安排专家，这些程序可以涵盖多个微服务。在典型的组织结构中，不同的团队会被分配特定的责任，以确保系统各方面的高效管理。例如，一个团队可能会被指定为负责基础设施管理，而另一个团队则可能负责数据管理。这种劳动分工使得专业化成为可能，并能够有效处理系统内的不同组件。

4. 为每个微服务定义技术栈：微服务的一个优势是可以为每个具体的服务选择最合适的技术栈。为了在每个微服务中实现可靠和高效的性能，必须与架构师、技术负责人和安全专家进行协作。这一合作需要识别出最适合每个应用组件的技术和框架。通过这样做，每个微服务都能够以最佳状态运行，整个应用也能正常运作。

5. 设置冲刺：在将团队分配到特定技术以进行微服务开发后，必须编制出单体应用程序中存在的功能的完整清单。随后，团队应该着手为这些功能建立冲刺和评估。一旦所有必要的准备工作完成，迁移过程就可以开始了。

6. 开发与测试：开发过程应通过创建最小可行产品（MVP）来启动。这是为了评估所选的架构和工具。这可以是一个包含一个或多个关键微服务的初始试点项目。采取这种方式可以集中评估所选组件及其在支持预期系统中的有效性。

   测试是代码重构的一个重要组成部分，确保代码的质量至关重要。必须确保团队在开发代码的同时进行单元测试、集成测试和验收测试。这些测试应与代码开发过程并行进行。

7. 部署：逐步部署微服务的过程涉及确保单片应用与变更兼容。这种方法允许从单片架构平稳过渡到微服务架构。实施这种方法的目标是减少过渡过程中可能发生的任何干扰。

在从单片架构迁移到微服务架构之前，重要的是考虑其他关键变量，以减轻常见障碍。虽然单片到微服务的路线图提供了一些指导，但以下额外的考虑将进一步增强迁移过程。

在将单片到微服务迁移之前需要考虑的因素

在从单片架构到微服务架构的过渡中，重要的是考虑以下几点：

• 彻底的计划创建：确保从单片架构平稳过渡到微服务架构的首要步骤是制定明确的迁移路线图。在此初始步骤中要格外注意，因为如果不注意，很容易漏掉重要细节并造成错误。在迁移过程中，如果有一个详细的计划，考虑资源公平分配、风险最小化和工作负载共享，那么开发团队、业务所有者和你都将从完全透明中受益。

  同时，为意外事件和可能的障碍做好准备。规划回退到旧设计，并在移动过程中出现问题时采取应对措施。

• 冻结新功能开发：在迁移期间仍在运行的系统进行升级和补丁是项目失败的主要原因。如果公司在过渡到基于微服务的架构期间不断要求系统更改、新功能或现有功能的更新，团队将要做的工作将增加一倍。在迁移到微服务之前，企业必须提供资源来在单体应用中执行这些增强功能。因此，单片架构变得更加复杂，这反过来使迁移时间更长，并导致技术债务累积。

  结果，团队面临浪费时间和精力的风险，导致庞大的未完成工作积压和功能不正常的微服务架构。

• 当前系统评估：对当前的单片系统进行彻底评估，以确定需要改进的领域或包含过时功能的地方。迁移过程为利用现代技术和方法重塑低效和过时流程提供了宝贵的机会。微服务架构允许在最小修改的情况下集成相对新的功能。

  除了重构预定的功能外，开发人员在迁移过程中可能会遇到额外的代码漏洞。由于这一原因，可能会出现额外的修改需求，导致开发周期延长。

• 选择经验丰富的迁移团队：尽管存在理想的理论微服务迁移计划，但由于每个项目的独特性，完全在现实场景中实现这一计划往往充满挑战，因此需要量身定制的解决方案。为了确定最合适的方案，拥有一支高技能的迁移团队至关重要。

  成功的迁移不仅仅是完成一个技术项目。毫无疑问，它将主要具有技术性质，需要有条不紊和谨慎的推进。然而，最关键的一点是慎重选择合适的团队。你需要的是那些具备正确心态和技术直觉的人员。其余的过程则依赖于特定方法论的应用和开发人员的熟练度。

• 为过渡分配充足的时间：考虑从单体架构转向微服务所需的时间。这不是一个简单的过程，而是一次探索未知领域的旅程，可能会非常耗时。项目的最短时间表取决于其复杂性和需求，持续时间可能从 1 年到几年不等。

  为了缓解关于这些时间表的焦虑，重要的是要注意，在整个迁移过程中，你的单体应用仍将保持功能性。虽然建议暂停扩展和添加新功能，但你的解决方案会在完成整个向微服务的迁移之前继续运行。

决定自动化错误的流程

经常地，在优化 DevOps 资源利用时，团队往往会过度自动化那些不需要自动化的操作。他们试图通过使用像 Amazon 或 Google 这样的行业领袖的配置管理技术来模仿他们的成就。在某些情况下，关键流程可能会被遗漏在自动化工作流之外。如果没有全面理解所有流程和子流程是如何相互关联的，团队可能会在开始自动化任务时，难以识别哪些流程需要自动化。

在自动化领域，谨慎起见，不应对每个过程都采取一刀切的方法。相反，建议将每个过程分解为其独立的子过程，就像进行价值流映射练习时一样。通过这样做，可以更全面地了解过程，从而更有针对性和更有效地应用自动化技术。接下来，需要评估每个过程，以确定它是否按照预期的行为运行。这个过程对 DevOps 团队有双重帮助。首先，它提供了每个过程的全面视图，确保没有步骤被忽略。其次，通过要求对所有程序进行全面审查，它避免了任何过程被错误地自动化。

你必须认识到，DevOps 不仅仅是自动化。它涵盖了整个过程，从生成想法到交付并将其实施到生产环境中。即使是拥有卓越 DevOps 团队和巨额预算的知名公司，可能也并不总能清晰地了解他们面临的问题，且他们可能会遇到影响其有效管理价值流或全面整合多个管道的困难。

简而言之，有一个普遍的误解认为 DevOps 主要是为了自动化每个过程。请记住，单单自动化某个操作并不意味着你正在自动改善它。事实上，你可能在不知情的情况下正在自动化你自己的毁灭，直到为时已晚。事后诸葛亮总是明智的…

安静的客户是一个幸福的客户

对于某些人来说，客户在整个项目过程中保持沉默的观念可能会被视为一个完美的场景，甚至是他们热切期望的事情。在项目团队的背景下，缺乏干扰并且能够专注于交付所要求的结果可以被视为一种幸福的状态。也许，在我们美好的梦想中，我们会意识到，将自己从客户之外、只局限于立即项目团队的隔离，并不是实现目标的明智方法。

不幸的现实是，项目团队有时会选择切断与客户的所有沟通。通常，这发生在意见不合或需求变更后，情绪变得激烈时。客户也可能认为他们从中受益，因为他们更愿意不再面对任何冲突或棘手的情况；毕竟，他们希望项目能顺利完成。

这种天真可能看起来有效，直到项目和客户之间需要某种互动时。重新建立这种联系并重新开始对话从来都不容易，但它对项目的成功至关重要。也许，重新建立的关系最终会不了了之，冲突和不同观点的恶性循环将再次开始。这种有毒的关系肯定不会对任何人或项目本身带来好处。

如果你故意避免与客户沟通，因为你错误地认为他们阻碍了你的进展，且认为提供更新或与他们交流会让你分心，影响完成项目工作，那么我想告诉你，这样做是愚蠢的！你必须尽可能及时地从客户那里获取反馈。这能够确保你的团队获得改善产品和为所有相关方产生最佳结果所必需的重要信息。

有几个因素可能导致客户沟通比预期的少：

• 客户对正在发生的事情感到满意：假设他们对项目进展感到满意，他们可能通过各种渠道了解到项目的进展情况与计划的对比，并对此感到满足。尽管完全可行，但最好还是打个电话，确认一下。

• 客户有更高优先级的工作需要他们关注：在某些情况下，个人可能会参与多个竞争的优先事项，例如其他他们认为更有趣或更有吸引力的项目。作为发布或项目经理，你的责任是识别你的项目在客户优先事项中的位置。要获得关于这一点的准确信息，建立与客户的持续沟通至关重要。

• 客户不知道他们的项目管理职责是什么：有时，尤其是在大公司中，客户可能不了解项目的运作方式，可能认为一旦启动了项目，他们就可以继续处理其他事务，并可以等待项目的成功完成。作为发布/项目经理，如果客户缺乏理解，你有责任让他们了解项目状态。毕竟，总有一天你可能需要他们的帮助。

• 客户对你的项目失去兴趣：在完成项目的过程中，个人通常会投入大量的时间和精力去实现目标。你的客户很可能忙于各自的工作，无法随时参与。当与他人互动时，保持谨慎和深思熟虑是很重要的。提供更新的主要目的是告知利益相关者当前的进展情况和在项目或任务过程中出现的任何挑战。为了确保项目未来获得支持，必须争取他们的支持。在客户参与的背景下，必须处理客户变得没有回应的情况。这种沟通的缺失可能表明他们对项目失去兴趣，进而反映出更广泛的组织问题。因此，积极与这些客户互动，了解他们的兴趣程度并识别潜在问题是至关重要的。

一个项目不应以培养一群对需求不太表达意见的客户为目标。如果有些客户比其他人更为内敛，或者变得比过去更少沟通，这表明需要更深入地调查。始终记住，项目的客户是其盟友和支持者，项目中的人员有责任保持与这些客户的互动。虽然确实会花费一些时间，可能会让一些人认为这不直接涉及项目工作，但最终确保你拥有一群既支持又全程参与的客户是有益的。

总结

这就是本书的第十一章的总结，也是本书的结尾。在这一章中，你了解了为什么精心设计的变更管理过程是至关重要的。你学会了如何利用变更请求和变更管理日志来保持日常工作的组织性和可追溯性。此外，你现在意识到保持和遵循软件发布检查单的重要性，并了解如何根据你管理的每个产品来定制这些检查单。最后，你学习了 DevOps 发布管理中的常见陷阱，并熟悉了避免在自己项目中重复这些问题的关键策略。

别忘了，本书的附录中有大量额外信息。一些内容包括章节问题的答案、术语词汇表、模板化的发布管理文档、未能纳入书本正文的扩展内容等等！

结论

让我个人感谢你花时间阅读我辛苦制作的内容。不管你是一个有抱负的 DevOps 发布经理，一个经验丰富的 DevOps 工程师，一个高级管理人员，还是介于两者之间的角色，衷心感谢你！

现在你已经读完了这本书，你对发布管理的简史、什么是 DevOps 发布管理、它的不同之处以及如何实施基本策略都有了了解。你已经看到了 CI/CD 管道如何推动良好的 DevOps 发布管理，并且学到了如何优化它们的技巧。此外，你还学到了如何创建一个跨职能的产品开发文化，减少浪费并增加客户价值。结果，你明白了它在消除团队成员之间孤岛的作用。最后，你现在有能力解释为什么 DevOps 发布管理正在成为当今最流行的战略。

DevOps 概念自诞生以来，就在 IT 行业引发了激烈的争论。对于这个话题的看法各不相同，某些群体将其视为一种表面的潮流，认为它会消失，而另一些人则认为它是绝对革命性的。随着时间的推移，战略家们对 DevOps 的未来做出了许多预测，尽管这一运动持续增长，但在某些经济部门中，它仍未得到广泛采纳。这正是你肩负的责任，要照亮那些尚未完全理解 DevOps 潜力和它为运营带来的价值的组织。

DevOps 经历了重大变革，从一个晦涩难懂的方法论发展成了一个强大的战略，它将开发团队和运维团队统一起来，最终彻底改变了公司的各个方面。凭借前瞻性思维，DevOps 通过提升整个组织的协作、沟通和对齐，重新定义了 IT 产品和服务的交付。现在你已经牢牢掌握了 DevOps 发布管理的概念，走出去，成为推动提高敏捷性、简化 IT 管理、降低成本和提升产品质量的催化剂，为你的企业和世界带来变革！

祝你在通往 DevOps 精通之路上一路顺利。

问题

回答以下问题，测试你对本章内容的理解：

1. 变更管理策略的目的是什么？

2. 变更提案的要素是什么，它的目的是什么？

3. 变更日志的要素是什么，它的目的是什么？

4. 发布检查清单是什么，它的目的是什么？

5. 成功的 DevOps 转型的秘密成分是什么？

6. 为什么认为 DevOps 主要是关于工具是错误的？

7. DevOps 发布经理应该坚决避免追踪的三种指标是什么？

8. 简要来说，单体到微服务的路线图的七个步骤是什么？

9. 使用 CI/CD 流水线是否意味着公司成功应用了 DevOps 实践？

10. 认为安静的客户就是满意客户的最大错误的关键原因是什么？

附录

最后，我们到达了书的结尾 - 附录。在这里，您将找到关于 DevOps 发布管理的大量精彩内容。

这是附录中涵盖的主要主题的快速列表：

• OWASP 十大 CI/CD 安全风险

• 价值流映射

• 发布管理模板：

  • 软件发布检查表

  • 业务规格文档

  • 软件需求规格 说明书（SRS）

  • 需求跟踪矩阵文档

  • 用例文档

• 章节问题的答案

• 术语表

OWASP 十大 CI/CD 安全风险

持续集成（CI）和持续部署（CD）已成为当代软件工程实践的关键要素。CI/CD 的利用还带来了一定的安全漏洞，需要仔细考虑。在本节中，我们将探讨OWASP 十大 CI/CD 安全风险，对威胁任何现代组织的 CI/CD 流水线基础设施的最常见安全风险进行全面探索。本节作为了解最突出的漏洞及其减轻风险建议的有价值参考资料。通过熟悉这些风险并实施建议的对策，您将能够增强组织中 CI/CD 流水线基础设施的安全性。

不足的流程控制机制（CICD-SEC-1）

在没有在预编码活动中解决安全性的情况下设计 CI/CD 基础架构时，会引入风险和安全漏洞。当公司在不有效采纳安全设计原则的情况下构建其 CI/CD 环境时，会出现设计和架构上的缺陷，从而导致潜在的安全威胁暴露。这些与系统初始化和配置期间发生的实施错误不应混淆。

这些危险案例展示了 CI/CD 流程的复杂性以及它们所带来的许多潜在攻击面。DevOps 治理模型的基本原则包括识别和绘制潜在的风险区域，随后实施一套政策、标准和程序。这些措施的目的是确保遵守既定流程，并保持所期望的代码质量和系统完整性水平。此外，这项工作将对业务的整体运营产生重大影响。通过实施更好的治理实践，不仅可以减少安全风险的程度，还能提高管道的效率，使开发人员能够维持工作流程，并更高效、更具成本效益地满足业务需求。

有必要对环境内的任何修改和适配进行全面评估和人工授权。自动化代码审查对高效、有效地评估代码质量至关重要。然而，尽管自动化有其优势，但仍然需要对任何新的定制或修改进行人工代码审查。这一要求在大多数源代码管理（SCM）平台中普遍存在，如 GitHub。

不充分的身份和访问管理（CICD-SEC-2）

访问控制是所有规模企业都必须考虑的问题。由于身份和访问管理不充分，攻击者可能会破坏你的工程生态系统。幸运的是，现有许多解决方案可以帮助你快速、轻松地授予、修改或取消访问权限，即使没有手动输入。这类工具确保访问限制在企业系统中得到一致应用，从而减少人为错误的可能性。此外，DevOps 应遵循最小权限原则，即用户只能获得完成工作所需的权限，而不应拥有额外的权限。这要求将对关键信息和系统的访问限制在那些确实需要这些信息和系统的人之间。

遵循职责分离的最佳实践非常重要，这一做法使得有人实施欺诈或故意破坏系统变得更加困难。同时，它还降低了错误的风险，因为多个不同的人会监督重要的任务，比如审查拉取请求和将新代码合并到主分支中。还可以考虑要求多因素认证，这要求用户必须提供至少两种不同类型的身份验证来证明身份。通常，他们需要知道某些抽象信息，比如密码，同时也需要拥有某些物理物品，如安全密钥或发送到他们手机的一次性代码。

依赖链滥用（CICD-SEC-3）

网络犯罪分子通过攻击供应链对企业造成破坏，目标是最薄弱的环节。从政府到石油行业，任何行业都可能成为供应链攻击的目标。软件和硬件都容易受到供应链攻击。网络犯罪分子常常在产品的生产或分发阶段插入恶意软件或硬件间谍组件。

恶意行为者经常利用工程和构建环境中的供应链漏洞，引入恶意软件。这些供应链攻击通常会利用已经存在于商业和开源依赖项中的已知漏洞。

为了减轻风险，建议采取实施集中化工件系统的方法。公司提供的依赖项被放入该系统中，并验证它们的校验和。示例包括 Sonatype Nexus、Jfrog Artifactory 和 Apache Archiva。

毒化管道执行（CICD-SEC-4）

毒化管道执行（PPE）风险的概念围绕着这样一种可能性：攻击者拥有访问源代码控制系统的权限，但没有访问构建环境的权限，通过巧妙地操控构建过程来实施攻击。这种操控通过将恶意代码或命令巧妙注入构建管道配置中，导致管道本身被“毒化”。因此，当构建过程启动时，毒化的管道会执行注入的恶意代码，并悄无声息地将其作为构建过程的一部分。

一旦 PPE 攻击成功，它可能接管 CI/CD 管道的身份并利用任意多个漏洞。潜在的有害操作包括访问 CI 作业可访问的机密，获得作业节点可以访问的外部资产，向管道发送看似有效的代码和工件，以及访问作业节点网络或环境中的其他主机和资产。由于其破坏性影响、难以检测的复杂性以及多种可用的攻击技巧，PPE 威胁是一个大问题。了解 PPE 及其应对措施对于安全团队、工程师和发布经理而言，是确保 CI/CD 安全至关重要的。

建议在隔离的系统中执行未经验证的代码，并限制对敏感区域的访问。应对公共代码库中的管道激活进行管理，撤销不必要的用户权限。建议在执行管道之前验证 CI 配置文件。

不足的基于管道的访问控制（CICD-SEC-5）

在 CI/CD 过程中的访问控制核心是建立有关自动化流程使用、位置和授权的治理指南。此外，设定环境保护规则，明确谁可以在不同环境（即构建、暂存和生产环境）中进行更改，是访问控制的另一个重要方面。没有这些访问控制，企业就会面临额外的风险，例如，可能会执行未经批准的工作流，导致系统被攻破，或者攻击者获得对 CI/CD 系统中重要环境的访问权限。

建议的缓解策略包括：使用专门为敏感管道指定的独立环境，仅限于必要资源的访问权限，限制执行环境内的网络连接。

凭证卫生不足（CICD-SEC-6）

在 CI/CD 环境中，访问和身份验证凭证（如密码）通常存储在自动化工作流中，因为它们涉及多个系统。这些被称为秘密，并贯穿整个 CI/CD 流程。如果没有适当保护，或者组织在授予访问这些秘密的权限时存在宽松的治理标准，未加密的秘密就可能成为一个强大的攻击面。

增强安全性的一个潜在措施是采用临时凭证，而不是静态凭证，并避免在不同情况下共享凭证。此外，建议使用能够检测文件中凭证的自动扫描工具。可能被提到的两种工具是 AWS Labs 开发的 git-secrets 和 Truffle Security 开发的 TruffleHog。

系统配置不安全（CICD-SEC-7）

具体而言，这指的是使用弱密码、不应用必要的安全补丁，以及在 CI/CD 环境中未能正确保护各种系统，这些都可能将敏感数据置于危险之中。即使这些问题容易被忽视，安全配置错误也可能让应用程序易受攻击。如果某些配置错误泄露了敏感数据，黑客甚至可能不需要发动故意的攻击。每一行代码和每一条数据，都增加了客户访问时应用程序安全面临的威胁。

例如，由于数据库服务器配置不当，数据可能通过简单的在线搜索就能获得。如果数据中包含管理员凭证，攻击者可能能够访问更多的数据，甚至发起对公司服务器基础设施的新攻击。如果存储设备的安全防护没有正确设置或完全缺失，可能导致大量个人身份信息公开在线。在大多数情况下，无法得知在采取安全措施之前，谁曾访问过这些数据。另一个常见的在线应用问题，尤其是基于流行平台（如 WordPress）构建的应用，是目录列表。人们能够自由地浏览和访问文件系统，这使他们很容易发现并利用安全漏洞。如果攻击者能够访问文件系统，他们可能会修改或反向工程一个程序。

为了增强 CI/CD 过程的安全性，必须不仅关注所涉及的代码和工件，还需要考虑每个系统的姿态和弹性。增强安全性的建议策略包括定期评估系统配置，并及时更新已废弃的程序版本。

无监管的第三方服务使用 (CICD-SEC-8)

在考虑 CI/CD 话题时，无监管的第三方服务使用指的是对已纳入或已经被授权访问组织 CI/CD 基础设施和资源的外部工具和服务进行不加限制和不受监督的利用。

在持续集成与持续交付（CI/CD）基础设施中，组织通常会将其主要的版本控制系统（VCS）、软件配置管理（SCM）和 CI 服务器与第三方供应商提供的外部工具和服务建立联系。若缺乏足够的治理措施来确保对这些工具的安全访问，未经授权侵入第三方工具可能使攻击者获得更高权限，从而访问更广泛的技术栈和源代码。

制定政策、进行监管、风险管理和系统监控都是有效治理第三方服务的关键因素。所有这些因素共同作用，确保外部工具和服务的使用符合组织的安全标准。

实施与使用第三方服务相关的治理控制对于提升安全态势至关重要。实现这一目标的一种可能方法是通过实施签名和校验和检查。

不当的工件完整性验证 (CICD-SEC-9)

由于缺乏验证代码和构件完整性的手段，恶意行为者如果获得了涉及持续集成和持续交付过程中某一系统的访问权限，可能会将看似无害的代码或构件通过管道传递，造成损害。

CI/CD 框架依赖多种来源和合作者，这可能为恶意行为者提供了通过操控代码、自动化工作流或安装恶意第三方包等方式侵害系统的多个途径。每当恶意软件未被及时发现进入 CI/CD 管道时，它都增加了最终被发布给终端用户的风险。

已经在软件交付过程中占据立足点的敌对者，可能会利用不充分的构件完整性验证，将恶意构件通过管道发送。参与 CI/CD 过程的系统，或者更严重的，生产系统，可能会因此受到威胁，执行恶意代码。

为了降低风险，建议进行资源完整性检查，例如使用代码和构件审查工具。

不充分的日志记录和可见性（CICD-SEC-10）

在当今快速发展的环境中，敌对者在追求实现其目标的过程中变得越来越狡猾。对于那些未能在这些环境中优先实施强大日志记录和可见性控制的组织来说，后果可能是灾难性的。如果没有必要的措施，检测到安全漏洞将成为一项艰巨的挑战。缺乏全面的日志记录和可见性控制使得组织处于脆弱状态，无法及时识别和应对安全事件。因此，缓解和修复的路径充满了障碍，并受到有限调查能力的制约。

为了防止这些潜在的陷阱，组织必须采取主动步骤来加强其工程环境。通过实施适当的日志记录和可见性控制，他们可以增强迅速有效地检测漏洞的能力。这种主动的方法使组织能够及时响应，减少安全事件的影响，并确保更顺利地进行缓解和修复。在这个竞争激烈的数字市场中，组织保持领先一步至关重要。

在企业中建立强大的监控和可见性能力至关重要，因为它使得可以利用日志机制来识别潜在威胁，并对安全事件进行深入调查。建议实施报警系统，以便在操作框架内识别异常和潜在的有害行为。

价值流映射

价值流图绘制是精益管理中的一种工具，涉及追踪创建产品或服务的各个步骤，从其开始到最终目的地——客户。通过价值流图，你可以清晰地看到每个阶段所投入的时间和精力，以及每个步骤的重要性。资源和数据都会在价值流图中显示，追踪它们在过程中的流动。

创建当前状态图作为团队的第一步是价值流图绘制中的常见做法。这指的是准确记录材料的物理移动以及信息在价值流中的流动的过程。下一步是团队开发未来状态图。换句话说，目标图代表了材料和信息在价值流中理想的流动方式。

持续重复这一行动是最直接且最优的方式，帮助自己和同事学会如何识别和欣赏价值。价值流图绘制主要应用于精益制造中。然而，各行业的管理者也可能从中获得显著的益处。

价值流管理

价值流管理是一种管理方法，优先改善公司价值交付的流动性和生产力，从客户需求开始，最终以客户满意为结束。这种方法所应用的精确策略，使企业能够有效地衡量并提升改进速度，从而减少将产品推向市场所需的时间，提高整体产出，提升产品质量，并优化期望的客户满意度。

价值流图绘制的主要目标是识别并最小化价值流中任何不必要的步骤或低效之处，最终提高特定价值流的整体效率。高效的浪费去除对于提升生产力和简化操作至关重要，从而帮助更好地识别浪费和质量问题。

浪费

精益一词指的是轻量化或缺乏多余的“脂肪”。精益操作的特点是没有浪费。精益操作可能产生的各种浪费，或称为 muda，通常用首字母缩写TIM WOODS来表示：

• 运输：将人员、货物和信息从一个地方转移到另一个地方

• 库存：提前存储物品、数据和组件，以备将来需要

• 运动：进行诸如伸展、旋转、拉动和推动等身体动作

• 等待：等待零件、组件、数据、指导或硬件

• 过度生产：生产超过紧急需求的产品

• 过度加工：指使用比实际需要更精确或更高质量的材料

• 缺陷：修订垃圾或错误的文档

• 技能：未充分发挥才能；在没有适当培训的情况下分配责任

精益运营框架围绕价值、流动、拉动和完美的原则展开，以最大限度地减少各种形式的浪费。

价值

客户始终是决定你在业务中所做的一切价值或重要性的人。要想成功，一家公司必须清楚理解客户认为有价值的内容。将资源投入到开发客户认为不值得的产品和服务中，等同于浪费财力和人力。如果你想了解客户的需求，你需要了解他们，并在每个可用的机会中征求他们的意见。

价值流图是精益方法学中用于描述流程图的术语。构建价值流图的目的是将每个过程的每个操作分类为不同的组别：

• 增值：从客户的角度进行提供价值的行为

• 非增值：从客户的角度来看无法提供价值的流程，必须立即废弃

• 本质的非增值：尚未消除的操作，这些操作没有实际用途，但却是法律或公司规定的

除了确定投入多少时间来创造价值，价值流图还展示了多少时间被浪费在存储或运输产品上。必须尽量减少存储或运输任何物品所花费的时间。

持续流动和持续改进

持续流动指的是一种生产系统，在该系统中，产品持续移动，无需等待时间，从而消除了物流和存储的需求。消除批次和排队是至关重要的，因为批量生产会导致闲置，且可视为浪费。排队意味着某一产品在前一个加工阶段已经完成，但下一个阶段尚未准备好接收更多输入。鉴于制造过程的最终阶段是将产品交付给消费者，因此至关重要的是，产品的生产节奏要与客户需求相匹配。你也可以用这种策略来构建服务。

苹果的持续流动和改进案例研究

在创造新产品时，苹果公司优先考虑客户的需求。深入理解客户的欲望、习惯和偏好是公司的主要目标。为了开发真正与消费者产生共鸣的产品，苹果公司进行详尽的用户研究，以获得能够塑造公司设计方向的反馈。

他们采用迭代设计过程，以便随着时间的推移使产品变得更好。为了测试和分析想法、交互和用户界面，设计团队构建了许多模型、原型和迭代版本。通过将用户反馈和可用性测试不断融入设计过程，苹果能够实现持续不断的改进循环。

在设计其产品时，苹果极力确保每个细节都完美无缺。苹果力求在每个方面都打造视觉美丽且高质量的产品，从材料选择到表面处理和组件配合。凭借 2.54 万亿美元的市值，苹果已经成为全球最大的公司，通过坚持这些理念和阶段走到了今天。

发现在制品（WIP）积压并形成排队现象，是识别瓶颈的一种方式。减少处理单个产品所需的时间或增加额外的计算能力，可能会在克服瓶颈的同时提高处理速度。尽管在瓶颈之前的 WIP 会随着速度的提高而消失，但新的瓶颈可能随时出现。

精益制造涉及按需拉动产品，而不是将它们推送通过系统；换句话说，除非客户要求，否则不生产任何产品。虽然必须保留一定的库存以满足当前需求，但通过实施持续交付等创新，您可以减少交货时间并增加产品变种。

精益系统通过持续追求不断改进来实现卓越。与其将成功与竞争对手进行比较，不如通过识别并消除公司内部任何不必要和浪费的活动来追求卓越。

发布管理模板

以下章节描述了几份能够帮助您完成日常发布管理任务的文档，包括软件发布检查表、业务规范文档、SRS、需求可追溯性矩阵文档和用例文档。

软件发布检查表

软件发布检查表是一份全面的文档，概述了软件开发团队在整个软件发布过程中必须遵循的行动和流程。这涵盖了从产品构思和创建到严格的质量保证措施和最终交付的所有方面。检查表作为一种预防措施，防止质量控制不充分，并确保客户要求的所有功能都准备好交付。检查表通常为几页长，并且被企业用于软件改进以及新软件应用程序的创建。

为帮助您创建自己的软件发布清单，请参考以下位置的模板：www.smartsheet.com/sites/default/files/IC-Release-Management-Checklist-9281_PDF.pdf。

业务规范文档

业务规范文档，也称为业务需求文档，是一个经过精心组织和正式化的关于即将开展的项目的声明。该文档的目的是阐明公司希望创建新应用程序或功能解决方案的理由。业务规范文档描述了组织面临的挑战，以及相应的项目将如何解决这些问题。通常，它包括对项目的财务影响的分析，包括如果软件完全不开发时的潜在优缺点。

为帮助您创建自己的业务规范文档，请参考以下位置的模板：assets.asana.biz/m/2dcf4dfc471895ad/original/Business-Requirements-Document-Template-PDF.pdf。

软件需求规格说明书（SRS）

软件需求规格说明书（SRS）是一个软件项目的综合性大纲，旨在为即将开发的软件产品设定使用目的，需求规格说明书为客户与企业之间的合同奠定基础。SRS 的目的是通过在设计和开发阶段之前对需求进行彻底评估，最大限度地减少未来的返工。它也可以作为评估产品的时间、风险和价格的合适框架。

为帮助您创建自己的 SRS 文档，请参考以下位置的模板：assets.asana.biz/m/6ac2683dd6006280/original/software-requirement-document-template.pdf。

需求可追溯性矩阵文档

需求可追溯性矩阵是一个正式文档，常用于发布管理和软件开发中。其目的是确保每个项目需求都已得到充分解决和考虑。作为大纲，它将项目中的每个需求与架构元素、测试场景以及与这些需求相关的其他交付物联系起来。它也可以作为确定产品的时间、风险和价格估算的合适框架。

若要帮助您创建自己的需求可追溯性矩阵文档，请参考此模板：www.projectmanager.com/wp-content/uploads/2022/08/Free_Requirements_Traceability_Matrix_Template_ProjectManager_WLNK.xlsx。

用例文档

用例是描述用户如何与系统交互的书面规范。每个用例都列出了为了达成特定结果所需的顺序行动，重点描述了开发应用程序、系统或流程所需的内容。值得注意的是，一个用例包含一个明确的起始点和终点，且其执行者旨在通过完成用例获得目标价值。

若要帮助您创建自己的用例文档，请参考此模板：static.dexform.com/media/docs/6584/use-case-template-2_3dac.pdf。

各章节问题的答案

本节包含本书每一章末尾问题的答案。

第一章

问题 1：SDLC（软件开发生命周期）指的是开发团队用来生产高质量软件的系统化方法，旨在实现最佳的成本效益。

问题 2：规划、分析、设计、构建、测试、实施和维护。

问题 3：软件开发生命周期仅限于软件组件的创建和测试。而系统开发则包括硬件、软件、人员和流程的设置与管理，构建一个完整的系统。

问题 4：SDLC 的主要目标是减轻风险，并保持开发工作的良好结构。与此相对，发布管理的主要目标是确保开发团队井然有序，并成功实现业务目标。

问题 5：软件开发生命周期主要强调应用程序的开发阶段，而 ALM（应用生命周期管理）采用更为全面的方法，涵盖程序整个生命周期。

问题 6：SDLC 包含几个不同的阶段，包括规划、设计、编码、测试和部署。与此相对，PDLC（产品开发生命周期）包括额外的阶段，如市场研究、产品规划和产品营销。

问题 7：发布管理保证软件发布按时交付，同时遵守预算限制并最小化潜在的中断。变更管理允许接受、记录并将变更传达给相关方，以促进对业务及其目标、需求和标准的正面影响。

问题 8：发布管理是监督软件发布的创建和分发的过程，包括其规划、调度、测试和部署。项目管理的目标是在一个特定项目的范围参数内确保项目的成功，例如规划时间限制、日程安排、财务和沟通。

问题 9：蓝绿部署产生两个相同的环境。在绿色环境中的测试通过后，应用程序流量会切换到该环境，蓝色环境将被废弃。金丝雀部署是一种逐步控制的发布策略，其中流量在现有版本和新版本之间进行分配。

问题 10：规划、分析、设计、构建、测试、实施和维护。

第二章

问题 1：系统开发生命周期。

问题 2：系统开发生命周期的主要目标是系统地、细致地追求信息系统的开发。软件开发生命周期旨在详细描述创建和维护软件系统所涉及的输入、输出和步骤。

问题 3：1953 年，保罗·尼凯特。

问题 4：赫伯特·D·贝宁顿，1956 年。

问题 5：托马斯·E·贝尔和 T.A.·塞耶，1976 年。

问题 6：请求、规划、设计和构建、测试、部署、部署后。

问题 7：帕特里克·德博瓦，2007 年。

问题 8：比利时根特，2009 年 10 月。

问题 9：1960 年。

问题 10：1960 年。

第三章

问题 1：本质上，ITIL 是一个管理组织 IT 基础设施的框架，旨在实现战略目标、创造商业价值并确保能力的基准。

问题 2：瀑布模型。

问题 3：初始化阶段、迭代步骤和项目控制清单。

问题 4：在 V 模型中，时间和开发进度从左到右推进，无法倒回过程。

问题 5：通过持续监控风险和检查中间产品，螺旋模型显著减少了大型软件项目失败的可能性。

问题 6：时间、资源、努力。

问题 7：经常且尽早地失败。

问题 8：DevOps 发布管理策略结合了沟通、自动化和分析。

问题 9：永远不会！

问题 10：每个阶段。

第四章

问题 1：持续发布是指用于确保客户能够访问公司软件产品的稳定和安全版本的自动化和手动流程的集合。其核心是持续部署（CD），这是一种统一的发布流程，结合了自动化构建、测试和部署步骤，旨在简化将新软件推向生产环境的操作。

问题 2：在实施审计追踪后，任何感兴趣的人都可以了解最近的修改上线花费了多少时间，为什么它是必要的，谁批准了它，以及前述阶段中的所有检查项是否都已完成。

问题 3：自动化测试在任何时候都适用。

Q4: 不要将变更审批流程作为阻碍创新的障碍，而应作为加速新功能交付给客户的过程的一部分。

Q5: 发布流水线的职责和责任是确保产品增强功能快速而安全地交付给最终用户，从源代码的更改开始，经过开发、测试和发布。

Q6: 用于将应用程序从开发、到 QA、再到生产的工具和流程，也可以用于灾难恢复和服务中断的故障转移。

Q7: 服务管理工具通过利用 API 自动生成变更票据并通知相关方，从而实现 CD 流水线与变更管理系统的无缝集成。

Q8: 变更的交付时间、变更失败率、部署频率、平均恢复时间。

Q9: 在发布日志中记录你的 CI/CD 流水线结果，并将其汇总到你的发布管理问题追踪产品、源代码管理和相关工具中。

Q10: 变更的交付时间。

第五章

Q1: 流程/系统思维、强化反馈循环，以及持续实验和学习的文化。

Q2: 采取左移（shift-left）的方法意味着在流程的尽早阶段就开始测试，而不是推迟到最后阶段才进行测试。

Q3: 快速反馈循环使你能够更快地构建安全、功能丰富且客户喜爱的系统。如果没有及时的反馈，就会在原因和结果之间产生差距，导致错误未被察觉，直到纠正错误所需的资源增加。

Q4: 消除孤岛的组织能够提高端到端操作的透明度。

Q5: 以 DevSecOps 为中心的工具扩展了现有的 DevOps 方法，如 CI/CD、自动化测试实践、系统监控和精简配置管理，通过无缝整合以安全为重点的工具和技术。

Q6: DevOps 的概念可以理解为一种文化范式，而不仅仅是存在孤立的个人或团队在各自领域内进行工具开发或协作。

Q7: 通过紧密集成数据系统、基于 CI/CD 的自助服务亭和运营专家的支持，推动自助服务以自动化日常业务流程。

Q8: DevOps 团队在更短、更规律的周期中运作。由于上一个开发周期所需的努力较少，因此发布的风险大大降低。

Q9: DevOps 的主要目标是提高客户满意度并加快交付。

Q10: 企业需要跨多种工具的轻松集成和执行，包括内部专有工具，以提供从客户创始到产品反馈的全面解决方案。

第六章

Q1: 是的，例如为业务部门生成报告，在非高峰时段关闭未使用的基础设施，并在下一个工作日前重新启动它们，用生产数据刷新开发数据库，进行自动化渗透测试等。

Q2: 团队需要统一的一组技术，以便在项目中协作高效地工作。

Q3: 这使得识别和解决代码中的 bug 和缺陷的任务更加高效，减少了从几小时到仅需几分钟的时间。

Q4: 随着新的代码更改的提交，持续集成服务器会监督一切并充当裁判。每当开发人员在代码库中提交工作时，CI 服务器会自动运行一组测试并记录结果。

Q5: 在持续交付中，有一个手动审批步骤，要求在允许将新代码更改部署到生产环境之前执行此步骤。而在持续部署中，自动化测试履行了这一角色，因此无需人工干预。

Q6: 提交、测试、构建、暂存、部署。

Q7: GitOps 是 DevOps 更广泛领域中的一个专门领域，它侧重于使用 Git 仓库有效地管理基础设施状态和应用程序部署。

Q8: 使用精心策划的自动化测试策略，持续测试确保软件开发团队能够实时获得反馈，使他们能够迅速消除尽可能多的潜在风险和缺陷，贯穿整个软件开发生命周期。

Q9: 开发人员甚至受益于直接安装在开发人员本地集成开发环境（IDE）中的自动化测试插件，例如 Eclipse、Microsoft Visual Studio 和 PyCharm。

Q10: 通过将应用程序的最新版本暴露给生产环境中少数消费者，你将测试阶段延伸到了软件交付生命周期的最后阶段。

第七章

Q1: 工作流是 GitHub Actions 中用于自动化工作流的 CI/CD 管道格式，包括测试、构建和部署应用程序。

Q2: ClickOps 是用来描述通过提供商的原生 Web 控制台手动配置云资源的过程。顾名思义，这个过程需要使用键盘和鼠标输入所有必要的信息。

Q3: AWS 访问密钥与 AWS IAM 用户相关联，并附带在 AWS 账户中以编程方式配置资源所需的 IAM 权限。

Q4: AWS IAM 用户必须被授予必要的角色，以便他们能够在 AWS 中配置资源。

Q5: Fork 是 GitHub 仓库的一个副本，它与原始仓库共享代码和可见性设置。

Q6: 安全组调节着它所关联资源之间的入站和出站网络流量。

Q7: Amazon ECS 集群是一个紧密集成的任务或服务集合，专门用于管理和执行 Docker 容器。这些容器运行在一组受管的 EC2 实例上。

Q8: 容器镜像仓库作为所有相关文件的中央仓库，简化了 Docker 容器的管理和分发，并允许进行更严格的版本控制。

Q9: 环境变量是内存中的一个对象，其值通常由操作系统或微服务从应用程序外部赋值，包含一个配对的名称和值。

Q10: README 文件提供了计算机软件目录或仓库内容的详细信息和使用说明。

第八章

Q1: 不足的流控机制、不充分的身份和访问管理、依赖链滥用、中毒的管道执行、不足的基于管道的访问控制、不充分的凭证、不安全的系统配置、未受管理的第三方服务使用、不当的工件完整性验证、不充分的日志记录和可见性。

Q2: 中央模式库治理模型、CI/CD 作为服务治理模型、集中管理基础设施治理模型。

Q3: 价值流映射创建了你的 CI/CD 流程和系统的可视化表示，提供了对整个 CI/CD 管道的全面理解。

Q4: Gitflow、GitHub 流程、主干开发、GitLab 流程

Q5: 扩展的主干开发可以分为短期存在的功能和修复分支。

Q6: GitLab 流程

Q7: 部署是将软件从一个受控环境迁移到另一个环境的过程。另一方面，发布是软件变更的精心挑选集合，旨在让最终用户体验。

Q8: 工件存储确保工件是不可分割的，并且与任何其他发布分开，避免任何形式的混合或干扰。配置存储是一个存放不同值的仓库，这些值在各种构建/发布配置中提供一致性。

Q9: 这些繁琐的方法增加了生产系统的风险暴露，因此增加了变更失败的概率，因为它们减缓了交付过程，导致开发者更少频繁地发布更大的工作批次。

Q10: 这有助于团队研究整个变更过程，寻找瓶颈，并识别潜在解决方案。

第九章

Q1: 范围、时间和成本。

Q2: 当你放宽质量标准时，不仅会损害产品的形象和整体可靠性，还会在后期的维护阶段给你带来额外的成本负担，尤其是在维护阶段。

Q3: 这种方法通过利用个人双方的优势和专长，旨在提高生产力和效率。通过协同工作，程序员可以在更短的时间框架内获得与传统单独编程相同的好处。

Q4: 精英表现团队首先克服的是在 DevOps 转型背后的人际挑战。

Q5: 时间。

Q6: 文化、自动化、精益、衡量、分享。

Q7: Scrum 和 Kanban。

Q8: 效率和减少浪费。

Q9: 涉及所有层级的组织成员，包括开发人员、系统管理员、安全专家和高层管理人员。

Q10: 这是由于不同企业和相关方在市场需求、行业考量、资源限制和接受变革的意愿方面存在显著差异。

第十章

Q1: 组织内领导层的坚定支持和积极参与。

Q2: 理论知识。

Q3: 授权、伦理、信任和耐心。

Q4: 自主性、拥有权和共同责任。

Q5: 软技能。

Q6: 应用程序生命周期的每一步，从规划和设计到测试和部署。

Q7: 引导团队避免参与指责型政治，而应专注于协作努力，旨在有效地解决问题并改进流程。

Q8: 反馈回路是对团队、系统和用户运作的自我评估，既通过定性也通过定量分析来衡量。

Q9: 来自消费者的反馈。

Q10: 仔细改进当前工作流程，以更好地满足最终用户需求的过程。

第十一章

Q1: 变更管理策略是一种有意识的方法，旨在帮助领导者有效地引导公司通过变革，同时减少干扰和潜在的不可预见结果。

Q2: 对变革背后的原因、预期结果和影响、所需的时间和资源以及需要评估的其他因素进行全面分析。

Q3: 一份书面记录，用于跟踪提出特定修改的人员、请求的日期和时间、变更请求的当前状态、其重要性级别以及其解决方案的详细信息。

Q4: 采取有条理的方法，通过您的软件发布检查清单为无误、有效和无缝的软件发布奠定基础。

Q5: 良好的领导力。

Q6: DevOps 的核心是消除障碍并优化交付价值给客户的流程。在解决问题的领域中，重要性不在于使用的工具，而在于识别并缓解痛点。

Q7: 非 DevOps 指标、无关指标和有争议的指标。

Q8: 绘制微服务架构，配置基础设施，定义并拆分团队，确定每个微服务的技术栈，设置冲刺，开发和测试，部署。

Q9: 不。

Q10: 您需要客户的反馈，以便首先创造他们真正想要的产品。

术语表

在本节中，您将找到本书中使用的术语表。

A

• 代理程序：部署在指定物理服务器上的程序，用于管理服务器内不同操作的执行。

• 敏捷：敏捷是一种软件开发技术，专注于通过迭代和协作方法实现灵活性、适应性和客户满意度。DevOps 使用敏捷方法，如 Scrum 或 Kanban，在短周期内开发软件，促进持续反馈、快速迭代和早期价值交付。

• 敏捷宣言：明确声明的价值观和原则，为一个迭代的软件开发过程提供指导，该过程关注用户需求。

• 敏捷组织：一个能够快速有效应对和适应预期及突发机会和挑战的动态公司。

• 敏捷项目管理：敏捷软件设计与开发是一种迭代和增量的方式，开发人员与用户直接协作，利用必要的知识启动规划和执行。

• 敏捷软件开发：敏捷是一种软件开发方法和态度，强调用户反馈、软件质量，以及及时适应变化和新产品需求的灵活性。

• AIOps：通过应用人工智能（AI）和机器学习（ML）算法，增强和标准化信息技术运维的实践。这包括容量规划、事件管理和监控等活动。

• AWS：这是亚马逊公司旗下的子公司，提供可扩展的云计算服务和应用程序接口（API）给个人、企业和政府组织。这些服务基于按使用量计费的定价系统，意味着客户只需为实际使用的部分付费。客户通常与自动扩展功能结合使用，该功能允许客户在应用请求量增加时分配额外的计算能力，并在需求较低时减少资源分配，从而在低使用周期中最大限度降低成本。AWS 提供的这些基于云的服务包含多种功能，例如网络、计算、存储、中间件和物联网（IoT）。

• 异常检测：异常识别，也称为离群点分析，是一种数据挖掘技术，用于查找数据集中超出或偏离正常范围、既定基准或预测趋势的数据点。这个识别过程至关重要，因为此类异常通常是非典型活动的指标，如潜在的欺诈行为、安全漏洞或网络安全攻击。

• Ansible：这是一个用于多种 IT 操作的自动化引擎，如云基础设施的配置和配置管理。Ansible 是一个免费的程序，它通过 SSH 连接、PowerShell 脚本或不同的 API 与多个软件模块进行通信。

• 反脆弱：“反脆弱”这一概念是由纳西姆·尼古拉斯·塔勒布教授提出的，用来描述一种系统特性，使得系统能够在面对压力、错误、缺陷或失败时提高其能力或性能。

• API 响应时间：这是软件性能优化的关键，因为它直接影响用户体验。API 调用响应的显著延迟可能导致客户不满，进而可能导致网站或应用的完全放弃。应用程序的有效性和可扩展性与 API 的响应时间直接相关。如果 API 遇到显著的响应延迟，可能无法在短时间内处理成百上千个请求。这会显著影响消费者应用程序的效率和可扩展性。

• API 版本控制：API 版本控制是软件开发中的一个重要过程，涉及管理 API（应用程序编程接口）随时间变化的修改和增强，同时仍确保与先前版本的兼容性。开发人员可以在不干扰当前依赖于该 API 的客户端或应用程序的情况下，提供新功能、增强功能或调整。

• 应用安全：应用安全涵盖了旨在实施安全软件开发生命周期的各种活动，通常由开发团队执行。最终目标是增强安全协议，从而识别、修复，并理想地预防应用程序中的安全漏洞。它涵盖了应用程序的整个生命周期，包括需求分析、设计、实现、验证和维护。

• 应用加固：应用加固是通过最小化漏洞和限制不必要的访问来增强应用程序安全性的过程。其目标是增强应用程序的安全性，防止注入攻击、DDoS 攻击、缓冲区溢出等漏洞的攻击。加固策略通过在应用程序和数据流周围实施多层保护来增强安全性，创建“深度防御”方法。这保护了基本的操作原则和机密数据。完全加固的应用程序只授予有合法需求的个人和系统功能访问权限。

• 应用基础设施：应用基础设施涵盖了所有必要的操作和计算资源，包括服务器、存储阵列和操作系统，这些对于有效设计、构建、管理和交付应用程序及其服务给最终用户至关重要。

• 应用迁移：将软件应用从一个计算环境迁移到另一个计算环境的过程称为应用迁移。许多可能的场景包括将应用基础设施从一个数据中心迁移到另一个，或者甚至从一个本地服务器迁移到由云服务提供商托管的服务器。

• 应用性能监控：应用性能监控，通常称为 APM，是一个持续的过程，用于监控被视为高度重要的应用程序的可用性。有效地监控性能指标和趋势可以早期发现并解决性能问题，确保最佳的用户体验。APM 旨在识别并解决复杂的应用性能问题，以维持所需的服务水平。它被认为是将 IT 指标转化为业务价值评估的过程。

• 应用程序编程接口（API）：这是一组定义好的协议和规则，能够实现不同软件应用之间的无缝通信和交互。它充当中介，允许系统之间交换信息，使企业能够与外部开发人员、供应商和内部部门交换其应用数据和功能。API 中的定义和协议促进了各个应用的无缝集成，提高了效率，促进了协作和创新。

• 应用发布自动化（ARA）：ARA 是一种简化的流程，自动化地将应用程序的打包和部署，包括更新，从开发到生产。这是通过利用软件功能如自动化应用程序发布、发布自动化、基础设施管理资源和应用程序分析来实现的。

• 工件：指软件开发过程中产生的任何物质副产品。软件架构、设计和功能通过工件来定义，如需求文档、类图、用例和其他统一建模语言模型。项目计划、商业案例、软件二进制文件和风险评估等文档也是开发过程的一部分。

• 自动扩展组（ASG）：自动扩展组是 AWS 的一项功能，它允许将多个 EC2 实例整合到逻辑组中，简化基础设施设计和管理。该组由相似的实例组成，可以根据工作负载需求增加或删除实例。

• 自动化部署：自动化部署使用软件工具和方法，将代码更改自动传送到测试、预发布和生产环境。自动化部署通常由事件触发，例如代码提交或合并请求批准。配置管理系统简化了寻找、记录和监控基础设施变更的任务。

• 自动化：这是指能够在几乎没有人工操作监督的情况下执行某个活动或程序的系统。通过自动化重复性任务，DevOps 活动变得更加高效，例如创建工作流、整合不同利益相关方使用的技术，以及生成即时反馈。这涉及将技术整合，打破不同领域工具之间的孤岛。

• 自治：指能够利用手头的资源进行调整，而无需依赖管理层次中更高层级的人或事物。

• 自动伸缩：自动伸缩是一种云计算技术，根据服务器群集的繁忙程度来调整计算能力。通常通过活跃服务器的数量来显示。例如，支持一个网页应用程序的服务器数量可能会根据同时使用该网站的用户数量立即发生变化。由于这些指标会在一天内频繁变化，而且即便服务器没有使用，运行服务器也会产生费用，因此通常需要“刚好足够”的服务器来应对当前负载，同时也要为突发的流量激增做好准备。此时，自动伸缩能够帮助通过减少低活跃度时的服务器数量和在高活跃度时增加服务器来实现这一目标。

• AWS CLI：这是一个工具，允许你通过在终端或命令行中发出命令与 Amazon Web Services 进行交互。AWS CLI 使得你可以直接在终端应用程序中执行与浏览器基础的 AWS 管理控制台相同的功能，且只需最小配置。

B

• 后台：应用程序的后台指的是软件的基本架构，用户无法直接访问。后台负责处理从前端接收到的数据，并执行特定任务，例如用算法进行计算，或从数据库中检索和保存数据。

• 备份：这是复制重要数据的过程，以生成一个可以在数据丢失或损坏时用于恢复数据的副本。该备份过程的结果是包含文件的存档。

• 行为驱动开发（BDD）：行为驱动开发（BDD）是一种迭代的软件开发方法，强调开发人员与业务利益相关者之间的协作。它包括定义用户故事，用户故事作为开发应用程序的基础。BDD 利用人类可读的领域特定语言（DSL）促进沟通和理解。

• 大爆炸：大爆炸方法缺乏其他发布管理模型中的面向过程特性；不需要提前准备。软件开发是该策略的主要关注点，允许程序员绕过规划阶段，直接进入代码生产阶段。

• 黑盒测试：黑盒测试是一种软件测试方法，它评估应用程序的功能，而不检查其内部结构或操作。该测试方法适用于所有级别的软件测试，包括单元测试、集成测试、系统测试和验收测试。

• 蓝绿部署：一种部署策略，涉及两个相同环境的共存：一个是生产就绪环境，另一个是新的环境。流量从蓝色环境无缝切换到绿色环境，从而在出现任何问题时能够轻松回滚。

• 瓶颈：任何限制过程或系统整体能力的因素。

• 分支：在源代码管理中创建文件的副本，以便多个开发人员能够同时修改相同的代码。

• 桶：桶是亚马逊简单存储服务（S3）的一个基本组件，旨在存储各种对象，主要包括不同形式的数据及其附带的元数据，后者提供数据的描述。

• 构建：构建可以指软件开发过程的最终产品，或者指将源代码转换为可执行计算机程序的步骤。通常，构建会在开发过程中的特定里程碑时生成，或者在代码被认为完成并可供执行时生成，无论是用于测试还是正式发布。

• 构建代理：构建代理是一个软件组件，接收来自 CI 服务器的命令并启动实际构建操作的执行。代理可以安装在与服务器相同的计算机上，也可以安装在独立的计算机系统上。后者通常是首选，以优化服务器性能。代理可以在与 CI 服务器相同的操作系统（OS）上运行，也可以在不同的操作系统上运行。

• 构建工件库：一个集中式的存储库，用于存放整个构建过程中使用的所有二进制文件。工件库有助于管理依赖关系和构建过程，提高安全性和团队之间的一致性，并促进自动化部署的可行性和可扩展性。

• 构建自动化：构建自动化是指自动化构建软件的过程，包括将计算机源代码编译成二进制代码、打包二进制代码和进行自动化测试等任务。

• 商业分析（BA）：商业分析涵盖了用于系统地分析和审查过往商业表现的专业知识、技术和方法。商业分析是一种旨在通过利用数据和统计技术，生成新的见解并增强对商业表现的理解的学科。

• 商业智能（BI）：商业智能是指公司用于分析和管理商业数据的方法和技术。商业智能技术包括一系列核心功能，如报告、在线分析处理、预测分析、数据挖掘、复杂事件处理、仪表盘开发、商业绩效管理等类似活动。

C

• 缓存：缓存是指用于临时存储数据的存储区域。这些数据随后被服务器、应用程序和网页浏览器访问，以提高内容加载速度。几乎所有的机器，无论是软件还是硬件，都会使用某种形式的缓存，缓存通常分布在多个位置。

• 节奏：在敏捷项目管理中，节奏指的是冲刺、迭代或发布的持续时间，通常以天或周为单位。节奏是指按规律间隔进行的事件和活动的连续序列，可以预测和确定其发生时间。在 DevOps 发布管理中，节奏为团队建立了结构化的框架，确保对任务和截止日期有清晰的理解，并确保在价值流中的工作进度。

• CALMS 模型：DevOps 的核心原则包括文化、自动化、精益实践、度量和共享。这个框架作为评估组织实施 DevOps 方法论准备情况的工具。

• 金丝雀部署：金丝雀部署是一种逐步发布新版本应用程序的部署技术，通常先发布给一部分用户或服务器。这种方法允许在全面上线之前，测试新版本的性能和可靠性。

• 容量测试：压力测试用于确定计算机、服务器或程序在发生故障之前能够承载的最大用户数。

• Certificate Authority (CA)：证书颁发机构是一个负责任的机构，负责颁发和撤销数字证书，并验证网站及其他在线实体的真实性。这个过程包括为在线企业颁发数字证书，其中包含加密凭证和密钥，以加密和保护数据在传输过程中的安全。这些数字证书用于验证域名所有权、认证身份，并在实体进行在线互动时增强彼此间的信任。因此，它们增强了互联网安全性，并在数字安全领域发挥着关键作用。

• Chaos engineering：这是一种故意向系统中注入故障和干扰，以评估其韧性并识别任何弱点的实践。这有助于确保系统能够在生产过程中处理突发故障。

• ChatOps：这是利用聊天应用、聊天机器人和互动通信工具，使 DevOps 任务更加有组织和高效的实践。

• Clean room：“洁净室”是指一种工程化空间，保持空气中颗粒物浓度极低。它具有主动清洁、良好的隔离性和良好的污染控制。此类房间通常用于工业生产中的所有纳米级工艺，包括半导体制造，以及科学研究。为了保护房间内操作的材料，必须保持洁净室内无尘和其他空气中的有机物，如蒸发粒子。

• Cloud computing：这是一种广泛使用的 IT 策略，通过互联网利用虚拟服务器来收集、处理和存储数据、运行应用程序以及管理资源。它是使用专用服务器或个人电脑进行该特定目的的替代方案。

• CI/CD：持续集成/持续交付（CI/CD）的缩写，构成了现代 DevOps 方法论的基础。CI 确保最新的代码被定期添加到中央代码库，每天多次进行自动化单元测试并生成新的软件构建。如果测试成功，CD 确保新版本的软件将在不间断服务的情况下部署到预生产和生产环境。CI/CD 工作流确保及早发现和解决任何缺陷，从而保证产品持续可用。

• Cluster：集群通过将多个网络实例（如虚拟机、裸金属服务器等）视为一个实体来实现负载均衡、自动伸缩和高可用性。

• Commit：提交是指将源代码推送到 Git 仓库，导致代码被存储并进行版本控制。

• 合规性水平：在达到预定义的性能和可靠性目标的背景下，“合规性水平”指的是观察到的符合程度。通过此方法评估系统或服务与已定义的标准、基准或目标的一致程度。在进行合规性评估时，需要将实际表现与已设定的目标进行比较，目标可能包括可用性、反应时间或错误率。通过它可以评估一个组织系统的有效性和效率，并识别可以改进的领域，同时保证所期望的性能和可靠性水平持续达成。

• 配置漂移：软件和硬件设置因手动或临时性修改（例如未提交回版本控制的热修复）而与主版本不兼容的过程。配置漂移在许多情况下是开发团队技术负担的重要来源。

• 配置管理：一种方法，包括定义和维护系统一致设置的过程。此外，这些解决方案还包括用于自动化 IT 基础设施的 SysAdmin 工具，如 Ansible、Puppet 和其他类似的程序。

• 约束：在项目的背景下，约束是指项目必须在其内进行操作的限制。时间、金钱、质量、范围、资源和风险是与项目相关的六个主要限制。管理这些约束要求管理者在各方面找到平衡，以确保项目的有效完成。

• 约束（理论）：一种理论框架，用于确定哪些约束最阻碍朝着目标的进展，并制定计划去消除或显著改进这些约束。

• 容器：容器是一个自包含的软件单元，包含应用程序代码、库和依赖项。它被设计为可移植的，并可以在多个平台上执行，例如桌面计算机、传统的 IT 系统或云环境。

• 容器化：在软件工程中，容器化指的是在各种网络资源上实施操作系统级虚拟化或应用程序级虚拟化的做法。这使得软件应用程序可以在被称为容器的独立用户空间中运行，无论环境是基于云的还是非基于云的，也无关特定类型、服务提供商或平台。

• 容器编排：容器编排涉及自动化系统中运行和管理容器所需的各种操作任务。这包括容器配置、部署、扩展、管理、负载均衡和网络等任务。

• 持续交付：一种软件工程策略，强调使用持续集成、自动化测试和自动化部署，使软件开发和部署能够快速、可靠且可重复进行，且几乎不需要人工干预。

• 持续部署：一种高效的软件开发实践，确保每次代码更改都会经过完整的管道流程，并无缝地部署到生产环境中，导致频繁且自动化的生产部署。它执行持续交付的所有功能，但整个过程完全自动化，没有任何人工干预。

• 持续开发：采用持续开发和敏捷方法的软件开发方式有很多相似之处。与一次性进行大规模改进不同，持续开发方法通过不断的小规模改进，允许在代码完成并经过测试后，立即发布给用户。软件开发、测试和更新生产环境的发布都可以通过持续开发进行简化和自动化。

• 持续集成：一种软件开发方法，当代码提交到源代码控制仓库时，涉及重新构建源代码的某个分支。这个过程通常扩展到涵盖生产环境中应用程序的分发、安装和测试。

• 持续智能：持续智能是一种战略方法，将实时分析整合到公司运营中，通过分析当前和过去的数据，建议应对事件的适当行动。为了促进决策和辅助，它利用多种技术，如增强分析、事件流处理、业务规则管理和机器学习。

• 持续质量：一个关键概念，强调在整个软件开发生命周期中保持高质量的重要性，从定义需求到开发代码、测试和运营。持续质量还特别重视协调应用程序代码管道。当代码在环境之间手动迁移时，存在许多可能会危及产品或软件应用质量的风险。

• 持续安全：持续安全指的是在软件交付管道中嵌入安全程序，以便在软件开发生命周期的每个阶段发现并解决安全漏洞。

• 持续测试：在软件交付管道的所有环境中执行自动化测试，以便迅速评估代码构建的质量，且无需人工干预。

• Cron 作业：这个术语指的是定期调度的操作，在特定时间在服务器上执行特定的脚本。

• CRUD：在计算机编程领域，持久化存储的基本操作通常被称为 CRUD，代表创建（create）、读取（read）、更新（update）和删除（delete）。用户的文本是对某个来源或引用的指代。CRUD 也偶尔用于表示简化访问、查询和通过计算机生成表单和报告修改数据的用户界面原则。

• 文化：文化指的是公司内部员工普遍持有并遵循的思想、价值观、信仰、实践和行为的集合。它也指在 DevOps 环境中对集体责任感的体现。

• 网络安全：网络安全包括使用技术、措施和实践来防止网络攻击或减少其后果。网络安全致力于保护个人和企业的系统、应用程序、计算设备、敏感数据以及金融资产，防范基础的和破坏性的计算机病毒，以及复杂且高成本的勒索软件攻击，和其他任何属于这一范围的威胁。

D

• 数据库：数据库是一个精心排列和有条理地组织的数据集合，存储在计算机系统中。数据库通常利用相互连接的表格来存储信息，每个条目包含特定字段中的相关数据。数据库管理系统（DBMS）负责管理表之间的关系，并执行添加、更新条目及根据查询显示数据等任务。

• 数据库管理：数据库管理包括创建、执行和维护一个组织良好的数字数据集合，通常称为数据库。数据库管理的主要目标是有效且安全地存储、整理、检索和修改数据，以支持组织内各种应用、流程和决策。

• 深度防御（DiD）：通过采用深度防御（DiD）网络安全策略，结合不同的安全技术和流程，可以更好地保护组织的网络、网站资产和资源。物理、技术和管理控制层的安全解决方案是分层安全的关键，因此这两个术语有时会互换使用。这种方法确保攻击者无法访问受保护的网络或本地资源。

• 完成定义：这是软件开发中关于完成任务所需满足的具体标准的共识。

• Dev：指的是参与软件开发项目的个人。

• DevSecOps：这是将安全操作和流程融入 DevOps 工作流的实践，能够自动执行关键的安全任务。其目标是在工作流的最早阶段将安全性纳入其中，以减少漏洞和潜在的风险。

• 部署：这是将更新的软件传递给利益相关者的行为。在 DevOps 环境下，部署是完全自动化的，确保一旦更新被生产和测试完成，就能够及时交付给用户。

• 部署管道：部署管道是一个自动化的过程，表示软件从版本控制到最终用户的迁移过程。

• DevOps：这是信息技术文化中的一个范式转变，侧重于通过在系统导向框架内应用敏捷和精益原则，快速交付 IT 服务。DevOps 优先考虑人类及其共同的道德和价值观，旨在改善运营和开发团队之间的协作。DevOps 解决方案利用现代技术，特别是自动化工具，在开发的每个阶段都能利用一个高度可编程和动态的基础设施。

• DevOps 转型：这是一个关键过程，涉及在公司内部整合和执行最新的 DevOps 原则和方法。它包括拆除开发和运营团队之间的障碍，促进轻松的合作、自动化测试和持续的软件产品交付。

  为了有效地实施 DevOps 转型，企业需要经历重大文化变革，彻底改革现有流程，并采用促进自动化和持续交付管道的先进工具和技术。各种方法和实践，如云原生开发和基础设施即代码，有可能显著改变企业的运营。

• 数字化转型：数字化转型是采纳以客户为中心、技术导向的战略，涵盖公司各个方面，包括业务模型、客户互动和运营流程。它运用人工智能、自动化、混合云和其他技术进步，利用数据并促进复杂的工作流，加速并增强决策制定，快速响应市场变化。最终，它改变了消费者的期望并创造了新的商业机会。

• Docker：这是一个开源平台，用于创建、传播和操作软件容器。它提供了一个多功能框架，用于构建云基础设施，并允许最佳利用云资源，成为现代云计算的基石。

  Docker 通过让软件开发人员将他们的应用程序打包成一种被称为容器的格式来简化应用程序的开发、测试和部署过程。该容器封装了运行时、库、系统工具、配置文件、依赖项和脚本等应用程序运行所需的内容。

• Dockerfile：这既是一种文件格式，也是一个全面的机器可读指令集，用于自动化生成容器镜像的过程。它清晰简洁地描述了生成过程中的所有命令，便于简化 Docker 容器的创建和部署配置与管理。

• Docker Swarm：这是由 Docker 组织自己开发的一个容器编排框架。它是一个全面的工具，可以实现 Docker 容器的集群和调度，允许同时执行大量容器，通常以微服务的形式。然而，它的功能不及 Kubernetes，且已被认为过时。

E

• EC2：亚马逊网络服务（AWS）的核心产品 Elastic Compute Cloud 提供了大量虚拟服务器，用于创建和启动基于云的应用程序。

• Egress：Egress 指的是数据从私有网络离开，进入更广泛的互联网或其他公开可访问的网络的过程。尤其在基于云的环境中，受监管的数据传输对效率和安全至关重要，这一过程对网络操作至关重要。

• EKS：EKS，全称为 Amazon Elastic Kubernetes Service，是亚马逊提供的一项托管服务。它使用户能够轻松地在 AWS 基础设施上部署和操作 Kubernetes，免去手动配置集群的需要。

• Elasticity：在 DevOps 范畴内，Elasticity 指的是根据需求波动灵活调整计算资源的能力。它涉及利用云基础设施或容器化技术，实时动态分配和释放计算资源，确保在响应波动工作负载时实现最佳的性价比。

• Environment：一个应用程序的环境包含了所有资源、操作系统、库、应用程序接口、框架、实用工具和其他必要的组件，确保软件在不同生命周期阶段的正常运行。

• 企业应用分发：企业应用分发平台通过各种分发渠道（如直接用户链接、企业门户网站、专有应用商店或移动设备管理与企业移动管理系统）来促进受政策启用的移动应用程序的安全部署和管理。

• 企业应用商店：企业应用商店是一个展示专门为目标终端用户设计的软件的在线平台。该平台通常为员工建立，提供访问各种软件应用程序的途径，如云服务、许可和移动应用。软件选项的可用性取决于组织授权的程度，包括经济型月度订阅和高价软件许可。企业应用商店的用户界面通常非常友好、直观，类似于苹果的 App Store 和 Google Play Store 等流行的应用商店。

• 企业应用集成（EAI）：企业应用集成是为解决不同企业应用之间连接不足的问题而提出的方案。它涉及开发能够促进企业应用之间数据无缝交换的技术，从而避免对数据库设置或应用程序本身进行大量修改。这种方式能够提高工作流程效率，并改善数据的可访问性。

• 错误预算：错误预算指的是在特定系统或流程中，预定的允许错误或故障的分配或阈值。它表示在不影响用户体验或系统整体可靠性的前提下，系统能够容忍的错误、故障或停机期。通过设定错误预算，团队能够有效地分配精力，在创新和稳定性之间找到平衡，并就资源分配做出明智决策，从而减少错误并提升整个系统的性能。

• 错误日志：错误日志是记录应用程序、操作系统或服务器在运行过程中发生的任何错误的文档。文档中包含有关事件发生的时间、严重性以及潜在原因的详细信息。检查错误日志和错误消息是确定应用程序停机或性能问题原因的最直接方法。

• 事件驱动架构：事件驱动架构是一种软件架构模型，其中系统生成事件或通知，并设计为响应、接收和识别其他事件。

• 事件日志：事件日志是按顺序组织的记录，记录组织结构或流程中发生的各类事件，通常用于识别和解决问题以及进行全面检查。日志内容可以包括各种事件，如错误、警告、信息性消息和用户活动。每个事件通常都会标注日期，并包含补充信息，如事件的来源、严重性级别以及与事件相关的任何数据。

• 演化原型开发：演化原型开发，也称为面包板原型开发，与其他原型开发策略不同。使用演化原型的主要目标是通过系统化的过程构建一个高度弹性的模型，并不断完善它。这一方法基于这样一个理念：演化原型是新实施系统的基础，随着时间的推移，可以逐步纳入未来的改进和额外的需求。

• 探索性测试：探索性测试是一种软件测试方法，涉及学习、测试设计和执行的同时进行。该方法强调探索，依赖测试人员的专业知识来识别其他测试方法可能未能充分发现的缺陷。通过探索性测试，测试人员在没有预定测试用例或系统先验知识的情况下分析系统。测试人员不拘泥于严格的测试流程，而是立即进行测试，并在实时中做出即兴判断，决定测试的内容。

F

• 快速失败：快速失败是一种战略方法，涉及尝试某件事情，及时识别其失败，获得即时反馈，相应地调整，并再次尝试。

• Fargate：Amazon Fargate 允许用户在托管的基础设施（如 弹性容器服务（ECS））上运行 Docker 容器，而无需管理底层的服务器资源。您可以按照无服务器计算的定价模型进行设置；无需手动配置集群，只需按使用的资源付费。

• 应急处理：在计算机科学领域，应急处理是指将资源分配给解决突发问题。这个词指的是故障排除而不是功能集成。在软件开发过程中，应急处理可能涉及增加工程师来修复在产品发布临近时发现的代码问题。

  许多企业已为应急情况做好准备，但反复发生的紧急情况表明缺乏计划或效率低下，浪费了本可以用于其他地方的资源。全面的灾难恢复计划（DRP）可以预见并可能预防灾难，减少紧急应对的需求。

• 流程：流程指的是个人或物体在一个过程中的多个步骤或阶段中流动的情况。DevOps 的第一种方式是提高系统内流程的效率。

• FluentD：FluentD 是一个基于 Ruby 的开源程序，用于收集和分析数据。该系统支持从各种工具（如 Elasticsearch）进行数据输入，并提供广泛的仪表盘数据输出，这些仪表盘可以通过多个插件进行配置。

• 全栈开发者：全栈开发者是一位熟练的专业人士，具备构建网站前端（用户界面及交互组件）和后端（数据存储与处理机制）的技能。前端和后端需要不同的技能集。由于全栈开发者负责开发过程的各个阶段，因此他们需要在这两个领域都有较高的专业水平。

• 全栈可观测性：这指的是对分布在 IT 环境中的技术栈中每个元素的实时性能进行持续监控。本质上，它涉及到对云应用程序、服务、基础设施、本地服务器、Kubernetes 集群及其他相关元素的深度了解。

  全栈可观测性技术利用从公司整个 IT 基础设施中获取的遥测数据，包括指标、日志和跟踪。这使得能够对应用程序和基础设施的性能、维护及相关活动进行全面分析。同时，它们帮助公司理解 IT 组件之间的相关性和关系。

• 功能测试：功能测试是一种软件测试形式，用于验证软件系统是否符合功能需求和规格。功能测试旨在通过提供适当的输入并将结果与指定的功能标准进行对比，来评估软件程序中每个组件的功能。

G

• Gemba：Gemba 是一个日语词汇，指的是“实际地点”或“真实地点”。在商业语境中，它通常指的是价值产生的地方。

• Git：Git 是一种流行的分布式版本控制系统（VCS），广泛应用于软件开发和 DevOps 方法论中。它使得多个开发者能够在项目开发中协作，便于跟踪源代码的修改，并有效管理源代码库。Git 提供了分支、合并和解决冲突等功能，促进了分布式团队之间的流畅协作和版本控制。

• GitHub：GitHub 是一个广泛使用的基于网页的平台，用于托管代码，并在标准 Git 功能的基础上加入了更多的能力。GitHub 经常是大多数开源和专有软件项目的开发中心。

• GitLab：GitLab 是一个开源的基于网页的 Git 界面，专为在 DevOps 环境中实现最佳性能而设计。它通过集成支持 CI/CD 技术，如 GitLab CI，达到了这一目标。

• .gitlab-ci.yml。Runner 是一个小巧高效的代理，利用 GitLab CI/CD 的协调员 API 处理 CI 任务。它执行任务并将结果报告回 GitLab 服务器实例。管理员可以创建 runner，并在 GitLab 用户界面中查看它们。Runner 可以专门为特定项目定制，或者在所有项目中使用。

• GitOps：这是一种 DevOps 方法，利用 Git 仓库作为基础设施和应用定义的主要来源，确保精确性和一致性。通过 Git 提交，可以轻松地实现基础设施和应用配置的修改，从而实现版本控制、自动化部署以及在出现问题时的快速回滚。

• GitOps 操作符：这是一个 Kubernetes 操作符，用于自动化和监督应用程序及资源的部署。它通过对 Git 仓库进行更改来实现这一点，并持续监视声明状态和实际状态之间的差异。

• Governance：IT 治理包含一系列指令和程序，旨在确保组织内部所有 IT 操作与其业务目标对齐。这些 IT 操作包括 IT 团队的组织、IT 资产的采购以及 IT 基础设施的实施。

H

• Helm：这是一个 Kubernetes 应用程序管理工具。通过利用易于用户读取的机器可读规范文件，Helm 简化了大规模操作中微服务的管理，确保复杂容器编排和基础设施开发的顺利进行。

• Helm Chart：这是一个高效的 Kubernetes 工具，简化了容器化应用的部署和管理。Helm Charts 利用易于用户读取的机器可读规范文件，确保在 Kubernetes 中复杂的容器编排和基础设施开发的顺利运行。

• HTTP：超文本传输协议（HTTP）是支撑万维网的基础技术。它通过超链接渲染网页。HTTP 作为应用层协议，位于网络协议栈的其他层之上，促进了网络设备之间数据的传输。一个 HTTP 流的例子是客户端机器发送请求，服务器机器发送响应。

• HTTP 请求：客户端发起 HTTP 请求到服务器的主机，以检索构建内容所需的资源。在发出请求时，客户端使用包含所需数据的统一资源定位符（URL）来请求服务器资源。

• HTTPS：HTTPS 是一种更安全的 HTTP 协议迭代版本，使用加密技术来保护网络流量的安全。它通过实现 TLS（之前的 SSL）来加密和验证在 web 服务器和客户端浏览器之间传输的数据，增强了安全性。最初，SSL 主要用于保护网站的登录凭据和财务数据，防止未经授权的拦截。然而，现在大多数 web 服务器都广泛使用 SSL 来加密所有通信，并确保每个网页在传输过程中完整无损，防止任何未授权的修改或损坏。

I

• 幂等性：数据管道中的幂等性指的是能够多次执行相同操作而不会改变初次应用结果的能力。这个特性确保了系统的一致性和可靠性，尤其是在分布式系统中。

• 镜像：在 Docker 中，镜像指的是容器的固定且不可更改的表示；这一特性通常被称为不可变性。Docker 镜像包含生成功能性 Docker 容器所需的指令，可用于独立和基于微服务的应用架构。

  此外，这个术语还可以应用于系统镜像，也称为硬盘快照，这是计算机系统当前状态的镜像，可以随时存储并应用到硬盘。

• 事件管理：事件管理涉及及时处理和解决公司内部服务中断或事件。在 DevOps 环境中，事件管理程序的主要目标是最小化系统不可用的持续时间，加快服务恢复，并从事件中提取有价值的见解，以主动减少事件的重复发生。事件管理通常包括识别、优先排序、解决和分析事件的过程。

• 基础设施即代码（IaC）：基础设施即代码（IaC）是利用编码来配置和管理 IT 基础设施的做法。将代码作为 IT 基础设施的管理框架，涉及使用软件开发技术，如持续集成（CI）、持续交付和版本控制。IaC 依赖于三个核心组件来实现：资源池化、软件定义的智能和专用的应用程序接口（API）。

• 基础设施即服务（IaaS）：IaaS（基础设施即服务）是一个 IT 管理框架，在这个框架中，计算资源和必要的技术作为服务提供，用于支持不同平台和应用的运行。

• 基础设施管理：在 IT 组织中，基础设施包括提供 IT 服务所需的硬件、软件和其他系统，这些服务必须符合服务级别协议（SLAs）。IT 基础设施管理包括对 IT 指导方针、规定、硬件、数据、人员和外部关系（如供应商或安全人员）的监督，以确保 IT 服务的无缝和有效运行。

• 基础设施监控：基础设施监控包括收集和分析来自不同基础设施元素（如服务器、网络和应用程序）的数据，以验证其性能、可访问性和可靠性。DevOps 团队使用监控技术和方法来深入了解基础设施的状态，识别问题，并采取主动措施以缓解潜在的瓶颈或故障。

• 基础设施弹性：基础设施弹性是指基础设施保持其运作并能迅速从中断或灾难中恢复的能力，目的是最小化对最终用户的负面影响。

• 入口：入口是指信息从另一个网络（通常是公共网络）进入私有网络的过程。云计算在很大程度上依赖于正确的入口管理，这对于维护网络的完整性和安全性至关重要。

• 入口控制器：这是指一个 API 对象，用于控制集群中的服务如何从外部源访问，通常使用 HTTP。负载均衡、SSL 终止和基于名称的虚拟主机是入口控制器可能提供的服务。

• 实例：简单来说，实例是应用程序运行的虚拟机。更一般的定义是执行应用程序所需的相互依赖组件的集合，例如 Docker 容器。

• 集成测试：集成测试是软件开发生命周期中的一个阶段，在这个阶段，整个应用程序或一组多个软件模块被组合在一起，作为一个整体进行测试。集成测试的目的是评估整个系统或组件是否符合特定的功能需求，并且它发生在单元测试之后，系统测试之前。之前已经进行过单元测试的模块将作为集成测试的输入。然后，这些模块被组合成更大的聚合体，并应用集成测试计划中设定的测试。最终，适合进行系统测试的集成系统就是集成测试的输出。

• 问题跟踪：问题跟踪是一个系统化的过程，使开发人员和质量保证专家能够监控新出现的问题和新功能的进展，从发现到解决的整个过程。

• IT 基础设施：企业的 IT 基础设施，有时称为信息技术基础设施，包含了提供企业内部 IT 服务所需的完整硬件、软件和网络资源。IT 基础设施作为提供服务或资源的手段，可以是在企业内部，也可以是对外部消费者。软件应用开发者利用 IT 基础设施来促进他们的开发方法，而各类公司则通过采用技术提升效率并创造价值。

• 迭代：迭代指的是一个单一的开发周期，通常持续一到两周。

J

• Jenkins：Jenkins 是一个广泛使用的开源自动化服务器，广泛应用于 DevOps 领域，用于构建、测试和部署软件应用。该平台为持续集成和交付工作流提供了一个强大的框架，使团队能够自动化构建过程、执行测试并可靠地发布软件。Jenkins 通过广泛的插件生态系统提供了极大的灵活性，证明它在各种 DevOps 场景中都非常灵活。

• Jenkins 作业：Jenkins 作业在自动化软件开发生命周期中的许多任务中发挥着至关重要的作用。这些独立的操作或过程优化了构建、测试和部署软件应用等重要步骤。Jenkins 通过使用多种作业类型，支持流程的定制，从而确保灵活性，以满足不同项目的需求。这些任务展示了持续集成和交付的重要性，通过使团队能够简化和优化开发流程，提高效率和可靠性。

• JVM 堆：Java 堆内存是Java 虚拟机（JVM）的一个重要组成部分，负责在程序运行时动态分配和管理对象。Java 应用程序利用运行时数据区作为对象存储和检索空间。当应用程序启动时，JVM 会为堆预留一定的内存，这个内存量可以通过命令行参数进行修改。

• JVM 线程：Java 线程是程序在执行过程中遵循的指令序列。Java 中执行的所有操作都在线程内进行。每个 JVM 环境中的应用程序本质上都包含线程，至少有一个，即使没有显式调用。代码执行从主程序开始，这个过程是在主应用程序线程中执行的。事实上，代码中生成的所有线程实际上是由 Java 虚拟机本身实例化的，并且由它进行管理。

K

• 改善（Kaizen）：改善是日本的一种商业方法，专注于工作场所实践和高效运营的持续改进。其目标是企业发现改进价值流各个方面的方法，以为客户创造更好的成果。

• 看板（Kanban）：这是一种视觉管理方法，帮助项目经理监督和调节开发项目中的工作流，以实现最大效率和可观察性。

• 看板板（Kanban board）：这是一种用于精益制造项目的视觉工具，用来直观表示工作、限制同时进行的任务数量，并提升速度或工作流。它可以帮助敏捷和 DevOps 团队高效管理日常任务。看板板通过卡片、列和持续改进，帮助服务和技术团队高效履行职责，并战略性地调节可管理的工作负载。

• 型（Kata）：这表示日本文化中对“正确”方法的遵循或文化教育的概念。它是一种系统化的方法，用于实现目标并克服障碍，可以在整个组织中实施。

• Kubernetes：Kubernetes 最初由 Google 开发人员创建，是一个开源框架，简化了容器的自动化部署、管理、扩展和执行。Kubernetes 因其扩展性和适应性而闻名，能够快速迁移工作负载到本地、混合或公共云基础设施。

• Kubernetes 定时任务（CronJobs）：Kubernetes 定时任务是 Kubernetes 集群中的一种特定资源，允许对重复操作或批处理作业进行调度和自动化。Kubernetes 定时任务可以在特定时间调度容器化作业或 Pod，使用 cron 表达式确定调度时间，类似于 Linux 操作系统中的传统 cron 作业。这些作业能够执行一系列操作，包括数据备份、常规维护和数据处理，确保它们会按预定的时间框架持续完成。

• Kubernetes 自定义资源定义（CRD）：自定义资源是对 Kubernetes API 的扩展，可能是 Kubernetes 标准配置中没有提供的。这表示对单个 Kubernetes 部署的修改。尽管如此，Kubernetes 现在更具模块化，因为许多核心功能都是通过自定义资源构建的。

• Kubernetes 操作器: Kubernetes 操作器是一个自动化程序，旨在管理 Kubernetes 环境中的应用程序。操作器充当自动系统管理员。用户可以通过组织一个自定义过程来扩展 Kubernetes API 的功能，该过程负责监控应用程序实例。它们的责任是维持应用程序的预期状态，预期状态由自定义资源定义 (CRD) 确定。该程序可以进行扩展、更新或重新启动。

• Kubernetes 持久卷 (PV): 持久卷 (PV) 是一个持久存在的实体，指定了集群的存储能力，并且其生命周期超过了 Pod 或节点的生命周期。PVs 与 Pods 具有不同的生命周期，是集群中的额外资源。因此，Kubernetes 管理员可以在运行应用程序之前独立配置存储。为了为 Pods 分配存储，需要一个持久卷声明对象。

• Kubernetes 持久卷声明 (PVC): 持久卷声明 (PVC) 是在 Kubernetes 集群中正式请求存储分配的方式。当用户生成具有特定存储标准的 PVC 时，控制平面中的控制循环会主动搜索一个相应的持久卷，并在它们之间建立绑定。

• Kubernetes Pod: 在 Kubernetes 中，Pod 是最基本的可部署对象。Kubernetes Pod 是一个包含一个或多个容器的集合，这些容器执行应用程序的实例。节点是托管 Pod 的工作机器，为容器提供一个配置良好的环境，以便容器能够以最佳效率执行。这包括提供依赖关系和资源，例如将数据存储在跨容器共享的卷中、分配内部 IP 地址以促进容器间通信，以及配置容器执行，包括端口使用和容器镜像版本等规格。

• Kubernetes 服务质量 (QoS): 这指的是 Kubernetes 中的一个标准，用来决定 Pods 在整个系统中的调度和管理方式。服务质量 (QoS) 根据不同应用程序的资源需求分配资源。Kubernetes 超越了容器编排的范畴，还包括应用程序资源的管理和执行调度。它允许开发人员为应用程序建立请求和限制，包括 CPU 和内存资源。

• Kubernetes 副本: Kubernetes 副本是可以为 Pods 提供自动恢复的复制实例。与许多其他进程和服务一样，Pods 也容易发生故障、错误、驱逐和终止。例如，当系统资源突然减少，节点压力增加时，Pods 可能会出现故障，并在之后被移除。

• Kubernetes 工作负载：Kubernetes 工作负载是定义 Kubernetes 集群中应用程序和服务配置、部署和管理的基本组件。这些工作负载决定了应用程序行为的关键方面，包括执行的实例数量（Pod）、如何根据需求调整大小，以及它们如何与彼此及其他服务进行通信。实质上，Kubernetes 工作负载充当了协调容器化应用程序的框架，确保它们在符合指定要求的情况下可靠高效地执行。

L

• 交货时间：交货时间指的是将进行中的工作转化为完成状态所需的时间。在软件开发的背景下，这一概念通过将对代码所做的修改转移到生产环境中来体现。

• 精益：精益是一种生产策略，强调减少浪费和改进流程，以增强向客户交付价值的能力。

• 精益 IT：精益 IT 是指在 IT 产品和服务的创建与运营过程中应用精益原则。

• 遗留应用程序：一个在日常运营中发挥关键作用的重要信息系统，即使它可能依赖于较旧的技术。信息系统专业人员面临的主要障碍之一是用新技术替换过时的应用程序和系统。当组织更新或修改技术时，确保与仍在使用的现有系统和数据格式的兼容性至关重要。

• 日志文件：日志文件是一种数据文件，保留了来自软件、操作系统或机器的各种信息，如事件、进程、消息和其他数据。它们提供了用户行为的有价值的洞察，在监控 IT 环境中起着至关重要的作用。你可以通过日志文件判断系统是否正常运行，并识别任何潜在的系统或网络安全问题。

• 日志轮转：日志轮转自动管理日志文件的大小，防止存储空间被填满并且系统性能被拖慢。更新日志文件的一种方式是重命名当前文件，并用新的文件替换它以存储最新信息。这通常是定期进行的，可能是每日或每周。

M

• 托管检测与响应：托管检测与响应（MDR）通过经验丰富的网络安全团队持续监控，利用先进的威胁情报资源和技术，帮助企业进行风险管理。通过高效地优先处理、调查和响应事件，MDR 提升了运营效率，并保护了宝贵的数据免受既有风险和新兴风险的威胁。

• 平均故障间隔时间（MTBF）：平均故障间隔时间是一种衡量应用程序、计算机系统或基础设施组件可靠性的指标。它是通过计算系统故障发生之间的算术平均时间来确定的。

• 平均恢复时间（MTTR）：平均恢复时间（MTTR）是指应用程序、计算机系统或基础设施组件从中断或灾难事件中恢复所需的平均时间。这类工具的实例包括自复制的 Kubernetes Pods 到故障转移电源供应系统。通常，这类恢复努力的恢复时间很短，通常以秒为单位进行衡量。

• 微服务：微服务是面向服务的软件设计策略的一种表现，特别是将单体应用分割成一组松散连接的服务的策略，这些服务处理特定的操作任务。这些服务使用经济的协议和 API 进行高粒度的通信，提供灵活且可扩展的产品功能。

• 微服务架构：微服务架构是一种将软件创建为一系列相互独立的、功能自足的服务，并且这些服务可以在地理位置上有所分布的网络化方法论。

• 移动应用：移动应用，也称为应用程序，是一种专门为在移动设备上运行（如智能手机或平板电脑）而开发的软件。移动应用通常为消费者提供类似于个人计算机上的服务。应用程序通常是紧凑的独立软件模块，功能较为简单。

• 移动应用管理：移动应用管理（MAM）是指管理和分发公司环境中使用的私有创建和公开可用的移动应用程序的软件和服务。这包括公司发放的设备以及“自带设备”（BYOD）上的移动操作系统，如智能手机和平板电脑。

• 基于模型的测试：基于模型的测试是一种软件测试方法，测试用例是通过指定被测试系统（SUT）功能的模型生成的。视觉模型可以作为被测试系统预期功能的表现形式，也可以作为测试方法论和测试环境的表示形式。通过利用模型指令，可以自动生成测试，包括模拟测试数据和自动化测试。

• 单体架构：单体架构指的是一种传统的软件设计，其中程序作为一个单一、独立的实体构建，并且与其他应用程序相互独立。“单体”这一术语通常与庞大且普遍的事物相关，这也准确地反映了单体架构在软件工程中的特点。单体架构指的是一个统一且广泛的计算网络，将所有业务考虑因素整合到单一的代码库中。要修改这种类型的应用程序，必须通过查阅整个代码库来更新完整的堆栈，从而构建和交付修订版的服务器端接口和后端基础设施。这导致改进变得零散且需要大量的时间和资金才能完成。

• Muda：Muda 是一个日语术语，表示徒劳、无效或浪费的状态。在精益流程工程的背景下，Muda 被归类为三种浪费类型之一。

• 多云架构：多云架构指的是一种 IT 基础设施策略，涵盖使用多个公共或私有云，或两者的组合，以及本地基础设施。通过实施多云架构，企业可以战略性地将重要的工作负载、应用程序和数据分配给多个云服务提供商。借助这种流动自由，组织可以根据多个因素选择服务提供商，如地理覆盖范围、性能能力、安全控制和定价结构。最终结果是一个精简的云基础设施，利用每个提供商的独特优势，满足特定场景，弥补不足，并实现组织目标。

• Mura：Mura 是一个日语术语，表示不均匀、不一致或缺乏同质性的状态。在精益流程工程的背景下，它被归类为三种浪费类型之一。

• Muri：Muri 是一个日语术语，表示由于极度困难而导致不合理、无法实现或超出个人能力的状态。在精益流程工程的背景下，它被归类为三种浪费类型之一。

N

• 网络：计算机网络是一个复杂的互联计算设备的布局，旨在促进信息的传输和交换。计算设备涵盖了从手持设备到超级计算机的各种设备。这些设备通过物理媒介如光纤进行互联，尽管它们也能够建立无线传输来完成这一任务。

• Network bottleneck: 网络瓶颈是计算机网络中的一种情况，数据流因网络中某个特定的链路或组件的容量或处理能力不足而受到严重阻碍或减少。这种限制可能导致数据传输变慢，并降低整体网络效率。

• Node: 一个 Kubernetes 集群包含称为节点的物理或虚拟计算机。其目的是作为 Pods 的宿主，而 Pods 负责运行 Docker 容器。

  节点还可以指任何连接在网络中的计算机或类似设备，这些设备能够传输、接收或分发数据。笔记本电脑、文件服务器、打印设备和网络路由器都是本地网络中节点的例子。

• Node pool: 这是 Kubernetes 中一组具有相同规格的集群节点，它们能够作为一个单元进行管理和控制。

• Non-functional testing: 非功能性测试是一种软件测试形式，验证软件程序的非功能性特征。其目的是基于多个未通过功能性测试解决的因素评估系统的准备情况。检查系统的可扩展性、效率、可用性、可靠性和性能都是非功能性测试的例子。

• NoOps: NoOps 指的是一种 IT 环境，其中管理、优化和保障 IT 服务与应用的任务已经被自动化、抽象化，或委派给传统中央运维单位之外的人员。"NoOps"一词没有精确的定义，导致供应商、分析师和客户之间有多种不同的解释。它用于描述不同级别的自动化、可以实施的特定 IT 组件以及 IT 运维职责的分配。

O

• Observability: 可观测性指的是获得对复杂分布式系统的功能和交互的全面理解的能力。它包括通过监控、日志记录和追踪活动来洞察应用程序和基础设施的性能。

• OpenShift: OpenShift，由 Red Hat 创建，是一个高质量的商业化容器编排解决方案，适用于 Kubernetes，并可以在本地云基础设施中运行。

• Open source: 开源指的是一种软件分发模型，版权持有者为用户提供访问应用源代码的权限，并赋予其阅读、修改和分发源代码的权利，可以为任何目的使用。

• OpenTelemetry：OpenTelemetry 是一个项目，提供了一套全面的工具和资源，用于从应用程序和服务中收集遥测数据。它旨在简化过程，并确保跨不同系统的兼容性。能够访问遥测数据对于监控和观察现代分布式系统至关重要。使用 OpenTelemetry 可以让开发人员全面分析应用程序的行为和性能，这有助于有效的监控、问题解决和性能优化。

• 运营智能：运营智能是指在组织的信息技术环境中，利用数据分析方法对实时生成或收集的数据进行处理。运营智能旨在收集来自 IT 基础设施各个部分的数据，实时分析这些数据，并以标准化格式提供给 IT 运维人员。这样，他们可以根据分析结果迅速采取行动并做出决策。

• 运维：在 DevOps 的上下文中，运维指的是参与日常职责的专业人员，这些职责包括共同部署和管理 IT 基础设施与服务。

• 编排：编排是简化与信息技术相关的操作程序。它包括管理容器和基础设施配置等任务。本质上，它是一个通过使用预先编写的自动化脚本执行预定任务的过程，这些脚本由如 Terraform 等专为配置管理设计的用户友好型应用程序辅助完成。

P

• 结对编程：结对编程是一种软件开发方法，其中两名开发人员共同开发一个功能，允许他们在编写过程中同时评估彼此的代码，目的是提高代码的整体质量。

• 打补丁和祈祷：打补丁和祈祷技巧是指一种软件开发和网络安全策略，涉及表面性地解决现有缺陷或漏洞，并依赖于希望这些措施能够修复问题或减轻未来攻击的影响。这是那些缺乏资源以更积极主动进行软件开发或安全防护的公司常用的做法。

• 管道：结合自动化、工具和技术，贯穿软件开发生命周期，以优化创建和交付软件给用户的方式。需要注意的是，没有一种普遍适用的方法来构建 DevOps 管道，因为它们在结构和执行上因不同组织而异。然而，自动化、CI/CD、自动化测试、报告和监控是大多数 DevOps 管道的常见组成部分。

• 平台即服务（PaaS）：平台即服务（PaaS）为开发人员提供一整套语言、库、服务和工具，以便在云中创建和发布应用程序，而无需关注底层操作系统架构及相关基础设施。

• 操作手册：在 Ansible 中，操作手册是一组部署基础设施的指令，提供关于执行一系列命令以完成特定任务的全面指导。

• 预测分析：预测分析是指一系列技术和方法，利用当前和过去的数据进行分析，从而对未来的事件做出准确的预测。预测分析涵盖了各种数学建模和计算机科学方法，旨在利用以往事件来估算未来事件发生的概率或机会。

• 产品负责人：产品负责人（PO）是敏捷团队中的一个关键角色，负责确保团队交付的产品最大程度地满足利益相关者和客户的需求，并最大化团队的价值交付。作为公司与其技术和商业战略人员之间的主要联络人，产品负责人代表团队客户的声音，并在更广泛的产品管理职能中发挥着核心作用。正因为如此，团队能够以最符合各方利益相关者需求的方式来发展解决方案。

• 生产：部署流程中的最终阶段，在这个阶段，产品将被目标用户所使用。

• 资源配置：资源配置指的是设置和实施 IT 系统资源的过程，无论是在现场还是在云环境中进行。在企业计算领域，这个术语通常与虚拟机（VMs）和云资源实例相关联。

• 公钥基础设施（PKI）描述了一个加密框架，用于支持 TLS 证书的使用。假设双方都信任一个独立的组织——证书颁发机构，PKI 允许一方使用证书确认另一方的身份。这种数字身份验证能确保互联网网站和受保护网络上的资产的合法性，同时保障网络连接的安全性。

R

• 实时仪表盘：实时仪表盘是一类图形用户界面，呈现与业务职能、过程或目标相关的绩效指标或关键数据，以直观且易于理解的方式展现。实时界面为 IT 操作员和其他人员提供最新的公司绩效、安全性和运营数据。

• 回归测试：回归测试是一种在代码更新后执行的软件测试，旨在验证该更改是否引入了新的缺陷。新代码的加入可能会与现有代码产生冲突逻辑，从而引发各种问题。通常，QA 团队会维护一套针对关键功能的回归测试用例，每当有代码修改时便反复运行这些测试。此做法旨在优化测试效率，并尽量减少测试所花费的时间。

• 发布：软件发布是将软件产品的新版本或增强功能引入目标用户群的过程。这个过程包括软件最终版本的开发和发布，可能包括修复问题、引入新功能、完善现有特性或提升整体性能。软件发布过程是软件开发生命周期的重要组成部分，确保产品满足客户需求，并准备好在实际环境中实施。

• 发布管理：发布管理包括软件构建在不同阶段和环境中推进时的系统化协调、组织和规范。这个全面的过程涉及软件发布的详细规划、调度、测试和部署，符合软件开发生命周期的要求。

• 发布编排：发布编排是一个帮助协调和自动化流水线中各个步骤的过程，最终实现应用程序的发布，包括将价值传递给客户。它涵盖了从代码提交到版本控制系统，到代码部署到生产环境供使用的整个过程。发布编排管理的一些职责包括在出现问题时通知技术和业务相关方，并为每次发布维护所有操作记录。

• 回滚：回滚是指将数据库或程序恢复到先前定义的状态的过程，既可以自动执行，也可以手动进行。回滚通常发生在部署失败或新软件发布出现问题时。

• 滚动发布：滚动发布，通常也称为滚动更新，是一种软件开发模型。软件改进是通过持续的、逐步的步骤进行开发，而不是通过离散的版本发布。用户可以随时升级程序以获得最新版本，并且鼓励用户经常进行更新。

• 滚动更新：滚动更新是一种无中断的应用程序更新过程，逐个实例地完成。它利用 Kubernetes 容器编排平台，确保应用程序在整个过程中持续可用，提升整体用户体验。

• 运行手册：运行手册作为一份全面的指南，提供执行业务常规操作的详细说明和步骤。其目的是确保这些任务能够一致且高效地执行。

S

• S3：Amazon 简单存储服务（S3）是 AWS 提供的一种存储服务，它允许你安全地存储各种类型的文件，包括照片、音频和视频。它为你的数据提供了更强的可扩展性和安全性。用户可以随时随地从互联网上轻松存储和访问数据。它支持高可用性、强安全性，并能与其他 AWS 服务轻松集成。

• SSL 证书：数字证书用于认证网站并确保其安全。SSL（安全套接字层）是一种网络协议，它通过建立加密链接来保护客户端与 Web 浏览器之间的通信。简而言之，SSL 证书通过防止恶意第三方截取、读取或篡改传输的信息来保证互联网安全。

• SSL/TLS 握手：SSL/TLS 握手负责在用户浏览器和 Web 服务器之间建立安全加密的通信通道，确保用户数据和交易的安全，防止未经授权的访问或篡改。

• Scrum：Scrum 是一种敏捷框架，通过迭代、时间敏感和渐进的方法来完成复杂的项目。

• 安全智能：安全智能涉及对用户、应用程序和基础设施的数据进行持续监控和分析，以评估和管理组织中的 IT 安全风险。其目的是提供实用且全面的见解，最大程度地减少风险并减轻各类组织的运营负担。

• 自助部署：自助部署使用户不仅能够启动业务流程，还能够终止和重启这些操作。许多自助服务应用程序还提供工作进度监控，允许用户追踪他们的工作。为实现这一点，最终用户可以使用基于 Web 的应用程序，这些应用程序具有用户友好的界面，或使用他们日常工作中所使用的业务生产力工具。

  商业用户比以往任何时候都更加期待并偏爱自助自动化，以便在需要时获得所需的信息。这不仅提高了用户体验和客户满意度，同时也减少了 IT 部门的工作负担。

• 无服务器计算：无服务器计算是一种云计算架构，它允许开发者专注于编程，而无需管理服务器。云服务提供商负责服务器管理的所有方面，包括扩展和维护。

• 无服务器框架: 无服务器框架是一个开源框架，用于简化无服务器应用程序的部署和管理。它支持多个云服务提供商，并通过隐藏其固有复杂性简化无服务器架构的操作。

• 无服务器监控: 无服务器监控使企业能够观察、增强和优化其无服务器应用程序。无服务器监控需要专门针对这种系统的事件驱动架构（EDA）进行监控。无服务器监控系统从服务器 less 基础设施的所有组件收集数据，汇总资源利用统计数据，并提供日志和分析。它们使得能够观察无服务器功能的活动，跟踪资源利用情况，并为可行分析建立自动警报。

• 服务水平协议（SLA）: 服务水平协议（SLA）是服务提供商与客户之间的合同承诺，确保诸如可用性、责任等重要标准的某些质量保证。未能满足协议中规定的某些要求将导致对服务提供商的惩罚措施，通常以货币形式，如返还、减少或信用形式。

• 服务水平指标（SLIs）: 服务水平指标（SLI）是企业用来量化和评估其向客户提供的特定服务组件的精确度量。SLIs 是影响服务整体可靠性的 SLAs 组成部分。SLIs 可以帮助企业识别持续的网络和应用程序问题，从而使更有效的修复工作成为可能。

  SLIs 通常用百分比来量化，其中 0%代表性能较差，100%代表完美的性能。SLIs 是 SLOs 的基础构建模块，后者是公司努力实现的具体目标。SLOs 将决定强调哪些 SLIs。

• 服务水平目标（SLOs）: SLOs 使 DevOps 和站点可靠性工程（SRE）团队能够通过使用 SLIs 有效地衡量和评估其 SLAs 的维护和遵守情况。SLO 框架规范了这些团队如何讨论系统的可靠性或所需的修改方式。

  SLO 是 SLA 的重要组成部分，后者是服务提供商与客户之间的合同。SLA 确保客户的技术在一段时间内始终保持指定的标准或服务水平。如果服务提供商未达到指定的标准，则必须支付罚款。SLO 管理指的是维护和测量 SLA 的过程。

• 面向服务架构（SOA）：面向服务架构（SOA）是软件工程中的一种架构范式，强调模块化服务，而不是单体设计。因此，它也被应用于软件设计的背景中，其中应用组件通过网络使用协议与其他组件通信。服务指的是一个独立且自包含的功能模块，能够远程使用并且可以自主控制或修改。

• 向左移动：向左移动指的是在开发过程中更早阶段进行测试、质量保证和性能评估的策略。向左移动的测试不仅验证软件功能，还确保符合客户要求。这使得开发人员和利益相关者能够识别可能改善客户体验和功能的改进措施。在开发过程的早期实施这些修改，可以减少在代码发布后实施它们的费用。

• 站点可靠性工程（SRE）：SRE 是谷歌提出的一种软件工程方法论，旨在确保大规模复杂系统的可靠和高效运行。其目标是通过结合传统软件开发和 IT 运营的方法论，缩小两者之间的差距。

• 软件开发：这是创建和维护应用程序、基础设施或其他信息系统架构组件的系统化过程。它包括创建、指定、设计、编程、文档编写、测试和解决 bug。程序开发包括源代码的创建和维护，但也包括将目标程序从构思到最终形式的所有步骤。通常会进行整体过程的规划和结构化，软件开发涉及的步骤包括研究、原型设计、修订、修复和维护。

• 软件部署：软件部署包括使软件系统或升级能够被预期用户访问的所有必要程序、流程和行动。大多数 IT 公司和软件开发人员结合人工和自动化流程来实施软件升级、修补程序和全新应用程序。软件部署可能包括多个过程，如产品发布、配置、部署、测试和性能评估。

• 软件测试：软件测试是用于验证软件产品是否符合指定标准，并确保软件产品没有缺陷的过程。它涉及使用手动或自动化方法执行软件或系统元素，以评估一个或多个期望的特性。软件测试的主要目标是发现并定位与指定要求相关的缺陷、不一致或遗漏。

• 版本控制：版本控制，也称为源代码管理，涉及系统地监控和管理对源代码所做的修改。版本控制系统是为帮助开发团队管理源代码修改而设计的软件工具。随着开发环境的快速发展，版本控制系统已成为软件团队提高生产力和效率的必要工具。它们对于 DevOps 团队尤其有利，因为它们有助于减少开发时间并提高成功部署的频率。

• 冲刺：冲刺是开发团队被分配在预定时间框架内完成特定任务的过程。冲刺通常持续大约两周，尽管它们的时长可以从一周到一个月不等。

  冲刺较短的持续时间的主要好处在于，它迫使开发人员集中精力实施小的、渐进的修改，而非大规模的、广泛的变更。因此，所需的调试工作大大减少，使程序的客户能够享受更流畅的产品体验。

• 软件质量保证（SQA）：软件质量保证（SQA）是一个系统化的过程，旨在监督和评估所有软件工程活动、技术和交付物，以确保其遵循既定的基准。这可能涉及确保遵守已建立的标准或模型，如 ISO/IEC 9126（现已被 ISO 25010 取代）、SPICE 或 CMMI。

  它包括管理人员、管理员或工程师可以应用的准则和实践，用于评估和审计与软件相关的活动和产品，确保它们遵守基于标准的质量要求。

• 预发布环境：预发布环境用于在程序正式部署到生产环境之前评估其最新版本。预发布的目的是尽可能地复制实际的生产环境，以最大限度地提高在软件发布前发现并解决软件问题的机会。

• 结构化日志：结构化日志指的是以标准化和逻辑化的方式系统地记录错误和访问事件，从而使任何应用程序或相关方都能够轻松地进行研究、搜索和分析。JSON 是最常用的结构化日志格式，因为它作为系统间和应用内消息解析的公认消息格式。

• 受测系统（SUT）：SUT 指的是正在进行测试以确保其正常工作的系统。从单元测试的角度来看，受测系统包括测试中所有非预定义代码元素的类，比如代理或模拟。每个单独的组件都可以用其独特的配置进行定制，配置内容包括唯一的名称和版本。这使得在进行大量测试时具有可扩展性，并能够根据被测试系统的质量和数量提高精度。

T

• 技术债务：技术债务是指在软件开发或其他 IT 领域中，为了快速实现解决方案而采取了限制性较强的方案，而没有选择可能需要更多时间实施的更优方法所产生的隐性开销。类似于财务债务，如果技术债务得不到偿还，它会像“利息”一样积累，使得进行改进变得更加困难。

  未解决的技术债务会导致软件的不稳定性增加，并且增加未来修改的成本。就像财务债务一样，技术债务本身并非完全负面，它可能是推动项目进展所必需的。相反，一些专家认为，“技术债务”这一比喻可能会淡化其后果，导致在修复它所需的关键任务上的优先级不足。

• 技术栈：技术栈包含了创建和运行单一应用程序、集成或移动应用所需的完整硬件和软件组件集。软件工程师可以选择使用一个预配置的技术栈作为构建新应用的基础，或者根据特定需求选择和集成软件，来创建一个技术栈。

• 遥测：遥测是一种自动化过程，通过使用传感器和其他数据收集工具，从远程源头收集、传输和量化数据。它利用通信技术将数据传输到中央位置，然后对数据进行分析，以监督和管理远程系统。遥测数据用于提升客户满意度，并监控安全性、应用健康、可靠性和性能。

• Terraform：Terraform 是由 HashiCorp 开发的一个重要基础设施编排应用。Terraform 通过使用声明式清单简化了基础设施部署和管理的过程。这些清单可以作为代码存储和版本控制，从而确保一致性并实现无缝的 DevOps 工作流程。

• Terraform Cloud：Terraform Cloud 是 HashiCorp 提供的一个实用的 SaaS 解决方案。它使得管理基础设施的协作变得更加容易，提供了基础设施代码的版本控制，并且提供了一个直观的用户界面来有效管理 Terraform 架构。

• Terraform 模块：这是一个标准化配置文件的集合，这些文件被安排在指定的目录中。Terraform 模块作为特定目的资源组的封装，从而减少了为相同基础设施组件编写冗长代码的必要性。Terraform 模块是通过引入预先存在的可重用代码块来扩展当前 Terraform 配置的一种方式，这样就减少了为类似基础设施组件编写新代码的需要。

• terraform plan 命令，你将在结尾处始终获得一个总结。这个总结提供了将要创建、更新或删除的资源数量信息。

• terraform.tfstate，它位于执行 Terraform 的目录中。它是在执行 terraform apply 命令后生成的。

  该文件包含配置中指定的资源与您当前基础设施中存在的资源之间的 JSON 格式映射。执行 Terraform 时，它会利用这个映射来将现有基础设施与代码进行对比，并执行必要的修改。

• 测试自动化：这涉及使用专门的软件，独立于正在测试的程序，来控制测试的执行并将实际结果与预期结果进行比较。

• 测试驱动开发：测试驱动开发是一种软件开发方法论，它要求在完全开发产品之前，将软件需求转化为测试用例。它强调在整个开发过程中持续地将软件与所有测试用例进行对比测试。这与传统的顺序开发方法不同，后者先开发软件，之后才编写测试用例。

• 测试环境：测试环境指的是一个精心设计的服务器基础设施，用于支持开发团队构建的测试用例的执行。测试环境不仅仅是配置一个用于测试执行的服务器，它还包括硬件和网络组件的设置与安排。

• 约束理论：约束理论（TOC）是一种管理方法，认为任何可控系统在实现更多目标的能力上都受到最小约束的限制。在 TOC 中，总是存在至少一个约束。TOC 通过一个集中过程来发现这一约束，并随后重新组织业务的其他方面。因此，TOC 采用了广泛使用的说法：“链条的强度取决于它最弱的环节。”因此，组织和过程容易因为某个“弱”的个体或组件而遭遇失败或中断，这可能会削弱或负面影响整体结果。

• 可观察性的三大支柱：日志、度量和跟踪是可观察性的三大基本组成部分。这三种数据输出为云计算和微服务架构中系统的整体健康状况和运行情况提供了不同的视角。

  日志是系统事件和问题的记录，可以以多种格式存储，包括纯文本、二进制或带有元数据的结构化格式。

• 度量：指的是可量化的指标，用来评估系统的性能和效率，包括 CPU 利用率、响应时间和错误频率等因素。

• 跟踪：这些是对通过系统的单个请求或事务的可视化描述，能够帮助识别瓶颈、依赖关系和问题的根本原因。

  通过整合和分析日志、度量和跟踪，能够获得系统的全面视角，帮助识别那些阻碍业务目标的问题。

• 三种方式：三种方式是由著名的首席技术官、作者和学者 Gene Kim 创造的一套原则，旨在精确定义 DevOps 的本质：

  • 第一种方式：提升工作流程的效率，涵盖从业务流程到开发阶段，再到运营活动，最终为客户带来好处。

  • 第二种方式：增加工作流程中的反馈循环数量，并提高接收反馈的速度。

  • 第三种方式：培养和促进一种积极鼓励持续实验和学习的文化。

• 扔到墙那边：“扔到墙那边”是一个习惯用语，用来描述完成自己部分的任务后，将其转交给下一个团队或小组。这个成语的起源可以追溯到商业和项目管理领域。它代表了一种将任务或作业分配给某人，而没有提供详细信息或指导的行为。在这个语境下，“墙”象征着一个比喻性的障碍，隔开了组织内部的多个部门或团队。这个词经常在合作、知识交流或委派过程中的透明度明显不足的情况下使用。

• 价值时间：价值时间是指企业从某个特性中获得实际收益所需的时间。

• TLS 证书：这是一种电子证书，帮助网络上的系统验证另一个计算机系统的身份，并通过安全套接字层（传输层安全协议，TLS）建立安全的网络连接。

• 工具链：工具链是指利用一整套专门的工具集来自动化整个过程，从开始到结束，例如自动化代码测试、发布和部署的过程。

U

• 单元测试：单元测试是一个代码片段，用于验证应用程序代码中较小且自包含的代码段的正确性，通常是函数或过程。单元测试的目的是验证代码块是否按预期执行，符合开发者的概念性推理。单元测试只能通过输入和记录的输出与代码段进行交互，输出可以是对的也可以是错的。

• 单元测试：单元测试是检查和评估最小工作代码片段的过程。软件测试对于确保代码质量至关重要，是软件开发的核心组成部分。将软件编写成小的功能单元，并为每个代码单元创建相应的单元测试，被视为软件开发中的最佳实践。最初，你可以通过可执行代码的形式表达单元测试。随后，每当对软件代码进行修改时，自动执行上述测试代码。通过这种方法，在测试失败的情况下，你可以迅速找出包含缺陷或错误的具体代码段。单元测试促进了模块化设计模式的使用，并提升了测试覆盖的广度和质量。自动化单元测试使你或你的工程师能够分配更多时间进行开发。

• 正常运行时间：正常运行时间是指计算机系统、服务或设备正常运行并可供使用的时间段。它量化了系统在没有明显中断或故障的情况下运行的持续时间。正常运行时间通常以百分比表示，用于评估系统的可靠性和效率。较高的正常运行时间意味着系统更加可靠和可访问，而较低的正常运行时间则表示服务中断的概率较大。正常运行时间是评估服务水平协议（SLA）并确保客户体验可接受的关键指标。

• 用户验收测试：用户验收测试（UAT）是由最终用户或客户进行的一种测试，用于验证并批准软件功能，在将其过渡到生产环境之前进行。用户验收测试是在测试过程的最后一步进行的，紧随其后的是功能测试、集成测试和系统测试。

V

• 商业价值：商业价值是指从商业活动中产生的可衡量和量化的效益，可以是有形的、无形的，或者两者的结合。价值的意义超越了企业的经济价值，涵盖了其他形式的价值，如员工价值、客户价值、供应商价值、管理价值和社会价值。其中一些类型的价值在货币背景下并没有直接量化。

• 价值流：价值流包括所有为客户交付价值所涉及的步骤，从需求的提出开始，直到客户实现这一价值为止。通常与公司流程对齐，价值流从第一个想法开始，经过不同的开发阶段，一直延续到交付和支持。客户始终处于价值流的中心，从开始到结束。

• 价值流管理：这是指一组专注于提高开发团队运营效果和效率的实践，旨在提供卓越的客户体验。价值流管理（VSM）最重视加速交付优质产品、特性和更新，确保客户能够感受到这些改进带来的价值。VSM 起源于精益生产及其与丰田生产系统的关联。该方法论旨在加速实现价值和生产卓越产品的时间。通过弥合高层管理、敏捷开发和 DevOps 团队之间的差距，VSM 帮助软件开发组织协调其工作，满足客户需求。

• 价值流图：价值流图是精益管理的一种实践，分析从初始构想到最终交付给客户的产品或服务的开发过程的当前状态和未来状态。价值流图是一种可视化工具，清晰地展示了特定过程中的关键步骤，并提供了每个阶段所涉及的时间和数量的明确度量。其目的是展示材料和信息在整个过程中的流动，以期发现可以改进的领域。

• 速度：速度是衡量开发团队在一次冲刺中完成了多少产品待办事项的指标。因此，它可以用来预测未来的完成情况或确定某一特定任务的完成时间。需要特别注意的是，速度是衡量价值产生速度的指标，而不是团队表现的指标。

• 版本控制：指的是对源代码所做的更改进行有序的跟踪和管理。版本控制系统（VCS）是专门为简化程序员团队对源代码修改的管理而创建的软件工具。由于开发条件的快速进展，版本控制系统已经发展成为软件团队提高效率和生产力的必备工具。它们对于 DevOps 团队尤为有用，因为它们帮助缩短开发时间并提高交付成功率。

• 虚拟化：这是一种能够实现物理计算机硬件最佳利用的过程，也是云计算的基础。虚拟化通过软件在计算机硬件上建立一个抽象层，使得单台计算机的物理组件（如处理器、内存和存储）可以划分成多个虚拟机（VMs）。每台虚拟机独立运行，拥有自己的独立操作系统，并作为一个独立的实体存在，同时只消耗计算机物理硬件的一部分。

• 虚拟机（VM）：这是一种计算机仿真，可以执行与物理计算机几乎相同的操作，例如运行程序和操作系统。虚拟机存在于物理系统上，通过名为虚拟机监控器（Hypervisor）的软件来利用计算能力。虚拟机监控器将机器本身的物理资源集中为一个集中的池，按需独立分配和共享，从而使多个虚拟机可以在单一物理机上运行。

W

• 浪费：浪费指的是任何活动中从客户的角度看不产生价值的部分。浪费可能表现为时间使用不当、材料过度使用和人力资本的低效利用。然而，浪费也可能与技能部署不匹配以及规划不足有关。

• 瀑布模型：瀑布模型是一种将开发操作组织成一系列连续阶段的方法。每个阶段都建立在前一个阶段的交付成果之上，并涉及专门的任务。这种方法是工程设计领域特定领域的典型特点。在软件开发领域，瀑布技术因其有限的迭代和灵活性而闻名。进展沿着线性路径前进，经过多个阶段，包括构思、启动、分析、设计、构建、测试、部署和维护。瀑布模型代表了最初为软件开发采纳的软件开发生命周期（SDLC）方法。

• Web 应用程序安全：Web 安全涵盖了广泛的安全措施，旨在保护你的用户、设备和网络免受来自互联网的网络攻击，例如恶意软件和钓鱼攻击。这些攻击可能导致数据泄露和损失。通过实施防火墙检查、入侵防御系统（IPS）扫描、沙箱化、URL 过滤以及其他安全和访问限制，可以帮助降低用户无意中访问有害文件和网站而给公司带来的安全风险。

• Webhook：Webhook 是一种回调函数，它通过 HTTP 协议实现两个 API 之间的轻量级、事件驱动的交互。Webhook 作为一种手段，使得 Web 应用程序能够从其他应用程序接收最小化的数据。然而，它们也可以被用于在 DevOps 和 GitOps 配置中启动自动化工作流。

• 白盒测试：白盒测试的目的是通过验证输入和输出的流向，并研究其基本架构和代码，来改善软件的设计、性能和安全性。与白盒测试相比，黑盒测试则是从外部人员或客户的角度进行测试。相反，白盒测试在软件工程中是基于应用程序的底层机制，并专注于内部测试。

• .github/workflows 目录（文件夹）位于仓库内，它可以包含多个工作流，每个工作流能够执行一组独特的任务。例如，你可以创建一个独立的工作流来构建和评估拉取请求，另一个工作流用于在生成发布版本时部署应用程序。

• 进行中的工作（WIP）：WIP 代表进行中的工作，表示团队目前正在进行但尚未完成的产品待办事项。简而言之，这项工作目前“处于开发中”。尽管这看起来很简单，但 WIP 对正在进行的冲刺、后续的冲刺、待办事项，以及团队的整体表现和心理健康有着重要影响。

Y

• YAML：YAML 是一种灵活且易于理解的数据序列化语言，经常用于编写配置文件。YAML 的设计本质上是为了优先考虑简洁性和可读性。该语言采用简化的语法，依赖于缩进、键值对和直观的规范。这种方法使开发者和用户能够以类似自然语言的方式表达复杂的数据结构，且一眼就能理解。YAML 的多功能性使其成为一个高度适应性强的解决方案，适用于广泛的应用场景。YAML 是一个多用途的工具，可用于不同领域，如配置管理、数据交换和自动化。它提供了一种用户友好且有组织的方式来表示和处理数据。