基础设施即代码

概述 某周三凌晨两点，我在某出行项目值班手机响了。告警群里弹出一条 Prometheus 告警——生产环境的 ALB（应用负载均衡）流量分布异常，一台后端 ECS 的权重突然变成 0，但实际上那台机器还活着。排查发现：有人在前一天通过控制台手动修改了 ALB 的监听规则，把一台 ECS 的权重从 50 改成了 0，但这个操作没有走 Terraform 流水线，Terraform state 文件里记的还是权重 50。 更让我后背发凉的是：当天下午跑了一次 terraform plan，输出是 No changes. Your infrastructure matches the configuration.——状态文件里一切正常，线上实际配置已经偏了。state 文件在骗我。 这就是配置漂移（Configuration Drift）：Terraform 声明的期望状态和云上实际运行状态之间产生了差异，而 Terraform 不知道。Verizon 的数据安全报告指出，68% 的云安全事件根因是配置错误和配置漂移——不是漏洞利用，不是 0day，而是"线上实际跑的东西和代码里写的不一样"。 这不是个例。在我经手的多家企业客户中，漂移几乎是 IaC 落地后的必经阶段——只要有人能绕过 Terraform 直接在控制台操作，漂移就会发生。问题不在于"怎么防止漂移"（你防不住），而在于"怎么检测漂移、怎么修复、怎么治理"。 这篇文章记录我在 9 年运维和 IaC 实践中处理漂移的完整工程决策，覆盖： 漂移的三种类型——不是所有"变了"都需要拉响警报 terraform plan -detailed-exitcode 的退出码机制和坑 driftctl（现 Snyk IaC）与 terraform plan 的互补关系 在 CI/CD 中嵌入漂移检测的完整流水线配置 漂移修复的三种策略：reconcile、import、rebuild，以及什么时候选哪个 6 个生产环境踩坑：从"eternal diff"到修复竞态条件 漂移治理框架：检测频率、告警阈值、修复归属、预防策略 先说清楚立场：漂移检测不是"跑一次 plan 看看有没有变化"那么简单。它涉及工具选型、流水线编排、告警策略、修复流程和团队协作。如果你只是把 terraform plan 塞进 cron 然后告警发到群里，你会被误报淹没，最后把告警关掉——这是我见过太多团队的真实经历。...

概述 周一的站会上，某出行平台的平台工程团队例行复盘上周事故：一周 17 个状态锁冲突、2 次生产环境被"好心"的同事手动 apply 改坏、1 次凭据明文躺在 CI 日志里。原因不是某个人操作失误，而是我们那套自建的 Terraform 后端——Git 仓库 + S3 状态桶 + DynamoDB 锁 + 一堆 hand-made CI 脚本——在团队从 5 人长到 30 人之后，已经彻底撑不住了。 Terraform 的配套托管平台 HCP Terraform（原 Terraform Cloud）我一直知道，但总觉得"不过是把状态文件托管到云端"，直到这次事故周才真正认真评估它。评估完发现，托管平台的真正价值不在状态存储，而在执行模型、权限模型和策略引擎。这篇文章不是产品介绍，而是我实际迁移后的决策记录：6 个关键工程决策、一份不掺水的 TCO 账本、以及每个决策对应的坑。 你会看到： 自建后端在团队规模增长后到底贵在哪里（一份真实成本拆解） 触发我们迁移的 6 个临界点信号 HCP Terraform vs Terraform Enterprise vs OpenTofu 自建的选型对比表 Workspace 与变量集的组织模型，以及我们踩过的"变量集陷阱" 从 S3 后端迁到 HCP Terraform 的完整步骤与 5 个迁移坑 Sentinel 策略即代码的实战示例（阻断一个"危险变更包"的完整过程） 平台 API 自动化：把 HCP Terraform 自身也纳入 IaC 管理 与 CI/CD 集成的两种模式（VCS 驱动 vs CLI 驱动）和 Run Tasks 扩展 一份按用户数、并发、存储估算的 TCO 对照表 先声明立场：本文不吹 HCP Terraform，也不劝你迁移。如果你的团队只有 3-5 人、基础设施规模不大，自建方案可能是更优解，我会在最后一节给出明确的"不要迁移"判断标准。这篇文章面向的是——团队规模已经在膨胀、自建方案开始频繁出事故、需要在失控前做一次理性选型的人。...

概述 去年年底接手一个项目：某出行平台的云基础设施代码库，Terraform HCL 写了 3000 多行，分了 40 多个模块，循环引用 3 处，for_each 嵌套两层 dynamic block 到没人看得懂。新来的运维改了一行 tags，terraform plan 输出 847 行变更，其中 600 行是"无实际影响但状态会更新"。他不敢 apply，我也看不懂那 847 行。 这不是个例。我在多个项目里见过同样的剧本：HCL 在 500 行以内很好用，超过 1000 行就开始失控，2000 行以上就是"只有写的人敢碰"的炸弹。原因不复杂——HCL 是领域专用语言（DSL），设计目标是"声明式配置"，不是"工程化代码"。它没有函数（只有 module），没有异常处理，没有类型推断，测试要靠第三方工具（如 Terratest）从外部驱动。 Pulumi 换了个思路：用你已经在用的编程语言（Go、Python、TypeScript 等）写基础设施。听起来只是"换种语法"，但它改变的是整个工程实践——你可以写单元测试、用 IDE 跳转定义、用包管理器复用代码、甚至把 IaC 嵌入应用里通过 API 驱动部署。 这篇文章不讲"Pulumi 比 Terraform 好"这种废话。我讲的是：在什么场景下你应该考虑迁移，迁移时做哪些架构决策，以及我踩过的 5 个坑。所有结论来自我在某出行平台和某电商平台的基础设施改造实践，数据脱敏但结构和逻辑保留。 为什么 HCL 写到 3000 行会"烂掉" 先说清楚问题出在哪，不然迁移决策就是拍脑袋。 HCL 的设计哲学与工程化冲突 HCL 的核心是声明式——你告诉 Terraform"期望状态是什么样"，引擎负责把现实对齐到期望。这个模型在 500 行以内很优雅：一段 VPC 配置、几个安全组、一个 RDS 实例，读起来像配置文件，改起来也直观。 但工程规模上去后，HCL 的设计约束变成短板： 场景 HCL 的做法 编程语言的做法 根据环境创建不同资源 count = var....

