订阅销售实现指南

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

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

我们创建了订阅销售 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 过程应自动执行以下步骤：

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

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

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

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

创建订阅

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

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

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

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

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

后期部署

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

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

• 创建并管理预算
• 使用 Azure 预算管理成本
• 成本分配
• 跨业务部门、环境或项目跟踪成本

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

• 移动管理组和订阅
• 使策略和策略计划保持最新
• 资源标记
• 根据要求定制 Azure 登陆区域体系结构

后续步骤

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

• Bicep 模块
• Terraform 模块
• 订阅销售概述
• Azure 登陆区域概述