通过

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

启用自动化的建议

  • 项目

适用于此 Azure 精心构建的框架卓越运营清单建议：

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

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

关键设计策略

设计工作负载组件以支持自动化

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

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

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

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

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

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

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

在生命周期内重新访问自动化设计

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

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

自动启动

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

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

将自动化纳入访问管理

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

在工作负荷中设计可变性

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

生成控制平面

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

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

采用数据驱动的方法来开发自动化

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

自动执行用户生命周期事件

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

自动执行 Desired State Configuration

作为持续工作负荷管理的一部分，可以在资源中自动执行 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 分发版的许多已启用 cloud-init 的 VM 映像。 有关完整列表，请参阅 Azure 中 VM 的 cloud-init 支持。

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 监视代理 更改跟踪和清单会跟踪 Azure VM 和已启用 Arc 的 VM 中的 OS 配置偏移。 这会自动检测偏移、清单运行的服务和工作负载中虚拟机上安装的包。 通过更改跟踪和库存跟踪的项目包括：

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

卓越运营清单

请参阅完整的建议集。

卓越运营清单