概述 去年给一家做电商的客户搭 IaC 体系，接手时他们的 Terraform 代码库大概长这样：三个环境（dev/staging/prod）各自一套配置，加起来 3000 多行，90% 是复制粘贴。改一个 VPC CIDR 要同步改三个文件，漏改一个就是环境漂移。最离谱的是有个安全组规则在 prod 里少了一条，三个月没人发现。 这种痛每个用过 Terraform 的团队都经历过。模块化是公认的解法——但很多人做完模块化后发现：代码确实短了，可维护性反而更差了。一个模块塞了 40 个变量、3 层嵌套，改一个参数要翻三个文件才能理解影响面。这就是"把模块写成黑盒"的典型症状。 这篇文章拆解我在多个企业客户项目中验证过的一套 Terraform 模块分层架构，以及 6 个在生产环境中真实踩过的反模式。不是泛泛的"最佳实践"罗列，而是每个决策点都附上"为什么这么做"和"什么场景下不推荐这么做"。 为什么需要模块化 先说清楚模块化解决什么问题。不是"代码复用"这么笼统的话，而是三个具体痛点： 痛点一：环境漂移。 三个环境的配置本应一致，但人工复制必然出错。在某出行项目中，我们统计过：复制粘贴的配置平均每个环境有 3-5 处细微差异（CIDR 偏移、可用区数量不一致、安全组规则遗漏），这些差异在平时不爆发，一出故障就是定位地狱。 痛点二：变更同步成本。 改一个 AMI ID 要在 3 套环境里各改一次。如果团队有 5 个人同时改不同模块，合并冲突频繁到让人怀疑人生。 痛点三：知识传递断裂。 新人来了看一个 800 行的 main.tf，完全不知道哪些资源是有关联的、改哪个会影响哪个。没有模块边界，就没有认知锚点。 模块化的本质不是"把代码拆短"，而是建立明确的抽象边界——让每个模块成为一个可以独立理解、独立测试、独立变更的单元。 模块分层架构设计 三层模型 我推荐的三层架构如下： 层级 职责 示例 变量数量 资源数量 基础模块 封装单一云资源 modules/vpc、modules/rds 5-15 3-8 组合模块 组合多个基础模块 modules/eks-platform 15-30 调用 3-5 个基础模块 环境层 定义环境差异化配置 envs/prod/ 不限 调用 2-4 个组合模块 这三层不是什么新概念，但很多人在实际落地时会把层级搞混——最常见的是基础模块里塞了组合逻辑，或者环境层直接调用基础模块跳过了组合层。下面逐层拆解。...

概述 凌晨三点，手机震了。告警群一条消息：某云厂商华东 region 存储服务大面积不可用。你负责的核心业务全量部署在这个 region，数据库的主库也在那边。故障已经持续 12 分钟，客户开始投诉，老板在群里问"多久能恢复"。 你心里清楚：跨 region 容灾方案半年前就评审过，但因为"成本太高"被砍了。现在只能硬扛。 这是真实发生过的场景。2023 年阿里云香港机房宕机事件，让不少只做单 region 部署的团队第一次认真思考跨云容灾的问题。但多云架构远不止"把服务部署到两个云"那么简单——网络怎么连通？数据怎么同步？监控怎么统一？成本怎么控制？切换时谁来决策？ 这篇文章拆解多云架构设计中的关键决策点，每一层都给出我在实际项目中的选型理由和踩过的坑。不是教科书式的"多云架构有哪些优势"，而是一线架构师面对真实约束时做的取舍。 多云 vs 混合云 vs 多区域：先搞清楚你在做哪个 很多人把这三个概念混着用，但它们解决完全不同的问题。 维度 多云（Multi-Cloud） 混合云（Hybrid Cloud） 多区域（Multi-Region） 定义 使用 2+ 个公有云厂商 公有云 + 私有云/本地机房 同一云厂商的不同区域 核心目标 避免厂商绑架、选择性采购 数据合规+弹性扩展 容灾+就近访问 网络复杂度 高（跨厂商 VPC 互联） 中（VPN/专线） 低（厂商内网） 典型场景 A 云跑 AI 推理，B 云跑数据库 核心数据在本地，弹性计算在云 同 region 双活+跨 region 灾备 我的判断：如果你的核心诉求只是"不把鸡蛋放在一个篮子里"，先做多区域部署，成本和复杂度远低于跨厂商多云。真正的多云架构应该由业务需求驱动——比如某个云的 GPU 性价比明显更好，或者合规要求特定数据必须在特定云上处理。 我在某出行项目里做过一次"伪多云"的评估：技术团队想用多云来"降低成本"，但拆开账单后发现，95% 的成本来自计算和存储资源，跨云迁移后资源单价差异不到 8%，而增加的运维和跨云传输成本吃掉了这块差价。最后改成同厂商多区域 + 预留实例优化，成本反而降了 22%。 别为了多云而多云。先算清楚收益和成本的账。 为什么真的需要多云：四个真实驱动因素 1. 供应商绑架规避 这是最常见的多云驱动因素，但也是最容易被高估的。...