第 7 章：部署到生产环境

2012 年 8 月 1 日发生的 Knight Capital 事件是一个鲜明的例子，它展示了软件部署出错可能导致灾难性后果。那天，Knight Capital（当时美国最大的交易公司之一）对其自动化交易系统进行了大规模更新。由于自动化程度有限、部署中的人为错误以及糟糕的特性标志管理等多种因素的共同作用，过时的代码被意外重新激活，导致系统迅速下达错误订单到股票市场。

在仅仅 45 分钟内，有缺陷的算法执行了超过 400 万笔交易，给该公司造成了高达 4.6 亿美元的巨额损失。这起事件不仅几乎让 Knight Capital 破产并最终被收购，还导致了重大的市场混乱。它突显了在高风险软件环境中，健全的部署实践、彻底的测试、治理和故障安全机制的关键重要性。

部署到生产环境可能是一项高风险活动。虽然并非所有应用程序都是市场制造型交易平台，但值得更新的应用程序都有依赖它们的用户，并且任何更改都会引入风险。尽管我们可能更希望通过减少部署频率来避免这种风险，但我们面临着更频繁更改的业务需求。此外，随着我们延迟并将在计划发布中积累越来越多的更改，某些类型的风险会增加，这使得持续交付方法更具价值。

在之前的章节中，我们在软件交付过程中探讨了减轻最终部署到生产环境风险的策略。在第二章中，我们讨论了代码审查的重要性。在第三章中，我们研究了如何使用早期扫描和单元测试来快速检测问题。第四章描述了其他类型的测试以强化您的软件，并回顾了部署到测试环境的最佳实践。通过使用一致的工具、管道步骤和部署策略，

并通过对环境差异进行参数化，我们利用部署到测试环境来验证我们部署到生产环境的部署。在第五章中，我们深入探讨了安全性，回顾了帮助保护生产部署的实践。

如今，人工智能正在改变组织如何进行生产部署以防止此类灾难。机器学习系统现在可以分析部署模式，在发布期间检测异常，并以比传统监控更高的精度验证应用程序健康状况。与依赖预定义阈值的基于规则的验证不同，AI 系统可以学习每个应用程序特有的正常行为模式，并检测可能预示新问题的细微偏差。这些能力使团队能够更快地部署，同时又奇迹般地降低了风险——这与传统的速度与安全权衡背道而驰。

在本章中，除了涵盖人工智能的变革性作用外，我们还将探讨生产部署治理的最佳实践、安全部署到生产环境的策略，并讨论可观测性以验证生产部署的质量。我们将探讨现代 AI 驱动的部署工具如何通过智能验证而不是仅仅被动监控来帮助缓解风险，以及 AI 驱动的系统如何同时评估多个信号以确定部署健康状况，从而捕获可能被人工操作员忽略的问题。

生产部署治理

Knight Capital 事件是一个很好的提醒：部署有缺陷的软件可能导致灾难性的财务损失。您的组织的信任和信誉也面临风险。对组织而言，部署后修复缺陷的成本可能飙升，远远超过在开发阶段解决这些问题的费用。

要充满信心地进行部署，我们需要了解哪些代码发生了变化以及谁进行了这些更改。我们需要验证我们实施的代码审查流程是否已执行，并了解谁进行了这些审查。对于引入的任何依赖项，我们希望了解它们并知道它们符合我们的政策。我们希望知道它们是否已针对任何已知缺陷进行了审查。我们需要确保所有代码更改都已执行我们要求的构建、扫描和测试流程。当然，我们希望确保扫描和测试的结果确实符合我们的通过标准。最后，我们要求有证据表明我们的开发流程本身符合与我们组织相关的框架和要求。

严格的代码审查、彻底而强大的测试实践以及自动化、可重复的部署程序对于避免部署失败至关重要。然而，如果没有适当的治理和控制来确保我们遵守了流程，我们所有的努力都可能变得无效。

人工智能正在开始改变部署治理，尽管大多数应用仍在兴起。当前的 AI 系统主要侧重于分析部署模式以识别风险因素和策略违规，而不是做出自主决策。这些系统可以同时处理比人类更多的部署变量，有助于识别代码更改、部署配置和历史事件之间的细微关联。组织开始利用这些洞察力来完善其治理框架，尽管人工监督对于最终的批准决策仍然至关重要。

