2. Azure平台工程的核心组件
Azure平台工程不是从零发明一套新体系，而是把Azure原生的治理与组织构件重新组合成“可自助、可约束、可审计”的内部平台。理解这些构件各自解决什么问题、彼此如何嵌套，是设计平台底座的第一步。本节围绕订阅、管理组、资源组、Azure Policy、RBAC、Azure Blueprints六类基础构件展开，重点说明它们在平台工程中的定位与协作关系。
一、从“容器”到“规则”：两类构件的分工
Azure的治理构件可以分成两组。第一组是组织与边界容器：管理组、订阅、资源组，它们回答“资源放在哪里、由谁付费、生命周期如何管理”。第二组是规则与授权机制：Azure Policy、RBAC、Azure Blueprints，它们回答“允许做什么、谁可以做、如何一次性交付合规环境”。容器决定治理的作用范围，规则决定在该范围内发生什么，二者必须成对设计。
管理组是纯治理层级，不承载资源，也不产生费用。它位于租户根管理组之下，可多层嵌套，典型结构是“根 → 平台 → 身份/管理/连接 → 工作负载 → 生产/非生产”。订阅是计费、配额与安全边界的基本单位，所有资源都必须归属于某个订阅。资源组是订阅内的逻辑分组，是部署、标记、删除和RBAC继承的最小操作单元。一个资源只能属于一个资源组，但可以跨资源组引用。
二、六类构件的定位与关键参数
管理组的核心价值是“一次分配、向下继承”。在管理组上分配RBAC或Policy，其下所有订阅自动继承，无需逐订阅重复配置。平台工程通常把“平台管理组”留给网络、日志、安全等共享服务，把“工作负载管理组”按业务域划分，再按环境细分。
订阅是隔离与配额的单位。常见做法是按“环境+业务域”拆分，例如 sub-pay-prod、sub-pay-dev。订阅级别适合放置跨资源组的策略，如允许的区域列表、强制标签、诊断设置。
资源组是生命周期单位。同一应用、同一环境、同一发布节奏的资源放在同一资源组，便于整体删除与权限收敛。资源组应避免跨团队共享，否则删除和授权都会互相牵连。
Azure Policy是“声明式约束”。它由策略定义（规则）和策略分配（作用范围+参数）组成，效果包括 Deny、Audit、Append、Modify、DeployIfNotExists。例如强制所有资源带 costCenter 标签，可用 Deny 阻止缺失标签的部署；要求存储账户启用HTTPS，可用 Deny 或 Audit。策略分配可带排除项，用于豁免特定资源组。
RBAC是“谁在什么范围对什么对象做什么”。它由安全主体、角色定义、作用范围三要素构成。平台工程常用内置角色如 Owner、Contributor、Reader，也会自定义角色以最小化权限。关键原则是：在管理组或订阅级别授予平台团队权限，在资源组级别授予应用团队权限，避免在单个资源上做零散授权。
Azure Blueprints是“可重复交付的合规环境包”。一个Blueprint可同时包含角色分配、策略分配、ARM模板、资源组，并支持版本管理与分配锁定。它解决的是“新订阅/新环境如何一次性达到基线”的问题。需要说明的是，Blueprints已进入逐步退役阶段，新项目更推荐用模板规格（Template Specs）+ 部署栈（Deployment Stacks）+ 策略组合替代，但理解Blueprints的“打包交付”思想对平台设计仍然重要。
三、构件如何协同：一次新环境交付的视角
假设平台要为支付团队开通一套生产环境。合理顺序是：先在管理组层级确认继承的策略与RBAC；再创建或申请订阅，并放入对应管理组；然后用Blueprint或部署栈一次性创建资源组、分配策略、绑定角色、部署基础网络与日志；最后应用团队在资源组内自助部署应用资源。整个过程里，管理组提供继承基线，订阅提供隔离与计费，资源组提供生命周期，Policy提供约束，RBAC提供授权，Blueprints提供打包交付。
四、平台工程中的设计要点
第一，继承优先于重复。能在管理组或订阅级别配置的策略与角色，不要下沉到每个资源组重复配置，否则维护成本会随订阅数量线性增长。第二，策略先用Audit再转Deny。新策略直接Deny容易阻断现有工作负载，建议先以Audit观察合规率，确认影响面后再切换为Deny。第三，RBAC最小化且分层。平台团队持有订阅级Contributor或自定义平台角色，应用团队只在资源组级持有Contributor，Reader可适当放宽到订阅级便于排障。第四，标签与命名是策略的抓手。强制 costCenter、environment、owner 三类标签，配合命名规范，才能让成本分摊和自动化巡检真正落地。第五，Blueprints思想可迁移。即使不使用Blueprints，也应把“策略+角色+模板+资源组”打包成可版本化的部署单元，用Template Specs和Deployment Stacks实现同等效果。
五、常见误区与排障线索
误区一：把资源组当权限边界。资源组可以承载RBAC，但跨资源组引用资源时权限不会自动传递，需在目标资源组单独授权。误区二：在管理组上分配过多Owner。管理组级Owner会继承到所有订阅，风险极高，应使用自定义角色限制可操作范围。误区三：策略分配范围过窄。只在单个资源组分配策略，新增资源组就会漏管，应尽量在订阅或管理组级别分配。排障时可按“管理组→订阅→资源组→资源”的顺序逐层检查继承的策略与角色分配，确认是继承冲突还是本地覆盖。