拥抱 DevOps 发布管理（二）

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

译者：飞龙

协议：CC BY-NC-SA 4.0

第八章：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 治理模型的实施常常受到组织技术架构复杂性的阻碍。在大多数情况下，开发团队倾向于使用各种不同的编程语言、框架、生产力工具和结构系统。然而，工具的泛滥给实施统一的治理实践和流程带来了挑战：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_1.jpg

图 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 流程、基础设施和工具，以便你能够充分理解转换的关键点，并在业务的控制、合规要求和行业法规之间建立联系。这样做使你能够优化当前的流程，建立治理模型，并为公司准备接受审计。增加流程的可见性是观察如何改进它的最快方法之一：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_2.jpg

图 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 分支。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_3.jpg

图 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 分支，并定期推送这些更改：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_4.jpg

图 8.4：GitHub 流程分支策略的图示

一旦feature或bugfix分支的开发完成，你需要创建一个拉取请求（pull request），以便对代码进行评估。在代码经过检查和验证后，它需要在同一分支中进行测试，然后才能合并回master分支。用户现在应该能够在达到这一点后，直接部署包含最新更新的master分支。

GitHub flow 的优点包括它相对容易理解，且具有直观的工作流。此外，这种方法能保持一份干净、易读的 Git 历史记录。你还可以轻松地将其集成到 CI/CD 流水线中。此外，GitHub flow 非常适合仅需要保留单一生产版本的情况。

GitHub flow 的一些缺点包括它过于简化，且与基于发布的软件开发不兼容。此外，GitHub flow 不适用于需要同时维护多个不同软件版本的情况。如果分支在合并到master分支之前没有经过彻底的测试，这可能导致生产环境的代码不可靠。

主干驱动开发

在主干驱动开发中，开发者需要每天至少一次将自己的代码修改直接集成到共享主干（master）中。共享主干保持在一个始终准备好发布的可部署状态。开发者编写的代码可以在从该主干分支拉取代码后，推送到本地仓库，并最终推送到共享主干：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_5.jpg

图 8.5：主干驱动分支策略的图形表示

release分支被视为源代码的快照，它们是从创建时并准备发布的那个时间点拍摄的。这意味着，在主干驱动开发中，release分支永远不会被维护。由于这种集成发生得非常频繁，开发者可以立即监控彼此的代码变化，并在发现问题时立即做出响应。

规模化主干开发

主干驱动开发的衍生版本，规模化主干开发，遵循类似的模式，但它为大型企业级开发团队提供了更易于使用的设计。

与主干开发的区别在于，在完成构建并确保功能测试成功后，较小的团队可以直接将他们的变更提交到共享主干。而对于规模化主干开发，开发过程可以划分为短生命周期的feature和bugfix分支，适用于员工较多的组织。在创建feature或bugfix分支后，开发人员将持续提交代码到这些特定的分支，并且可以通过拉取请求和自动化测试验证这些代码，然后再将其合并回共享主干。规模化主干开发使开发团队可以同时做到两件事：

• 在不对主分支造成太大压力的情况下进行扩展

• 实现对每个变更更高水平的监管和监督：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_6.jpg

图 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分支进行合并：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_7.jpg

图 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 在传播变更信息方面是有效的，但许多跨时区工作的团队可能会无意中对新变更或政策的意义产生误解。掩盖审批流程的低效是企业常犯的另一个错误。这意味着，当所有变更都经过统一的审批流程时，变更审查的低效就会显现，无法让个人为那些由于风险或截止日期差异而需要特别关注的变更分配足够的时间和精力。

另一个企业常犯的错误是缺乏对持续改进计划的投资。为了提升变更管理流程的绩效，必须关注关键绩效指标，如交付时间和变更失败率。这就要求为团队提供合适的工具和培训，以帮助他们有效地通过流程：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_08_8.jpg