部署治理就是对软件部署过程进行系统性的监督和控制，以确保我们定义的规则和策略得到执行。从根本上说，治理是为了降低变更的风险。治理包括组织用来确保软件部署以一致、受控、安全和合规的方式进行的策略、流程和工具。治理的挑战在于平衡对敏捷性和创新性的需求与对稳定性和风险管理的需求。

在接下来的几个部分中，我们将讨论部署治理的传统方法和现代方法。我们将研究如何自动化我们治理策略的强制执行，以使我们的交付过程更高效。我们将审查支持我们治理流程的工具和策略，最后，我们将展望部署治理的未来。

传统部署治理方法

传统部署治理方法是为 DevOps 前的世界构建的。在这个世界中，生产环境的更改不频繁、风险高，并且由传统的运维团队执行。决策是集中的，并涉及僵化的流程。

信息技术基础设施库（ITIL）是一种广泛采用的框架，它代表了一种传统方法。ITIL 最初在 1980 年代出现，以应对对标准化 IT 管理实践的需求，从最佳实践的集合演变为一个综合框架。它包括几个与部署治理直接相关的流程和实践。

其中之一是变更管理流程，它定义了一种结构化的方法来管理服务和基础设施的所有变更，包括部署。它规定了对拟议变更的正式文档，包括其目的、范围、影响和风险评估。变更咨询委员会（CAB）或类似机构评估变更。变更请求根据其优点和潜在风险被正式授权或拒绝。如果变更获得批准并执行，

将进行实施后评估，以确保变更达到其目标并识别任何经验教训。

发布管理流程同样正式，它规定了将发布规划、调度和控制到生产环境。它与变更管理流程密切相关，旨在确保部署以受控和透明的方式执行。

CAB 是 ITIL 等方法的一个典型特征。CAB 是一个委员会，由负责正式评估和批准或拒绝拟议软件变更的个人组成。该委员会可能包括一名负责协调变更请求审查和跟踪变更实施的变更经理，以及技术专家、业务利益相关者、安全专家、合规官等。其目的是通过从多个角度彻底评估请求来降低风险。

此外，如果出现任何问题，CAB 还可以确保问责制。虽然一个高效运作的 CAB 将提供预期的监督，但最糟糕的 CAB 由不专心的审查人员组成，他们不进行评估就草草批准审查。或者 CAB 可能名义上有效但效率低下。邮件驱动的审批流程因被忽略的邮件、审批人外出且没有委托以及审查会议被重新安排而减慢。

研究表明，这些传统的 CAB 流程不仅效率低下，实际上对它们旨在确保的稳定性是适得其反的。Forsgren、Humble 和 Kim 在他们的里程碑式研究《加速》一书中，在谈到高性能组织时解释道：“外部审批与交付周期、部署频率和恢复时间呈负相关，与变更失败率无关。”换句话说，像 CAB 这样的外部机构的审批明显减慢了交付速度，而没有提高稳定性。

发生这种情况是因为 CAB 将责任与知识分离；对变更了解最深的人不是做出批准决定的人。虽然这些委员会营造出尽职调查的表象，但它们通常充当合规剧场，当事情出错时，它们提供了一个可以指责的对象，而不是真正防止失败。它们提供的控制错觉甚至可能降低实施变更人员的警惕性，因为“CAB 批准了”成为推卸责任的挡箭牌。

CAB 会议的开销，加上低效和延迟，在应用程序不经常发布时尚可容忍。随着发布频率的增加，CAB 的问题变得越来越明显。

现代部署治理方法

在前面的章节中，我们探讨了如何通过自动化每个阶段的步骤来简化开发过程，从而实现更快、更频繁的软件发布。现代部署治理方法同样侧重于自动化手动步骤，这些手动步骤是不必要的软件发布障碍。

现代方法不再依赖委员会和手动审批来做出部署决策，而是倾向于自动化决策和部署。由于生产部署的风险很高，因此必须非常谨慎地进行。在本节中，我们将探讨如何做到这一点。

