📚 课程目录第2章 Azure企业架构与治理基础

2. Azure企业架构与治理基础

当企业把业务系统从本地数据中心迁移到 Azure 时，最先遇到的往往不是虚拟机怎么建、数据库怎么迁，而是“谁来管、按什么规则管、钱花在哪里”。Azure 提供了一整套从顶层到底层的治理骨架：管理组（Management Group）负责组织层级，订阅（Subscription）是计费与配额边界，资源组（Resource Group）是生命周期与部署边界，Azure Policy负责约束“什么能做”，RBAC负责约束“谁能做”，成本管理负责回答“花了多少、花在哪”。理解这六者的分工与嵌套关系，是设计 Landing Zone 的前提。

一、四层资源层级：从租户到资源

Azure 的资源组织是一条严格的包含链：租户（Entra ID Tenant）→ 管理组 → 订阅 → 资源组 → 资源。上层是下层的容器，下层继承上层的策略与权限。这条链决定了治理的两个关键特性：继承性和作用域（Scope）。在管理组上分配一条“只允许在 East Asia 和 Japan East 创建资源”的策略，其下所有订阅、资源组、资源都会自动生效，无需逐个配置。

管理组最多支持六层嵌套，但实践中通常只用三到四层。一个典型的企业结构是：根管理组下分“平台（Platform）”“业务（Landing Zones）”“沙箱（Sandbox）”“退役（Decommissioned）”四个一级管理组；平台下再分“身份”“管理”“连接”三个订阅；业务下按事业部或环境再分管理组，最终挂载具体订阅。这种结构让“生产环境策略”和“开发环境策略”可以分别绑定在不同分支上，互不干扰。

二、订阅：不只是计费单位

订阅常被误解为“一个账单账户”，实际上它同时承担四个角色：计费边界（每张发票对应一个订阅）、配额边界（如每订阅默认 250 个存储账户、每区域 vCPU 配额）、安全边界（订阅级 RBAC 可隔离团队）、策略作用域（订阅级策略可覆盖其下所有资源组）。因此订阅划分策略直接影响治理复杂度。

企业常见的订阅划分模式有三种：按环境划分（生产/测试/开发各一个订阅）、按业务线划分（每个事业部一个订阅）、按功能划分（网络、身份、日志等平台订阅独立）。推荐做法是平台订阅与业务订阅分离：网络中心（Hub）、身份、日志分析等共享服务放在平台管理组下的独立订阅中，业务系统放在业务管理组下的订阅中。这样网络策略变更不会误伤业务，成本也能按“平台成本”和“业务成本”分开归集。

三、资源组：生命周期与部署的边界

资源组是“一起部署、一起删除、一起管理”的资源集合。它的核心价值在于生命周期一致性：删除资源组会级联删除其中所有资源，因此同一应用、同一环境的资源应放在同一资源组。例如 rg-web-prod 放生产 Web 应用及其 App Service Plan、Application Insights；rg-data-prod 放 SQL Database、存储账户。不要把“所有生产资源”塞进一个资源组，否则一次误删会波及全部业务。

资源组还有两个实用约束：资源只能属于一个资源组，但可以跨资源组通信（通过 VNet 对等互连或私有终结点）；资源组本身有位置属性（存储元数据），但其中的资源可以部署在不同区域。设计时建议按“应用 + 环境”命名，如 rg-{app}-{env}-{region}，便于自动化脚本识别。

四、Azure Policy：把合规要求变成代码

Azure Policy 是治理的执行引擎。它由三部分组成：策略定义（Policy Definition）描述“检查什么条件、产生什么效果”；计划（Initiative）把多条策略打包；分配（Assignment）把策略或计划绑定到某个作用域，并可通过参数定制。

