2017年，我接了一个烂摊子。生产环境跑在AWS上，一百多台EC2，RDS、ELB、安全组规则乱得像意大利面。前任运维离职前没留文档，最要命的是——所有东西都是控制台点出来的。你猜恢复一次全栈故障要多久？6个小时，其中4小时在回忆那些破安全组的端口号。这就是没有基础设施即代码的下场。人类的手指头根本不可靠，点错一个按钮就完蛋。所以我开始用Terraform，后来是Pulumi，彻底告别手工作坊。
声明式的魔法：不是怎么建，而是建什么
很多人以为基础设施即代码就是写脚本，自动创建资源。错了。脚本是命令式的——你告诉机器每一步怎么做：创建一个VPC，然后子网，然后路由表……这就像你指挥一个痴呆的搬运工：往前走三步，左转，放下箱子。声明式呢？你直接说“我要一个三居室的房子，客厅朝南，厨房有20平米”，然后平台去采购、施工。Terraform的HCL语言，或者Pulumi的通用语言，本质上是在描述期望状态。
底层机制其实很精妙。拿Terraform举例，你写完main.tf，执行plan，它干三件事：刷新当前状态（从state文件或云API查真实世界），构建资源图，比对差异。这个图是个有向无环图（DAG），节点是资源，边是依赖。比如防火墙规则依赖子网，子网依赖VPC。然后它会算出最小变更集——只动必须动的部分。我第一次看到这个机制的时候，差点拍大腿：这不就是函数式编程里的不可变数据结构吗？声明式配置就是初始值，每次apply生成新基础设施版本，旧版本被替换而非修改，天然避免配置漂移。
问题是，声明式虽好，坑也无数。最经典的是状态文件。Terraform把所有资源映射写在一个JSON文件里，叫terraform.tfstate。这东西就是你的命根子。丢了它，Terraform就失忆了，觉得资源都不存在，会试图重建一切——生产数据库也给你重建！我曾手贱把state文件提交到Git，结果团队协作时互相覆盖，差点搞出分裂脑。解决方案？远程状态存储+锁。用S3做后端，DynamoDB做锁。每次操作前抢锁，操作完释放。别嫌麻烦，这是血泪教训。
数据不会撒谎：压测下IaC的碾压级优势
光吹概念没用，上硬货。去年我们团队做过一次对照实验：部署一套典型的三层Web应用——包含负载均衡、自动伸缩组、RDS、Redis、CloudFront CDN。A组用控制台手动操作，B组用Terraform。结果？A组平均耗时47分钟，出错率38%（少配安全组、忘记打开多AZ等）。B组第一次terraform apply耗时12分钟，但后续任何变更——比如增加一台缓存节点——只需1分20秒，出错率0.5%。而且B组的配置可以复刻到另一个区域，耗时几乎相同。
这里有个反直觉的细节：单纯创建资源，Terraform并不总是最快的，因为它要计算依赖、并行度有限。真正恐怖的是重复执行和漂移修复。手动环境运行半年后，你绝对不敢说它和当初部署时一样。总有某个家伙偷偷改了安全组，或者扩了磁盘没记录。IaC通过定期plan就能发现漂移，然后一键修正。我们甚至搞了个定时任务，每小时跑一次plan，有差异就发告警——基础设施的单元测试。
别以为我在哄你。HashiCorp官方公布过一份报告，使用Terraform的企业平均部署频率提升5倍，故障恢复时间缩短90%。但注意，这些数据背后都是工程实践，不是买了个工具就自动变快。你得把基础设施当软件工程来搞：版本控制、代码审查、自动化测试、CI/CD管道。我们现在的任何配置变更都要走PR，Jenkins跑terraform plan并推送到Slack，人工确认后再apply。这套流程建起来累，建完爽得飞起。
落地的三个巨坑，以及我摔过的跟头
坑一：模块化贪多嚼不烂。新手一上来就想写超级通用的模块，能适配所有环境。结果呢？模块里几十个变量，条件判断一堆，嵌套三层，读起来像天书。我见过一个模块的outputs比核心代码还长。记住：模块的复用边界是单一职责，比如一个模块就管一个EKS集群。别试图把网络、计算、安全全揉一起。我们现在的标准是模块代码不超过200行，变量不超过10个。超过就拆。简单即是美。
坑二：敏感信息裸奔。密码、API密钥直接写代码或者环境变量里？那你就是在埋雷。即使state文件加密，它明文存储了所有属性，包括数据库密码。我曾不小心把state文件curl到一个公开gist，当场吓出冷汗。必须用外部密钥管理。我们用HashiCorp Vault，Terraform通过Vault provider动态读取密码，state里只存引用路径。Pulumi更干脆，可以把密文标记为secret，输出自动加密。但核心原则不变：永远不要把机密静止在代码或状态里。
坑三：Provider依赖地狱。Terraform的provider版本锁死了一个次要版本，有次我们升级AWS provider从3.x到4.x，结果新版本要求修改十几个资源属性——API名字都变了。那次我们对着plan报告改了整整两天。教训是：显式锁定版本并建立升级测试环境。我们在CI里加了一个stage，用新provider版本跑plan，看有没有破坏性变更。有的话先修，再推进生产。还有个更狠的招：把provider配置也模块化，用一个版本仓库统一管理，所有项目引用同一个仓库的特定commit。
写到最后，我想起一个架构师朋友老周的吐槽：“你们搞IaC的，就是不想让别人看懂你们的配置，好保住工作！” 我大笑。其实正好相反，好的IaC代码就像好的散文，清晰、简洁，别说同事，三个月后的自己都能一眼看懂。这才是工程美学的真谛——用代码驯服混乱，让基础设施变得可预测、可重现。你可能会觉得我偏执。没错，不偏执搞不了这个。
