3. 企业组织与资源层级设计
在 Google Cloud 中，资源并不是平铺在账号里的，而是被组织成一条自上而下的层级链：Organization → Folder → Project → 资源，而 Billing Account 则是一条横向挂接的“付费通道”。理解这条链的语义，是后续 IAM、网络、日志、配额与成本治理能否顺利落地的前提。很多项目后期出现的权限爆炸、账单无法分摊、网络无法共享，根源往往不是技术选型错误，而是最初层级与命名没有设计好。
一、四个对象的职责边界
Organization（组织）是层级的根节点，通常对应一个企业实体，由 Google Workspace 或 Cloud Identity 的域名自动创建。它是所有资源策略的最终继承源，也是组织策略（Organization Policy）、集中日志、VPC Service Controls 的挂载点。一个企业原则上只应有一个 Organization；若因并购出现多个，应通过迁移而非长期并存来收敛。
Folder（文件夹）是 Organization 下的分组容器，用于表达“业务单元、环境、地域、合规域”等中间层。Folder 可以嵌套，是承载差异化策略的关键层：把“生产环境禁止删除审计日志”这类约束放在生产 Folder 上，比在每个 Project 上重复配置更可靠。建议 Folder 层级控制在 3～4 层以内，过深会让策略继承难以推理。
Project（项目）是资源与计费的基本单元，也是 API 启用、配额、服务账号、网络资源的实际归属点。Project 是“隔离边界”而非“团队边界”：一个团队可以拥有多个 Project，一个 Project 也可以被多个团队按角色访问。判断是否需要新建 Project 的实用标准是——是否需要独立的计费归属、独立的 IAM 边界、独立的配额或独立的生命周期。
Billing Account（结算账号）是付款主体，与层级树是“多对多挂接”关系：一个 Billing Account 可以支付多个 Project，一个 Project 只能绑定一个 Billing Account。它不参与 IAM 资源继承，但决定费用归属、预算告警和发票拆分。企业常见做法是按法人实体或成本中心建立少量 Billing Account，再通过 Project 的标签与 Folder 结构实现成本分摊。
二、规划原则：先定边界，再定命名
层级设计的第一原则是“按治理需求分层，而不是按组织架构图照搬”。组织架构会频繁调整，而资源层级一旦建立，迁移 Project 的成本很高。因此 Folder 应表达相对稳定的维度，例如环境（prod / nonprod）、合规域（pci / non-pci）、地域（cn / global），而不是“张三的部门”“李四的组”。
第二原则是“策略放在能覆盖最多对象的最浅层”。例如“禁止创建外部 IP”应放在 prod Folder，而不是逐个 Project 配置；只有确实需要例外的 Project 才在自身层级做覆盖。这样策略数量少、可审计、变更影响面清晰。
第三原则是“Project 数量可控、职责单一”。常见反模式是把所有业务塞进一个 Project，导致 IAM 角色无法收敛、配额互相挤占、故障爆炸半径过大。建议按“一个应用或一组强耦合服务 + 一个环境”划分 Project，并为其指定明确的负责人（Owner）与生命周期。
第四原则是“Billing Account 少而稳，成本分摊靠标签”。Billing Account 变更涉及付款与合同，不宜频繁新建。成本归属应通过 Project 的 labels（如 cost-center、env、owner）以及 Folder 结构在账单导出（BigQuery Billing Export）中聚合分析。
三、命名规范：可读、可排序、可自动化
命名规范的价值在于让资源 ID 本身携带语义，从而支持脚本批量操作、日志检索和成本报表分组。推荐采用小写字母、数字与连字符，用连字符分隔语义段，避免下划线和中文。Project ID 全局唯一且创建后不可更改，因此命名要一次到位。
建议的命名模式为：{类型}-{环境}-{业务}-{序号}。例如：
Folder: fld-prod-payment
Folder: fld-nonprod-payment
Project: prj-prod-payment-api
Project: prj-prod-payment-worker
Project: prj-dev-payment-api
Billing: billing-corp-cn
其中 fld-、prj-、billing- 前缀让资源类型在列表和日志中一眼可辨；prod/dev/stg 表达环境；payment 表达业务域；api/worker 表达组件角色。对于多地域部署，可在业务段后追加地域，如 prj-prod-payment-api-cn。
四、一个可落地的规划示例
假设某企业有支付与商城两条业务线，需要生产、预发、开发三套环境，并有一个共享网络与日志项目。可以规划如下：
| 层级 | 资源 ID | 用途 | 关键策略 |
|---|---|---|---|
| Organization | example.com | 策略根节点 | 启用组织策略、集中日志 |
| Folder | fld-prod | 生产环境 | 禁止外部 IP、禁止删除审计日志 |
| Folder | fld-nonprod | 非生产环境 | 允许较宽松的调试权限 |
| Folder | fld-shared | 共享服务 | 仅平台团队可管理 |
| Project | prj-prod-payment-api | 支付生产 API | 绑定 billing-corp-cn |
| Project | prj-prod-mall-web | 商城生产前端 | 绑定 billing-corp-cn |
| Project | prj-shared-net | 共享 VPC 宿主 | 跨项目网络共享 |
| Billing | billing-corp-cn | 中国区付款主体 | 预算告警 80% / 100% |
落地时，先用 gcloud organizations 与 gcloud resource-manager folders create 建立 Folder，再创建 Project 并指定 --folder 与 --billing-account。例如：
gcloud projects create prj-prod-payment-api \
--folder=fld-prod \
--name="支付生产 API"
gcloud beta billing projects link prj-prod-payment-api \
--billing-account=billing-corp-cn
创建后应验证三件事：一是 Project 的父节点是否正确（gcloud projects describe 查看 parent）；二是账单是否已挂接（Billing 控制台或 billing projects list）；三是继承的策略是否符合预期（在 IAM 与组织策略页面查看有效策略）。若发现 Project 建在了错误 Folder 下，应尽早迁移，而不是靠额外 IAM 绑定“打补丁”。
总结来看，Organization 定根、Folder 定域、Project 定界、Billing Account 定账。四者各司其职，命名规范让这套结构在脚本、日志和账单中保持一致可读。把这一层设计做扎实，后续的网络共享、集中日志、成本分摊与合规审计都会顺理成章。