图 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 发展过程中，某个时刻，似乎突然间，我们成为了一个为所有事情进行成本效益分析的文化。这样做，我们违反了经典的公理：你只能同时满足三个约束中的两个：范围（质量）、时间（速度） 和 成本（低成本）。这就是所谓的项目管理三角形或三重约束，它表明这三个约束中的任何一个发生变化，必然会影响其他两个；你必须选择其中两个并在第三个上做出妥协。我们往往会引入一些新工具，并试图说服他人它将如何加速进程、节省成本，或者为我们腾出更多时间去做更有意义的任务。然后，我们会发现如果我们通过添加另一个新功能或能力来扩展这个新工具，它能够提高质量，并承诺与现有流程相比，它将带来更可靠的结果：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_09_1.jpg

图 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 实施中的障碍，但高效团队之间的共同点揭示了一些显著的趋势。区别高效团队和低效团队的决定性特点是专注于提升团队成员技能的做法。这可能包括为同事提供某些认证的奖励，或者提供在线教育资源的访问权限，类似的方法也是有效的。公司不能忽视沉浸式学习的方法，因为这些投资比那些没有采用这种方法的公司更为成功：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_09_2.jpg

图 9.2：一个 DevOps 团队在协作工作

组织可以建立内部社区，推动教育并提高对员工或产品线调整的韧性。这有助于识别广泛的内部冲突，促进更具合作性的环境。高效的团队利用实践社区，由少数专注的专业人士组成，他们有共同的兴趣，通过持续互动不断提升技能。此外，高绩效团队通常会参与草根 DevOps 活动，并开发概念验证来解决公司独特的挑战。团队成员可以通过实践培训更好地理解同事的责任，而战术策略可以通过内部小组讨论和新闻简报来制定，成功故事也能得到分享。成熟的 DevOps 采用者努力避免知识孤岛，并致力于加强软技能，如有效地分享信息，以便能够继续开放合作。

在整个组织内推广知识非常重要，使其对每个人都能访问。高度成功的 DevOps 团队会努力提供指导机会，提升软技能，并采用一系列相关方法。

本节故意简明扼要，特别是为了避免稀释优先考虑依赖于团队成员以实现成功结果的核心观点——不仅仅是在 DevOps 中，而是在任何项目中。现在我们已经做出了这个重要的区分，接下来我们将研究文化、自动化、精益、衡量与共享（CLAMS）方法。这个战略框架将提升你团队成员的个人成功，帮助他们实现最大的潜力。这一策略的副作用是显著增强你业务实现战略目标的能力。这种协同效应是 DevOps 方法的标志，它源自所有利益相关者之间的互惠互利关系。

采用 CALMS 方法

CALMS 是一个概念框架，用于促进 DevOps 团队、职能和系统在组织内的无缝集成。CALMS 框架提供了计算机科学领域的成熟度模型，帮助管理者评估组织实施 DevOps 的准备情况。它使管理者能够识别需要改进的领域，从而实现准备工作。值得注意的是，CALMS 方法归功于Jez Humble，他是《DevOps Handbook》的共同作者之一。

CALMS 框架的 DevOps 包含五个基本原则：

• 文化：这包括集体问责制的主流理念。

• 自动化：团队成员积极寻找机会实施自动化，简化和优化各种流程，同时拥抱持续交付。

• 精益实践：与同时处理多个任务不同，专注于一次处理较少的任务。精益强调通过可视化工作来提高协调和协作。特别需要注意的是，管理队列长度和等待处理的任务积压非常重要。

• 衡量：这一点至关重要，因为它可以收集有价值的信息，确保全面了解操作环境。这些机制使得数据能够系统地收集，从而有助于更深入地理解各个过程和系统。

• 共享：开发和运维之间共享简单的沟通渠道促进了持续的双向对话。这些沟通渠道旨在促进 DevOps 团队之间的持续合作：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_09_3.jpg

图 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 能力的提升，逐渐转向较小的、增量式的变化：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_09_4.jpg

图 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 文化强调优先考虑客观的改进，而非主观和自我中心的做法。培养以团队为先的精神对于提高生产力和项目各阶段的整体进展至关重要。虽然转型可能不会立即发生，但预计结果会是无可否认的有利。

一个常见的误解是认为文化可以从一开始就启动或建立。与一些人的观点相反，值得注意的是，从内部发展文化具有重要意义。然而，普遍认为文化在许多情况下可以视为滞后指标。操作实践的变化会导致文化的改变。团队工具集的变化也有可能引发文化的转变：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_09_5.jpg

