你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关启用自动化的建议

  • 项目

适用于此 Azure Well-Architected 框架卓越运营清单建议：

OE：10 为生命周期问题、引导以及应用治理和合规性防护等操作提前设计和实现自动化。 以后不要尝试改造自动化。 选择平台提供的自动化功能。

本指南介绍有关设计和实现工作负载以实现自动化的建议。 在设计工作负载时考虑到自动化，以确保快速可靠地执行预配资源、缩放和部署等常规任务。 自动化简化了维护任务，并允许你更高效地更新、修补和升级系统。

关键设计策略

工作负载设计

可以将工作负载设计为支持从构思阶段到持续改进阶段的自动化。 首先，考虑如何在工作负载中应用自动化，以帮助确保准备好必要的部分。 从 Well-Architected 框架支柱的角度考虑工作负载，以帮助规划要使用的自动化类型。 可以自动执行安全性、可靠性、性能、操作和成本控制等许多功能。

在设计时考虑到自动化，以最大程度地减少工作负载运行后的重构。 在决定使用哪些自动化工具时，请考虑工作负载要求。 你的团队可能已经熟悉现成的自动化工具。 采用这些工具可以更轻松地实现工作负载自动化，但请注意其限制和与云平台的兼容性。 例如，某些自动化工具可能与 Azure CLI 工具很好地集成，而其他自动化工具可能需要 REST 接口。 始终调查云平台提供的工具，以确保它们兼容并提供所需的功能。 可以主动规划自动化的方法示例包括：

  • 部署：自动执行应用程序和基础结构部署，以确保可预测的标准。 通过制定部署标准、对团队进行你将使用的工具进行培训以及实现必要的基础结构来规划自动部署。

  • 验证：使用业务流程或策略工具自动验证工作负载的合规性要求。 确定适合工作负载的验证工具，并计划实现所需的系统，例如业务流程服务器。

  • 自动缩放：在整个基础结构中使用自动缩放来帮助实现可靠性和性能要求。 除了规划冗余和自然增长外，还应提前在工作负载中分配 IP 地址空间和子网，以考虑缩放操作。

权衡：在设计工作负载以实现自动化时，请考虑要保持的控制程度与通过自动化获得的效率。 在某些情况下，工作负荷可能不够成熟，无法自动执行某些功能，或者可能需要自动化无法提供的灵活性。

在设计工作负载时，还要考虑团队的技能组合。 如果高度自动化需要团队不具备支持能力的工具，则可能需要将不太全面的设计用作中间步骤。

持续工作负载改进

工作负载在云中运行后，必须确定持续改进的优先级。 观察操作中的工作负载，分析使用模式，并查看与工作负载相关的客户行为，以确定可以改进自动化的领域。 寻找增强现有自动化或引入新自动化以改进客户体验的方法。 例如，你可能已启用自动缩放，但工作负荷增加的生存期很短。 可以集成横向扩展自动化，以在负载降到阈值以下时减少 CPU 使用率。

本指南的以下部分提供有关特定自动化领域的建议，可帮助你设计和实现工作负载。

启动

引导是指对资源进行配置更新，该更新必须在预配后，但在资源作为工作负荷池的一部分可用之前进行。 引导通常与虚拟机 (VM) 相关联，但必须在部署过程中设置许多其他资源，包括平台即服务 (PaaS) 技术和容器托管技术（如 Azure Kubernetes 服务 (AKS) ）。

云平台可能会为你提供引导解决方案，你应该尽可能使用这些解决方案。 例如，可以在部署过程中使用 Azure 中的 VM 扩展进行预定义的配置更改，并通过注入 PowerShell 脚本自定义配置更改。

身份验证和授权

在设计身份验证和授权策略时，将自动化考虑在内。 在生产工作负荷中保持最高级别的安全性非常重要，但这可能会影响自动化。 例如，使用生物识别或多重身份验证会增加自动化设计中必须考虑的复杂性。 使用非人的安全帐户进行自动身份验证，例如托管标识、工作负载标识或证书。 确保已在自动化中包含机密和密钥管理，以提高身份验证安全性。

