この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
現場で何度聞いたか分からない、定番の一言です。原因を聞くと、たいていの場合「環境が同じだと思い込んでいた」に行き着きます。
正直に白状すると、私も若い頃は「OSのバージョンが同じならだいたい同じだろう」と高を括って、本番で派手に火を吹かせた経験があります。あの時の冷や汗は今でも覚えていて、それ以来、環境差分を疑うクセが身体に染みつきました。
この記事では、20年以上Linuxサーバーを運用してきた経験から、環境差分で事故るエンジニアが見落としている3つの観点と、開発と本番の違いを日常的に意識する習慣を解説します。コマンド解説ではなく、現場で繰り返し使える思考の型としてまとめました。
この記事のポイント
・本番で落ちる原因の8割は「環境が同じはず」という思い込み
・OSバージョン・パッケージ・カーネルパラメータの3層を比較する
・差分を見える化する習慣がトラブル対応速度を一段引き上げる
・環境差分を意識できる人ほど現場で信頼される運用者になれる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ「開発で動いたから本番でも動く」という発想が事故を呼ぶのか
ここが一番の落とし穴です。依頼者やチームメンバーが「動作確認しました」と言ってきた時、ベテランほどそのまま鵜呑みにしません。理由は単純で、開発と本番では「同じに見えて違う部分」が必ず存在するからです。
私が受講生からよく聞かれる質問が、「同じディストリビューションを入れているのに、なぜ挙動が変わるんですか？」というものです。気持ちはよく分かります。CentOS Stream 9を開発と本番に入れた、それで終わりだと思いたい。でも実際には、マイナーバージョンが違ったり、片方だけセキュリティパッチが当たっていたり、カーネルパラメータが本番だけチューニングされていたりします。
環境差分の事故は、たいてい「同じはずだったのに」から始まります。だからこそ、最初に疑うのは現象ではなく、本当に環境が同じなのかという前提のほうです。
環境差分で事故るエンジニアが見落としている3つの観点
順番に意味があります。上から順に確認することで、原因の層が自然に絞れます。1. OSのマイナーバージョンとパッチレベルの差
最初に必ず見るのは、OSのバージョン情報です。メジャーバージョンだけ揃えて満足してはいけません。# check os version (minor release) $ cat /etc/os-release NAME="Rocky Linux" VERSION="9.4 (Blue Onyx)" ID="rocky" VERSION_ID="9.4" # カーネルバージョンも忘れずに確認 $ uname -r 5.14.0-427.42.1.el9_4.x86_64
私が現場でよく見かけるのが、開発環境は9.4のまま、本番だけdnf updateで9.5に上がっていたというパターンです。マイナーバージョンが1つ違うだけでも、glibcやopensslの細かい挙動が変わり、アプリのリンクエラーや暗号化通信のハンドシェイク失敗が起きます。
特に注意したいのは、本番だけが先に更新されるケースは少なく、たいてい本番のほうが古いまま放置されている逆パターンです。「開発で最新パッケージを入れて動いたから本番に持っていったら依存関係が解けない」という事故は、毎月のように耳にします。
2. インストール済みパッケージとそのバージョンの差
OSが揃っていても、入っているパッケージは別物です。# インストール済みパッケージ一覧をバージョン付きで取得 $ rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort > /tmp/pkglist_dev.txt # 本番側でも同じファイルを取得しておき、diffで突き合わせる $ diff /tmp/pkglist_dev.txt /tmp/pkglist_prod.txt
ここで頻出するのが、開発環境にだけ便利系のツール（vim-enhanced、tree、jqなど）が入っていて、本番にはminimalで入れたデフォルトパッケージしかないケースです。シェルスクリプトの中でjqを使っていて、本番でだけ「command not found」が出る。これは典型的な環境差分事故です。
・同じパッケージ名でもバージョンが違う：マイナーバージョンの差で挙動が変わる
・片方だけにしか入っていない：スクリプトやアプリが暗黙に依存している
・外部リポジトリ経由で入っている：EPELやRemiの有無で大きく違う
本番でしか起きない問題は、ほぼこの3パターンに収まります。
3. カーネルパラメータとリソース上限の差
3つ目はカーネルパラメータとulimitです。ここを見ない人が本当に多い。# カーネルパラメータの現在値を一覧取得 $ sysctl -a > /tmp/sysctl_dev.txt 2>/dev/null # プロセスごとのリソース上限も確認 $ ulimit -a core file size (blocks, -c) 0 open files (-n) 1024 max user processes (-u) 4096
逆に開発環境はインストール直後の状態のまま、ということが珍しくありません。「開発ではセッションが捌けたのに本番で詰まった」というケースの多くは、ulimit -nの上限差で説明できます。
私のセミナーでは、新しい本番サーバーを構築したらまずsysctl -aとulimit -aの出力をファイルに残し、開発環境にも同じ設定を反映するよう徹底してもらっています。これだけで「本番で初めて発覚するリソース不足」が劇的に減ります。
差分を見える化する習慣を業務に組み込む
3つの観点を都度思い出すのは現実的ではありません。日常の作業フローに組み込んでしまうのがコツです。私が現場でやっているのは、構築直後に「環境スナップショット」をファイルとして残しておくことです。
# 環境情報を1つのファイルにまとめる簡易スナップショット $ { echo "=== OS ===" cat /etc/os-release echo "=== KERNEL ===" uname -a echo "=== PACKAGES ===" rpm -qa | sort echo "=== SYSCTL ===" sysctl -a 2>/dev/null echo "=== ULIMIT ===" ulimit -a } > /var/log/env-snapshot-$(date +%Y%m%d).txt
さらに、変更を入れる前と後で同じスナップショットを取っておくと、「本番で何かおかしい」と言われた時に「直前の変更で何が変わったのか」を即座に切り分けられます。これは現場で本当に効きます。
受講生に伝えているのは、「環境を見える化していないエンジニアは、何かが起きた時に毎回ゼロから推理することになる」という話です。差分を取れる状態にしておくだけで、トラブル対応の体感速度が一段上がります。
「Permission denied」や「No such file」が本番だけで出た時の対処の型
環境差分を疑う訓練としてよく出くわすのが、本番でだけ権限系のエラーが出るケースです。よくある原因は次の3つに収まります。
・SELinuxが本番だけEnforcingになっている：getenforceで状態確認、ausearchでブロック内容を確認
・実行ユーザーが違う：開発はrootで動かしていて、本番はサービスアカウントで動いている
・ファイルシステムのマウントオプションが違う：本番だけnoexecが付いているなど
ここで重要なのは、エラーメッセージだけを見て「権限を緩めれば解決する」と短絡しないことです。本番だけで起きる権限エラーには、本番側でわざわざ堅くしている理由があります。理由を理解せずに緩めると、セキュリティの意図ごと壊してしまいます。
本番のSELinuxやmountオプションが「なぜそうなっているのか」を理解した上で、開発側の設定を本番に合わせる。順番が逆になると、本番のセキュリティを開発レベルに引き下げる事故になります。
環境差分を意識できる人が現場で重宝される理由
ここまでの話をまとめると、環境差分への感度はそのまま現場での信頼に直結します。| 確認したいこと | コマンド |
|---|---|
| OSのマイナーバージョンを確認する | cat /etc/os-release |
| カーネルバージョンを確認する | uname -r |
| パッケージ一覧をバージョン付きで取得する | rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort |
| 2環境のパッケージ差分を比較する | diff /tmp/pkglist_dev.txt /tmp/pkglist_prod.txt |
| カーネルパラメータの現在値を全件取得する | sysctl -a |
| プロセスごとのリソース上限を確認する | ulimit -a |
| SELinuxの動作モードを確認する | getenforce |
派手なトラブルシュート技術より、地味な確認の積み重ねのほうが、結果的に事故を防ぎます。
環境差分を意識できる人は、本番作業の前に必ず開発環境とのスナップショットを比較し、想定外を潰してから手を動かします。だからこそ、止められないサーバーの作業を任せられる存在になっていきます。
本記事のまとめ
環境差分による事故は、特別な技術ではなく日常の習慣で防げます。・開発と本番が「同じはず」という思い込みが、本番事故の温床になる
・OSのマイナーバージョン、パッケージ、カーネルパラメータの3層を必ず比較する
・環境スナップショットをファイル化し、diffで差分を即座に見える化する
・本番で堅くしてある設定には理由がある。緩める方向で揃えない
・差分を取る習慣がトラブル対応速度を引き上げ、現場の信頼を作る
明日からの作業で、まずは開発と本番のos-releaseとuname -rを並べてみてください。たったそれだけで、潜んでいた差分が見つかることが珍しくありません。差分を見える化する小さな習慣が、止められないサーバーを安心して触れる運用者への第一歩になります。
環境差分で事故らない、現場で通用するサーバー運用の「型」を身につけたいと思いませんか？
OSバージョン、パッケージ、カーネルパラメータ。個別の確認コマンドはネットに転がっていても、「現場でどう積み上げて事故を防ぐか」という運用の型は、なかなか体系化されていません。
断片情報をつなぎ合わせて独学するよりも、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます