Terraformで本番環境を壊しかけた3つのミスと、今でも使っている防止策

Terraformは怖い、という感覚は正しい

Terraformを使い始めたころ、「コードでインフラを管理できる」という体験が単純に楽しかった。
EC2を1行で増やせて、VPCをコードとして保存できる。
最初はステージング環境でしか触らなかったので、ミスしても「もう一回 apply すればいいか」で済んでいた。

本番環境に初めて触ったのは入社から4ヶ月後。
先輩から「これ、本番に適用してみて」と言われた軽い感じのタスクで、ほぼ死にかけた。

結果的には被害を最小限に抑えられたが、その後も2回ほど「やばかった」と思う場面があった。
計3回の経験から得た防止策を、実際に今も使い続けている形でまとめる。

ミス1: plan の出力をちゃんと読まなかった

最初のミスは典型的なやつだった。
EC2のセキュリティグループにルールを追加するだけのはずが、plan の出力をざっと眺めて「まあ問題なさそう」と apply したら、既存のルールが全部消えた。

原因は aws_security_group_rule と aws_security_group の混在だった。
既存のリソースは ingress ブロックを security group 内に直書きしていたのに、私が追加したのは aws_security_group_rule リソース。
Terraform は「既存の ingress ルールは管理対象外になった」と判断して、destroy しようとしていた。
それが plan の出力に書いてあったのに、私は + が増えたことしか確認していなかった。

# terraform plan の出力（一部）
-/+ aws_security_group.main (replaced due to conflict)
　・ingress { ... }  # ← これに気づかなかった
+ aws_security_group_rule.new_rule

幸い、apply 直後に接続が切れたことでアラートが飛んで、5分以内にロールバックできた。
でもこれは運が良かっただけで、アラートの閾値がもう少し甘ければ気づくのに30分かかっていた。

plan の読み方で学んだことが一つある。-/+（置き換え）と -（削除）の行だけを先に全部確認する、というルールを自分に課すようにした。
増える変更は基本的に安全だが、消える変更は何かが壊れる可能性がある。
plan が100行あっても、最初に grep で - を探すだけで8割のリスクは検出できる。

# plan の削除・置き換えだけ先に確認するワンライナー
terraform plan -out=tfplan 2>&1 | grep -E '^\s*([-]|\-/\+)' | head -50

これを習慣にしてから、想定外の削除に事前に気づけるようになった。
plan を流してから apply まで2分かかるようになったが、そのくらいの時間は払う価値がある。

ミス2: tfstate を手動で触った

2回目のミスは、ステージングと本番でリソースを分離するリファクタリング中に起きた。
既存の tfstate に入っているリソースを別の module に移したくて、terraform state mv コマンドを使った。
手順書通りに進めていたつもりが、コマンドを一つ間違えて本番のリソースを state から消した。

Terraform の state からリソースを消しても、実際のインフラは消えない。
ただ、「Terraform の管理外になる」ということが問題だった。
次の apply で Terraform が「このリソースは存在しないから作る」と判断して、既存の RDS インスタンスと同名のリソースを作ろうとした。
当然エラーになったが、設定によっては既存リソースを上書きしようとする動作もあり得る。
焦った。

# 間違えた操作（やってしまったこと）
terraform state mv module.old.aws_db_instance.main module.new.aws_db_instance.main
# module名を1文字間違えて別のリソースを操作してしまった

# 正しい手順
terraform state list | grep db_instance  # まず一覧で確認
terraform state show module.old.aws_db_instance.main  # 対象リソースの詳細を目視してから mv

この経験から、tfstate を操作する前には必ず state list と state show で対象を目視確認するようにした。
コマンドをそのまま実行するのではなく、確認ステップを1つ挟む。

それと、tfstate は S3 + DynamoDB でリモート管理するのが前提のプロジェクトが多いと思うが、操作前に手動でバックアップを取る習慣もつけた。
S3 のバージョニングで自動的に残るとはいえ、「自分が手を加える前の状態」を明示的に保存しておくと、失敗した時に戻りやすい。
このひと手間を省かない、というのが3年経った今でも守っているルールだ。