设计工作负载的可变性

通过在项目中构建灵活性，避免在进行小更改时不必要地部署新基础结构。 例如，可以使用设置的参数来更新应用配置等组件，而不是在功能标志更改时重新部署基础结构。 请务必清楚地定义和记录如何使用可变性来避免过度使用和配置偏差。

生成控制平面

控制平面是用于通过统一接口管理应用程序及其依赖项的后端系统或工具套件。 构建控制平面（如 REST 接口、CLI 或 Webhook），以支持外部工具的自动化。

通过控制平面公开维护操作，以便协调工作负荷组件，例如有序备份和还原、启动、配置、导入/导出和批处理操作。 在决定要通过控制平面公开的操作时，请谨慎选择适当的粒度级别。

监视和记录

制定监视策略以捕获驱动所需自动化类型的指标。 使用结构化日志记录和自定义指标以自动化工具易于识别的格式提供自动化所需的信息。 捕获的指标应与监视系统中定义的阈值配对，以触发警报和自动操作（如通知或自我修复机制）（如果适用）。 有关详细信息，请参阅 自我修复和自我保护的建议。

用户生命周期

将应用程序和基础结构设计为允许个人或多租户客户自动加入和卸载用户。 通过脚本、基础结构预配和取消预配以及凭据和机密管理来规划自动数据库更新。

业务流程和策略使用

作为持续工作负载管理的一部分，可以在资源中自动Desired State Configuration (DSC) ，以帮助确保它们满足合规性和业务需求。 DSC 自动化有助于确保快速捕获和修正配置偏移。 可以使用业务流程工具或策略管理工具自动执行 DSC。 将业务流程工具（如 Azure DevOps 服务或 Jenkins）视为基于推送的机制。 业务流程工具允许通过工作流事件（例如手动或自动部署）推送配置更新。 这些更新作为部署脚本中定义的任务序列的一部分运行。 策略管理工具使用基于拉取的机制，这意味着系统在工作负荷的基础级别运行，定期轮询工作负荷，以针对定义的 DSC 检查其状态。 如果轮询发现不一致或配置偏移，该工具将采取纠正措施。 在业务流程和策略管理工具之间做出决定时，请考虑以下因素：

  • 业务流程工具没有内置功能，无法主动轮询工作负载以查找配置偏移。 业务流程工具应集成到持续集成和持续交付 (CI/CD) 管道中，以维护基础结构即代码 (IaC) 部署和管理的标准。 使用业务流程工具的一个优点是，部署时始终完全配置资源。

  • 使用策略管理工具可以定义影响一个或多个资源组的策略。 当资源签入策略管理系统时，将强制实施这些策略。 使用策略管理的一个优点是，这些系统不是代码驱动的，因此团队中的操作员可能更容易采用这些系统。

在业务流程或策略工具之间做出决定时，请考虑是否必须在部署时对新资源进行配置更新。 另请考虑在代码中定义更新是否符合操作实践以及计划部署的资源类型数。 如果跨资源类型存在许多不同的配置，则策略工具可能是管理更新的更简单方法。

Azure 简化

策略管理

Azure Policy：使用Azure Policy，可以强制实施标准并大规模评估合规性。 Azure Policy提供了一个聚合视图，用于评估合规性仪表板中工作负荷环境的总体状态。 或者，可以使用Azure Policy在粒度级别评估每个资源和策略。 还可以使用 Azure Policy 自动修正新资源或批量修正现有资源。

权衡：将自动化从 CI/CD 管道卸载到平台工具或服务（如Azure Policy）可以简化管道，但存在一些缺点，例如使用多个系统会增加管理负担。 例如，平台服务中的执行失败不会在管道日志中捕获，并且必须智能地馈送到可观测性平台中，以便通知相应的各方。

