1. 课程导入与治理全景
在基础设施即代码（IaC）的实践中，Terraform 已经成为事实上的标准工具。它让团队可以用声明式配置描述云资源，通过 terraform plan 预览变更、terraform apply 落地变更。然而，当 Terraform 从个人实验走向企业级多团队协作时，一个更棘手的问题浮现出来：代码能跑通，不代表变更可以放心执行。一次误删生产数据库、一次把安全组端口开放到 0.0.0.0/0、一次绕过审批直接 apply，都可能造成难以挽回的后果。这正是本课程要解决的核心命题——策略合规与变更治理。
一、核心目标：从“能变更”到“可控地变更”
策略合规与变更治理的目标可以概括为三句话：让该发生的变更顺利发生，让不该发生的变更无法发生，让发生过的变更可追溯、可审计。它关注的不是 Terraform 语法本身，而是围绕 Terraform 工作流建立的一套约束、检查与记录机制。
具体来说，这套机制要回答四个问题：
- 谁可以发起变更？——身份与权限边界。
- 什么变更被允许？——策略规则，例如禁止公开存储桶、强制标签、限制实例规格。
- 如何执行变更？——审批流程、计划评审、自动化流水线。
- 结果如何被记录？——状态文件、审计日志、变更历史。
这四个问题构成了治理的基本骨架。缺少任何一环，治理都会出现缺口：只有权限没有策略，等于给了钥匙却没规定能开哪扇门；只有策略没有审批，规则可能被绕过；只有审批没有审计，事后无法复盘。
二、关键挑战：为什么治理在 Terraform 中特别难
Terraform 的治理难点，源于它自身的几个特性。
第一，状态文件是“真相之源”，也是风险集中点。 terraform.tfstate 记录了资源与配置的映射关系。如果状态文件被误改、丢失或多人同时写入，轻则 plan 结果失真，重则资源被错误重建。远程后端（如 S3 + DynamoDB 锁）解决了部分问题，但状态文件的访问控制、加密和备份仍需专门治理。
第二，plan 与 apply 之间存在“时间差”。 团队评审的是 plan 输出，但真正执行时环境可能已经变化。如果评审后有人手动改了云上资源，apply 的结果就可能与评审内容不一致。这种“计划漂移”是治理中非常隐蔽的风险。
第三，策略检查往往滞后。 很多团队在 apply 之后才通过云平台的安全扫描发现问题，此时资源已经创建，修复成本高。理想的做法是把检查前移到 plan 阶段，甚至前移到代码提交阶段。
第四，多环境、多团队带来复杂度。 开发、测试、生产环境对同一份配置的要求不同；不同团队可能共用模块，但合规标准各异。如何在不牺牲效率的前提下统一治理，是组织层面的挑战。
三、整体框架：四层治理模型
为了把上述目标与挑战组织成可落地的体系，本课程采用一个四层治理框架，从下到上依次是：
- 代码与状态层：管理 Terraform 配置、模块、状态后端、锁与版本控制。
- 策略层：用策略即代码（Policy as Code）定义合规规则，如 Sentinel、OPA/Conftest、Checkov、tfsec。
- 流程层：把 plan、策略检查、审批、apply 串成自动化流水线，控制变更节奏。
- 审计与反馈层：记录变更、收集违规、生成报告，并反哺策略与流程优化。
这四层不是孤立的。策略层依赖代码层的结构化信息；流程层调用策略层的检查结果；审计层的数据又用于调整策略和流程。下图展示了这一整体框架以及各层之间的数据与控制流向。
四、学习路径：本课程将带你走完的旅程
围绕上述框架，本课程后续章节将按“先建认知、再学工具、后做整合”的顺序展开。你会先理解策略即代码的基本理念与常见工具，然后学习如何编写和测试策略规则，接着把策略检查嵌入 CI/CD 流水线，最后掌握审计、漂移检测与持续改进的方法。
需要强调的是，治理不是一次性项目，而是一个持续循环：定义策略 → 执行检查 → 处理违规 → 收集反馈 → 调整策略。每一轮循环都会让规则更贴合实际、让流程更顺畅。本课程的目标，是让你不仅知道有哪些工具，更能根据自己团队的规模、合规要求和风险偏好，设计出可落地的治理方案。