你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上任务关键型工作负荷的部署和测试
部署失败和错误发布是应用程序中断的常见原因。 部署和测试方法在任务关键型应用程序的整体可靠性方面起着关键作用。
部署和测试应构成所有应用程序和基础结构操作的基础，以确保任务关键型工作负载的结果一致。 准备每周、每天或更频繁地部署。 (CI/CD) 管道设计持续集成和持续部署以支持这些目标。
该策略应实现：
严格的预发布测试。 汇报不应引入可能危及应用程序运行状况的缺陷、漏洞或其他因素。
透明部署。 应该可以随时推出更新，而不会影响用户。 用户应能够在不中断的情况下继续与应用程序交互。
高度可用的操作。 部署和测试过程和工具必须高度可用，以支持整体应用程序可靠性。
一致的部署过程。 应使用相同的应用程序项目和进程在不同的环境中部署基础结构和应用程序代码。 端到端自动化是必需的。 必须避免手动干预，因为它们可能会带来可靠性风险。
此设计区域提供了有关如何优化部署和测试过程的建议，目的是最大程度地减少停机时间和维护应用程序的运行状况和可用性。
重要
本文是 Azure Well-Architected Framework 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从什么是任务关键型工作负载开始。
零停机部署
观看以下视频，了解零停机时间部署的概述。
实现零停机部署是任务关键型应用程序的基本目标。 应用程序需要全天可用，即使在营业时间推出新版本时也是如此。 预先投入精力来定义和规划部署过程，以推动关键设计决策，例如是否将资源视为临时资源。
若要实现零停机时间部署，请在现有基础结构旁边部署新基础结构，对其进行全面测试，转换最终用户流量，然后才解除以前的基础结构的授权。 其他做法（如 缩放单元体系结构）也是关键做法。
任务关键联机和 Azure Mission-Critical 连接参考实现演示了此部署方法，如下图所示：
应用程序环境
观看以下视频，大致了解应用程序环境的建议。
需要各种类型的环境来验证和暂暂部署操作。 这些类型具有不同的功能和生命周期。 某些环境可能反映生产环境且生存期较长，而其他环境可能生存期较短，其功能比生产环境少。 在开发周期的早期设置这些环境有助于确保敏捷性、分离生产和预生产资产，并在发布到生产环境之前对操作进行彻底测试。 所有环境都应尽可能多地反映生产环境，但你可以根据需要将简化应用于较低环境。 下图显示了任务关键型体系结构：
有一些常见注意事项：
组件不应跨环境共享。 可能的例外是下游安全设备，如防火墙和综合测试数据的源位置。
所有环境都应使用基础结构即代码 (IaC) 项目（如 Terraform 或 Azure 资源管理器 (ARM) 模板）。
开发环境
观看以下视频，了解有关临时开发环境和自动功能验证的信息。
设计注意事项
功能。 对于开发环境，可以接受对可靠性、容量和安全性的较低要求。
生命周期。 应根据需要创建开发环境，并在短时间内存在。 较短的生命周期有助于防止配置偏离代码库并降低成本。 此外，开发环境通常共享功能分支的生命周期。
密度。 Teams 需要多个环境来支持并行功能开发。 它们可以在单个订阅中共存。
设计建议
将环境保留在专用订阅中，并设置了用于开发的上下文。
使用自动化过程将代码从功能分支部署到开发环境。
测试或过渡环境
这些环境用于测试和验证。 执行许多测试周期以确保无 bug 部署到生产环境。 持续验证和测试部分介绍了针对任务关键型工作负载的相应测试。
设计注意事项
功能。 这些环境应反映生产环境的可靠性、容量和安全性。 在没有生产负载的情况下，使用综合用户负载提供现实指标和有价值的运行状况建模输入。
生命周期。 这些环境生存期较短。 测试验证完成后，应销毁它们。
密度。 可以在一个订阅中运行多个独立环境。 还应考虑使用多个环境，每个环境都位于一个专用订阅中。
注意
任务关键型应用程序应接受严格的测试。
可以在单个环境中执行不同的测试功能，在某些情况下需要执行。 例如，若要使混沌测试提供有意义的结果，必须先将应用程序置于负载之下，以便了解应用程序如何响应注入的错误。 这就是混沌测试和负载测试通常并行执行的原因。
设计建议
确保至少一个过渡环境完全反映生产，以启用类似于生产的测试和验证。 此环境中的容量可以根据测试活动的执行而灵活。
生成综合用户负载，为其中一个环境中的更改提供真实的测试用例。
在开发和发布周期中定义过渡环境的数量及其用途。
生产环境
设计注意事项
功能。 应用程序需要最高级别的可靠性、容量和安全功能。
生命周期。 虽然工作负载和基础结构的生命周期保持不变，但所有数据（包括监视和日志记录）都需要特殊的管理。 例如，备份和恢复需要管理。
密度。 对于某些应用程序，可能需要考虑使用不同的生产环境来满足不同的客户端、用户或业务功能。
设计建议
对于生产和较低环境，具有明确的治理边界。 将每种环境类型置于专用订阅中以实现该目标。 此分段可确保较低环境中的资源利用率不会影响生产配额。 专用订阅还会设置访问边界。
临时蓝/绿部署
蓝/绿部署模型至少需要两个相同的部署。 蓝色部署是在生产环境中为用户流量提供服务的活动部署。 绿色部署是准备并测试以接收流量的新部署。 完成并测试绿色部署后，流量逐渐从蓝色定向到绿色。 如果负载传输成功，则绿色部署将成为新的活动部署。 然后，可以通过分阶段过程解除旧的蓝色部署。 但是，如果新部署出现问题，则可能会中止该部署，并且流量可以保留在旧的蓝色部署中，也可以重定向到该部署。
Azure Mission-Critical建议采用蓝/绿部署方法，其中基础结构 和应用程序 作为部署标记的一部分一起部署。 因此，对基础结构或应用程序进行更改始终会导致包含这两个层的绿色部署。 使用此方法，可以在将用户流量重定向到基础结构和应用程序之前，对基础结构和应用程序进行全面测试和验证更改的效果。 由于可以验证与下游依赖项（如 Azure 平台、资源提供程序和 IaC 模块）的兼容性，因此该方法提高了发布更改的信心，并实现了零停机时间升级。
设计注意事项
技术功能。 利用 Azure 服务中的内置部署功能。 例如，Azure 应用服务提供可在部署后交换的辅助部署槽位。 使用 Azure Kubernetes 服务 (AKS) ，可以在每个节点上使用单独的 Pod 部署并更新服务定义。
部署持续时间。 部署可能需要更长的时间才能完成，因为标记包含基础结构和应用程序，而不仅仅是已更改的组件。 但是，这是可以接受的，因为所有组件不按预期工作的风险会覆盖时间问题。
成本影响。 由于两个并行部署必须共存，直到部署完成，这两个部署必须共存，因此会付出额外的成本。
流量转换。 验证新部署后，流量必须从蓝色环境转换为绿色环境。 此转换需要协调环境之间的用户流量。 转换应完全自动化。
生命周期。 任务关键型部署标记应被视为临时的。 在预配资源之前，每次使用生存期较短的标记都会创建一个新的开始。
设计建议
采用蓝/绿部署方法来发布所有生产更改。 每次针对任何类型的更改部署所有基础结构和应用程序，以实现一致的状态和零停机时间。 尽管可以重复使用环境，但我们不建议将其用于任务关键型工作负载。 将每个区域部署标记视为暂时的，其生命周期与单个版本的生命周期相关联。
使用全局负载均衡器（如 Azure Front Door）协调蓝绿环境之间的用户流量自动转换。
若要转换流量，请添加一个绿色后端终结点，该终结点使用低流量到卷权重，例如 10%。 验证绿色部署上的低流量是否正常工作并提供预期的应用程序运行状况后，逐渐增加流量。 这样做时，请应用一个较短的上升期来捕获可能不会立即明显的故障。
转换所有流量后，从现有连接中删除蓝色后端。 例如，从全局负载均衡器服务中删除后端、排出队列并分离其他关联。 这样做有助于优化维护辅助生产基础结构的成本，并确保新环境没有配置偏差。
此时，停用旧的、现在处于非活动状态的蓝色环境。 对于下一个部署，重复此过程，蓝色和绿色反转。
订阅范围的部署
根据应用程序的缩放要求，可能需要多个生产订阅作为缩放单元。
观看以下视频，大致了解有关确定任务关键型应用程序的订阅范围的建议。
设计注意事项
可伸缩性。 对于具有大量流量的大规模应用程序方案，请将解决方案设计为跨多个 Azure 订阅进行缩放，以便单个订阅的规模限制不会限制可伸缩性。
重要
使用多个订阅需要额外的 CI/CD 复杂性，必须进行适当的管理。 因此，建议仅在极大规模方案中使用多个订阅，其中单个订阅的限制可能会成为限制。
环境边界。 将生产、开发和测试环境部署到单独的订阅中。 这种做法可确保较低环境不会对缩放限制造成影响。 它还通过提供明确的管理和标识边界，降低了低环境更新污染生产的风险。
治理。 如果需要多个生产订阅，请考虑使用专用应用程序管理组通过策略聚合边界简化策略分配。
设计建议
在专用订阅中部署每个区域部署标记，以确保订阅限制仅在单个部署标记的上下文中应用，而不应用于整个应用程序。 在适当的情况下，可以考虑在单个区域中使用多个部署标记，但应跨独立订阅部署它们。
将全局共享资源置于专用订阅中，以实现一致的区域订阅部署。 避免对主要区域使用专用部署。
持续验证和测试
测试是一项关键活动，可用于全面验证应用程序代码和基础结构的运行状况。 更具体地说，测试使你符合可靠性、性能、可用性、安全性、质量和缩放标准。 测试必须明确定义并作为应用程序设计和 DevOps 策略的一部分进行应用。 测试是本地开发人员流程 (内部循环) 以及整个 DevOps 生命周期的一部分， (外部循环) （即代码从发布管道流程到生产环境的路径上启动时）期间，
观看以下视频，大致了解持续验证和测试。
本部分重点介绍外部循环测试。 它描述了各种类型的测试。
| 测试 | 说明 |
|---|---|
| 单元测试 | 确认应用程序业务逻辑按预期工作。 验证代码更改的总体效果。 |
| 冒烟测试 | 标识基础结构和应用程序组件是否可用并按预期运行。 通常，仅测试单个虚拟用户会话。 结果应该是系统使用预期值和行为进行响应。 常见的冒烟测试方案包括访问 Web 应用程序的 HTTPS 终结点、查询数据库以及模拟应用程序中的用户流。 |
| UI 测试 | 验证是否已部署应用程序用户界面以及用户界面交互是否按预期方式工作。 应使用 UI 自动化工具来推动自动化。 在 UI 测试期间，脚本应模拟真实的用户方案，并完成一系列步骤以执行操作并实现预期结果。 |
| 负载测试 | 通过快速和/或逐渐增加负载来验证可伸缩性和应用程序操作，直到达到预先确定的阈值。 负载测试通常围绕特定的用户流进行设计，以验证在定义的负载下是否满足应用程序要求。 |
| 压力测试 | 应用重载现有资源的活动，以确定解决方案限制并验证系统正常恢复的能力。 main目标是识别潜在的性能瓶颈和缩放限制。 相反，纵向缩减系统的计算资源，监视它在负载下的行为方式，并确定它是否可以恢复。 |
| 性能测试 | 结合负载和压力测试的各个方面来验证负载下的性能，并为应用程序操作建立基准行为。 |
| 混沌测试 | 将人为故障注入系统，以评估其反应方式，并验证复原措施、操作过程和缓解措施的有效性。 关闭基础结构组件、故意降低性能以及引入应用程序故障是测试示例，可用于验证应用程序在方案实际发生时是否按预期做出反应。 |
| 渗透测试 | 确保应用程序及其环境满足预期安全状况的要求。 目标是识别安全漏洞。 安全测试可以包括端到端软件供应链和包依赖项，扫描和监视已知的常见漏洞和暴露 (CVE) 。 |
设计注意事项
自动化. 自动测试对于以及时且可重复的方式验证应用程序或基础结构更改至关重要。
测试顺序。 测试的进行顺序是一个关键考虑因素，因为存在各种依赖项，例如需要有一个正在运行的应用程序环境。 测试持续时间也会影响顺序。 运行时间较短的测试应尽可能在周期的早期运行，以提高测试效率。
可伸缩性限制。 Azure 服务具有不同的软限制和硬限制。 请考虑使用负载测试来确定系统在预期生产负载期间是否面临超出其风险。 负载测试还可用于为自动缩放设置适当的阈值。 对于不支持自动缩放的服务，负载测试可以帮助你微调自动化操作过程。
系统组件（如主动/被动网络组件或数据库）无法适当缩放可能是限制性的。 压力测试有助于识别限制。
故障模式分析。 在应用程序和底层基础结构中引入故障并评估效果对于评估解决方案的冗余机制至关重要。 在此分析过程中，确定部分或完全中断) (风险、影响和影响范围。 有关为 Mission Critical Online 参考实现创建的示例分析，请参阅 各个组件的中断风险。
监视。 应单独捕获和分析测试结果，并对其进行聚合以评估随时间推移的趋势。 应持续评估测试结果的准确性和覆盖率。
设计建议
观看以下视频，了解如何将复原能力测试与 Azure DevOps CI/CD 管道集成。
通过自动执行基础结构和应用程序组件上的所有测试来确保一致性。 在 CI/CD 管道中集成测试，以协调和运行它们（如果适用）。 有关技术选项的信息，请参阅 DevOps 工具。
将所有测试项目视为代码。 它们应与其他应用程序代码项目一起进行维护和版本控制。
使测试基础结构的 SLA 与部署和测试周期的 SLA 保持一致。
在每个部署中运行冒烟测试。 此外，还运行广泛的负载测试以及压力和混沌测试，以验证应用程序性能和可操作性是否得到维护。
- 使用反映实际峰值使用模式的负载配置文件。
- 与负载测试同时运行混沌试验和故障注入测试。
提示
Azure Chaos Studio 是一套原生的混沌试验工具。 借助这些工具，可以轻松地在 Azure 服务和应用程序组件中执行混沌试验和注入故障。
Chaos Studio 为常见故障方案提供内置混沌试验，并支持面向基础结构和应用程序组件的自定义试验。
如果负载或冒烟测试需要数据库交互（如创建记录），请使用特权降低的测试帐户，并使测试数据与实际用户内容分离。
扫描和监视已知 CVE 的端到端软件供应链和包依赖项。
- 使用 Dependabot for GitHub 存储库，确保存储库自动更新它所依赖的包和应用程序的最新版本。
基础结构即代码部署
基础结构即代码 (IaC) 将基础结构定义视为与其他应用程序项目一起进行版本控制的源代码。 使用 IaC 可促进环境之间的代码一致性，消除自动部署期间人为错误的风险，并提供可跟踪性和回滚性。 对于蓝/绿部署，必须使用 IaC 进行完全自动化的部署。
任务关键型 IaC 存储库有两个不同的定义，它们映射到全球和区域资源。 有关这些类型的资源的信息，请参阅 核心体系结构模式。
设计注意事项
可重复的基础结构。 以每次生成相同环境的方式部署任务关键型工作负载。 IaC 应该是主要模型。
自动化. 所有部署都必须完全自动化。 人工流程容易出错。
设计建议
应用 IaC，确保所有 Azure 资源都在声明性模板中定义，并在源代码管理存储库中维护。 通过 CI/CD 管道从源代码管理自动部署模板并预配资源。 不建议使用命令性脚本。
禁止对所有环境执行手动操作。 唯一的例外是完全独立的开发人员环境。
DevOps 工具
有效使用部署工具对于整体可靠性至关重要，因为 DevOps 过程会影响整体功能和应用程序设计。 例如，故障转移和缩放操作可能依赖于 DevOps 工具提供的自动化。 工程团队必须了解部署服务不可用对整个工作负荷的影响。 部署工具必须可靠且高度可用。
Microsoft 提供了两个 Azure 本机工具集（GitHub Actions和 Azure Pipelines），这些工具集可以有效地部署和管理任务关键型应用程序。
设计注意事项
技术功能。 GitHub 和 Azure DevOps 的功能重叠。 可以结合使用它们来充分利用这两者。 一种常见方法是在使用 Azure Pipelines 进行部署时，将代码存储库存储在 GitHub.com 或 GitHub AE 中。
请注意使用多种技术时增加的复杂性。 根据整体可靠性评估丰富的功能集。
区域可用性。 就最大可靠性而言，对单个 Azure 区域的依赖性表示运营风险。
例如，假设流量分布在两个区域：区域 1 和区域 2。 区域 2 托管 Azure DevOps 工具实例。 假设区域 2 发生中断，实例不可用。 区域 1 自动处理所有流量，并需要部署额外的缩放单元以提供良好的故障转移体验。 但是，由于区域 2 中的 Azure DevOps 依赖项，因此无法执行该操作。
数据复制。 数据（包括元数据、管道和源代码）应跨区域复制。
设计建议
这两种技术都托管在单个 Azure 区域中，这可能会限制灾难恢复策略。
GitHub Actions非常适合 (持续集成) 生成任务，但可能缺少复杂部署任务的功能， (持续部署) 。 鉴于 Azure DevOps 的丰富功能集，建议将其用于任务关键型部署。 但是，应在评估权衡后做出选择。
为部署工具定义可用性 SLA，并确保符合更广泛的应用程序可靠性要求。
对于使用主动/被动或主动/主动部署配置的多区域方案，请确保即使托管部署工具集的主区域不可用，故障转移业务流程和缩放操作也能继续运行。
分支策略
有许多有效的分支方法。 应选择确保最大可靠性的策略。 良好的策略可实现并行开发，提供从开发到生产的清晰路径，并支持快速发布。
设计注意事项
最大程度地减少访问。 开发人员应在 功能/* 中完成工作，并 修复/* 分支。 这些分支将成为更改的入口点。 应将基于角色的限制应用于分支，作为分支策略的一部分。 例如，仅允许管理员创建发布分支或强制执行分支的命名约定。
针对紧急情况的加速过程。 分支策略应允许尽快将修补程序合并到 main。 这样，将来的版本将包含修补程序，并避免问题重复出现。 仅将此过程用于解决紧急问题的次要更改，并克制地使用它。
设计建议
优先使用 GitHub 进行源代码管理。
重要
创建至少详细说明 功能 工作和 发布的 分支策略，并使用分支策略和权限来确保正确实施该策略。
触发自动测试过程，在代码更改贡献被接受之前对其进行验证。 团队成员还必须查看更改。
将main分支视为一个持续向前移动且稳定的分支，主要用于集成测试。
- 确保仅通过 PR 对main进行更改。 使用分支策略禁止直接提交。
- 每次将 PR 合并到main时，它都应自动启动针对集成环境的部署。
- 应将main分支视为稳定分支。 在任何给定时间从 main 创建发布应该是安全的。
使用从 main 分支创建并用于部署到生产环境的专用发布/* 分支。 release/* 分支应保留在存储库中，并可用于修补发布。
记录修补程序过程，并仅在需要时使用它。 在 fix/* 分支中创建修补程序，以便后续合并到发布分支并部署到生产环境。
适用于 DevOps 的 AI
可以在 CI/CD 管道中应用 AIOps 方法，以补充传统的测试方法。 这样做可以检测潜在的回归或降级，并允许提前停止部署，以防止潜在的负面影响。
设计注意事项
遥测数据量。 CI/CD 管道和 DevOps 进程为机器学习模型发出各种遥测数据。 遥测范围从测试结果和部署结果到有关复合部署阶段的测试组件的操作数据。
可伸缩性。 传统的数据处理方法（如提取、转换、加载 (ETL) 可能无法缩放吞吐量，以跟上部署遥测和应用程序可观测性数据的增长。 可以使用不需要 ETL 和数据移动的新式分析方法（如数据虚拟化）通过 AIOps 模型实现持续分析。
部署更改。 需要存储部署中的更改，以便自动分析和关联部署结果。
设计建议
定义要收集的 DevOps 流程数据及其分析方式。 遥测（如测试执行指标和每个部署中更改的时序数据）非常重要。
- 公开过渡、测试和生产环境中的应用程序可观测性数据，以便在 AIOps 模型中进行分析和关联。
采用 MLOps 工作流。
开发上下文感知和依赖项感知的分析模型，通过自动化特征工程提供预测，以解决架构和行为更改。
通过在部署管道中注册和部署训练最佳的模型来操作模型。
后续步骤
查看安全注意事项。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