2. 组织资源层级与治理边界
在 Google Cloud 中，资源不是平铺在账号里的，而是被组织成一棵严格的树。理解这棵树，是设计权限模型、落地治理边界的前提。很多团队在早期把项目当成“大号文件夹”使用，结果在权限继承、账单归集、策略下发时反复踩坑。本节从层级结构出发，讲清每一层的职责、继承规则，并给出可落地的资源树设计方法。
四层资源模型：谁包含谁
Google Cloud 的资源层级自顶向下依次为：Organization（组织）→ Folder（文件夹）→ Project（项目）→ Resource（资源）。每一层都是上一层的子节点，形成一棵有根树。
- Organization：对应一个企业或机构的顶级节点，通常绑定一个 Cloud Identity 或 Workspace 域名。它是整个资源树的根，也是组织策略（Organization Policy）和集中审计的落点。一个域名一般只对应一个组织节点。
- Folder：组织下的分组容器，可多层嵌套。它本身不承载计算资源，只用于表达管理意图，例如按“业务线 / 环境 / 地域”分组。Folder 是治理边界最灵活的一层。
- Project：资源的基本归属单元。所有 Compute、Storage、BigQuery 等资源都必须创建在某个项目内。项目是启用 API、结算、配额、IAM 绑定的实际载体。
- Resource：项目内的具体对象，如一台 VM 实例、一个 GCS 存储桶、一张 BigQuery 表。资源继承其所属项目的所有策略与权限。
关键点在于：权限和策略沿树向下继承。在 Organization 上授予某用户 roles/viewer，该用户对整棵树内所有资源都具备查看权限；在某个 Folder 上授予，则只影响该 Folder 及其所有后代。这意味着“把权限放在哪一层”直接决定了治理的粗细粒度。
为什么不能把项目当文件夹用
项目是资源容器，但它同时绑定了结算账号、API 启用状态、配额和 IAM 策略。如果按“每个小功能一个项目”随意创建，会带来三个问题：一是配额分散，难以统一申请和监控；二是账单碎片化，成本归集困难；三是权限需要在每个项目重复绑定，容易遗漏或过度授权。Folder 的存在正是为了解决“分组管理”与“资源承载”职责分离的问题。
一个常见的反例是：把生产、测试、开发三套环境直接建成三个平级项目，挂在 Organization 下。这样做的后果是，任何针对“生产”的集中策略（如禁止外部 IP、强制 CMEK 加密）都无法只作用于生产项目，只能逐个绑定，且新增项目时容易漏配。正确做法是先建 prod、staging、dev 三个 Folder，再把各环境的项目放入对应 Folder，策略在 Folder 层统一下发。
设计企业资源树的三个维度
资源树的结构没有唯一正确答案，但通常围绕以下维度展开，且同一棵树内应保持维度一致，避免混用导致语义混乱。
| 维度 | 适用场景 | 示例结构 |
|---|---|---|
| 按业务线 | 多产品线、独立核算 | Folder: 电商 / 金融 / 广告 |
| 按环境 | 需要严格隔离生产与测试 | Folder: prod / staging / dev |
| 按地域或合规 | 数据驻留、监管要求 | Folder: cn-north / eu-west |
实践中常采用两级组合：第一级按业务线，第二级按环境。例如 业务线A/prod、业务线A/dev。这样既满足业务隔离，又能在业务线内统一环境策略。需要注意的是，Folder 嵌套层数不宜过深，一般控制在 3～4 层以内，否则权限排查和策略继承会变得难以追踪。
落地示例：从零搭建一棵资源树
假设某公司域名 corp.example.com，有两条业务线“支付”和“风控”，每条业务线都需要生产与测试环境。可以按以下顺序搭建（示例参数，非实测结果）：
# 1. 确认组织节点（由域名自动创建）
gcloud organizations list
# 输出示例：ID=123456789012, DISPLAY_NAME=corp.example.com
# 2. 创建一级 Folder：业务线
gcloud resource-manager folders create \
--display-name="支付" --organization=123456789012
gcloud resource-manager folders create \
--display-name="风控" --organization=123456789012
# 3. 在“支付”下创建二级 Folder：环境
gcloud resource-manager folders create \
--display-name="prod" --folder=支付FolderID
gcloud resource-manager folders create \
--display-name="dev" --folder=支付FolderID
# 4. 在环境 Folder 下创建项目
gcloud projects create pay-prod-001 \
--folder=prodFolderID --name="支付生产"
gcloud projects create pay-dev-001 \
--folder=devFolderID --name="支付测试"
# 5. 在 Folder 层绑定权限（示例：给运维组只读）
gcloud resource-manager folders add-iam-policy-binding prodFolderID \
--member="group:ops@corp.example.com" \
--role="roles/viewer"
执行完成后，可以用 gcloud resource-manager folders list --organization=123456789012 查看顶层 Folder，用 gcloud projects list 确认项目归属。判断资源树是否合理，可以问三个问题：新增一个项目时，是否只需放入已有 Folder 即可自动获得正确策略？某个业务线下线时，是否能通过删除一个 Folder 完成整体回收？审计某个环境的全部资源时，是否能通过一个 Folder 路径枚举？如果答案都是“是”，说明结构基本可用。
pay-prod-001，便于在日志和账单中快速定位归属。
resourcemanager.folders.delete 权限，防止误删整棵子树。
掌握这四层关系后，后续的 IAM 绑定、组织策略、结算归集、日志聚合都会围绕这棵树展开。资源树设计得好，治理成本会随规模增长而保持可控；设计得差，权限和账单问题会在项目数量上升后集中爆发。