Azure Stack Hub 套餐、计划与订阅模型深度解析（下篇）

未经同意，请勿转载！

本篇定位：上篇从"为什么"出发，把 Quota / Plan / Offer / Subscription 的概念模型讲透；本篇进入"实战与治理"维度------把模型变成可落地的 ARM / PowerShell 自动化、可量化的运维指标、可审计的治理流程。

建议阅读路径：先看上篇 §2~§5 建立概念基础，再回到本篇 §1~§4 落地自动化与治理。

版本基础 ：本文基于 Azure Stack Hub 当前主流 GA 版本整理（生命周期见 §5.1）。AzureRM 模块已经退役，当前主流推荐使用 Az 模块；不同 OEM 集成系统（Dell / HPE / Lenovo 等）和不同版本之间 cmdlet 行为可能存在差异，实际执行前请以当版本 Operator 文档为准。

1. PowerShell / ARM 自动化：把服务目录模型转化为 IaC 流程

上篇 §6 描述了 6 步创建流程。本节把它翻译成 ARM + PowerShell + GitOps 的自动化范式------重点不在某一个 cmdlet，而在于 整个 IaC 流程。

1.0 Azure Stack Hub 自动化体系四层模型

|--------|----------------------------|----------|
| 层级 | 工具 | 定位 |
| 声明层 | JSON/YAML Template | 定义服务目录状态 |
| 执行层 | Admin ARM API / PowerShell | 执行变更 |
| 治理层 | GitOps / PR / CI | 版本控制 |
| 操作层 | Operator Portal | 人工操作与验证 |

Azure Stack Hub 的"自动化"本质是 四件事的组合，单一 cmdlet 解决不了 Quota / Plan / Offer 这类 Operator 层对象：

|------------------------|---------------------------------------------------------------------------------------|---------------------|
| 层 | 工具 / 范式 | 适用场景 |
| ARM Template（JSON） | 用于描述和版本管理服务目录定义，通过 Admin API / Resource Provider API 自动化配置，而不是作为普通 ARM Resource 直接部署。 | 版本化、可审计、可回滚（推荐） |
| PowerShell（Az 模块） | 交互式运维 / 脚本化批量操作 | 日常运维 / 一次性变更 |
| GitOps / 模板仓库 | JSON 模板 + Git 仓库 + PR 流程 | 跨环境一致性 / 审计追溯 |
| Operator Portal | 图形化操作 | 单次 / 紧急 / 调试 |

推荐组合：JSON 模板作为单一事实源（Single Source of Truth）→ Git 仓库管理 → PR 评审变更 → PowerShell 驱动部署 → Operator Portal 验证结果。

本节中所有 PowerShell 代码块都是伪代码示例 ，用于演示自动化逻辑与参数传递结构，不代表真实 cmdlet 名称 。Azure Stack Hub Quota / Plan / Subscription 不是普通 ARM Resource，主要通过 Admin ARM API、RP Provider API 或当版本官方 PowerShell 模块管理；实际执行前请用 Get-Command -Module Az.* 与 Get-AzResourceProvider 探测当前环境可用的 cmdlet 与 RP。

1.1 前置：连接 Azure Stack Hub Operator 环境（Az 模块）

复制代码

# 在 Azure Stack Hub Operator PowerShell 环境中（任一 PEP 节点 / 特权工作站）

# 1) 注册 Operator 环境（Az 模块，当前主流）
Add-AzEnvironment `
    -Name "AzureStackAdmin" `
    -ArmEndpoint "https://adminmanagement.<region>.<fqdn>"

# 2) 使用 Operator 凭据登录（Cloud Admin）
Connect-AzAccount -EnvironmentName "AzureStackAdmin"

# 3) 验证连接（可选）
Get-AzResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

演进说明 ：早期 Azure Stack Hub 基于 AzureRM 模块，对应 cmdlet 为 Add-AzsAzureRmEnvironment。AzureRM 已经退役，当前主流推荐使用 Az 模块的 Add-AzEnvironment 。少数文档/脚本仍可见 Add-AzAzureStackEnvironment 写法，但本质上都是注册一个 ARM 环境。Add-AzEnvironment 参数集随 Az.Accounts 版本变化，生产脚本应通过 Get-Help Add-AzEnvironment 验证。

