自动化

在软件定义的云基础结构中，团队使用各种工具和技术来预配、配置和管理基础结构。 随着团队的发展和成长，他们可以从使用门户和手动工作过渡到使用代码和自动化来预配、配置和管理基础结构和服务。

平台自动化注意事项

• 通过实现“一切即代码”方法（EaC），团队可以解锁关键优势，创建强大的开发文化，并使每个团队中的每个人都能够检查部署资源的方式和方式。 EaC 还有助于平台团队采用关键开发做法，以提高其敏捷性和效率。 你的团队可以通过将代码存储在存储库中并使用版本控制系统来管理更改和控制哪些代码移动到生产环境。
• Teams 可以遵循 4 眼原则 ，并使用 结对编程 或 同行评审 来确保永远不会单独进行代码更改。 对等编程和对等评审提高了代码质量，让团队共同负责更改，并增加团队对已同意和部署的内容的知识。 代码评审是团队成员学习编码和自动化的新技术和方法的绝佳方法。
• 团队应当使用 Git 等版本控制系统以及 Git 存储库来推动代码审查。 Git 存储库允许团队定义重要的分支，并使用 分支策略对其进行保护。 可以使用策略来要求对这些分支进行代码更改，以满足某些条件，例如最少数量的团队成员批准，然后才能合并到受保护的分支中。
• 团队应将 EaC 方法与更改评审过程和 持续集成和持续交付（CI/CD） 过程结合。 每个代码更改都应自动触发执行静态代码分析、验证和测试部署的 CI 进程。 CI 可确保开发人员提前检查其代码（通常称为 快速失败 或 左移测试），以识别可能导致未来问题的错误。 根据团队使用的 分支策略 ，对任何重要分支的更改都应触发部署到不同的 环境。 更改被批准并合并到main后，CD 过程会将这些更改部署到生产环境。 此代码管理系统为团队提供了每个环境中运行的 单一可信来源。
• 为了确保平台完全自我修复并为工作负荷团队提供自助服务，平台团队必须努力自动执行从预配、配置和平台管理到工作负载团队登陆区域订阅预配的所有作（通常称为 极端自动化）。 极端自动化使平台团队能够专注于提供价值，而不是部署、配置和管理平台。 极端自动化还会创建自我增强的周期，使团队有更多的时间来构建更多的自动化。
• 随着平台团队自动执行运营活动并减少人工干预，他们应将其重点转移到在 Azure 上实现和加速工作负荷团队创新的重要任务。 为了实现这一目标，您的平台团队必须通过多个构建和开发周期进行迭代，同时落实平台的工具、脚本和功能增强。
• 可以使用多个选项来帮助团队开始使用其 Azure 登陆区域部署。 这些选项取决于团队的当前功能，并且随着团队的发展而发展。 更具体地说，对于 平台部署，可以在门户、Bicep 或基于 Terraform 的体验之间进行选择，具体取决于相应团队的代码（IaC）熟练程度和工具首选项。
  • 正在逐步了解 IaC 并且熟悉使用门户来部署和管理资源的新兴平台团队，可以使用 Azure 登陆区域加速器。 此加速器支持当前使用 ClickOps 方法的团队。 ClickOps 是通过单击门户、管理控制台和向导来进行资源的预配、配置和管理的过程。 此加速器允许你的团队使用门户作为初始部署工具。 随着平台工程成熟度的增长，你的团队可以逐渐整合 Azure CLI、PowerShell 或 IaC。
  • AzOps 解决方案允许团队将其平台自动化和管理实践从 ClickOps 转换为能够支持 DevOps。 你的团队可以从使用个人帐户访问权限过渡到仅依赖 CI/CD 原则和实践，采用 AzOps 和 IaC 的 DevOps 实践。 AzOps 允许你的团队自带体系结构，使用 Azure 登陆区域门户加速器部署的体系结构（在基于门户的初始部署后，因为 AzOps 集成不是 ALZ 门户体验的一部分），与现有系统部署集成，或使用自定义模板（Bicep 或 ARM）构建和运营化你的平台。
  • 具有已建立技能和功能的平台团队可以采用遵循 DevOps 原则和做法的编码方法。 你的团队应重度依赖 IaC 和现代开发实践，逐步从在其个人帐户上使用 Azure 访问权限过渡到通过 CI/CD 管道运行所有操作。 你的团队应使用基于 IaC 的加速器（如 ALZ-Bicep 或 Azure 登陆区域 Terraform 模块 ）来加速此转换。
