IaC 不测试就上生产？Terraform 四层验证体系让凌晨告警少 80%
概述 去年接手一个项目，前同事写的 Terraform 代码跑得好好的，某个周一上午他改了一行 instance_type，terraform plan 显示正常，apply 也成功了。然后业务炸了。 原因不是代码写错，是那个 instance_type 对应的 AMI 在目标可用区不存在。plan 能过是因为它只检查"逻辑上通不通"，不检查"云上到底有没有这个资源"。这种问题在静态检查阶段就能拦住，但那个团队的 IaC 流水线里只有 terraform fmt && terraform validate，连 tflint 都没装。 很多人对 IaC 测试的认知停留在"跑一下 plan 看看输出对不对"。这不叫测试，这叫碰运气。Terraform 不是事务系统——apply 失败后基础设施会停在一个半成品状态，比没改之前更糟。我在多个生产环境中踩过这个坑，最后总结出一套四层验证体系：静态检查 → 安全扫描 → 计划验证 → 集成测试，从代码提交到生产部署逐层拦截问题。本文拆解每一层的工具选型、配置方法和踩坑细节。 本文假设你已经了解 Terraform 基本用法。如果不熟悉，先看 相关文章：Terraform 基础设施即代码入门 和 相关文章：状态文件丢了怎么办：Terraform State 灾难恢复与生产级后端架构。 一、为什么 IaC 需要测试体系 先说清楚一个认知误区：terraform plan 通过 ≠ 代码正确。 terraform plan 只验证两件事：HCL 语法是否合法、资源依赖关系是否合理。它不验证： instance_type 在目标区域是否可用（t2.nano 在某些区域不存在） 安全组规则是否暴露了不该暴露的端口（0.0.0.0/0 开 22 端口） IAM 策略是否过宽（Action: "*", Resource: "*" 这种"上帝权限"） 资源命名是否符合团队规范（一个 VPC 叫 prod-vpc 另一个叫 test_vpc_01） 模块间参数传递是否类型匹配 这些全是生产事故的高频原因。我在某电商平台做过统计：37% 的 IaC 相关故障，terraform plan 阶段没有任何报错，是 apply 后才暴露的。...