1. 课程导入与全景认知
在单机实验环境里，Terraform 的体验往往非常顺滑：写几个 .tf 文件，执行 terraform apply，云上资源就建好了。可一旦把同一套配置交给一个团队、接入 CI/CD、面对多环境与多账号，问题会立刻从“语法会不会写”变成“状态归谁管、谁能改、改完怎么不互相踩”。本课程要解决的核心，正是围绕 state（状态） 这一 Terraform 的“事实来源”展开的治理与协作问题。
为什么状态是 Terraform 的命门
Terraform 并不通过扫描云平台来推断资源现状，而是依赖本地或远端的 terraform.tfstate 文件，把配置文件中的资源地址（如 aws_instance.web）与云上真实资源 ID 建立映射。这个映射里还保存了资源属性、依赖关系、输出值和元数据。因此，状态文件一旦丢失、损坏或被多人同时写入，Terraform 就会“失忆”或“错认”，轻则计划里出现大量无意义的销毁重建，重则误删生产资源。
可以这样理解三者的关系：配置（Configuration） 是期望，状态（State） 是记忆，真实基础设施（Real Infrastructure） 是现实。Terraform 的工作就是不断让现实向期望靠拢，而状态是它做判断的唯一依据。下图展示了这一核心关系与团队协作中状态流转的关键路径。
团队协作中真正会踩的坑
把状态放在开发者本地，是团队协作最典型的反模式。假设 A 和 B 同时基于同一份配置工作：A 先执行 apply 创建了 3 台 ECS，状态只更新在 A 的本地文件里；B 随后用自己那份“旧状态”执行 apply，Terraform 会认为这 3 台机器不存在，于是重复创建，最终云上出现 6 台机器，而两份状态各执一词。更危险的是 destroy：B 若执行销毁，可能删掉 A 创建的资源，而 A 的状态文件仍以为它们存在。
除了并发覆盖，还有几类高频问题：状态漂移（有人绕过 Terraform 在控制台改了安全组规则，状态与真实资源不一致）、敏感信息泄露（状态里常以明文保存数据库密码、密钥，放进 Git 等于泄密）、环境混用（dev 和 prod 共用一个 state，一次误操作波及生产）、锁缺失（没有远端锁，两个 CI 流水线同时跑 apply）。这些问题共同指向一个结论：状态治理不是可选项，而是团队使用 Terraform 的前置条件。
本课程的学习地图
围绕“状态治理 + 团队协作”这条主线，课程将分四个层次推进，建议按顺序学习：
- 认知层（第 1～5 章）：理解 state 的本质、结构、生命周期，以及本地状态为何不适合团队。
- 治理层（第 6～15 章）：远端后端选型与配置、状态锁定、加密与版本化、状态拆分与目录/工作区策略、导入与迁移。
- 协作层（第 16～24 章）：代码仓库结构、模块化、CI/CD 中的 plan/apply 审批流、权限与最小授权、代码评审与变更窗口。
- 运维层（第 25～30 章）：漂移检测、状态修复、灾难恢复、审计与成本治理、成熟度评估。
关键术语速查
| 术语 | 含义 | 团队关注点 |
|---|---|---|
| State | 资源地址与真实 ID 的映射及属性快照 | 集中存储、加锁、加密 |
| Backend | 状态的存储与访问方式（local/remote） | 选 OSS/S3 等远端后端 |
| State Locking | 防止并发写入的锁机制 | 必须开启，避免覆盖 |
| Drift | 真实资源偏离配置与状态 | 定期 plan 检测 |
| Workspace | 同一配置下的多状态实例 | 环境隔离的轻量方案 |
| Import | 把已存在资源纳入状态管理 | 接管存量资源 |
| Module | 可复用的配置单元 | 统一规范、减少重复 |
terraform state list 能看到资源清单，执行 terraform state pull | head -30 可查看状态头部信息。如果状态仍在本地且已多人协作，请把它列为第一优先治理项。
整体框架一句话总结
用一句话概括本课程的框架：以远端后端为地基，以状态锁定与加密为护栏，以状态拆分为边界，以 CI/CD 审批流为闸门，以漂移检测与恢复为兜底。掌握这条主线，你就能把 Terraform 从“个人效率工具”升级为“团队可信赖的基础设施交付体系”。