除了自动化之外，现代治理方法还利用当前的策略和工具来管理合规性。我们将研究如何使用审计日志来简化合规性，以及 Open Policy Agent (OPA) 等工具来强制执行安全和法规标准。

自动化决策

借助现代 CI/CD 工具，我们可以让我们的管道自主做出部署决策。如果我们能够确保我们的管道能够充分强制执行治理策略以维持我们的标准，我们就可以通过消除或最大限度地减少手动审批来加速软件交付。

考虑以下步骤，以在您的交付过程中自动化部署决策：

1. 明确您的“通过”标准

为推广构建明确标准对于自动化部署过程至关重要，但这可能具有挑战性。我们合作的一家银行将其控制措施记录在一个三英寸厚的活页夹中，其中包含数百页的法规和政策。通常，决策者可能同时依赖客观数据和主观判断。模糊性使得将人类决策转化为一套僵硬的自动化规则变得具有挑战性。例如，决策者可能会推广一个有少量次要测试失败的构建，如果他们认为这些问题风险低且不太可能影响用户。然而，将这种直觉转化为准确评估风险和用户影响的自动化规则可能很复杂。人工智能在将人类决策中更模糊的元素引入完全或大部分自动化流程方面发挥着越来越大的作用。如果以这种方式使用，它应该被要求解释其建议和见解。

2. 使用“质量门”实现复杂标准，尽可能自动化控制

门是 CI/CD 管道中的检查点，用于评估特定标准，以确定构建是否应进入下一阶段。门可以考虑测试结果、基于静态分析结果的代码质量指标、代码覆盖率、编码标准合规性、安全扫描结果和性能指标。其他工具允许您引入一个管道步骤，如果决策为“否”，则该步骤将失败；或者您可以根据您的特定标准设置条件执行。通常，最简单的方法是配置每组测试，使其在不符合您的标准时失败。这样，如果任何步骤失败，整个管道将停止，从而阻止不合格构建的推广。

3. 自动化细微决策时，考虑历史结果

例如，安全计划通常从对新的高优先级问题实行零容忍政策开始，但会容忍现有问题，直到团队解决它们。这需要考虑历史数据，而不仅仅是最新的结果。

4. 最后，将自动化标准化

使用标准化选择或痛苦的手动合规性作为使用标准化工具的激励。我们合作的银行的团队可以选择通过证明发布符合活页夹中详述的所有控制来部署到生产环境，或者使用其标准化的自动化流程和工具。这成为了一个简单的选择。

建立强大的审计追踪以自动化合规性

部署治理和合规性密切相关。有效的治理实践对于实现和维持与各种监管标准和框架的合规性至关重要。

我们在第五章中回顾了几个框架，特别是与安全相关的框架。PCI DSS 是一个广泛适用的例子。它用于确保所有接受、处理、存储或传输信用卡信息的公司都维护一个安全环境。无论您处理的交易规模或数量如何，如果您的组织处理持卡人数据，则您都必须遵守其要求。主要卡品牌（Visa、Mastercard 等）如果无法证明合规性，可能会处以罚款或限制您处理卡支付的能力。

虽然 PCI DSS 主要侧重于保护持卡人数据，但有几个要求直接涉及软件开发和部署过程。这是为了确保处理此数据环境的整体安全性。例如，PCI DSS 要求您通过采取措施（例如在发布到生产环境之前对自定义代码进行审查和解决常见的编码漏洞）来开发和维护安全的系统和应用程序。PCI DSS 还包括

测试要求，规定在任何重大的基础设施或应用程序升级或修改后进行内部和外部渗透测试。

强大而全面的审计追踪对于证明合规性所需的实践至关重要。虽然您的组织可能不受 PCI DSS 要求的约束，但许多其他可能相关的框架将对其开发和部署流程提出类似的要求。

您的源代码控制和 CI/CD 系统在这里发挥着至关重要的作用，它们捕获了交付管道中每个操作的详细信息，从代码提交和构建到测试结果、部署和环境配置，以及相关的用户、时间戳和任何相关的元数据。这包括日志记录用户操作、系统事件、工件跟踪、配置更改和外部集成。通过将这些信息以结构化和可访问的格式存储，CI/CD 工具提供了通用审计追踪，可适应任意数量的安全和法规框架。