1.2 Step 0-1：Resource Provider 与 Quota（伪代码）

Quota 是 Azure Stack Hub Admin 层针对 Resource Provider 的资源限制策略，不是 Compute RP 自身资源。命名建议遵循上篇 §6 Step 1 推荐的 资源类型-容量级别 模式。但 Quota 的实际创建方式因 RP 与版本而异------本文用伪代码展示参数结构：

复制代码

# ============================================================
# 以下为伪代码示例，展示 Quota 自动化逻辑与参数结构
# Azure Stack Hub Quota 不是普通 ARM Resource
# 实际创建通过 Admin ARM API / RP Provider API / 当版本 PS 模块完成
# 执行前请用 Get-Command 探测当前环境可用 cmdlet
# ============================================================

# Compute Quota（引用 Microsoft.Compute RP）
New-ComputeQuota `
    -Name "Compute-Small" `
    -Location "local" `
    -VmCount 50 `
    -CoresCount 100 `
    -AvailabilitySetCount 10 `
    -VMScaleSetCount 100 `
    -ManagedDisksCount 50

# Network Quota（引用 Microsoft.Network RP）
New-NetworkQuota `
    -Name "Network-Default" `
    -Location "local" `
    -PublicIpCount 50 `
    -VirtualNetworkCount 50 `
    -VirtualNetworkGatewayCount 1 `
    -LoadBalancerCount 50 `
    -NicCount 100 `
    -NetworkSecurityGroupCount 50

# Storage Quota（引用 Microsoft.Storage RP）
New-StorageQuota `
    -Name "Storage-Default" `
    -Location "local" `
    -CapacityInGB 2048 `
    -StorageAccountCount 20

为什么是伪代码：

不同 Azure Stack Hub 版本的 Quota cmdlet 集合差异较大------可能通过 AzsCompute / AzsStorage / AzsNetwork 模块提供，也可能直接通过 Admin ARM API 调用。
实际执行前必须用 Get-Command -Module Azs.*（或 Az.*）确认当前环境可用 cmdlet 列表与参数集。
把 cmdlet 名称做成"环境探测步骤"的输出，而不是脚本里的硬编码字符串。

1.3 Step 2：创建 Plan（伪代码）

复制代码

# ============================================================
# 以下为伪代码示例
# Plan 是 Operator 层对象，不是普通 ARM Resource
# ============================================================

# 把多个 Quota 组合成一个 Plan
New-Plan `
    -Name "testplan" `
    -ResourceGroupName "testrg" `
    -QuotaIds @(
        $computeQuota.Id,
        $networkQuota.Id,
        $storageQuota.Id
    ) `
    -Description "Test plan"

# Plan 角色（Base / Add-on）不在创建时指定，由后续 Offer 引用决定

1.4 Step 3：创建 Offer（伪代码）

复制代码

# ============================================================
# 以下为伪代码示例
# ============================================================

# 创建 Offer，关联 1 个 Base Plan + 0 个或多个 Add-on Plan
New-Offer `
    -Name "testoffer" `
    -ResourceGroupName "testrg" `
    -BasePlanIds @($testPlan.Id)   # 数组，但约定 1 个 Base Plan

关键点：

BasePlanIds 是数组，但 Azure Stack Hub 模型约定 一个 Offer 只能有 1 个 Base Plan。
Add-on Plan 通过单独的 API 在 Offer 创建后追加（具体 cmdlet 因版本而异）。
Offer 的可见性（Public / Private）由后续状态切换决定。

1.5 Step 4-5：创建订阅

订阅创建有 两条路径，对应不同 cmdlet / API：

复制代码

# ============================================================
# 路径 A：用户自助订阅（User Portal）
#   在 User Portal 中完成，无 cmdlet
#   参考：https://aka.ms/Azurestack/Subscribe
# ============================================================

