你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
自动化
在软件定义的云基础结构中，团队使用各种工具和技术来预配、配置和管理基础结构。 随着团队的发展和壮大，他们可以从使用门户和手动操作转换为使用代码和自动化操作来预配、配置和管理基础结构和服务。
平台自动化注意事项
- 实现一切皆代码 (EaC) 方法可以让团队解锁关键优势，创建强大的开发文化，并使每个团队中的每个人都能够检查如何部署资源以及部署了哪些资源。 EaC 还有助于平台团队采用关键的开发做法来提高其敏捷性和效率。 团队可以跟踪更改并控制将哪些更改移至生产，方法是将代码存放在存储库中，并使用版本控制系统对其进行管理。
- 团队可以遵循“四眼原则”，并使用“结对编程”或“同级评审”来确保永远不会单独进行代码更改。 结对编程和同级评审提高了代码质量，让团队共同为更改负责，且增进团队对达成一致的内容和部署内容的了解。 代码评审是团队成员学习编码和自动化新技术和方法的绝佳方式。
- 团队应结合使用 Git 等版本控制系统以及 Git 存储库来强制实施同级评审。 Git 存储库让团队可以定义重要的分支，并使用分支策略对其进行保护。 可以使用策略来要求在这些分支上进行代码更改，以此满足某些条件，例如在合并到受保护的分支之前，团队成员需要审批的最低数量。
- 团队应将 EaC 方法和更改评审流程与持续集成和持续交付 (CI/CD) 流程联系起来。 每个代码更改都应自动触发 CI 流程，该流程执行静态代码分析、验证和测试部署。 CI 确保开发人员能提前检查其代码（通常称为“快速失败”或“测试左移”）是否存在错误，这些错误可能会在将来产生问题。 根据团队使用的分支策略，对任何重要分支所做的更改都应触发部署到不同环境。 审批更改且将其合并到
main后，CD 流程就会将这些更改部署到生产中。 此代码管理系统为团队提供了“单一事实来源”，可让他们了解在每个环境中运行的内容。 - 为确保平台完全自愈并为工作负载团队提供自助服务，平台团队必须努力实现一切自动化（通常称为极度自动化），此自动化涵盖从预配、配置和平台管理到工作负载团队的登陆区域订阅预配的全部内容。 极度自动化使平台团队能够专注于提供价值，而不是部署、配置和管理平台。 极度自动化还会创建自我增强周期，使团队有更多的时间来生成更多的自动化。
- 随着平台团队自动执行操作活动并减少人为干预，他们应将注意力转移到重要任务上，这些任务能在 Azure 上实现和加速工作负载团队创新。 为实现此目标，平台团队必须循环访问生成和开发的多个周期，因为其已将平台的工具、脚本和功能增强落实到位。
- 提供了多种选项来帮助团队开始部署 Azure 登陆区域。 这些选项取决于当前团队的能力，并且可以随着团队的发展而增长。 更具体地说，对于 平台部署，可以根据各自的 Teams IaC 熟练程度和工具首选项在门户、Bicep 或基于 Terraform 的体验之间进行选择。
- 仍在了解 基础结构即代码（IaC） 且更熟悉使用门户部署和管理资源的新平台团队可以使用 Azure 登陆区域加速器 启动，这支持仍在使用 ClickOps 方法的团队。 ClickOps 是通过单击门户、管理控制台和向导来预配、配置和管理资源的过程。 通过此加速器，团队可以使用门户作为初始部署工具，随着平台工程成熟度的增长，可以进一步使用 Azure CLI、PowerShell 或 IaC。
- AzOps 解决方案能让团队将其平台自动化和管理做法从 ClickOps 驱动发展到 DevOps 支持。 借助 AzOps 和 IaC，团队可以从使用其个人帐户访问转换为使用仅依赖 CI/CD 的 DevOps 原则和做法。 AzOps 允许你的团队自带体系结构，使用 Azure 登陆区域门户加速器部署的体系结构（在基于门户的初始部署后，因为 AzOps 集成不是 ALZ 门户体验的一部分），与棕色部署集成，或使用自定义模板（Bicep 或 ARM）构建和操作平台。
- 具备既定技能和能力的平台团队可以采用规范化方法，此方法遵循 DevOps 原则和做法。 团队应以 IaC 和现代开发做法为基础，从在其个人帐户上使用 Azure 访问转换为通过 CI/CD 管道运行所有操作。 你的团队应使用基于 IaC 的加速器（如 ALZ-Bicep 或 Azure 登陆区域 Terraform 模块 ）来加速此转换。
- 基于 IaC 的加速器管理范围有限。 新版本提供更多功能和增强的资源管理能力。 若要使用加速器，团队应考虑分层方法，此方法从加速器开始，而后添加一层自动化。 自动化层提供团队所需的功能，以便借助平台功能（如旧应用程序的域控制器部署）全面支持工作负载团队。
- 随着平台团队转换为使用 DevOps 方法，他们需要制定处理紧急修复的流程。 他们可以使用 Privileged Identity Management (PIM) 合格权限来请求访问权限以执行修复，然后将其带回代码来限制配置偏移，或者使用代码来实现快速修复。 团队应始终在其积压工作 (backlog) 中注册快速修复，以便其之后能修改每个修复并限制其技术债务。 技术债务过多会导致将来减速，因为某些平台代码未经全面评审，也不符合团队编码指南和原则。
- 可以使用 Azure 策略向平台添加某些自动化。 请考虑使用 IaC 来部署和管理 Azure 策略，通常称为策略即代码 (PaC)。 借助这些策略，可以自动执行日志收集等活动。 许多 PaC 框架还实现了豁免流程，因此请为工作负载团队计划，以请求豁免策略。
- 当工作负载团队尝试部署不符合安全控制的资源时，请使用“策略驱动的治理”向其发送信号。 针对这些情况，请考虑部署具有
deny效果的策略，这样工作负载团队也可以遵循“一切皆代码”，并避免在部署时发生配置偏移（即代码声明某件事而策略更改了某个设置）。 避免使用modify效果，例如，工作负载团队部署存储帐户时在其代码中定义了supportOnlyHttpsTraffic = false，而modify策略在部署时将其更改为true以保持其合规性。 这会导致代码偏移部署的内容。
平台自动化设计建议
- 遵循“一切皆代码”方法，用于实现 Azure 平台、文档、部署和测试过程的完全透明和配置控制。
- 使用 版本控制 管理所有代码存储库，包括：
- 基础结构即代码
- 策略即代码
- 配置即代码
- 部署即代码
- 文档即代码
- 实现“四眼原则”以及“结对编程”或“同级评审”流程，用于确保在将所有代码更改部署到生产之前，团队对其进行了评审。
- 为团队采用分支策略，并为要保护的分支设置分支策略。 使用分支策略时，团队必须使用拉取请求来进行合并更改。
- 使用持续集成和持续交付 (CI/CD) 实现代码测试和部署到不同环境的自动化。
- 努力实现“一切自动化”，例如平台的预配、配置和管理，以及为工作负载团队预配登陆区域订阅。
- 使用与团队能力相匹配的某个可用加速器开始部署 Azure 登陆区域。
- 计划使用分层部署方法来添加功能，这些功能未涵盖于加速器中，但需要其为工作负载团队提供全面支持。
- 建立使用代码来实现快速修复的流程。 始终在团队的积压工作 (backlog) 中注册快速修复，以便之后能修改每个修复并限制技术债务。
- 使用基础结构即代码来部署和管理 Azure 策略（通常称为策略即代码）
- 实现策略豁免流程。 为工作负载团队计划以请求豁免策略，并准备好在需要时解除对团队的阻止。
- 当工作负载团队尝试部署不符合安全控制的资源时，请使用“策略驱动的治理”对其执行阻止操作。 这有助于减少配置偏移，即代码声明的状态与最终部署的状态不同。