支持强大审计追踪的工具使您的组织能够证明合规性，而无需为每个框架维护单独的日志。它还可以让您主动解决潜在的安全或合规问题。

使用策略即代码管理强制执行

策略即代码（PaC）在自动化生产部署的同时保持强大的治理方面发挥着重要作用。PaC 是将安全、合规和操作策略定义和管理为代码的实践，从而实现自动化强制执行。策略以声明式语言定义，可以像任何其他关键代码一样进行管理：在源代码控制中进行版本控制，从而实现跟踪、协作、所需的代码审查和回滚能力。

OPA 是一种流行的开源策略引擎，用于实现 PaC。通过 OPA，每次部署都会根据您定义的策略进行自动评估，确保一致的强制执行，而不会减慢您的交付过程。想象一下，您的部署策略要求所有容器镜像在进入生产环境之前必须经过关键漏洞扫描。使用 OPA，您可以表达此 PaC，并将其集成到您的管道中。现在，每次触发部署时，OPA 会自动扫描镜像，如果镜像干净则允许部署继续，如果发现漏洞则停止部署。这消除了手动安全检查，并确保在没有人为干预的情况下，始终如一地遵守您的安全标准。

OPA 的多功能性超出了安全检查。您可以将各种部署策略编纂成代码，例如强制执行金丝雀部署、要求批准特定更改或验证资源配置。通过自动化这些检查，您可以确信每次部署都符合您组织的标准和法规要求。这不仅加速了您的交付过程，还降低了人为错误和不合规的风险。

保护部署流程

严格控制您的治理机制有助于保护您的部署。开发人员赋能对于现代部署也至关重要。在实践中，您需要在两者之间取得平衡。虽然您希望使开发人员能够适应其部署管道，但您也需要防范潜在风险。恶意行为者可能会篡改或绕过您设置的治理机制，或者他们可能会因人为错误而受到影响。或者，对部署的过度严格控制可能会为高效部署制造另一个障碍。

OPA 也能在这里提供帮助。通过 OPA，您可以对策略更新过程本身应用严格控制，确保对您的治理框架的任何更改都经过仔细审查和符合规定。通过将策略规则集中到 OPA 并将其应用于管道，您可以创建关注点分离。这使得单个开发人员更难规避策略，因为他们需要修改中央 OPA 策略，而这些策略可能受到更严格的访问控制、同行评审和审计追踪。

随着我们越来越依赖 AI 为我们生成管道，OPA 策略既为 AI 提供了我们想要的指导性输入，也提供了保护，确保 AI 的输出符合我们的标准。

保护部署过程的另一个重要控制是实施健壮的 RBAC。如第二章所述，RBAC 允许您精细控制谁有权修改管道和 CI/CD 平台内的敏感配置设置。这确保了只有授权人员才能更改您的部署过程，从而最大限度地降低恶意活动的风险。

通过结合这些方法，您可以集中执行策略，确保您的部署防篡改并得到有效监控。

部署治理的未来趋势

与软件开发的几乎所有领域一样，人工智能和机器学习将推动部署治理的重要未来趋势。例如，预测分析是数据分析的一个分支，它应用机器学习技术分析历史数据以预测未来结果。应用于软件部署时，预测分析可用于识别模式和风险因素以标记潜在问题。供应商正在创建仪表板，例如 Digital.ai 的“变更风险预测”，该仪表板基于团队失败率和测试中发现的缺陷等趋势。如今，大多数这些解决方案都是在广泛数据集中发现的相对简单的相关性。我们有理由期望未来能从模型中获得更多洞察力，特别是那些能够轻松访问更广泛数据集的 DevOps 平台。

您的团队可以在问题影响用户之前主动解决它们。AI 和 ML 可用于实时自动执行治理策略，分析代码更改、配置和部署，以确保符合安全和操作标准。这些进步将使组织能够以更快的速度、更大的信心和更强的弹性交付软件。

协调传统与现代方法

在传统治理方法中，ITIL 将标准变更定义为预批准、低风险且具有明确程序的变更，允许以最少形式授权更快地实施。通过使用现代 DevOps 实践，依赖质量门和现代策略强制执行，我们可以显著降低即使是复杂软件部署的风险。这种控制和可靠性水平允许将这些部署视为标准变更。从本质上讲，现代 DevOps 实践中固有的风险缓解与 ITIL 的标准化、可预测变更管理目标相一致，从而在不损害稳定性或合规性的情况下实现更快、更频繁的部署。

