配置漂移

概述 某周三凌晨两点，我在某出行项目值班手机响了。告警群里弹出一条 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 然后告警发到群里，你会被误报淹没，最后把告警关掉——这是我见过太多团队的真实经历。...

概述 凌晨两点，手机炸了。某出行项目的运维群弹出一连串告警：RDS 主从切换失败、EIP 绑定状态异常、安全组规则缺失。排查了一圈，根因是有人手动在控制台改了安全组规则，Terraform 的 state 文件和云上实际状态不一致，一次 terraform apply 把手动修改的资源全部"纠正"回旧配置——直接覆盖了线上紧急热修复。 这不是个例。Terraform 的 state 文件是整个 IaC 体系的"唯一真相源"（Single Source of Truth），但它同时也是最脆弱的环节。state 文件丢失、锁死、配置漂移，这三个问题我在多个生产环境中全部遇到过。这篇文章不讲 Terraform 基础语法（相关文章：Terraform 基础设施即代码入门 已经讲过），而是聚焦于：生产环境中 state 文件怎么存、怎么锁、怎么迁移、出了事怎么救。 你会看到： state 文件的内部结构和它为什么这么重要 S3 + DynamoDB 远程后端的完整生产级配置（含权限隔离方案） 状态锁卡死的排查和解除方法 配置漂移的检测、修复和预防策略 状态文件拆分迁移的实战步骤（附 terraform state mv 的避坑指南） 一个真实的"state 文件被误删"灾难恢复全过程 state 文件到底是什么 先说人话：state 文件就是 Terraform 的"资产清单"。 你用 Terraform 创建了一台 EC2、一个 RDS、一个 VPC，Terraform 需要记住这些资源的 ID、属性、依赖关系。不然下次 terraform plan 的时候，它怎么知道哪些资源已经创建过、哪些需要更新？ state 文件就是一个 JSON 文件，记录了所有被 Terraform 管理的资源的当前状态。每次 terraform apply 后自动更新。 state 文件的内部结构 打开一个 terraform....