# ============================================================
# 路径 B：Operator 代创建（伪代码）
#   通过 Admin ARM API 或对应版本 PS 模块
#   参数：Owner / Offer / DisplayName
# ============================================================

New-Subscription `
    -Owner "<user-principal-name>" `
    -OfferId $testOffer.Id `
    -DisplayName "dev-team-A"

不要硬编码 cmdlet ：Operator 代创建订阅的具体 cmdlet 因版本而异------可能是 New-AzSubscription（需特殊权限上下文）、RP 提供的 cmdlet，或直接 Admin ARM API 调用。实际执行前以当版本文档为准。

1.6 批量操作的范式（IaC 视角）

真实运维场景里，管理员往往要批量处理几十甚至上百个 Quota / Plan / Offer / Subscription。推荐做法：

JSON 模板驱动：把所有 Quota / Plan / Offer 定义写到 JSON 文件（按环境拆分 dev / staging / prod），用脚本读 JSON 后批量 Apply。这是 Azure Stack Hub 自动化最稳的做法------JSON 模板可审计、可回滚、可走 PR 流程。
环境变量注入：把 Offer 名、ResourceGroup、Owner、QuotaIds 等做成变量，跨环境复用脚本。
幂等性保证 ：每次 Apply 前先 Get- 判断对象是否存在，存在则 Set-，否则 New-，避免重复创建。
错误处理：捕获 cmdlet 的异常并写入审计日志，便于后续追责。

示例伪代码（展示 IaC 批量 Apply 范式）：

复制代码

# ============================================================
# 伪代码示例
# ============================================================

# 读取模板
$templates = Get-Content -Raw "D:\AzureStack\offers.json" | ConvertFrom-Json

foreach ($offer in $templates.offers) {
    # 1. 创建 / 更新 Quota
    # 2. 创建 / 更新 Plan
    # 3. 创建 / 更新 Offer
    # 4. 写入审计日志
    Write-Output "[$(Get-Date -Format 'o')] Apply Offer: $($offer.name)"
}

关键提示 ：Azure Stack Hub Operator PowerShell 的 cmdlet 集合 跨版本差异较大。建议：

在 Operator 环境中先 Get-Command -Module Azs.* 与 Get-AzResourceProvider 确认实际可用 cmdlet 与 RP。

把 cmdlet 列表作为脚本的"环境探测步骤"，避免硬编码 cmdlet 名。

Azure Stack Hub Quota / Plan / Offer / Subscription 不是普通 ARM Resource ------多数情况下要通过 Admin ARM API 或 RP Provider API 创建，而不是直接 New-AzResource。

PowerShell heredoc 里的中文分号 ； 会破坏脚本结构------通过 base64 + bash 通道传入是更稳的做法（详见系列专题文章）。

2. Subscription 生命周期管理：启停 / 服务目录升级 / 审计

创建只是开始。Subscription 的 生命周期治理 才是日常运维的主战场。本节覆盖三类典型动作。

2.1 启用 / 禁用 Subscription

复制代码

# ============================================================
# 伪代码示例：Subscription 状态管理
# ============================================================

# 获取某个用户的订阅
$sub = Get-Subscription -SubscriptionId "<subscription-id>"

# 禁用
$sub.State = "Disabled"
Set-Subscription -Subscription $sub

# 启用
$sub.State = "Enabled"
Set-Subscription -Subscription $sub

Azure Subscription 状态分类（公有云参考）：

Enabled：正常
Warned：超出额度警告
PastDue：欠费
Disabled：禁用
Deleted：已删除

但 Azure Stack Hub 的 Subscription 状态管理不像 Azure 公有云：

管理员通常通过 Offer 移除 / Subscription 删除 / RBAC 控制 / Tenant 禁用 来实现访问控制。
Subscription 状态切换（特别是 Disabled ）属于管理状态操作，不建议作为日常容量控制手段------它会影响现有订阅的资源访问，更适合在用户欠费、安全事件、账户冻结等一次性场景下使用。
日常容量控制首选 Quota 调整 + RBAC 收紧，而不是频繁 Disabled。

典型场景：

欠费 / 超额 ：用户 Quota 用尽或成本超标------首选 Quota 收紧 而非 Disabled。
安全事件 ：发现账号异常时立即 Disabled。
人员变动 ：员工离职时 Disabled 而非删除，保留资源供交接。

2.2 服务目录升级：替换 / 更新 / 等候迁移（重要：不是直接修改 OfferId）

Azure Stack Hub 不支持直接修改现有 Subscription 的 OfferId------这是它与 Azure 公有云 Subscription 模型的关键差异之一。Azure 公有云可以把 Subscription 切换到不同的 EA / PAYG；Azure Stack Hub 没有这个能力，Azure Stack Hub Subscription 创建后，其服务目录归属关系不会像 Azure 公有云 Subscription 那样提供直接 Offer 切换能力。

因此，服务目录升级 通常通过以下 三种合法路径 实现：

路径 A：新 Offer + 新 Subscription（推荐）

适用场景：原 Offer 完全弃用，新业务体系完全替代。

复制代码

1. Cloud Admin 创建新 Offer（如 Offer-Dev-v2）
2. 用户 / 管理员为新业务创建新 Subscription（绑定 Offer-Dev-v2）
3. 通过 ARM Template / Azure CLI 把现有资源迁移到新 Subscription
4. 验证资源访问正常
5. 弃用原 Subscription（保留一段时间后删除）

优点：边界清晰、影响可控、可回滚。缺点：需要资源迁移，对运行中业务有停机窗口要求。

路径 B：更新原 Offer 的 Plan / Quota（不创建新 Offer）

适用场景：服务目录"小版本"升级，只调整 Quota 上限或新增 Add-on Plan。

复制代码

1. Cloud Admin 直接修改原 Offer 中的 Plan（例如调整 Quota 上限）
2. 修改 Offer 引用的 Plan 后，Subscription 通常同步更新，具体生效取决于 Plan 类型、RP 状态和版本
3. 无需新建 Subscription，业务不中断

优点：无需创建新的 Subscription，服务目录变更可以影响现有租户；业务影响通常小于重新创建 Offer。缺点：影响范围是"所有引用该 Offer 的 Subscription"，需要变更评审。

路径 C：弃用旧 Offer，等候现有 Subscription 自然迁移

适用场景：希望现有 Subscription 过渡到新体系后再删除原 Offer。

复制代码

1. Cloud Admin 将原 Offer 设为 Private，停止新订阅
2. 创建新 Offer（Offer-Dev-v2），Public 公开
3. 现有订阅者按需新建 Subscription 绑定新 Offer
4. 等候足够长的过渡期（数月）让现有用户自行迁移
5. 当所有现有 Subscription 都已迁移或释放后，删除原 Offer

关键提示 ：删除 Offer 是 破坏性操作------会让所有引用它的 Subscription 失效。建议在确认所有现有订阅都已迁移后再执行。

三种路径的选择速查

|----------------------------|-----------|----------|-------------|
| 路径 | 适用场景 | 业务影响 | 回滚难度 |
| A：新 Offer + 新 Subscription | 业务体系完全替代 | 中（有停机窗口） | 中（资源已迁移可回滚） |
| B：更新原 Offer 的 Plan | 服务目录小版本升级 | 小 | 低（直接改回） |
| C：弃用旧 Offer 等候迁移 | 大型组织渐进式过渡 | 小 | 高（需联系现有订阅者） |

2.3 用量归集与内部计费

Azure Stack Hub 没有原生 Azure 计费体系 ------管理员需要自行做 用量归集 与内部计费。Azure Stack Hub Usage API 提供资源使用计量数据，但不等同于 Azure Commerce Billing 系统。Operator 需要自行建立价格模型、成本中心映射和内部结算流程。

Azure Stack Hub 提供：

Usage API（按订阅按资源类型的用量明细）
Metering Data（RP 内部计量）
Resource Usage（资源级实际使用数据）

Azure Stack Hub 不提供：

Azure Cost Management（无原生成本管理面板）
Billing Account（无计费账户体系）
Invoice（无发票）

常见内部计费做法：

Usage API 定期拉取：通过 Azure Stack Hub Usage API 定期拉取每个 Subscription 的资源使用量。
Power BI / Grafana 报表：把 Usage 数据落到数据仓库，做按部门 / 按项目 / 按环境的成本分摊报表。
成本归集模型 ：很多企业用"资源池 + 部门系数"做内部结算------Quota 上限本身不是计费依据，实际使用量才是。

官方定位 ：Azure Stack Hub 是 Customer 拥有 + Customer 计费 的本地云服务。微软不参与计费 / 账单 / 发票，Operator 自行决定。

2.4 审计与变更追溯

|---------------------------|----------------------|---------------------------------------|
| 审计项 | 记录什么 | 怎么落地 |
| Quota 变更 | 谁在何时改了哪个 Quota、改了什么值 | Operator 门户操作日志 + 备份 Git 仓库的 Quota 模板 |
| Plan / Offer 变更 | 谁增删了 Plan / Offer | 同上 |
| Subscription 变更 | 创建 / 启用 / 禁用 / 删除 | Get-Subscription 定期快照 |
| Offer 可见性切换 | Public ↔ Private | 操作日志 |
| Delegated Provider 操作 | 经销商注册 / 取消注册 | Cloud Admin 审计视图 |

最佳实践 ：把 Quota / Plan / Offer 定义做成 Git 仓库托管 的 JSON 模板，所有变更走 PR 流程------这样审计、回滚、责任追溯都能落到代码层。

3. 多租户与 Delegated Provider 治理

上篇 §4.3 讲了 Delegated Provider 的基本定位。本篇进入 CSP Hub 场景下的实际操作与边界。

3.1 Azure Stack Hub多租户CSP场景（Delegated Provider）

复制代码

┌────────────────────────────────────────────────────────────┐
│  Cloud Admin（云管理员）                                   │
│  - 拥有 RP、容量、硬件、Region 管理权                       │
│  - 创建 / 授权 Plan                                       │
└────────────────────────────┬───────────────────────────────┘
                             │
                    授权（Tenant 维度 + Plan 维度）
                             │
        ┌────────────────────┴────────────────────┐
        ▼                                         ▼
┌─────────────────────┐                   ┌─────────────────────┐
│ Delegated Provider A│                   │ Delegated Provider B│
│  - 自管用户          │                   │  - 自管用户          │
│  - 自管 Offer        │                   │  - 自管 Offer        │
│  - 自管 Subscription │                   │  - 自管 Subscription │
└────────┬─────────────┘                  └─────────┬────────────┘
         │                                          │
         ▼                                          ▼
   Customer Tenant A                            Customer Tenant B
   (sub-customer-A1)                           (sub-customer-B1)

3.2 Delegated Provider 的边界

能做：

自管自己的用户 / 用户组。
基于 Cloud Admin 授权的 Plan 创建自己的 Offer（不能自行创建 Plan）。
创建 / 管理自己的 Subscription。
在自己的租户内做 Public / Private 切换。

不能做：

注册 / 注销新的 RP（仅 Cloud Admin 能做）。
创建 / 修改 Plan（仅 Cloud Admin 能做；DP 只能引用授权过的 Plan）。
调整 Quota 上限（仅 Cloud Admin 能做）。
管理底层硬件 / 存储 / 网络拓扑。
调整 Region / Stamp 划分。
访问其他 Delegated Provider 的租户数据。

本质：Delegated Provider 是 租户级的"二级 Operator"------能运营服务（Offer / Subscription），但不能运营基础设施，也不能创建 Plan。Plan 的创建权牢牢握在 Cloud Admin 手中。

3.3 操作示例（伪代码）

复制代码

# ============================================================
# 以下为伪代码示例
# ============================================================

# Cloud Admin 侧：创建并授权 Plan 给 DP（伪代码）
New-Plan -Name "DP-Authorized-Plan" -ResourceGroupName "dp-shared-rg" -QuotaIds @($quota.Id)
Grant-PlanAccess -PlanId $plan.Id -DelegatedProviderId "DP-A"

# Cloud Admin 侧：注册 Delegated Provider（伪代码）
New-DelegatedProvider -Name "DP-A" -SubscriptionId "<dp-a-subscription-id>"

# Delegated Provider 侧：登录后基于授权 Plan 创建 Offer
Connect-AzAccount -EnvironmentName "AzureStackAdmin" -TenantId "<dp-a-tenant-id>"
New-Offer -Name "DP-A-Offer" -ResourceGroupName "dpa-rg" -BasePlanIds @($authorizedPlan.Id)

关键提示 ：Delegated Provider 的 cmdlet 与 Cloud Admin 有所不同，且 通常不在标准 Az. 模块中*------实际执行前需查阅当版本 Operator 文档。

3.4 多租户场景的治理建议

资源池容量按 Delegated Provider 划分：Cloud Admin 给每个 DP 分配容量上限（通常通过独立 Subscription 或 Quota 模板）。
审计日志必须保留：DP 操作与 Cloud Admin 操作要分别审计，便于合规追溯。
避免 DP 之间资源共享：每个 DP 的用户 / Offer / Subscription 都应严格隔离。
Onboarding / Offboarding 流程：DP 加入 / 退出要走正式审批，避免临时授权造成治理漏洞。

再次强调 ：Delegated Provider 不是企业内部私有云的常规功能 。如果企业只是想"内部多部门隔离"，应该用 多个 Subscription + RBAC 来实现，而不是启用 Delegated Provider。

4. 最佳实践：命名 / 分级 / 对账 / 变更

4.1 命名规范

|--------------|------------------|--------------------------------------------------|
| 对象 | 命名建议 | 示例 |
| Quota | <RP 类型>-<容量级别> | Compute-Small / Storage-Large |
| Plan | Plan-<业务含义> | Plan-VMs-Base / Plan-Web-AppService |
| Offer | Offer-<业务场景> | Offer-IaaS-Plus-Web / Offer-Research-Private |
| Subscription | <业务>-<环境>-<标识> | dev-team-A / prod-project-x |

原则：

业务可读：名字要让人一眼看出是给谁用的、什么场景。
避免缩写黑话：团队新人第一天看到 Offer 名就能猜到含义。
版本后缀：当 Offer 演进到 v2 / v3 时，名字里要带版本号。

4.2 Quota 分级

重要声明 ：以下分级数字是 企业内部服务目录设计示例 ，并非微软官方默认规格。Azure Stack Hub 不存在"官方套餐规格"，Quota 数值由 Operator 结合自身 Stamp 容量、业务诉求、合规要求自行决定。

不要把所有用户塞进同一个 Quota。建议：

小：教学 / 培训 / 单人开发。
中：业务团队项目（参考默认值量级）。
大：业务部门生产。
超大：核心生产系统（需 Capacity Planning 论证）。

|--------|----------------|-----------------------------|------------------------------|
| 级别 | 典型用途 | VM 上限（参考） | vCPU 上限（参考） |
| 小 | 教学 / 培训 / 单人开发 | 20 | 40 |
| 中 | 业务团队项目（默认量级） | 50 | 100 |
| 大 | 业务部门生产 | 200 | 500 |
| 超大 | 核心生产系统 | > 500（需 Capacity Planning） | > 1000（需 Capacity Planning） |

再次强调 ：上表数字仅为 Operator 设计示例，不是 Azure Stack Hub 官方推荐规格。生产环境请以 Capacity Planner 输出的容量上限为准。

4.3 Capacity vs Quota 对账（修正公式）

这是 Operator 最重要的工作之一 ------定期对账 Quota 承诺总量 与 Stamp 实际容量。

4.3.1 关键指标

Oversubscription Ratio（超卖比）：

复制代码

Oversubscription Ratio = Allocated Quota / Physical Capacity

含义：Quota 承诺量相对于物理容量的倍数。> 1.0 即为超卖。

例如：

物理容量：200 VM
Quota 分配总量：500 VM
超卖比 = 500 / 200 = 2.5x（即承诺了 2.5 倍物理容量的资源）

Capacity Buffer（容量缓冲）：

复制代码

Capacity Buffer = (Physical Capacity - Allocated Usage) / Physical Capacity

含义：物理容量中尚未被实际使用的比例，作为突发负载缓冲。典型建议 ≥ 20%。

例如：

物理容量：200 VM
实际已用：120 VM
缓冲 = (200 - 120) / 200 = 40%

4.3.2 对账步骤

|----------------|---------------------------------------------------------------------------------|
| 步骤 | 怎么做 |
| 1. 汇总 Quota 承诺 | 把所有 Public + Private Offer 中所有 Plan 引用的 Quota 加总，得到 Allocated Quota |
| 2. 测量实际容量 | 通过 Capacity view 获取 Stamp 当前可用容量 Physical Capacity |
| 3. 测量实际用量 | 通过 Usage API 获取当前所有 Subscription 的实际用量 Allocated Usage |
| 4. 计算超卖比 | Oversubscription Ratio = Allocated Quota / Physical Capacity |
| 5. 计算容量缓冲 | Capacity Buffer = (Physical Capacity - Allocated Usage) / Physical Capacity |
| 6. 调整策略 | 超卖比过高（如 > 2.0）时降低 Quota 上限 / 限制 AddOn 数量 / 扩容硬件；缓冲不足（如 < 20%）时收紧 Quota 或暂停新订阅 |

场景示例 ：某客户给 100 个业务团队发了 50 VM / 100 vCPU 的 Quota，Quota 承诺总量 5000 VM / 10000 vCPU；Stamp 实际只有 200 VM / 800 vCPU。超卖比 = 5000/200 = 25x，远超安全水位，必须立刻调整（降低 Quota / 限制 AddOn / 扩容硬件）。

4.4 变更管理

所有 Quota / Plan / Offer 的变更都要走变更流程：

变更单：记录变更原因 / 影响范围 / 回滚方案。
审批：Cloud Admin 审批；涉及大量现有 Subscription 时需业务方会签。
执行窗口：选择业务低峰期执行。
验证：变更后抽样验证 Subscription 是否正常。
回滚预案：保留变更前的 Quota / Plan / Offer 快照，出现问题可快速回滚。

4.5 Update Bundle 节奏

Azure Stack Hub 的 OS / 驱动 / 固件更新通过 Update Bundle 推送。微软不强制具体更新策略------以下为行业经验推荐：

推荐采用 N-1 或 N-2 更新策略 ：结合 OEM 验证周期（Dell / HPE / Lenovo 环境尤其如此），对于生产环境，通常采用N-1或N-2更新策略，在OEM验证完成后部署，而不是第一时间追随最新Update Bundle。
测试 Stamp 优先：如果有多个 Stamp，先在非生产 Stamp 上验证，再推到生产。
变更窗口：与业务方约定每月 / 每季度的变更窗口，避免突发事件。

4.6 自动化工具链建议

|---------------------------|------------------------------------------|
| 场景 | 推荐工具 |
| Quota / Plan / Offer 模板管理 | Git 仓库 + JSON / YAML（ARM Template） |
| 批量 Apply | PowerShell（Az 模块） + Admin ARM API |
| 审计日志 | Operator Portal 操作日志 + 自定义 PowerShell 快照 |
| 用量归集 | Usage API → 数据仓库 → Power BI / Grafana |
| 变更管理 | ServiceNow / Jira 工单流 |

5. 下篇小结与系列收尾

5.1 Azure Stack Hub 生命周期版本说明（参考）

重要声明 ：以下版本状态基于编写时（2026-07）的公开信息整理，实际支持范围与 OEM 集成包进度有关，部署前请咨询 OEM 与微软最新文档。

|--------|----------|-------------------------------------|
| 版本 | 大致状态 | 备注 |
| 2306 | 较旧 | 已退出主流支持窗口 |
| 2311 | 维护期 | 仍可使用，建议评估升级路径 |
| 2402 | 主流 | 大量现网部署运行中 |
| 2406 | 当前主流 | 推荐生产目标版本 |
| 2501+ | 待 OEM 验证 | 需确认 Dell / HPE / Lenovo OEM 集成包是否到位 |

版本选型建议：

新部署：优先 2406 或更新的稳定版本（具体取决于当期的 OEM 集成包成熟度）。
现网：N-1 或 N-2 策略------不要追最新也不要落后太多。
OEM 集成：Dell / HPE / Lenovo 的集成包交付节奏直接影响可用版本。

5.2 下篇小结

本篇我们把上篇的概念模型转化为 可落地的 ARM 自动化、Subscription 生命周期治理、多租户治理与运维最佳实践：

ARM / PowerShell / GitOps 自动化：自动化本质是 ARM Template + PowerShell (Az 模块) + JSON 模板 + GitOps 的组合，不是单一 cmdlet；Quota / Plan / Subscription 不是普通 ARM Resource，多数通过 Admin ARM API 或 RP Provider API 管理。
Subscription 生命周期 ：启停属管理状态操作，不建议作为日常容量控制手段；服务目录升级 通过新 Offer+新 Subscription / 更新原 Offer Plan / 弃用旧 Offer 等候迁移三种合法路径实现（不支持直接修改 Subscription 的 OfferId）。
Delegated Provider 治理 ：仅 CSP Hub 场景启用；DP 能创建 Offer 但 必须基于 Cloud Admin 授权的 Plan，不能自行创建 Plan；明确"能做 / 不能做"的边界。
最佳实践：命名规范、Quota 分级（示例数字）、Capacity vs Quota 对账（修正后的 Oversubscription Ratio / Capacity Buffer 公式）、变更管理、Update Bundle N-1 / N-2 节奏、自动化工具链。

5.3 全系列收尾

上篇：概念模型 + 管理员视角 + 配额参考 + 客户场景套餐选型。
下篇（本篇）：ARM / PowerShell 自动化 + Subscription 生命周期 + Delegated Provider 治理 + 最佳实践 + 版本说明。

整个系列的核心叙事始终围绕一个观点：

Azure Stack Hub 不是一个"本地 Hyper-V 集群"，而是一套云服务运营模型。 Operator 的角色不是"管理几台服务器"，而是"运营一朵云"。

希望这个系列能帮助更多管理员从"虚拟化思维"切换到"云运营思维"，把 Azure Stack Hub 真正用出 Azure 的味道。

6. 附录

6.1 Azure Stack Hub 自动化栈速查

|-------------------------|--------------------------------------------------------|-----------------------|
| 操作类别 | 推荐方式 | 备注 |
| 连接 Operator 环境 | Add-AzEnvironment + Connect-AzAccount | 当前主流（Az 模块） |
| Quota / Plan / Offer 创建 | Admin ARM API（JSON Template） | 不是普通 ARM Resource |
| Subscription 创建 | User Portal 自助 / Operator 代创建（ARM API） | 两条路径 |
| 批量 Apply | JSON Template + GitOps + PowerShell 驱动 | 推荐 IaC 范式 |
| 用量归集 | Usage API | 无原生 Azure 计费 |
| 跨版本 cmdlet 探测 | Get-Command -Module Azs.* / Get-AzResourceProvider | 必做环境探测 |

6.2 参考文档

Azure Stack Hub Operator 文档：Azure Stack Hub Documentation - Tutorials, API Reference | Microsoft Learn
用户自助订阅：搜索 - Microsoft 必应
Capacity Planner：https://learn.microsoft.com/en-us/azure-stack/capacity-planner/
Quota 与 Quota 类型：Quotas and quota types in Azure Stack Hub - Azure Stack Hub | Microsoft Learn
Delegated Provider（多租户）：Delegating offers in Azure Stack Hub - Azure Stack Hub | Microsoft Learn
Update Bundle 概述：Manage updates - Azure Stack Hub | Microsoft Learn

作者：徐火军，Principal Engineer @ Dell Technologies，Azure Stack Hub 解决方案首席架构师。 上篇回顾：Azure Stack Hub 如何构建企业私有云服务目录：套餐、计划与订阅模型解析（上篇）