在“生产部署策略”中，我们将探讨如何使用渐进式部署来进一步降低生产部署的风险。

生产部署策略

在第四章中，我们介绍了如何自动化我们的部署流程，现在我们已经了解了如何通过部署治理实践来降低风险。接下来，我们将重点转向实际的软件生产部署业务。在本节中，我们将研究如何通过渐进式部署技术进一步降低风险。即使拥有最强大的治理和最谨慎的渐进式部署，我们的部署仍然可能失败。我们必须准备好回滚策略，因此我们将研究快速恢复的方法。最后，我们将研究工具选择。选择现代工具可以帮助您轻松地进行治理、渐进式部署和回滚。

传统的大爆炸式部署

在研究现代方法之前，我们可以回顾一下传统方法——以及对于有状态应用程序的某些元素仍然可能需要的方法。传统上，我们会将应用程序下线，升级应用程序每个组件的每个实例，然后重新启动应用程序。经过快速验证后，我们会将其重新暴露给用户，并观察一段时间以确保其健康，然后才认为部署成功。如果出现问题，我们会将应用程序重新下线并尽力回滚应用程序——这通常是一项艰巨的挑战。

这种传统方法需要应用程序停机，引入了重大风险，并需要工程师投入大量精力。改进的机会比比皆是。

使用渐进式交付策略

软件部署就像走钢丝——一步走错，后果可能很严重。但渐进式部署策略为您提供了一个安全网。通过逐步推出更改并密切监控其影响，这些策略最大限度地降低了风险，并在出现问题时允许快速纠正。在本节中，我们将介绍多种流行的部署策略，包括滚动更新、蓝绿部署、金丝雀部署以及特性标志的使用。

部署滚动更新

滚动部署是一种非常常见的交付策略，您可以通过逐步将旧版本实例替换为新版本实例来增量更新应用程序或服务。这是以受控方式完成的，确保在更新过程中始终有一定数量的实例可用以处理用户流量。

滚动部署具有明显的优势。它们最大限度地减少了停机时间，因为应用程序在整个更新过程中保持可访问。重要的是，滚动部署降低了风险。通过增量更新实例，可以及早检测并解决新版本的潜在问题，从而限制其影响。这种部署类型可以根据特定的应用程序需求进行定制，允许对更新过程的速度和规模进行无限调整。

然而，实施和管理滚动部署可能比其他部署策略更复杂，特别是对于大规模或分布式系统。还存在潜在的不一致性。在更新过程中，同时运行的两个不同版本的应用程序可能导致数据或用户体验的差异。此外，回滚正在进行的部署可能很复杂，并且需要额外的步骤来保持数据完整性。

实现选项众多。Kubernetes 通过其 Deployment 对象提供对滚动更新的内置支持。新的 Pod（带有更新版本）会逐渐创建，旧的 Pod 在新的 Pod 准备就绪后终止。容器编排平台（例如 Docker Swarm、Nomad）提供类似的滚动更新机制，允许增量替换容器或服务。负载均衡器可用于通过在旧实例可用时逐渐将流量从旧实例转移到新实例来实施滚动更新。在某些情况下，滚动部署可以使用管理更新过程和监控应用程序健康状况的自定义脚本或自动化工具来实施。

虽然滚动部署需要付出努力才能实施，但它们为在应用程序更新期间最大限度地减少停机时间和风险提供了一个有价值的选择。

使用蓝绿部署

蓝绿部署是一种发布策略，涉及维护两个相同的环境，通常称为“蓝色”和“绿色”。在任何给定时间，这些环境中的一个（通常是蓝色）是实时运行的，服务于生产流量。

当您的应用程序新版本准备就绪时，它会部署到非活动环境（绿色）。在绿色环境中进行测试和验证后，流量从蓝色环境切换到绿色环境，使新版本上线。滚动部署是随着时间推移进行更新，不同流量会体验到不同版本的服务，而蓝绿部署通常具有硬切换功能。开关一拨，流量（或至少是新流量）就会立即从旧版本转移到新版本。图 7-1 描绘了部署更新前后的蓝色和绿色环境。

