本番・検証・開発の3つの環境は、何のために分けているのか。現場に入る前に知っておきたい環境の使い分け

こんにちは、インフラエンジニアのryuです。

インフラエンジニアとして現場に入ると、最初のうちによく聞く言葉があります。

「それ、まず検証環境でやってみて」「本番は来週の作業で触ります」といった会話です。

同じシステムなのに、なぜ「検証」と「本番」があるのでしょうか？

独学でサーバーを1台立てて勉強していると、環境が1つしかないのが普通なので、この感覚はなかなかつかめません。

この記事では、現場でよく使われる開発環境・検証環境・本番環境の3つについて、何のために分けているのか、それぞれでどんな作業をするのかを整理していきます。

開発・検証・本番環境とは？¶

まずは、それぞれの環境がどんなものかを見ていきます。

呼び方は会社やプロジェクトによって少しずつ違いますが、多くの現場では次の3つに分けています。

本番環境：実際のユーザーや業務が使っているシステムが動いている環境。ここが止まると、サービスや業務が止まる。

検証環境と本番環境の間に、もう1つ受け入れテスト用の環境（UAT環境などと呼ばれます）を置く現場もあります。逆に、小さなシステムでは開発と検証を1つにまとめていることもあります。

数は現場によって違いますが、考え方は同じです。本番に近づくほど、自由に触れなくなっていくと覚えておけば大丈夫です。

開発環境は「壊してもいい場所」¶

開発環境は、新しい設定やプログラムを作りながら試すための環境です。

ここでは、設定を何度も書き換えたり、サーバーを作り直したりするのが当たり前です。失敗しても困る人がほとんどいないので、いろいろ試せます。

その代わり、本番と同じ構成になっているとは限りません。サーバーの台数が少なかったり、性能の低いマシンを使っていたりすることがよくあります。

検証環境は「本番の予行演習をする場所」¶

検証環境は、本番に入れる前の最終確認をする環境です。

本番とできるだけ同じOS、同じミドルウェアのバージョン、同じ設定にしておき、作業手順を実際に流して問題がないかを確かめます。

インフラエンジニアにとっては、ここがいちばん大事な環境と言ってもいいかもしれません。本番作業の手順書は、検証環境で一度通してから使うのが基本だからです。

なぜ環境を分けるのか？¶

では、なぜわざわざ環境を分けるのでしょうか？

理由はシンプルで、本番環境で失敗すると、困る人がたくさん出るからです。

理由1：本番で初めて試すのは危ないから¶

設定を変えたり、パッチを当てたりする作業には、いつも失敗の可能性があります。

設定ファイルの書き間違いでWebサーバーが起動しなくなる、アップデートでミドルウェアの動きが変わる、といったことは珍しくありません。

これを本番でいきなりやると、失敗したその瞬間にユーザーがサービスを使えなくなります。だから先に別の環境で試して、問題が出ないことを確かめてから本番に入れるわけです。

AWSのベストプラクティスをまとめたWell-Architectedフレームワークでも、複数の環境を用意し、本番に近づくほど管理を厳しくすることが推奨されています。

理由2：本番のデータと権限を守るため¶

本番環境には、お客さまの個人情報や取引のデータなど、本物のデータが入っています。

開発中のプログラムや、作業中の人が誤ってこのデータを消したり書き換えたりしたら大変です。そのため、本番環境に入れる人や操作できる範囲は、ほかの環境よりずっと絞られています。

同じ理由で、検証環境や開発環境には本番のデータをそのままコピーしないのが基本です。

テストに使うデータは、ダミーで作ったものや、氏名や電話番号などを別の値に置き換えたものを使います。本番のデータを使わないと再現できない不具合を調べるときでも、扱える人や場所を決めたうえで慎重に扱います。

検証環境は本番環境より守りが緩いことが多いので、そこに本物の個人情報を置くと、情報漏えいの入り口になりかねないからです。

