📚 课程目录第2章组织与资源层级设计

2. 组织与资源层级设计

在 Google Cloud 中，资源并不是平铺在账号里的，而是被组织成一棵严格的层级树。理解这棵树，是后续所有网络、安全、计费与自动化设计的地基。层级从高到低依次是：Organization（组织）→ Folder（文件夹）→ Project（项目）→ 具体资源，而 Label（标签） 不属于这棵树，它是横向贴在资源上的键值对，用于筛选、计费和成本归集。把“层级”和“标签”混为一谈，是初学者最常见的规划错误。

一、四层结构各自解决什么问题

Organization 节点绑定一个 Workspace 或 Cloud Identity 域，是整棵树的根。它决定了：谁能成为组织管理员、组织策略（Organization Policy）在哪里下发、以及所有项目的账单如何汇总。一个企业通常只有一个 Organization，除非存在并购导致的多个域。

Folder 是组织内的“管理分组”，可以嵌套多层（官方建议不超过 10 层，实际 3～4 层足够）。Folder 的核心价值是把 IAM 和策略一次性授予一组项目。例如按“环境”分：Production / Staging / Sandbox；或按“业务线”分：Retail / Logistics / Finance。两种切法不要混用在同一层，否则继承关系会变得难以推理。

Project 是资源、API、配额、计费和 IAM 的基本边界。虚拟机、Cloud Storage 桶、BigQuery 数据集、VPC 网络都归属于某个项目。项目是“隔离单元”，不是“团队单元”——一个团队可以拥有多个项目，一个项目也可以被多个团队共享。

Label 是键值对，例如 env: prod、cost-center: cc-1024、owner: team-payments。它不参与 IAM 继承，但可以用于账单导出后的成本分摊、资源筛选和自动化脚本的匹配条件。Label 的键和值都应来自受控词表，否则半年后会出现 env、Env、environment 三种写法并存。

二、IAM 继承模型：向下继承、向上不可见

IAM 策略的继承规则只有一句话：在某个节点授予的角色，会被该节点下所有后代资源继承；子节点无法“收回”父节点授予的权限，只能额外增加。这意味着在 Organization 上给某人 roles/editor，他就在所有项目里都是 Editor，任何 Folder 或 Project 级别的策略都无法剥夺这一点。因此生产环境的铁律是：高层的授权要极窄，宽泛的角色尽量下沉到具体项目。

有效权限是“沿路径所有策略的并集”。判断某人能否对某资源执行操作，需要从资源向上走到 Organization，收集每一层的 allow 策略，取并集，再减去拒绝策略（Deny Policy，目前主要在 Organization Policy 中表达）。下图展示了这一继承与并集关系：

三、资源配额与命名规范

配额（Quota）分为两类：项目级配额（如每项目 VPC 数量、每项目 CPU 核数）和区域级配额（如某区域可用的外部 IP 数）。配额是项目维度的硬上限，Folder 和 Organization 不直接持有配额，但可以通过配额偏好（Quota Preferences）在项目创建时批量下发。规划时要提前估算：一个生产项目若需要 200 个 vCPU，而默认配额只有 24，就必须在项目创建后立即提交配额调整，否则扩容时会卡住。

命名规范建议采用“可解析”的格式，让脚本能直接从名字推断归属。推荐模式：

项目 ID：  {env}-{bu}-{app}-{seq}
示例：     prod-retail-payments-01
           stg-retail-payments-01
           sbx-dev-sandbox-07

Folder 名：{env} 或 {bu}，同一层只用一种维度
Label 键： env / cost-center / owner / data-class
Label 值： prod | staging | sandbox
           cc-1024
           team-payments
           pii | internal | public

项目 ID 一旦创建不可更改，且全局唯一，因此要避免使用会过期的信息（如年份、临时负责人姓名）。显示名（Display Name）可以改，但脚本应以项目 ID 为准。

四、多项目架构实战：一个可落地的三层切分

假设一家零售企业有支付、物流、门店三条业务线，需要生产、预发、沙箱三套环境。推荐结构如下：

Organization：只放 Organization Admin、Security Reviewer、Billing Admin 三个极窄角色。
第一层 Folder：按环境切分为 Production / Staging / Sandbox，便于统一施加“生产禁止外部 IP”“生产必须开启审计日志”等 Organization Policy。
第二层 Folder：在 Production 下按业务线切分为 Payments / Logistics / Stores。
Project：每个业务线在每个环境下至少一个项目，如 prod-payments-01、stg-payments-01。共享服务（如集中日志、Artifact Registry）单独建 prod-shared-logging 项目。
Label：所有项目统一打 env、cost-center、owner、data-class 四个标签，账单导出到 BigQuery 后即可按成本中心聚合。

判断层级是否合理的快速检验：如果某个 IAM 角色需要授予“一组项目”，就应该有一个 Folder 能覆盖它们；如果某个标签需要用于成本分摊，它就必须出现在所有相关项目上，而不是只出现在部分项目上。

常见反模式：把 Folder 当成“团队通讯录”，按人名建 Folder；或者在 Organization 层给整个工程团队授予 Editor。前者导致人员变动时层级频繁重构，后者让最小权限原则彻底失效。正确做法是按“环境 + 业务线”这种稳定维度建 Folder，人员权限通过 Google Group 授予，人员进出只改组成员，不动层级。

最后，配额与命名要一起纳入项目创建流水线：用 Terraform 或 Config Connector 定义项目模板，自动附加标签、绑定账单账号、申请基础配额、创建服务账号。这样每新增一个项目，都天然符合上述层级与规范，而不是靠人工记忆去补。