インフラ設定をGitで管理していない会社が必ず経験すること

深夜2時、誰も「何を変えたか」知らない

本番サーバーが落ちた。アラートが鳴る。チームのSlackが騒ぎ始める。

最初の質問は決まってこれだ。「最後に何か変えた人いる？」

Aさんは「昨日nginxの設定を少し触った気がする」と言う。Bさんは「今日の午前中にファイアウォールのルールを追加した」と言う。Cさんは「自分は何もしていない」と言う。

どれが原因か、誰にもわからない。設定ファイルを直接サーバーで開いて見比べる。バックアップがあれば良い方で、ないこともある。

この状況に一度でも陥ったことがある人は多いはずだ。

---

Cloudflareでさえ「設定変更の差分ミス」で落ちた

2022年6月21日、世界最大のCDN企業であるCloudflareが大規模な障害を起こした。

原因はBGPルーティングポリシーの設定変更。コードにするとこういう差分だった。

[edit policy-options policy-statement AGGREGATES-OUT]
term 6-DISABLED_PREFIXES { ... }
!    term 6-ADV-TRAFFIC-PREDICTOR { ... }
!    term 4-ADV-TRAFFIC-PREDICTOR { ... }
!    term ADV-FREE { ... }
...

一見、ほかの設定変更と同じに見える。しかしこのtermの並び順に問題があり、本来広告されるべきIPプレフィックスが「取り下げ」られた。

結果: 19拠点が同時にオフライン。全グローバルトラフィックの50%が消えた。

Cloudflareはこのとき、変更申請チケットの作成・ドライランの実施・複数エンジニアによるピアレビューを実施していた。それでも起きた。

さらに深刻だったのが復旧作業だ。Cloudflareの事後報告にはこう書かれている。

“network engineers walked over each other’s changes, reverting the previous reverts, causing the problem to re-appear sporadically.”

（ネットワークエンジニアたちが互いの変更を上書きし合い、以前のリバートをさらにリバートしてしまったため、問題が断続的に再発した）

設定変更を「誰が今何を触っているか」を把握する仕組みがなければ、復旧中に別のエンジニアが同じ設定を逆方向に戻してしまう。Cloudflareほどの組織でも、この問題から逃げられない。

障害発生から完全復旧まで: 1時間15分。

---

Gitがあれば何が変わるのか

Gitはバージョン管理システムだ。ファイルの変更履歴を「誰が・いつ・なぜ変えたか」とともに記録し続ける。

インフラ設定にGitを使うと、具体的に何が変わるか。

1. 変更履歴が永続的に残る

git log --oneline nginx.conf

a3f2b1c  2026-06-25 yamada  本番DBへの接続タイムアウトを30sに延長
d891e4f  2026-06-20 tanaka  SSLの証明書更新に伴いssl_certificate_keyのパスを修正
7c3a091  2026-06-15 suzuki  gzip圧縮を有効化

「最後に何を変えたか」を聞き回る必要がなくなる。

2. 差分が一目でわかる

git diff HEAD~1 nginx.conf

- keepalive_timeout  65;
+ keepalive_timeout  120;

バックアップファイルを手動で比較する作業がなくなる。Cloudflareの障害も、差分の目視確認でtermの並び順の問題に気づくのが難しかったことが一因だった。

3. 以前の状態に戻せる

git revert a3f2b1c

タイムアウト設定を変更する前の状態に、コマンド1行で戻せる。「どのファイルをどこに戻せばいいかわからない」という状況がなくなる。

4. 変更を本番適用前にレビューできる

GitHubのPull Request機能を使えば、設定変更を本番に適用する前にチームメンバーが確認できる。Cloudflareがやっていた「ピアレビュー」をより確実な形で実施できる。

---

よくある反論

「設定ファイルは数個しかない。管理するほどでもない」

1個でも変更履歴が消えた瞬間に障害の原因調査が詰まる。量の問題ではない。

「Gitは開発者のツールで、インフラ担当には難しい」

基本的な使い方（add・commit・log・diff）は30分で覚えられる。難しいのはブランチ戦略や高度なマージ操作で、それは最初は不要だ。

「本番サーバーに直接入って直すことが多い。Gitでは対応しきれない」

緊急時は直接変更して問題ない。ただし変更後に git add して git commit -m "緊急: ポート8080を一時開放" とコメントを残す習慣をつけるだけで十分だ。

---

どこから始めるか

全部を一度にGit管理する必要はない。まず1ファイルから。

優先度	対象ファイル
高	nginx.conf / httpd.conf
高	firewall ルール（ufw / iptables）
中	/etc/hosts
中	crontab
低	.htaccess

ローカルのMacで git init → ファイルをコピーして git add → git commit するだけで始まる。GitHubへのpushはその後でいい。

---

まとめ

設定管理にGitを使わない理由として「面倒」「必要ない」という声をよく聞く。しかし実際に障害が起きたとき、最初にほしいのは「いつ・誰が・何を変えたか」の記録だ。

Cloudflareほどの組織が、設定変更の差分ミスと復旧時の上書き問題で1時間以上サービスを止めた。規模が小さい組織が同じ問題を抱えても、復旧にかかる時間は長くなる傾向がある。専任のインフラチームがいないからだ。

変更履歴は、つけ始めた瞬間から価値が生まれる。