HCP

概述 周一的站会上，某出行平台的平台工程团队例行复盘上周事故：一周 17 个状态锁冲突、2 次生产环境被"好心"的同事手动 apply 改坏、1 次凭据明文躺在 CI 日志里。原因不是某个人操作失误，而是我们那套自建的 Terraform 后端——Git 仓库 + S3 状态桶 + DynamoDB 锁 + 一堆 hand-made CI 脚本——在团队从 5 人长到 30 人之后，已经彻底撑不住了。 Terraform 的配套托管平台 HCP Terraform（原 Terraform Cloud）我一直知道，但总觉得"不过是把状态文件托管到云端"，直到这次事故周才真正认真评估它。评估完发现，托管平台的真正价值不在状态存储，而在执行模型、权限模型和策略引擎。这篇文章不是产品介绍，而是我实际迁移后的决策记录：6 个关键工程决策、一份不掺水的 TCO 账本、以及每个决策对应的坑。 你会看到： 自建后端在团队规模增长后到底贵在哪里（一份真实成本拆解） 触发我们迁移的 6 个临界点信号 HCP Terraform vs Terraform Enterprise vs OpenTofu 自建的选型对比表 Workspace 与变量集的组织模型，以及我们踩过的"变量集陷阱" 从 S3 后端迁到 HCP Terraform 的完整步骤与 5 个迁移坑 Sentinel 策略即代码的实战示例（阻断一个"危险变更包"的完整过程） 平台 API 自动化：把 HCP Terraform 自身也纳入 IaC 管理 与 CI/CD 集成的两种模式（VCS 驱动 vs CLI 驱动）和 Run Tasks 扩展 一份按用户数、并发、存储估算的 TCO 对照表 先声明立场：本文不吹 HCP Terraform，也不劝你迁移。如果你的团队只有 3-5 人、基础设施规模不大，自建方案可能是更优解，我会在最后一节给出明确的"不要迁移"判断标准。这篇文章面向的是——团队规模已经在膨胀、自建方案开始频繁出事故、需要在失控前做一次理性选型的人。...