Terraform 状态手术包

解决什么问题

Terraform 的 state 文件是实际资源与代码之间的映射。一旦资源被手工创建、跨工作区迁移，或者某个实例反复不可复现，terraform plan 就会因为 drift 而失真：它不认识 state 里不存在的东西，也不知道该怎么处理已经漂移出去的资源。

常见的应对手段是 terraform state 系列子命令，例如 terraform state rm、terraform state mv、terraform state pull/push。这些操作直接改写 state，属于不可逆动作。手工执行时最常见的问题是：

• 没有先备份 state，出错后无法回退；
• 参数顺序或资源地址写错，把资源归属改到错误的模块路径下；
• 忘记 target 参数，导致资源被重建而不是迁移。

Terraform 状态手术包把这类高风险操作收敛成一条可审计的流程，而不是让工程师临时敲命令。

工作方式

技能的核心能力分三层：

1. 选择执行通道：优先走 terraform CLI 的 state 子命令处理本地工作区；在托管环境下改走 Terraform Cloud API，保证操作落在正确的 organization / workspace 上。
2. 三类操作：state import 把已存在的资源纳入 state；state mv 调整资源在 state 中的归属路径；taint 标记资源以便下次计划时替换。
3. 自动备份与回滚：任何写操作之前先取一份 state 快照，失败或结果不符预期时可以回到操作前的状态。

典型的执行步骤大致如下：

• 读取当前工作区，确认 terraform init 已完成且 provider 可访问；
• 对目标资源做状态查询，校验其地址与模块路径；
• 备份当前 state 到安全位置；
• 执行 import / move / taint 中的一种，并显式给出 -ignore-unchanged 之类的必要参数；
• 重新运行 terraform plan 检查变更是否符合预期；
• 若异常则用备份的 state 回滚。

适用边界与注意点

这个技能不替代正常的 IaC 流程。 如果资源可以通过修改配置再 apply 来重建，应该优先走那条路；state 手术是针对 drift、遗留资源、跨模块迁移这类特殊场景的补救手段。

几个容易踩的坑：

• state mv 不会改变远端资源本身，它只改 state 里的记录。如果目标地址对应的资源不存在，后续 plan 会试图新建它。
• taint 只是标记，不会立刻销毁资源，它的效果要等到下一次 apply 才显现。
• 在团队协作的工作区里执行 state 写操作前，需要先确认没有其他人正在 plan 或 apply，避免 state 被覆盖。
• 回滚依赖备份的完整性，备份文件需要落在与工作区不同的存储位置，否则 state 本身损坏时备份也不可用。
• Terraform Cloud API 路径下，操作权限受 workspace 的执行角色限制，需要确认 token 有足够的 state 读写权限。

总的原则：先备份、再操作、最后用 plan 验证。任何一步出现偏差，回滚成本远低于继续在错误的 state 上叠加变更。