“我们团队来写不就行了吗？”
— 这一句话会耗费组织三个月的时间。
>
🎯 本文涵盖内容
- Terraform 代码所有权争议产生的真正原因
- 基础设施团队负责的优点与局限性
- 开发团队（包括 DevOps）负责的优点与局限性
- 实际场景中通用的3种模型
- 按组织规模划分的最佳结构建议
📌 引入 / 背景
随着云采用的加速，Terraform 在某个时刻从“基础设施团队的专属物”变成了“每个人都需要触及的共享资源”。
问题就从这里开始。
“我提交了一个创建 ECS 集群的工单，结果花了2周时间。”
“开发团队直接编写的 Terraform 代码删除了生产 VPC。”
这两个故事都是真实发生的。前者是基础设施团队成为瓶颈的情况，后者是由于没有所有权，任何人都可以随意操作而导致的惨剧。
Terraform 代码的所有权问题不仅仅是“谁来编写代码”的问题。这是一个涉及组织结构、责任归属、变更速度三者交织的复杂问题。
🔍 首先，区分 Terraform 处理的领域
Terraform 代码大致可以分为两个层面。
层面1 — 平台基础设施 (Foundation Layer)
- VPC、子网、路由、TGW
- IAM 策略、安全组基本模板
- EKS/ECS 集群本身
- S3 存储桶策略、KMS 密钥
- DNS (Route 53 托管区域)
这个领域变更频率低，一旦误操作可能导致全公司范围的故障。需要谨慎对待。
层面2 — 应用基础设施 (App Layer)
- ECS 服务、任务定义
- Lambda 函数、API Gateway
- RDS 实例（应用专用）
- CloudFront 分发设置
- 环境变量、服务专用 S3 存储桶
这个领域变更频率高，与部署周期直接相关。速度至关重要。
当同一个团队试图以相同的方式管理这两个层面时，就会发生冲突。
⚙️ 模型1 — 基础设施团队集中所有 (Centralized)
基础设施团队（或 SRE 团队）拥有并管理所有 Terraform 代码的方式。
优点
- 易于标准化：命名约定、标签策略、模块结构保持一致
- 安全控制：谁创建什么都必须经过审查
- 专业性集中：Terraform Provider 版本管理、state 文件管理等经验得以积累
缺点
- 产生瓶颈：开发团队的请求堆积如山，工单队列爆炸
- 缺乏上下文：基础设施团队在不完全理解应用需求的情况下编写代码
- 部署速度降低：与敏捷的 CI/CD 流水线冲突
适用组织
- 金融、公共、医疗等安全和合规要求严格的机构
- 基础设施变更不频繁的本地部署 + 云混合环境
- 云迁移初期阶段（尚未建立标准化）
⚙️ 模型2 — 开发团队自主所有 (Decentralized / “You Build It, You Run It”)
每个开发团队（服务团队）直接使用 Terraform 定义其服务所需的基础设施。Netflix、Spotify 等大型科技公司采用了这种模式。
优点
- 部署速度：提交 PR 即可立即生效，无需等待基础设施团队
- 上下文一致：最了解应用的团队也决定基础设施
- 责任明确化：“我编写的基础设施我负责”
缺点
- 碎片化风险：各团队以不同方式创建资源，导致一致性被破坏
- 安全事故风险：缺乏 Terraform 知识的开发人员可能创建公共 S3 存储桶
- state 文件冲突：多个团队操作重叠资源时，状态文件可能混乱
适用组织
- DevOps 成熟度高的初创公司或科技公司
- 通过 MSA（微服务）明确划分团队的组织
- 开发人员熟悉云环境（AWS 认证级别以上）
⚙️ 模型3 — 平台团队 + Golden Path 模型 (Platform Engineering)
这是目前最受关注的模型。核心理念是：基础设施团队构建“平台”，开发团队部署“服务”。
核心思想：基础设施团队创建并提供经过验证的 Terraform 模块，开发团队使用这些模块。
# 基础设施团队创建的已验证模块（示例）
module "my_ecs_service" {
source = "git::https://github.com/company/terraform-modules//ecs-service?ref=v2.1.0"
# 开发团队填写的值
service_name = "payment-api"
container_port = 8080
desired_count = 2
cpu = 512
memory = 1024
# 安全相关内容在模块内部强制执行
environment = "prod"
vpc_id = var.vpc_id
}开发团队不能更改源模块，只能输入允许的变量。安全组规则、IAM 策略、标签标准已内置于模块中。
优点
- 同时实现速度和标准化
- 开发团队无需成为 Terraform 专家
- 基础设施团队只需专注于模块质量
缺点
- 模块设计初期成本高
- 模块过于受限可能导致开发团队不满
- 需要模块版本管理（必须以 ?ref=v2.1.0 形式进行标记）
适用组织
- 中大型企业，团队数量在5个以上
- 单独运营平台工程 (Platform Engineering) 或开发者体验 (DevEx) 团队的机构
- 计划构建内部开发者门户 (IDP, Internal Developer Portal) 的组织
💡 现实中常见的错误模式
❌ 模式1 — “大家一起用就行了”
没有明确的所有权划分，任何人都可以向 main 分支提交 PR。没有审查标准，state 锁冲突定期发生。这是小型团队中常见并容易固化的模式。
❌ 模式2 — 基础设施团队编写所有代码但没有审查
虽然实现了集中化，但缺乏代码质量管理。多年未动的 Terraform 代码变成了无人敢碰的“遗留 IaC”。
❌ 模式3 — 开发团队编写代码但不与基础设施团队共享
团队独立运营，声称“我们最了解我们的服务基础设施”，结果在安全审计中发现大量未经授权的资源。
✅ 总结 / 结尾
“Terraform 应该由谁来编写”的答案取决于组织的规模和成熟度。
| 组织情况 | 推荐模型 |
| 云迁移初期，5人以下团队 | 基础设施团队集中所有 |
| DevOps 成熟，MSA，小型初创公司 | 开发团队自主所有 |
| 团队5个以上，需要标准化 | 平台团队 + Golden Path 模块 |
| 金融/公共等合规性要求高的环境 | 基础设施团队所有 + 强制审查关卡 |
最重要的原则是：
平台基础设施（VPC、IAM、集群）由基础设施团队负责，应用层面（服务、函数）由开发团队负责
— 但模块和标准由基础设施团队提供。
所有权明确，才能在发生故障时明确谁来响应。代码的所有权，即是运营的责任。
发表回复