ミス3: workspace を間違えた状態で destroy した

3回目が一番ヒヤッとした。
terraform workspace を使って staging と production を分けていたプロジェクトで、cleanup 作業としていらなくなったリソースを destroy しようとした。
workspace の確認を怠ったまま destroy を実行して、途中で気づいて止めた。

# やってしまった操作の再現
terraform workspace list
# * default
#   staging
#   production

terraform workspace select staging  # ← 選んだつもり
# （実際には選択コマンドが失敗していた）

terraform destroy -target=aws_lambda_function.batch_job
# production で実行してしまった

Lambda 関数1つが本番から消えた。
ちょうどバッチ処理の実行タイミングとずれていたので被害はなかったが、5分ずれていたら確実にアラートが鳴っていた。

destroy コマンドは今では必ず terraform workspace show でワークスペースを表示させてから実行するようにしている。
コマンド1行で済むので省略しがちだが、この確認を Makefile に組み込んでルール化した。

3つのミスに共通している防止策

振り返ると、3つのミス全部に共通する問題がある。
「手を動かす前の確認が足りなかった」という一点につきる。
plan を読む、state を確認する、workspace を表示する。
どれも手間は10秒以内なのに、「わかってる」という慢心で省略していた。

今チームで使っている Makefile の一部を載せておく。
apply や destroy の前に確認ステップを強制するようにしている。

# Makefile（一部抜粋）
.PHONY: plan apply destroy

plan:
	@echo "Current workspace: $$(terraform workspace show)"
	terraform plan -out=tfplan

apply: plan
	@echo "--- 削除・置き換え対象のリソース ---"
	terraform show -json tfplan | jq '.resource_changes[] | select(.change.actions[] | contains("delete","replace")) | .address'
	@read -p "上記を確認しました。続けますか？ [y/N]: " confirm && [ "$$confirm" = "y" ]
	terraform apply tfplan

destroy:
	@echo "Current workspace: $$(terraform workspace show)"
	@read -p "Workspaceを確認しました。destroyを続けますか？ [y/N]: " confirm && [ "$$confirm" = "y" ]
	terraform destroy

これに加えて、本番への apply は CI/CD 経由に限定して、手元からの直接 apply を禁止するルールも導入した。
GitHub Actions で PR がマージされたら自動で plan を走らせ、レビューを通過したものだけ apply する形にしている。
これで「うっかり本番に手動 apply する」ミスはほぼゼロになった。
チームが3人の時点でこの仕組みを入れたが、早すぎることはなかった。

Terraform の怖さに慣れないほうがいい

本番 Terraform を触り続けて感じるのは、慣れてきたころが一番危ないということだ。
操作が手になじんできて、確認ステップを省略したくなる。
その油断が一番リスクを高める。

3つのミスは全部、「この程度なら大丈夫」という感覚で確認をスキップしたときに起きた。
今でも本番の apply 前には1分だけ立ち止まる時間を取るようにしている。
plan の削除行を確認して、workspace を確認して、ターゲットのリソースが想定通りかを確認する。
たったそれだけで、これまでミスは再現していない。

具体的にやることをまとめると、

• plan 後に削除・置き換え行だけ先に確認する

• tfstate 操作前は list と show で対象を目視確認する

• destroy 前は workspace show を必ず実行する

• 本番 apply は CI/CD 経由に限定する

この4つを守るだけで、壊しかけた3回のうち2回は確実に防げていた。
残り1回は CI/CD を導入する前だったので、今なら発生しないはずだ。

Terraform は強力なツールだからこそ、使い方より先に「止まり方」を学ぶべきだと思っている。
慌てた状態での apply と destroy がインシデントの9割を作る、という体感がある。
次にコマンドを打つ前に、まず plan と workspace show を実行する。
それだけで本番を守れる確率はかなり上がる。