AWSでは、環境ごとにAWSアカウント自体を分けることも推奨されています。アカウントが別なら、開発環境で何かを間違えても本番環境には影響が届きにくくなるからです。

理由3：作業の手順と結果を確かめるため¶

もう1つ見落とされがちな理由があります。それは、作業の手順そのものを確かめることです。

本番作業では、手順書どおりに作業して、終わったら正しく動いているかを確認します。この手順が正しいかどうかは、実際に流してみないと分かりません。

検証環境で手順書を流してみると、「このコマンドの前にサービスを止める必要があった」「確認のコマンドが足りなかった」といった抜けに気づけます。手順書の読み方や事前に確かめることについては、その手順書、そのまま実行して大丈夫ですか？ で詳しく書いています。

「検証では動いたのに本番で動かない」はなぜ起きる？¶

環境を分けていても、検証環境では問題なかったのに本番で失敗する、ということは起きます。

これは、検証環境と本番環境が、実は完全には同じではないからです。

アプリ開発の設計方針としてよく知られる「The Twelve-Factor App」では、開発と本番の差をできるだけ小さく保つことが勧められています。差がある場所に、本番だけのトラブルが潜んでいるからです。

インフラの現場でよくある差を、表にまとめてみます。

どれも、手順そのものは正しかったのに、環境の違いのせいで失敗するパターンです。

設定値の違いはパラメータシートで管理する¶

環境ごとに違う値は、ホスト名、IPアドレス、接続先、台数などたくさんあります。

これを人の記憶に頼っていると、どこかで必ず取り違えます。そのため現場では、環境ごとの設定値を「パラメータシート」という表にまとめて管理していることが多いです。

パラメータシートの読み方は、パラメータシートの読み方 で解説しています。検証と本番で値が違う行に印をつけておくだけでも、取り違えはかなり減らせます。

今どの環境にいるかを必ず確かめる¶

もう1つ大事なのが、作業している画面がどの環境なのかを確かめることです。

ターミナルを何枚も開いていると、検証環境のつもりで本番のサーバーにコマンドを打ってしまう、という事故が起きます。

作業前には、次のようなコマンドで接続先を確かめる習慣をつけておきましょう。

# 今ログインしているサーバーのホスト名
hostname

# IPアドレスを確認する
ip -brief address

# 誰としてログインしているか
whoami

現場によっては、本番サーバーだけプロンプトの色を赤くしたり、ホスト名に prd や stg を入れたりして、ひと目で分かるようにしています。

たとえば、~/.bashrc に次のような設定を入れておくと、本番サーバーのプロンプトに目立つ表示を出せます。

# 本番サーバーだけ、プロンプトを赤字にして [PROD] と表示する
PS1='\[\e[1;31m\][PROD]\[\e[0m\] \u@\h:\w\$ '

自分がどこで作業していたかをあとから説明できるように、作業ログを残しておくのも大切です。やり方は 作業ログ（証跡）の残し方 にまとめています。

本番環境での作業はどんな流れで進むのか？¶

環境を分ける意味が分かったところで、本番環境での作業が実際にどう進むのかも見ておきましょう。

開発環境なら思いついたときに設定を変えられますが、本番環境ではそうはいきません。多くの現場では、だいたい次のような流れを踏みます。

新人のうちは、この流れの重さに驚くかもしれません。設定ファイルを1行変えるだけなのに、申請書を書いて、夜間に作業する、ということもよくあります。

でもこれは、本番環境が止まったときの影響がそれだけ大きいからです。

作業する時間帯が決まっている¶

本番環境の作業は、ユーザーへの影響が少ない時間帯に行うのが一般的です。

業務システムなら平日の夜や土日、ECサイトのように夜も使われるサービスなら、アクセスの少ない深夜や早朝が選ばれます。こうした作業用の時間帯は、メンテナンスウィンドウと呼ばれることもあります。

時間が決まっているので、検証環境で「この作業は何分かかるか」を測っておくことも大事です。時間内に終わらない作業は、そもそも本番で始められません。

