1. 课程导入与全景认知

很多团队第一次接触 Terraform，是从“把手工点控制台的动作写成 .tf 文件”开始的。这确实解决了单次部署的可重复性问题，但当基础设施规模从几十个资源增长到几千个资源、从一个人维护变成十几个团队协作时，问题会迅速从“语法怎么写”转移到另外一类问题上：谁有权改生产网络？某个模块升级后会影响哪些业务？一次误删如何被拦截？成本异常能否在合并请求阶段就被发现？这些问题的答案，构成了本课程的核心——平台化交付与治理。

先给出定义。Terraform 平台化交付，是指把 Terraform 从个人工具升级为组织级能力：以标准化模块和目录结构承载基础设施定义，以自动化流水线承载变更执行，以远程状态和锁机制承载并发协作，以策略即代码承载合规约束。治理则是在这套能力之上，明确“谁能改、能改什么、改完如何验证、出问题如何追溯”的规则体系。二者不是两件事：交付是“把变更安全地推下去”，治理是“让推下去的变更始终处于可控边界内”。

理解价值，最好从一次典型变更的生命周期看。假设某团队要把一个服务的实例规格从 t3.medium 调整为 t3.large。在非平台化模式下，工程师本地执行 terraform apply，状态文件可能只存在于他的电脑或某个共享目录，变更记录散落在聊天记录里。在平台化模式下，这次变更会经历：代码提交 → 静态检查与格式化 → 策略校验（例如是否允许该环境使用该规格）→ terraform plan 生成计划 → 计划被评审并留档 → 受控执行 → 状态写回远端后端 → 审计日志归档。同一件事，前者只完成了“改”，后者完成了“可追溯地改”。

下面这张图展示了本课程要建立的整体认知框架：从基础设施代码出发，经过模块化封装、环境分层、状态与后端、流水线执行，最终落到策略治理与可观测反馈，形成闭环。

这张图里，最容易被忽视的是最下方那条虚线——治理不是终点，而是反馈回代码与模块的约束。例如策略校验发现某模块默认开启了公网访问，正确的做法不是每次在流水线里手工拒绝，而是回到模块层修正默认值，让“安全”成为默认行为。这正是平台化交付与治理区别于“写脚本 + 加审批”的关键。

那么，这套能力适用于哪些场景？第一类是多云或混合云基础设施管理，需要统一描述不同云厂商的资源；第二类是多环境、多团队协作，环境之间需要隔离，团队之间需要边界；第三类是合规与成本敏感型组织，要求变更可审计、可拦截、可追溯；第四类是平台工程团队对外提供自助能力，让业务团队通过模块和流水线自助申请资源，而不是排队等运维。相反，如果只是个人维护三五个资源、没有协作和合规要求，直接使用 Terraform CLI 反而更轻量，不必强行平台化。

本课程的学习地图按“能力递进”组织，共 30 章，可以分成四个阶段。第一阶段是认知与基础：理解平台化交付与治理的定义、价值、适用边界，掌握 Terraform 核心工作流与状态机制。第二阶段是工程化：模块设计、目录结构、环境分层、远程后端与锁、变量与输出契约。第三阶段是自动化与治理：CI/CD 流水线、plan 评审、策略即代码、权限与审批、漂移检测、成本与安全反馈。第四阶段是规模化与复盘：多团队协作模式、模块版本治理、故障排查、变更复盘与持续改进。

为了让你对最终交付目标有具体预期，这里给出一份本课程结束时你应当能够独立完成的成果清单。它不是抽象的能力描述，而是可以直接对照检查的交付物：

需要强调的是，这些交付物不是一次性写完就结束的。平台化交付与治理的本质是持续运营：模块会迭代，策略会随合规要求变化，环境会增减，团队会调整。因此本课程在每个阶段都会同时讲“怎么建”和“怎么维护”，并在后续章节中反复回到一个判断标准——这次变更是否可解释、可追溯、可回退。如果答案是肯定的，说明你的平台化与治理能力正在生效；如果是否定的，就需要回到对应的环节补齐。

最后回到本节的起点。Terraform 平台化交付与治理，不是把 Terraform 用得更复杂，而是让基础设施变更从“个人操作”变成“组织能力”。它要求你同时具备工程视角（模块、状态、流水线）和治理视角（策略、权限、审计、反馈）。接下来的 29 章，会沿着这条主线逐步展开，每一章都对应一个可以实际落地的能力点。你现在需要建立的，是这张全景图：代码 → 模块 → 环境 → 状态 → 流水线 → 治理 → 反馈，闭环运转，持续改进。