凌晨发现线上多了 3 个没人建的资源：Terraform 漂移检测与修复的 6 个工程决策
概述 某周三凌晨两点，我在某出行项目值班手机响了。告警群里弹出一条 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 然后告警发到群里，你会被误报淹没，最后把告警关掉——这是我见过太多团队的真实经历。...