• 基于 IaC 的加速器的管理范围有限。 新版本提供了更多功能和更高的资源管理功能。 如果使用加速器，团队应考虑以加速器开头的分层方法，然后添加一层自动化。 自动化层提供团队所需的功能，以便为工作负荷团队提供完整的平台功能，例如旧应用程序的域控制器部署。
• 随着平台团队过渡到 DevOps 方法，他们需要建立一个处理紧急修复的过程。 他们可以使用 Privileged Identity Management（PIM） 符合条件的权限来请求访问以执行修复，后来将其带回代码以限制配置偏移，或者他们可以使用代码来实现快速修复。 你的团队应始终在待办事项中记录快速修复，以便他们可以在以后重新处理每个修复并限制其技术债务。 技术债务过多会导致未来的减速，因为某些平台代码没有完全审查，并且不符合团队编码准则和原则。
• 可以使用 Azure 策略 将一些自动化添加到平台。 请考虑使用 IaC 部署和管理 Azure 策略，通常称为“策略即代码”（PaC）。 通过这些策略，可以自动执行日志收集等活动。 许多 PaC 框架还实施豁免过程，因此请为您的工作负载团队计划请求政策豁免。
• 尝试部署不符合安全控制的资源时，请使用“策略驱动的治理”向工作负荷团队发出信号。 请考虑为这些情况部署 deny 策略，使你的团队能够将“一切皆代码”应用于工作负载管理，并避免配置漂移现象，其中代码描述了一种设置，而策略在部署时更改了该设置。 避免使用 modify，例如，如果工作负荷团队在其代码中定义了一个 supportOnlyHttpsTraffic = false 存储帐户，而 modify 策略在部署时将其更改为 true 以保持合规性。 这会导致代码偏离所部署的内容。

平台自动化设计建议

• 遵循“ 一切为代码 ”方法，实现对 Azure 平台、文档、部署和测试过程的完整透明度和配置控制。
• 使用 版本控制 管理所有代码存储库，包括：
  • 基础结构即代码
  • 策略即代码
  • 配置即代码
  • 将部署视为代码
  • 文档即代码
• 实施 4 眼原则 和 对等编程 或 对等评审 过程，以确保团队在部署到生产环境之前审查所有代码更改。
• 为团队采用 分支策略 ，并为要保护的 分支设置分支策略 。 使用分支策略时，团队必须使用 拉取请求 进行合并更改。
• 使用 持续集成和持续交付（CI/CD） 自动执行代码测试和部署到不同的环境。
• 努力将一切自动化，例如平台的预配、配置和管理，以及为工作负载团队预配着陆区订阅。
• 使用与团队功能匹配的可用加速器之一开始部署 Azure 登陆区域。
• 计划使用分层部署方法添加那些尽管未被加速器涵盖但为了完全支持您的工作负荷团队所需的功能。
• 建立使用代码实现快速修复的过程。 始终在团队的待办事项清单中记录快速修复，以便以后可以重新处理每个修复，以限制技术债务。
• 使用 基础结构即代码 部署和管理 Azure 策略 （通常称为策略即代码）
• 为政策实施豁免流程。 规划工作负荷团队请求策略豁免，并准备好在需要时为团队清除障碍。
• 使用“策略驱动治理”来阻止当工作组尝试部署不符合安全控制的资源时的操作。 这有助于减少配置偏移，其中代码声明的状态与最终部署的状态不同。

阅读更多

• 采用策略驱动的防护措施
• 肱二头肌基础知识
• 中级肱二头肌
• 高级二头肌
• 使用 Bicep 和 GitHub Actions 部署 Azure 资源
• 使用 Bicep 和 Azure Pipelines 部署 Azure 资源
• 通过将基础结构部署为代码来控制和管理 Azure 环境