策略效果（Effect）决定了“不满足时怎么办”，常见的有：Deny（拒绝创建不合规资源）、Audit（仅记录合规性，不阻断）、Append（自动补充字段，如强制添加标签）、DeployIfNotExists（缺失时自动部署，如自动启用诊断日志）、Modify（修改资源属性）。迁移初期建议先用 Audit 观察现状，确认影响面后再切换为 Deny，避免一次性阻断业务部署。

一个典型的企业策略计划可包含：允许的区域列表、强制标签（CostCenter、Owner、Environment）、禁止公共 IP、要求存储账户启用 HTTPS、要求虚拟机使用托管磁盘、要求 SQL 启用审计。下面是一个强制标签的策略定义示例：

{
  "if": {
    "allOf": [
      { "field": "type", "notEquals": "Microsoft.Resources/subscriptions" },
      { "field": "tags['CostCenter']", "exists": "false" }
    ]
  },
  "then": { "effect": "deny" }
}

分配后，在“策略 → 合规性”中可以看到每个资源的合规状态。若某资源显示“不合规”，可查看具体原因并修正；对于已存在的不合规资源，可用修正任务（Remediation Task）批量修复。

五、RBAC：最小权限的落地方式

RBAC 由安全主体（谁）、角色定义（能做什么）、作用域（在哪做）三要素构成。Azure 内置角色中，迁移项目最常用的有：Owner（完全控制，含授权）、Contributor（可管理资源但不能授权）、Reader（只读）、User Access Administrator（仅管理权限）、Network Contributor（管理网络资源）。

实践原则是：在管理组或订阅级授予平台团队权限，在资源组级授予业务团队权限。例如网络团队在“连接订阅”获得 Network Contributor，应用团队只在 rg-web-prod 获得 Contributor。避免在订阅级给业务团队 Owner，否则他们可以自行提权。对于需要临时权限的场景，使用 PIM（Privileged Identity Management） 做即时激活，而不是长期常驻高权限。

六、成本管理：从可见到可控

成本管理的第一步是标签体系。建议至少定义四个强制标签：CostCenter（成本中心）、Owner（负责人）、Environment（生产/测试/开发）、Application（应用名）。配合 Azure Policy 的 Append 或 Deny 效果，确保新资源必须带标签。第二步是预算与警报：在订阅或资源组上设置月度预算，当实际支出达到 50%、80%、100% 时触发邮件或 Action Group 通知。第三步是成本分析：按标签、资源组、服务维度查看趋势，识别异常增长。

一个可参考的预算配置示例：某生产订阅月度预算 8000 元，警报阈值设为 4000 元（50%）、6400 元（80%）、8000 元（100%），通知发送给应用负责人和财务接口人。若连续两月超 80%，则触发资源优化评审，检查是否有闲置 VM、未挂载磁盘或过高规格的 App Service Plan。

Landing Zone 设计顺序建议：先定管理组层级与订阅划分，再定资源组命名与标签规范，然后绑定策略计划，最后配置 RBAC 与预算。顺序颠倒会导致策略反复调整、权限重复授予。

七、把六者串起来：一个最小治理闭环

假设企业要上线一个“订单系统”到生产环境。治理动作可以这样落地：在“业务管理组 → 生产管理组”下创建订阅 sub-order-prod；在订阅上分配策略计划（强制标签、限制区域、禁止公共 IP）；在订阅级给平台团队 Reader，在资源组 rg-order-prod 给应用团队 Contributor；创建资源时自动继承标签 CostCenter=EC-01、Environment=Prod；设置月度预算 3000 元并配置 80% 警报。这样，一个资源从创建到计费，全程都在治理框架内，既满足合规，又保留业务团队的自主权。

Landing Zone 不是一次性项目，而是持续运营的基线。随着业务增长，管理组可以继续细分，策略可以逐步收紧，RBAC 可以按需调整，成本视图可以按标签重新聚合。掌握这六个基础对象的职责与关系，就掌握了 Azure 企业治理的“骨架”，后续的网络、安全、灾备设计都将在此基础上展开。