Terraform 状态管理最佳实践：远程后端与状态锁定
Terraform State Management Best Practices: Remote Backends and State Locking
| David | 2026-09-10T22:46:00
Terraform 的状态文件是基础设施即代码的核心，但管理不当很容易翻车。分享我们在多人协作场景下的状态管理方案。
Terraform state files are the core of infrastructure as code, but poor management leads to disasters. Sharing our state management approach for team collaboration.
Terraform 用得越多越觉得状态管理才是最核心的问题。代码写得再漂亮，状态文件一乱全白搭。 本地状态的坑 刚开始用 Terraform 的时候，状态文件就放在本地的 terraform.tfstate。一个人用没啥问题，但一旦多人协作就炸了： 两个人同时 terraform apply，状态文件冲突 有人忘了提交状态文件，其他人 apply 就把资源重建了 状态文件里有敏感信息（密码、密钥），放 Git 里不安全 迁移到远程后端 我们最终选了 S3 + DynamoDB 的方案： terraform { backend "s3" { bucket = "mycompany-terraform-state" key = "prod/vpc/terraform.tfstate" region = "ap-southeast-1" encrypt = true dynamodb_table = "terraform-locks" } } S3 存状态文件（开启版本控制和加密），DynamoDB 做状态锁。这样多人同时操作时，后执行的人会被锁住等待，不会产生冲突。 状态文件的组织 不要把所有资源放一个状态文件里。我们按环境和功能模块拆分： terraform-state/ ├── prod/ │ ├── vpc/terraform.tfstate │ ├── database/terraform.tfstate │ ├── app/terraform.tfstate │ └── monitoring/terraform.tfstate ├── staging/ │ └── ... └── shared/ ├── iam/terraform.tfstate └── dns/terraform.tfstate 这样改网络的时候不会影响到数据库的状态，blast radius 可控。 状态文件的备份和恢复 S3 开了版本控制之后，误操作可以回滚到之前的版本。另外建议定期把状态文件 export 一份到别的地方，双保险。 最重要的一条：永远不要手动编辑状态文件。如果需要修改状态，用 terraform state mv 或 terraform import。
The more you use Terraform, the more you realize state management is the core challenge. Remote Backend We use S3 + DynamoDB: S3 for versioned encrypted state storage, DynamoDB for state locking to prevent concurrent conflicts. State Organization Split by environment and module (vpc/database/app/monitoring) to limit blast radius. Key Rule Never manually edit state files. Use terraform state mv or terraform import instead.