切り戻しの手順も検証しておく¶

もう1つ、本番作業で必ず用意するのが切り戻し（元に戻す）の手順です。

どれだけ検証していても、本番で想定外のことは起きます。そのときに、作業前の状態にすばやく戻せるかどうかで、障害の長さが大きく変わります。

切り戻しの手順も、検証環境で実際に試しておくのが理想です。設定ファイルのバックアップから戻す、パッケージを前のバージョンに戻す、といった操作が本当に動くかは、やってみないと分かりません。

なお、設定を元に戻せることと、データを守れることは別の話です。この違いについては、冗長化とバックアップの違い で整理しています。

未経験のうちから環境を分ける感覚を身につけるには？¶

ここまで読んで、「独学だと環境は1つしかないから、練習しようがない」と思った方もいるかもしれません。

でも、規模を小さくすれば、個人の学習でも同じ考え方を試せます。

練習用のサーバーを2つ用意してみる¶

おすすめは、仮想マシンやクラウドのサーバーを2台用意して、片方を検証、片方を本番に見立てる方法です。

たとえば、Webサーバーの設定を変えるときに、次の流れで進めてみます。

1. 検証用のサーバーで設定を変えて、動作を確認する
2. 実行したコマンドを手順書にまとめる
3. その手順書だけを見て、本番用のサーバーに同じ設定を入れる
4. 最後に、2台の設定ファイルに差がないかを比べる

2台の設定ファイルを比べるときは、diff コマンドが使えます。

# 2台の設定ファイルを取ってきて差分を見る
scp stg-web:/etc/nginx/nginx.conf ./stg-nginx.conf
scp prd-web:/etc/nginx/nginx.conf ./prd-nginx.conf
diff -u stg-nginx.conf prd-nginx.conf

これをやってみると、手順書に書き忘れたコマンドや、検証の途中で手で直したまま記録していなかった設定に気づくはずです。現場の「検証では動いたのに」の多くは、まさにこういう抜けから起きています。

学習用の環境の作り方は、自宅で作るインフラ学習ラボ を参考にしてください。

クラウドならアカウントやタグで分けてみる¶

AWSで練習しているなら、リソースに Environment=stg や Environment=prd といったタグを付けて区別してみるのもよい練習になります。

実際の現場では、環境ごとにAWSアカウントを分け、AWS Organizationsでまとめて管理する形が多く使われています。いきなりそこまでやる必要はありませんが、なぜアカウントを分けるのかを知っておくと、現場の構成図を見たときに理解が早くなります。

まとめ¶

開発・検証・本番の3つの環境は、本番で失敗しないために分けられています。

開発環境は試すための場所、検証環境は本番の予行演習をする場所、本番環境は実際のユーザーが使う場所です。本番に近づくほど、触れる人も操作も絞られていきます。

それでも「検証では動いたのに本番で動かない」が起きるのは、環境の間に差があるからです。台数、データ量、ネットワーク、バージョン、設定値の違いを意識して、作業前には今どの環境にいるかを必ず確かめましょう。

この感覚は、現場に入ってから身につけることもできます。ですが、学習の段階から2台のサーバーで検証と本番を分けて練習しておくと、最初の本番作業で落ち着いて動けるようになります。

InfraAcademyでは、Linuxのサーバー構築から手順を確かめながら進める練習まで、順番に学べるようにしています。何から手をつけるか迷っている方は、Linuxロードマップ や AWSロードマップ から始めてみてください。

まずは検証用と本番用の2台を用意して、同じ設定を手順書どおりに入れるところから試してみましょう。

参考¶

• OPS05-BP08 Use multiple environments（AWS Well-Architected Framework）
• SEC01-BP01 Separate workloads using accounts（AWS Well-Architected Framework）
• Benefits of using multiple AWS accounts（AWS Whitepaper）
• X. Dev/prod parity（The Twelve-Factor App）