以前的实时环境（现在是蓝色）可用于下一次部署，也可以作为需要回滚时的备份，或者被解除。

蓝绿策略具有显著优势：

减少停机时间

流量在环境之间切换，最大限度地减少对用户的任何中断并减少停机时间。

轻松回滚

如果新部署出现问题，流量可以快速切换回以前的版本。

改进测试

新版本可以在上线前在类似生产的环境中进行测试。

主要缺点在于基础设施成本增加，因为维护两个独立、相同的环境可能很昂贵。此外，蓝绿部署可能不适用于具有复杂状态管理或数据库模式更改的应用程序，因为在环境之间同步数据可能具有挑战性。

更高级的蓝绿模型可以通过集成 IaCM 实践来克服大部分基础设施成本挑战。在稳定生产状态下，只存在一个实例。在部署开始时，部署会触发 IaCM 工具来预置一个新实例，从而使蓝色和绿色都存在。在流程结束时，多余的实例被解除。因此，多余的基础设施只需要在蓝绿部署期间存在。

使用金丝雀发布

金丝雀发布提供了另一种类似于滚动更新的渐进式策略。应用程序的新版本会发布给一小部分用户或服务器。这个“金丝雀”组充当测试平台，允许您在真实世界的生产环境中监控新版本的性能和稳定性，然后将其提供给所有用户。

在典型的金丝雀部署中，只有一小部分流量（例如 5% 到 10%）可能被引导到新部署的版本。新版本的性能、稳定性、错误率会被密切监控并与现有版本进行比较。响应时间、CPU 使用率和错误日志等指标会被分析，以识别任何潜在问题。如果新版本在金丝雀环境中表现良好，则引导到它的流量百分比会逐渐增加，允许更多用户访问它。这个过程持续到新版本完全取代旧版本。如果在金丝雀阶段检测到任何问题或性能下降，部署可以迅速回滚，最大限度地减少对用户的影响。

金丝雀部署可以通过简单的指标阈值实现，但它们越来越多地利用 AI 或 ML 功能来确定新版本是否表现令人满意。传统上，金丝雀部署侧重于性能基准，但我们可以预期，未来它们将越来越多地利用业务指标，即使新版本的应用程序没有崩溃，如果它损害了业务，也会停止发布。

虽然金丝雀部署和滚动更新都旨在实现渐进和受控的软件发布，但它们的侧重点不同。滚动更新解决了最小化服务基础设施的停机时间和服务中断的问题。金丝雀部署则侧重于以指标为指导的决策，决定是逐步增加新版本的流量还是回滚到旧版本。

使用特性标志

特性标志提供了一种以渐进方式部署特性的策略。将特性标志想象成代码中隐藏的开关，允许您为特定用户或组打开或关闭特性，而无需部署新代码。这使您可以精细控制谁看到什么，从而实现 A/B 测试和有针对性的发布。特性标志与其他渐进式部署策略类似，它们允许您在真实世界环境中监控性能并收集反馈，并利用这些信息来降低风险。然而，特性标志在不同级别操作；它们控制单个版本内的功能。其他渐进式策略测试一个全新的版本。

特性标志带来的好处不仅限于部署风险缓解，我们将在第八章中再次讨论它们。

回滚

我们已经探讨了几种渐进式部署策略，但您的选择是无数的。变体和混合方法，融合了滚动更新、蓝绿部署、金丝雀发布和特性标志的元素，都是可能性。这些策略的共同点是受控发布，允许您在需要时停止部署并回滚到以前的版本。对于蓝绿部署这样的策略，这是一个简单的提议：您的以前版本随时待命。对于滚动更新或金丝雀部署，回滚过程是关于从带有缺陷软件的节点中移除流量，然后系统地用以前的软件版本替换这些节点。

回滚不仅涉及重新部署先前稳定的软件版本，还包括其相关的配置、依赖项和数据。回滚到先前状态的复杂性可能与部署本身一样复杂，甚至更复杂。某些部署方法将促进可靠的回滚。例如，如果部署是幂等的，意味着它可以重复并实现相同、无损的结果，那么重新部署先前版本将等同于回滚。

