Terraform vs 手动操作：效率对比实测
我为什么做这个测试
去年我们的测试环境出了个事故：一个同事在控制台上手动改了安全组规则，另一个同事第二天又手动改了回去，因为没人知道第一处改动是谁做的、为什么做。那次排查花了整整一下午。
我当时就在想：如果这些操作都是代码化的，这种事根本不会发生。但“基础设施即代码”的效率到底怎么样？控制台点几下就能干完的事，写 Terraform 会不会反而更慢？光靠感觉争论没意义，我决定做个实测。
测试设计
我选了一个我们团队最常见的场景：搭建一套完整的 Web 测试环境，包括：
- 1 个 VPC + 子网
- 1 个安全组（开放 80/443/22 端口）
- 2 台 EC2 实例
- 1 个负载均衡器
- 1 条 Route53 DNS 记录
我用秒表记录两个流程的纯操作时间，不包括等待资源创建的时间（云厂商的等待时间两边都一样）。测试环境用的是 AWS，Terraform 版本 1.6。
第一轮：手动操作
我平时自认为控制台操作很熟练，但真计时起来还是被吓到了：
- VPC 向导：4 分钟（向导页面加载慢，还要确认网段不冲突）
- 安全组：6 分钟（加了 3 条规则，每条都要选协议、端口、来源，改错了 1 次又删了重加）
- EC2 × 2：12 分钟（选 AMI 花了时间，还得手动给第二台复制第一台的配置，标签也要一个个敲）
- ALB：9 分钟（要选目标组、配置健康检查，页面上来回跳转）
- Route53：2 分钟
总计：33 分钟纯操作时间，而且中途被打断过两次——这正是手动操作的真实痛点：你不可能一口气点完 30 分钟的页面。
第二轮：Terraform
先写代码。对第一次写这套东西的人来说，查文档和试错花了大约 2 小时。但关键在于：我写完之后，又跑了两遍。
resource "aws_security_group" "web" {
name = "web-sg"
vpc_id = aws_vpc.main.id
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"] # 只允许内网 SSH
}
tags = { Name = "web-sg", Env = "test" }
}
第二遍和第三遍的流程是：
terraform init # 40 秒（首次会慢，之后有缓存）
terraform plan # 15 秒
terraform apply # 确认后执行，操作时间 1 分钟
第二、三遍的纯操作时间：约 1.5 分钟。
那个让我惊喜的瞬间
测试没到此为止。我加了一个变更场景：给两台 EC2 换实例类型，从 t3.medium 换成 t3.large。
- 手动：先停机、改类型、再启动，两台机器来回切换，9 分钟，中间还忘了给第二台改。
- Terraform：改一行
instance_type = "t3.large"，terraform plan明确告诉我"2 to change"，apply 确认，2 分钟。
而 plan 输出的这个差异预览，是手动操作完全给不了的东西：
~ resource "aws_instance" "web" {
~ instance_type = "t3.medium" -> "t3.large"
我踩过的坑
- state 文件管理。第一次我把
terraform.tfstate留在本地，同事的电脑上又跑了一遍 apply，直接状态错乱。必须一开始就配远程后端：
terraform {
backend "s3" {
bucket = "my-tfstate"
key = "test-env/terraform.tfstate"
dynamodb_table = "tf-locks"
}
}
手动改动会导致漂移。Terraform 管起来之后，有人在控制台偷偷改了安全组，下次 apply 会把它改回去。这其实是好事，但要提前跟团队约定：控制台只读，改动一律走代码。
import 历史资源很痛苦。我们把存量资源导入 Terraform 时，
import块写漏了字段，plan 里出现大量"will be destroyed"，差点酿成事故。现在我的习惯是：import 之后先看 plan，确认显示的全是更新而不是删除，才敢 apply。
效率结论
| 场景 | 手动 | Terraform |
|---|---|---|
| 首次搭建 | 33 分钟 | 2 小时（含学习） |
| 重复搭建第 N 遍 | 33 分钟 | 1.5 分钟 |
| 小变更（改实例类型） | 9 分钟 | 2 分钟 |
| 删除整套环境 | 20+ 分钟，容易漏 | terraform destroy，1 分钟 |
| 新人接手 | 依赖口口相传 | 读代码即可 |
转折点在“第二次”。 如果你的环境只搭一次、再也不动，手动确实更快。但真实项目里环境会被反复搭建：测试、预发、多区域、灾备演练。Terraform 的一次投入换来了近乎零成本的复制。
实用建议
- 从安全组和标签这类低风险资源开始，别一上来就管数据库。
- 强制使用远程 state + 锁，s3 + dynamodb 是 AWS 上的标准组合。
- 在 CI 里跑
terraform plan，让每次变更都有记录可查——这直接解决了开头那个事故。 - plan 输出必须人工审阅，看到 destroy 字样先停下来想清楚。
诚实的局限
Terraform 不是银弹。学习曲线是真的：state 机制、模块组织、版本兼容性，新手至少要一两周才能安心使用。有些冷门服务 provider 支持滞后，还得靠控制台兜底。另外 plan/apply 的执行速度也不快，大规模变更时等待时间不短。
但哪怕只算“环境可重建、变更有记录、新人可接手”这三条，对任何超过两个人的团队来说，Terraform 都值得投入。我现在的判断标准很简单：这个资源坏了能不能 10 分钟内重建？不能的话，就该把它写进代码。