启动自动化

Azure 虚拟机扩展：虚拟机扩展是在 VM 上运行部署后配置和自动化的小型包。 多个扩展可用于不同的配置任务，例如运行脚本、配置反恶意软件解决方案和配置日志记录解决方案。 使用 Azure 资源管理器模板、Azure CLI、Azure PowerShell模块或Azure 门户在 VM 上安装并运行这些扩展。 每个 VM 都安装了一个 VM 代理，用于管理扩展的生命周期。

通常，VM 扩展使用自定义脚本扩展在 VM 或 Azure 虚拟机规模集上安装软件、运行命令和执行配置。 可以将这些扩展设置为作为 IaC 部署的一部分运行，以便它们使用 Azure VM 代理在新 VM 上运行。 还可以使用 Azure CLI、PowerShell 模块或 Azure 门户在 Azure 部署外部运行扩展。

Cloud-init： Cloud-init 是一种行业工具，用于在首次启动时配置 Linux VM。 与 Azure 自定义脚本扩展非常类似，cloud-init 允许在 Linux VM 上安装包和运行命令。 可以将 cloud-init 用于软件安装、系统配置和内容暂存。 Azure 包括许多跨已知 Linux 分发版的已启用云 init 的 VM 映像。 有关完整列表，请参阅 cloud-init 对 Azure 中 VM 的支持。

Azure 部署脚本资源： 使用 Azure 进行部署时，可能需要运行任意代码来启动用户帐户、Kubernetes Pod 的管理或从非 Azure 系统查询数据。 由于无法通过 Azure 控制平面访问这些操作，因此需要单独的机制。 有关详细信息，请参阅 Microsoft.Resources deploymentScripts。 与任何其他 Azure 资源一样，部署脚本资源：

  • 可在 Azure 资源管理器模板中使用。

  • 包含其他资源中的 Azure 资源管理器模板依赖项。

  • 使用输入并生成输出。

  • 使用用户分配的托管标识进行身份验证。

部署后，部署脚本将运行 PowerShell 或 Azure CLI 命令和脚本。 可以在 Azure 门户或使用 Azure CLI 和 PowerShell 模块观察脚本运行和日志记录。 可以在脚本失败后自定义运行环境、超时选项和资源管理的变量。

使用 GitOps 启动 AKS 群集：可以通过在 GitHub 存储库中声明配置设置，使用 GitOps 和 Flux v2 群集扩展来启动新预配的 AKS 群集。 由于 AKS 群集文件存储在 GitHub 存储库中，因此会对其进行版本控制，并且可以轻松跟踪版本之间的更改。 Kubernetes 控制器在群集中运行，并通过从存储库拉取文件，持续协调群集状态与 Git 存储库中声明的所需状态。 有关详细信息，请参阅 AKS 基线参考体系结构。

配置管理

Azure 自动化 State Configuration 是由 Azure Policy 来宾配置功能管理的 DSC 管理工具，可用于编写、管理和编译任何云或本地数据中心节点的 PowerShell DSC 配置。 还可以使用此工具导入 DSC 资源并将配置分配给目标节点。

Azure 应用程序配置 是一项服务，可用于集中管理应用程序设置和功能标志。 它与 Azure 密钥保管库配合使用，因此可以跨环境安全地管理各种应用程序配置。

更改跟踪和库存

使用 Azure Monitoring Agent 跟踪更改跟踪和清单 ，跟踪虚拟机中的 OS 配置偏移。 这会在工作负荷中的虚拟机上自动检测偏移、运行服务的清单和已安装的包。 通过更改跟踪和库存跟踪的项目包括：

  • 已安装的 Windows 和 Linux 软件
  • 关键 Windows 和 Linux 文件
  • Windows 注册表项
  • Windows 服务和 Linux 守护程序

卓越运营清单

请参阅完整的一组建议。

卓越运营清单