测试回滚对于确保您可以无所畏惧地回滚至关重要。仅仅有一个回滚机制是不够的；您需要定期验证其就绪状态。这包括模拟各种故障场景，然后执行回滚程序，以确保其快速可靠地恢复到以前的稳定版本。彻底的回滚测试验证了应用程序、其数据和其依赖项是否正确恢复。根据应用程序及其数据存储机制，回滚可能需要数据恢复或迁移以确保数据一致性。定期测试程序以确保它们在所有场景中按预期工作。

对您的回滚程序充满信心后，您可以根据部署健康状况配置自动触发回滚。验证部署健康状况是下一节将讨论的主题。系统不再依赖手动干预，而是当预定义的阈值被突破时，自动恢复到以前的稳定版本。这不仅减轻了运维团队的负担，还将人为错误排除在外，从而最大限度地减少停机时间。

特定架构的特殊考虑

部署和回滚的复杂性因软件架构而异。单体应用由于其紧密耦合的代码库，通常需要完整的部署和回滚，这会影响整个系统。另一方面，微服务提供了更细粒度的部署和回滚，针对单个服务。然而，这种相互连接意味着必须仔细管理依赖项，以确保服务之间的一致性。分布式单体应用兼具单体架构和微服务的特点，结合了微服务的部署复杂性和单体应用的相互依赖问题。

数据库增加了另一层复杂性。当更新涉及对持久数据结构进行破坏性更改时，需要“扩展和收缩”等策略。该策略涉及在现有数据库字段或表旁边添加新的字段或表，部署更新后的应用程序以利用新结构，并最终逐步淘汰旧字段。该方法实施起来很复杂，但通常需要这样做才能在支持渐进式部署策略和干净回滚时确保数据完整性。

选择合适的工具

有了渐进式部署策略和强大的回滚能力，您就可以充满信心地部署到生产环境。但要真正发挥这些策略的力量，您需要合适的工具。现代部署工具是关键，它们开箱即用地为渐进式部署策略提供无缝支持。

在选择用于编排软件部署的工具时，除了基本功能之外，还需要考虑给定工具与您的特定需求有多么契合。如果您计划在采用新的持续交付工具的同时过渡到自动化部署决策，那么提前了解所有影响您的推广决策的因素将有助于您选择具有所需治理和门功能的正确工具。此外，请确保部署工具与您的目标环境无缝集成，无论是云、本地服务器还是混合设置。同样重要的是，该工具能否处理您的特定应用程序类型和架构，包括任何复杂的数据库部署或协调的多服务发布。

除了基础设施和架构兼容性之外，部署工具还应包含对您首选渐进式部署策略的开箱即用支持，确保您可以轻松实施金丝雀发布、滚动更新或其他

技术。健壮的回滚机制应作为首要关注点，因为它们允许您在出现意外问题时快速恢复到以前的稳定版本。此外，还要考虑该工具是否与您现有的特性标志管理系统集成，或者是否提供自己的特性标志功能，从而让您对特性发布进行精细控制。

验证生产部署

即使是最勤奋的治理也无法消除对健全实践的需求，以系统地验证您的生产部署。在本节中，我们将探讨可观测性的作用。我们将讨论如何现代化您的验证流程，并研究特定于生产部署验证的测试策略。

部署中的可观测性

验证您的部署从可观测性开始。可观测性简单来说是指通过检查系统的外部输出来理解其内部状态的能力。可观测性让您从知道出了问题到理解为什么出了问题，从而实现更快的故障排除和更有效的根本原因分析。可观测性数据包含三个关键支柱：

指标

这些提供系统性能的定量测量，例如响应时间、错误率和资源利用率。通过跟踪这些指标的趋势和异常，团队可以快速识别潜在问题并评估新部署的影响。

日志

日志提供应用程序及其基础设施内部发生的事件和错误的详细记录。分析日志数据有助于查明问题的根本原因并了解导致问题的事件序列。

追踪

追踪提供请求如何流经系统的可视化表示，突出瓶颈、延迟问题以及不同服务之间的依赖关系。这有助于识别性能问题并优化应用程序架构。

现代化“战情室”

