4. Azure Landing Zones与平台基础

Azure Landing Zones（简称 ALZ）不是一组“开箱即用的资源模板”，而是一套面向企业级云采用的可扩展架构基线。它解决的核心问题是：当组织从几个订阅、少量资源，发展到几十上百个订阅、多个团队并行交付时，如何让身份、网络、安全、治理、日志和成本管理保持一致，同时又不拖慢开发者的自助交付速度。平台工程团队的任务，就是把 ALZ 从设计原则落地为可重复部署、可版本化演进、可被自助服务消费的基础环境。

ALZ 的架构分层与设计原则

ALZ 的参考架构通常按“管理组层级 + 订阅分类 + 平台资源”三个维度组织。管理组层级决定策略和权限的继承边界，常见结构是：根管理组下划分“平台”“登陆区（Landing Zones）”“沙盒”“退役”等二级管理组；平台管理组下再细分“身份”“管理”“连接”“安全”等订阅；登陆区管理组下按业务域或环境划分“在线（Corp）”“离线（Online）”等子管理组。订阅是治理、计费与配额的基本单元，平台订阅承载共享服务，应用登陆区订阅承载业务工作负载。

设计原则可以归纳为四条：第一，订阅作为扩展单元，通过订阅隔离配额、权限和成本，而不是把所有资源塞进少数订阅；第二，策略驱动治理，用 Azure Policy 在管理组层级强制约束，而不是靠人工评审；第三，平台与工作负载分离，身份、网络、日志、安全等共享能力由平台团队集中提供，业务团队只消费接口；第四，自动化优先，所有平台资源用 IaC（Bicep/Terraform）声明式部署，避免手工漂移。

从设计到部署：平台基础环境的落地路径

把 ALZ 落地，通常分四步。第一步是确定管理组与订阅边界：根据组织架构、合规要求和成本归属，画出管理组树，并明确哪些订阅属于平台、哪些属于登陆区。第二步是部署平台基础资源：在连接订阅中创建 Hub 虚拟网络、Azure Firewall、VPN/ExpressRoute 网关和私有 DNS 区域；在管理订阅中创建 Log Analytics 工作区、存储账户和恢复服务保管库；在身份订阅中配置域控或 Entra 混合身份。第三步是分配策略与权限：在管理组层级分配策略集（如“禁止公网 IP”“强制标签”“允许的区域”），并用 RBAC 把平台团队设为 Owner、业务团队设为 Contributor 或自定义角色。第四步是提供自助服务接口：把登陆区订阅的创建封装成模板或内部开发者平台（IDP）的申请表单，开发者提交后自动完成订阅创建、策略继承、网络对等和预算告警配置。

下面是一个用 Bicep 声明式创建管理组和订阅别名的示例，展示平台团队如何把“订阅申请”变成可重复的代码。示例参数为教学假设值，实际使用时需替换为组织真实值。

// 创建业务域管理组，并挂到登陆区管理组下
targetScope = 'tenant'

param landingZoneMgId string = 'mg-landingzones'
param businessDomain string = 'finance'

resource domainMg 'Microsoft.Management/managementGroups@2023-04-01' = {
  name: 'mg-${businessDomain}'
  properties: {
    displayName: '业务域-${businessDomain}'
    details: {
      parent: {
        id: '/providers/Microsoft.Management/managementGroups/${landingZoneMgId}'
      }
    }
  }
}

// 在业务域管理组下创建订阅别名，由平台自动分配订阅
resource subAlias 'Microsoft.Subscription/aliases@2021-10-01' = {
  name: 'sub-${businessDomain}-prod'
  properties: {
    displayName: '${businessDomain}-生产订阅'
    billingScope: '/providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/7654321'
    workload: 'Production'
    managementGroupId: domainMg.id
  }
}

部署后，平台团队可以通过 Azure CLI 验证管理组层级和策略继承是否生效：

az account management-group show --name mg-finance --expand --recurse
az policy assignment list --scope /providers/Microsoft.Management/managementGroups/mg-finance -o table

判断部署是否成功，可以观察三个信号：一是新订阅出现在正确的管理组下，且继承的策略分配数量与预期一致；二是 Hub 与 Spoke 之间的对等连接状态为 Connected，DNS 解析能返回私有区域记录；三是 Log Analytics 工作区开始收到来自新订阅的诊断日志。如果策略未继承，优先检查管理组层级是否挂错、策略分配的作用域是否覆盖目标订阅；如果网络不通，检查对等连接是否双向建立、防火墙规则是否放行、路由表是否指向 Hub。

为自助服务预留的扩展点

ALZ 要支撑开发者自助服务，必须在设计时预留扩展点。第一，策略即产品：把安全与合规要求写成策略集，按管理组分配，开发者无需理解每条策略细节，只要在允许范围内部署即可。第二，网络即服务：Hub 提供统一的出口、入口和 DNS，Spoke 通过标准化的对等模板接入，开发者不需要自己规划 IP 和防火墙。第三，订阅即接口：订阅创建、配额申请、预算设置都通过 API 或 IDP 暴露，而不是邮件和工单。第四，可观测性默认开启：诊断设置、日志转发和告警规则在订阅创建时自动配置，开发者无需额外操作就能获得监控能力。

需要强调的是，ALZ 不是一次性项目，而是持续演进的产品。平台团队应把管理组结构、策略定义、网络拓扑和订阅模板都纳入版本控制，每次变更通过 CI/CD 流水线部署到测试租户验证后再推广到生产。这样，当业务需求变化或合规要求更新时，平台可以快速调整基线，而不会影响已经运行的工作负载。对于刚开始建设的团队，建议先从最小可用基线开始：一个根管理组、平台与登陆区两个二级管理组、一个 Hub 网络、一组核心策略，然后随着业务增长逐步细化，避免一开始就设计过度复杂的层级而拖慢交付。