图 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 转型中扮演着至关重要的角色。

在本节中，我们将讨论缺乏信任会给你的组织带来的结果。帕特里克·兰乔尼在他的书《团队的五大功能障碍》中指出，缺乏信任是众多组织问题的根本原因：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_10_1.jpg

图 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）的研究，成功的变革型领导者具有以下四个主要特征：

• 智力激励：除了质疑现状，变革型领导者还激励追随者创新。领导者鼓励人们探索新的方法和教育机会。

• 个性化关怀：变革型领导力是一种领导风格，涵盖了对个别追随者提供支持和鼓励的行为。变革型领导者优先建立支持性关系，通过保持开放的沟通渠道，鼓励追随者自由表达他们的想法，并使领导者能够及时确认和欣赏每个追随者的独特贡献。

• 鼓舞人心的激励：变革型领导者拥有明确的愿景，并能够有效地传达给他们的追随者。领导者有能力激励并鼓舞追随者，培养共同的激情和动力，以实现共同的目标。

• 理想化影响力：在领导力的背景下，变革型领导者承担着作为其追随者榜样的责任。追随者表现出对领导者的信任和尊敬，这使他们模仿领导者的行为，并将领导者的价值观视为自己的：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_11_1.jpg

图 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）

在当今快速发展的环境中，敌对者在追求实现其目标的过程中变得越来越狡猾。对于那些未能在这些环境中优先实施强大日志记录和可见性控制的组织来说，后果可能是灾难性的。如果没有必要的措施，检测到安全漏洞将成为一项艰巨的挑战。缺乏全面的日志记录和可见性控制使得组织处于脆弱状态，无法及时识别和应对安全事件。因此，缓解和修复的路径充满了障碍，并受到有限调查能力的制约。

为了防止这些潜在的陷阱，组织必须采取主动步骤来加强其工程环境。通过实施适当的日志记录和可见性控制，他们可以增强迅速有效地检测漏洞的能力。这种主动的方法使组织能够及时响应，减少安全事件的影响，并确保更顺利地进行缓解和修复。在这个竞争激烈的数字市场中，组织保持领先一步至关重要。

在企业中建立强大的监控和可见性能力至关重要，因为它使得可以利用日志机制来识别潜在威胁，并对安全事件进行深入调查。建议实施报警系统，以便在操作框架内识别异常和潜在的有害行为。

价值流映射

价值流图绘制是精益管理中的一种工具，涉及追踪创建产品或服务的各个步骤，从其开始到最终目的地——客户。通过价值流图，你可以清晰地看到每个阶段所投入的时间和精力，以及每个步骤的重要性。资源和数据都会在价值流图中显示，追踪它们在过程中的流动。

创建当前状态图作为团队的第一步是价值流图绘制中的常见做法。这指的是准确记录材料的物理移动以及信息在价值流中的流动的过程。下一步是团队开发未来状态图。换句话说，目标图代表了材料和信息在价值流中理想的流动方式。

持续重复这一行动是最直接且最优的方式，帮助自己和同事学会如何识别和欣赏价值。价值流图绘制主要应用于精益制造中。然而，各行业的管理者也可能从中获得显著的益处。

价值流管理

价值流管理是一种管理方法，优先改善公司价值交付的流动性和生产力，从客户需求开始，最终以客户满意为结束。这种方法所应用的精确策略，使企业能够有效地衡量并提升改进速度，从而减少将产品推向市场所需的时间，提高整体产出，提升产品质量，并优化期望的客户满意度。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_App_01.jpg

价值流图绘制的主要目标是识别并最小化价值流中任何不必要的步骤或低效之处，最终提高特定价值流的整体效率。高效的浪费去除对于提升生产力和简化操作至关重要，从而帮助更好地识别浪费和质量问题。

浪费

精益一词指的是轻量化或缺乏多余的“脂肪”。精益操作的特点是没有浪费。精益操作可能产生的各种浪费，或称为 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 是一个多用途的工具，可用于不同领域，如配置管理、数据交换和自动化。它提供了一种用户友好且有组织的方式来表示和处理数据。