传统的部署验证通常类似于高风险的战情室场景，工程师们监控仪表盘和日志，随时准备在出现问题的最初迹象时进行手动干预。这个过程高度依赖人工，依赖人类对可观测性数据的解读。它也是被动的，团队通常只在问题影响用户后才匆忙解决。

这种方法不仅压力大、效率低，而且容易遗漏问题并导致响应时间慢。此外，它常常导致验证程序不一致，并且对问题根本原因的可见性有限。

部署验证的现代化涉及自动化这些手动任务和人类决策。自动化系统取代了工程师监控仪表盘和日志的工作，持续分析遥测数据并在检测到异常时触发警报。从被动监控转向主动监控减少了对人工干预的需求并加快了响应时间。

实现这种自动化的诀窍是将您的部署工具与您的可观测性平台集成。集成可以根据所使用的工具采取不同的形式。在一种方法中，您的 CI/CD 工具在部署进行时通知可观测性平台，提供一个可以用于触发回滚的“钩子”。然后可观测性平台分析遥测数据并决定是否启动回滚，调用 CD 工具提供的钩子。

或者，Harness 等 CD 工具可以配置为在部署过程中监视一个或多个可观测性工具是否存在问题迹象。如果检测到问题，CD 工具可以自动触发其自己的回滚机制，停止部署并恢复到以前的稳定版本。部署工具和可观测性工具之间的紧密集成实现了无缝和自动化的验证过程，最大限度地减少了停机时间并确保了更快的反馈循环。

无论哪种情况，业界都不再容忍停机，并寻求在应用程序失败之前检测出问题正在酝酿的迹象。因此，AI/ML 被用于分析多个数据源，以识别预示失败可能性的异常。AI 异常检测已成为现代部署验证的核心组件。与依赖预定义阈值的传统监控不同，这些系统围绕数百个指标构建正常应用程序行为的统计模型，并且可以检测复杂的、多维的异常，而这些异常是无法通过静态规则定义的。这种能力在生产部署后的关键几分钟内特别有价值，因为细微的性能问题可能在升级为影响用户的事件之前被忽视。

部署验证系统将这些 AI 功能集成到自动化验证门中，在整个部署过程中提供持续评估，而不是一次性检查。当检测到异常时，这些系统可以自动暂停渐进式发布，甚至自动触发回滚过程。

测试生产部署

我们在第四章中详细讨论了测试。现在我们回过头来，看看特别适合生产验证的测试策略。验证生产部署需要分层测试方法。

合成测试可以与分阶段或渐进式部署搭配使用。通过在生产环境中模拟典型的用户交互和事务，合成测试运行各种场景以快速捕获问题。这使得团队能够尽早解决问题，无论是通过回滚部署还是通过实施必要的修复。

除了初始部署阶段，生产环境中的持续测试对于确保长期稳定性和性能至关重要。合成测试继续发挥着重要作用，提供对关键用户旅程的持续监控，并识别任何回归或性能下降。第六章中涵盖的混沌工程更进一步，通过故意向系统中注入故障来测试其弹性和恢复能力。

持续测试的另一个重要方面是渐进式特性披露。这涉及逐步向一部分用户发布新特性，允许团队在全面发布之前收集反馈并监控性能。A/B 测试等技术可以比较不同版本的特性，帮助识别最有效的实现。这种受控的特性发布方法最大限度地降低了风险，并允许基于真实用户行为做出数据驱动的决策。通过结合合成测试、混沌工程和渐进式特性披露，组织可以建立一个全面的测试策略，确保其生产部署的持续验证和改进。

总结

随着人工智能继续改变生产部署，部署策略和特性管理之间的联系变得越来越重要。AI 驱动的部署验证系统不仅监控整体应用程序健康状况；它们现在还可以跟踪部署中单个特性的影响，提供粒度见解，为回滚决策和未来的特性发布提供信息。这些系统创建了一个持续的反馈循环，其中部署数据输入特性标志决策，而特性行为为部署策略提供信息。现代平台分析跨部署的特性性能模式，以推荐哪些特性应通过特性标志逐步发布，以及哪些特性可以安全地传统部署。这种智能有助于团队平衡开发速度与运营稳定性，为管理生产环境中的部署和特性创建更复杂的方法。在第八章中，我们将深入探讨特性管理。