この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「設定ファイルを上書きしてサービスが止まった」「パーミッションを変えたらログインできなくなった」。Linuxを触っていれば、誰でも一度は冷や汗をかく場面に遭遇します。
Linuxサーバーを触り始めた頃、「なぜ動いているのかよく分からないまま管理している」という感覚を持ったことはありませんか。コマンドを打つたびに「本当にこれで合っているのか」「何かを壊してしまうのではないか」という不安がつきまとう——いわば「借り物を触っているような感覚」です。その感覚を突き破るきっかけになるのが、実は「失敗の経験」なのです。
この記事では、20年近くLinuxサーバーを運用し、3,100名以上のエンジニアを指導してきた経験から、私自身がサーバーを「壊した」トラブル体験と、そこから得た5つの教訓をお伝えします。
この記事のポイント
・Linuxサーバーを壊した経験が成長の転機になる理由
・現役講師がSE時代に経験した5つのトラブルと具体的な教訓
・失敗を「次に活かす」ための3つの実践的な習慣
・検証環境で安全に失敗を積み重ねる方法
・本番サーバー変更前に必ず確認すべきチェックリスト
・「借り物感」が消えてサーバーを「自分のもの」として管理できるようになる転換点
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
失敗した人だけが手に入れるスキルがある
セミナーで3,100名以上を指導してきた中で、成長が速い人に共通するポイントがあります。それは「過去にサーバーを壊した経験がある」ことです。意外に思うかもしれません。でも、これは事実です。
教科書を100回読むより、一度の障害対応で学ぶことのほうが圧倒的に多い。なぜなら、障害が起きた瞬間は「二度と同じことを繰り返したくない」という強烈な感情が伴うからです。感情を伴った記憶は定着します。インシデントが起きた日時、自分の手が震えていたこと、上司に電話をかけた時刻——細部まで鮮明に残る。それが「使える技術」に変わります。
逆に、失敗を一度も経験していない人は、どこかで大きな事故を起こすリスクを抱えています。小さな失敗を早い段階で経験し、そこから学ぶ。この積み重ねが、現場で信頼されるエンジニアを作ります。
ここにはもう一つの側面があります。Linuxサーバーの管理を始めた頃、「なぜ動いているのかよく分からないまま、とにかくサービスを動かしている」という感覚を持ったことはないでしょうか。設定ファイルの意味も半分しか理解できていないのに、サービスは動いている——いわば「借り物を触っている感覚」です。管理者として存在しているのに、責任の実感が持てない状態。
この「借り物感」が消えるのは、教科書の知識が増えた時ではありません。自分の手でトラブルを発見し、夜中に冷や汗をかきながら解決した時です。「このサーバーは自分が守っている」という実感は、失敗と向き合った先にしかない。だからこそ、失敗した人だけが手に入れるスキルがあると私は考えます。
現場の先輩エンジニアに「サーバーを壊したことはありますか?」と聞いてみてください。たいてい「ある、それも何度も」と苦笑いしながら教えてくれます。経験値というのは、そういう「傷跡」の数で測られる面があります。怖がらずに検証環境で失敗を重ねた人ほど、本番で冷静に動けるのです。
SE時代に経験した5つのトラブルと教訓
私がSE時代（2001年～2006年）に実際に経験したトラブルを、そのまま紹介します。どれも当時は本当に焦りましたが、今振り返ると全てが貴重な学びでした。1. iptablesの設定ミスでリモート接続を遮断した
入社して間もない頃、ファイアウォールの設定変更を任されました。iptablesのルールを追加する際、既存のルールを確認せずにINPUTチェインのデフォルトポリシーをDROPに変更してしまったのです。# 当時の私がやってしまったこと（絶対に真似しないでください） # iptables -P INPUT DROP # SSH接続用のルールを追加する「前に」デフォルトをDROPにした # → 自分自身のSSH接続も即座に切断された
今ならこうします。まずiptables-saveで現状をバックアップし、SSH許可ルール（ACCEPT）が確実に設定されていることを確認してからポリシーを変更します。さらに安全策として、「n分後にルールをリセットするcronジョブ」を一時的に仕込む方法も有効です。万が一自分を締め出しても、cronが元に戻してくれます。
# 安全な変更手順（現在実践している方法） # ① 現状をバックアップする $ iptables-save > /root/iptables_backup_$(date +%Y%m%d%H%M%S).rules # ② 保険のcronジョブを仕込む（10分後にルールをリセット） # at コマンドが使える環境では at now + 10 minutes も有効 $ echo "iptables-restore < /root/iptables_backup_$(ls -t /root/iptables_backup_*.rules | head -1)" | at now + 10 minutes # ③ SSH許可ルールを先に追加してからDEFAULT POLICYを変更する $ iptables -A INPUT -p tcp --dport 22 -j ACCEPT $ iptables -P INPUT DROP
2. dfコマンドを見ていなくてディスクが100%になった
お客様のWebサーバーを運用していた時のことです。ある月曜の朝、「サイトが表示されない」と連絡を受けました。原因は、ログファイルが肥大化してディスク使用率が100%に達していたことでした。ディスクが満杯になると、サービスは突然かつ静かに止まります。エラーメッセージはサービスのログに吐き出されますが、サーバー自体は「生きている」——だからこそ最初は原因が分かりにくい。Apacheの場合、こんなエラーがログに大量に出るパターンが典型的です。
# ディスクフルが原因のApacheエラー（例） [error] (28)No space left on device: Could not write to error log file # ディスク使用状況の確認 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 20G 20G 0 100% / # どのディレクトリが容量を圧迫しているかを大まかに調べる $ du -sh /* 2>/dev/null | sort -rh | head -10 8.5G /var 3.2G /usr 1.1G /home # /var の中をさらに絞り込む $ du -sh /var/log/* | sort -rh | head -10 3.2G /var/log/httpd/access_log 1.8G /var/log/httpd/error_log
アプリケーションによっては /tmp（一時ファイル置き場）に巨大なキャッシュを吐き出すケースもあります。
du -sh /* 2>/dev/null | sort -rh でルートパーティション配下のディレクトリを一覧すると、どこが膨らんでいるか一目で分かります。問題のディレクトリが特定できたら、さらに一段階掘り下げて絞り込む——これが「ディスクフル調査の基本動作」です。この事故以来、サーバーを構築したら最初にlogrotateの動作を確認し、ディスク監視の自動化を必ず設定するようにしています。特に自分でソースインストールしたサービスのログは、パッケージ管理ツールが面倒を見てくれないため、
/etc/logrotate.d/ に設定ファイルを必ず追加します。# /etc/logrotate.d/httpd-custom の例 /var/log/httpd/custom_access.log { daily rotate 14 compress missingok notifempty sharedscripts postrotate /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2>/dev/null || true endscript }
rotate 14 は14世代分を保持する設定、compress で古いログをgz圧縮します。これを入れておくだけで、ディスクを静かに食い続けるログの問題をほぼ防げます。ディスクの監視はcronで定期的にdf -hの結果をチェックするだけでも十分です。80%を超えたらメールで通知するスクリプトを入れておけば、月曜の朝に「サイトが見えない」という連絡を受けずに済みます。
教訓：ディスク容量の監視は「仕組み」で行う。人間の記憶に頼ると必ず見落とす。dfコマンドの定期実行と閾値アラートは、サーバー構築直後に設定すること。原因調査は「df → du /* → du サブディレクトリ」の順で段階的に絞り込む。logrotateの設定確認も構築直後の必須作業に加えること。
3. chmodで再帰的にパーミッションを壊した
テスト環境だと思って実行したchmod -Rが、実は本番環境だった。これは本当に血の気が引きました。# 私がやってしまったコマンド # chmod -R 777 /etc/ # /etcディレクトリ配下の全ファイルのパーミッションが777に… # /etc/shadow の正しいパーミッション（参考） $ ls -la /etc/shadow ----------. 1 root root 1234 May 30 10:00 /etc/shadow # → 0000 が正常。777 になると sshd も sudo も動かなくなる
【注意】「-R」オプション付きのchmodやchownをシステムディレクトリに実行する際は、カレントディレクトリとコマンドのパスを3回声に出して確認してください。「/etc/」と「./etc/」は全く別のパスです。ターミナルのプロンプトには必ずホスト名を表示する設定にしておくことで、作業対象のサーバーを間違える事故を防げます。
教訓：「-R」オプション付きのコマンドは、実行前に必ずパスを3回確認する。「/etc/」と「./etc/」は全く違う。ターミナルのプロンプトでホスト名を必ず表示する設定にしておくこと。
4. cronジョブの動作を確認せず本番に投入した
バックアップ用のシェルスクリプトをcronに登録した時の失敗です。手動で実行した時は問題なく動いたのに、cronで動かすとエラーになる。原因はPATH環境変数でした。# cron環境ではPATHが限定される # 手動実行で動いても、cronでは以下のようにフルパス指定が必要 # NG例: mysqldump -u root dbname > /backup/db.sql # OK例: /usr/bin/mysqldump -u root dbname > /backup/db.sql # cronのログで実行状況を確認する $ grep CRON /var/log/cron # PATHを明示する方法（cronファイルの先頭に記載） PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
もう一点、見落としがちなのがサーバーの時刻同期です。cronジョブはシステム時刻を基準に動作します。NTP（Network Time Protocol）同期が切れてサーバーの時刻がずれていると、「毎日01:00に実行」のはずのバックアップが実際には別の時刻に動いたり、複数サーバー間でのジョブ連携が時刻のズレで崩れたりします。cronを本番に投入したら、timedatectlでNTP同期状態を確認する習慣をつけてください。
# NTP同期状態の確認（2行とも正常であることを必ず確認する） $ timedatectl System clock synchronized: yes NTP service: active
5. 設定ファイルのバックアップを取らずに上書きした
Apacheの設定を変更する際、httpd.confのバックアップを取らずに直接編集してしまいました。変更箇所が多く、途中でApacheが起動しなくなった時、元の状態に戻せなくなったのです。# 設定変更前のバックアップ（今は必ずやる） $ cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.$(date +%Y%m%d) # 変更後の構文チェック $ httpd -t Syntax OK # さらに安全な方法: /etc を git で管理する $ cd /etc && git init && git add httpd/ && git commit -m "before: httpd config change"
最近では、/etcディレクトリをgitで管理する方法も普及しています。変更のたびにコミットしておけば、どこを変えたかが履歴として残り、切り戻しも1コマンドです。etckeeperというツールを使うと、apt/yumでパッケージをインストールするたびに自動でコミットしてくれます。手動バックアップと組み合わせると、さらに安心です。
教訓：設定ファイルを編集する前に、日付付きのバックアップを必ず取る。これは技術ではなく「習慣」の問題。習慣がなければ、いつか必ず取り返しのつかないミスをする。
失敗を「次に活かす」ための3つの習慣
失敗は、ただ反省するだけでは意味がありません。次に同じ失敗をしないための「仕組み」に落とし込むことが大切です。1. 検証環境で「安全に壊す」練習をする
本番で壊すのは論外ですが、検証環境で意図的に壊すのは最高の学習方法です。私のセミナーでは、受講生に「まず壊してみてください」と伝えることがあります。例えば、検証環境でchmod 000 /etc/passwdを実行するとどうなるか。ログインできなくなる? suコマンドが使えなくなる? 実際に試してみると、教科書で読んだ知識が一気に実感に変わります。
特に効果的な「安全な壊し方」の例を挙げると：
・iptablesのINPUT DROPをやってみて、コンソールから復旧する
・/etc/passwdを意図的に壊してシングルユーザーモードで復旧する
・ディスクを意図的に埋めてサービスがどう落ちるか観察する（
fallocate -l 10G /tmp/dummy で大きなファイルを作れる）・NTP同期を止めて、時刻がどれだけずれるか確認する
・/etc/ssh/sshd_configを1行ずつ読んで各設定の意味を理解し、設定値を変えてSSHの挙動を確かめる（変更前は必ずバックアップを取ること。現在の接続セッションを切らずに別セッションで動作確認してから完了させるのが鉄則だ）
VirtualBoxやWSL2、あるいはKVMで立てた仮想マシンがあれば、壊しても数分でリセットできる環境が手に入ります。失敗のコストがゼロの検証環境で、どんどん壊してください。
壊す練習を始める前に、一つアドバイスがあります。壊す前に「なぜ動いているのか」を自分の言葉で説明できるかを確かめてみてください。設定ファイルを1行読んで「この値がこの動作を決めている」と言えるようになると、壊した後の「なぜ壊れたか」の理解も格段に深まります。
2. 障害対応を「再現手順」まで書き残す
障害が起きた時、「何をしたら直ったか」だけをメモする人が多いのですが、それでは不十分です。「何をしたら壊れたか」を再現手順として書き残すことが重要です。再現手順があれば、次に同じ状況に遭遇した時に「あ、これは前に見たパターンだ」と即座に判断できます。さらに、チーム内で共有すれば、他のメンバーが同じ失敗をするのを防げます。
私が実際に使っている障害記録のフォーマットはシンプルです。
・発生日時：いつ起きたか
・再現手順：何をしたら壊れたか（実行したコマンドをそのまま記載）
・症状：どのようなエラーが出たか
・根本原因：なぜ起きたか
・対処手順：どのコマンドで直したか
・予防策：今後どうすれば防げるか
この6項目を書き残す習慣が、チーム全体のナレッジベースになります。
3. 他人の失敗事例を自分のチェックリストに加える
自分で全ての失敗を経験する必要はありません。先輩や同僚の失敗事例を聞いたら、それを自分のチェックリストに加えてください。私は今でも、サーバーの設定変更前に以下の確認を行っています。
・バックアップ：設定ファイルの日付付きコピーを取ったか
・切り戻し手順：失敗した時に元に戻す手順を書いたか
・影響範囲：この変更で他のサービスに影響が出ないか
・作業環境：本当に作業対象のサーバーにログインしているか
・実行タイミング：利用者が少ない時間帯を選んでいるか
・時刻同期：NTPが正常に動作しているか（timedatectlで確認）
・logrotate：新しく追加したサービスのログローテーション設定が済んでいるか
このチェックリストは、自分の失敗と先輩たちの失敗から作り上げたものです。20年かけて少しずつ項目が増えていきました。
チェックリストと並んで、ぜひ習慣にしてほしいのが「毎朝のサーバー状態確認」です。変更前後の比較でも、障害の予兆発見でも、「昨日と何が違うか」を知っていることが出発点になります。私がセミナーでよくお伝えする「朝一番のコマンドセット」はこの4つです。
# 朝一番の状態確認セット（毎日習慣にする） $ uptime # サーバーの稼働時間と負荷平均 $ df -h # ディスク使用率（80%超えに注意） $ free -h # メモリ使用量（available列を確認） $ tail -20 /var/log/messages # 直近のシステムログ（エラーがないか確認）
さらに一歩進めるなら、週次で自動通知を仕掛けておくことを勧めます。毎週月曜の朝にdf -hの結果をメールで受け取るだけで、「気づいたら80%超えていた」という事態をほぼ防げます。
# crontabの設定例（週次でディスク使用率をメール通知） # 毎週月曜 09:00 にディスク使用率をメール送信 0 9 * * 1 df -h | mail -s "Weekly Disk Report: $(hostname)" root
まとめ
| トラブルの内容 | 得られた教訓 |
|---|---|
| iptablesで自分を締め出した | 許可ルール追加→ポリシー変更の順序を守り、保険のcronジョブも仕込む |
| ディスク100%でサービス停止 | logrotate設定とディスク監視の仕組みを構築直後に完了させる。調査はdf→du/*→サブディレクトリの順で絞り込む |
| chmod -Rでパーミッション破壊 | -Rオプション実行前にパスとホスト名を3回確認する |
| cronジョブが実は動いていなかった | 登録後にログで動作確認。PATHの明示とNTP時刻同期の両方をチェック |
| バックアップなしで設定ファイル上書き | cpコマンドは設定変更前の「呼吸」。/etcのgit管理も有効 |
「失敗が怖くてサーバーを触れない」という方もいるかもしれません。でも、検証環境なら何度壊してもやり直せます。大切なのは、失敗を恐れることではなく、失敗を「記録し、仕組みに変え、二度と繰り返さない」ことです。
そして、その積み重ねの先に「借り物を触っている感覚」が消える瞬間が来ます。「なぜ動いているか」を知り、「今何が起きているか」を日々確認し、「自分が問題を発見した」という経験を積む——それが揃った時に、サーバーが「自分のもの」になります。
まずは検証環境を1つ用意して、今日紹介した5つのトラブルを自分で再現してみてください。ディスクを意図的に埋める、iptablesで自分を遮断してコンソールから復旧する——教科書で読むのとは比べものにならない学びが得られるはずです。
失敗しても大丈夫な環境で、Linuxを基礎から学びたい方へ
「本番で失敗する前に、安全な環境で実力をつけたい」「基礎からやり直したいけど、何から始めればいいか分からない」——そのような悩みは、正しい手順で体系的に学べば必ず解決できます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxを独学で学んだ人が現場で最初につまずく5つの場面｜現役講師が教える実務との埋め方
- 前のページへ：シェルスクリプトが書けるようになると仕事が変わる理由｜コマンドの次に学ぶべきスキルを現役講師が解説
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます