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

订阅销售实现指南

Azure

本文提供有关订阅销售自动化的实现指导。订阅自动售货将请求、部署和治理订阅的流程标准化，使应用程序团队可以更快地部署其工作负载。

图 1. 示例 Azure 环境中的订阅销售实现。

GitHub 图标我们创建了订阅销售 Bicep 和 Terraform 模块，你应该将它们用作起点。应修改模板以满足实现需求。有关订阅自动售货流程的详细信息，请参阅订阅自动售货概述。

体系结构

应设计订阅销售自动化，完成三项主要任务。订阅自动售货自动化应 (1) 收集订阅请求数据，(2) 启动平台自动化并 (3) 使用基础结构即代码创建订阅。可通过多种方法实现订阅自动售货自动化以完成这三项任务。此示例实现（图 2）演示了一种使用 Gitflow 的方法。 Gitflow 设计与许多平台团队用于管理平台的声明性方法保持一致。

图 2. 实现订阅销售自动化的示例。

在示例实现（图 2）中，数据收集工具负责收集订阅请求数据。当订阅请求获得批准时，它将启动平台自动化。 平台自动化包括请求管道、源代码管理和部署管道。 请求管道会使用数据收集工具中的数据创建 JSON 或 YAML 订阅参数文件。请求管道还会创建新分支、提交订阅参数文件，并在源代码管理中打开拉取请求。新分支会与源代码管理中的主分支合并。合并会触发部署管道，以使用基础结构即代码模块创建订阅。

部署应根据治理要求（见图 1）将订阅置于正确的管理组中。部署会创建初步订阅预算作为成本管理的基础。根据工作负载的需求，部署可以创建一个空虚拟网络，并配置与区域中心的对等互连。创建和配置后，平台团队应将订阅移交给应用程序团队。应用程序团队应更新订阅预算并创建工作负载资源。

收集数据

收集数据的目标是接收业务批准并定义 JSON/YAML 订阅参数文件的值。应用程序团队提交订阅请求时，你应使用数据收集工具来收集所需的数据。数据收集工具应与订阅销售工作流中的其他系统进行交互，以启动平台自动化。

使用数据收集工具。 可以使用 IT 服务管理 (ITSM) 工具来收集数据，或使用低代码或无代码工具（如 Microsoft PowerApps）构建客户门户。数据收集工具应提供业务逻辑来批准或拒绝订阅请求。

收集所需的数据。 需要收集足够的数据来定义 JSON/YAML 订阅参数的值，以便自动执行部署。收集的具体值取决于你的需求。应捕获请求授权者、成本中心和网络要求（Internet 或本地连接）。向应用程序团队询问预期的工作负载组件（应用程序平台、数据要求）、数据敏感度和环境数量（开发、测试、预生产、生产）可能会有所帮助。

验证数据。 应在数据收集过程中验证数据。在平台自动化阶段的后期，解决问题会更加困难。

创建可跟踪请求。 数据收集工具应为新订阅创建已记录且可跟踪的请求（例如 ITSM 工具中的票证）。请求应包含满足该订阅要求的所有必要数据。应将业务逻辑和授权跟踪绑定到请求。

与其他内部系统对接。 如果需要，数据收集工具应与组织中的其他工具或系统对接。目标是使用来自其他系统的数据扩充请求。可能需要标识、财务、安全和网络数据来执行自动化。例如，自动化可以与 IP 地址管理 (IPAM) 工具对接，以保留正确的 IP 地址空间。

创建触发器。 当订阅请求获得批准时，数据传输应触发平台自动化。最好使用数据收集工具中的必要数据创建推送通知。可能需要中间件层（例如 Azure Functions 或 Azure 逻辑应用）来启动该过程。

启动平台自动化

数据收集工具中的通知和数据应触发平台自动化。平台自动化的目标是创建 JSON/YAML 订阅参数文件，将文件合并到主分支，并将其与基础设施即代码模块一起部署以创建订阅。平台团队应拥有和维护平台自动化。示例实现中的平台自动化包括请求管道、源代码管理和部署管道（见图 2）。

使用 JSON 或 YAML 文件。 应使用结构化数据文件（JSON 或 YAML）来存储用于创建订阅的数据。应记录文件的结构，使其可扩展以支持将来的需求。例如，以下 JSON 代码片段定义了 GitHub 中某个 Bicep 模块的订阅参数值。

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionDisplayName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionAliasName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionBillingScope": {
      "value": "providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/123456"
    },
  // Insert more parameters here
  }
}

查看整个文件。有关更多示例，请参阅 Bicep 示例和 Terraform 示例

每个订阅请求使用一个文件。 订阅是订阅销售过程中的部署单元，因此每个订阅请求都应有一个专用的订阅参数文件。

使用拉取请求系统。 创建订阅参数文件的 Gitflow 过程应自动执行以下步骤：

为每个订阅请求创建新分支。
使用收集的数据为分支中的新订阅创建单个 YAML/JSON 订阅参数文件。
创建从分支到 main 的拉取请求。
使用状态更改和对此拉取请求的引用来更新数据收集工具。

示例实现中的请求管道会执行这些步骤（见图 2）。如果工作流很复杂，也可以使用 Azure 中托管的基于代码的解决方案。

验证订阅参数文件。 拉取请求应触发 Lint 分析进程来验证请求数据。目标是确保部署成功。它应验证 YAML/JSON 订阅参数文件。它还可以验证 IP 地址范围是否仍然可用。你可能还希望添加人工干预的手动评审入口。他们可以执行最终评审，并更改订阅参数文件。输出应该是 JSON/YAML 订阅参数文件，其中包含用于创建订阅的所有数据。

触发部署管道。 当拉取请求合并到 main 分支中时，合并应触发部署管道。

创建订阅

订阅销售自动化的最后一项任务是创建和配置新订阅。示例实现使用部署管道将基础结构即代码模块与 JSON/YAML 订阅参数文件一起部署（见图 2）。

使用基础结构即代码。 部署应使用基础结构即代码来创建订阅。平台团队应创建和维护这些模板，以确保进行适当的治理。应使用订阅销售 Bicep 和 Terraform 模块，并对其进行修改以满足实现需求。

使用部署管道。 部署管道协调新订阅的创建和配置。管道应执行以下任务：

任务类别	管道任务
标识	• 创建或更新 Microsoft Entra 资源以表示订阅所有权。 • 为工作负载团队部署配置特权工作负载标识。
调控	• 置于管理组层次结构中。 • 分配订阅所有者。 • 对已配置的安全组配置订阅级基于角色的访问控制 (RBAC)。 • 分配订阅级 Azure Policy。 • 配置 Microsoft Defender for Cloud 注册。
网络	• 部署虚拟网络。 • 配置与平台资源（区域中心）的虚拟网络对等互连。
预算	• 使用收集的数据为订阅所有者创建预算。
正在报告	• 更新外部系统（例如 IPAM）以提交到 IP 预留。 • 使用最终订阅名称和全局唯一标识符 (GUID) 更新数据收集工具请求。 • 通知应用程序团队订阅已准备就绪。

需要商业协议才能以编程方式创建订阅。如果没有商业协议，则需要引入手动过程来创建订阅，但仍可自动执行订阅配置的所有其他方面。

建立工作负载标识。 部署管道需要权限才能对与之对接的所有系统执行这些操作。应使用托管标识或 OpenID Connect (OIDC) 向 Azure 进行身份验证。

后期部署

订阅销售自动化以订阅的创建和配置结束。创建后，平台团队应将新订阅移交给应用程序团队。应用程序团队应更新订阅预算、创建工作负载资源并部署工作负载。平台团队控制订阅的治理，并管理订阅治理随时间的更改。

强制实施成本管理。 订阅预算提供对成本管理至关重要的通知。部署应基于订阅请求数据创建初步订阅预算。应用程序团队收到订阅。该团队应更新预算以满足工作负载的需求。有关详细信息，请参阅：

管理订阅治理。 应随着工作负载的治理要求的变化而更新订阅。例如，可能需要将订阅移动到其他管理组。应为其中一些例行操作生成自动化。有关详细信息，请参阅：

后续步骤

订阅销售可简化和标准化订阅创建过程，并将其置于组织的治理之下。应实现订阅销售自动化，帮助应用程序团队更快地访问应用程序登陆区域，并更快地载入工作负载。有关详细信息，请参阅：

通过