Linuxサーバーを壊して初めて分かった5つのこと|現役講師が語る失敗の活かし方

HOMEリナックスマスター.JP 公式ブログLinux学習ガイド > Linuxサーバーを壊して初めて分かった5つのこと|現役講師が語る失敗の活かし方

この記事の監修:宮崎智広(Linux教育歴15年以上・受講者3,100名超)
「本番サーバーで取り返しのつかないミスをした経験、ありませんか?」
「設定ファイルを上書きしてサービスが止まった」「パーミッションを変えたらログインできなくなった」——Linuxを触っていれば、誰でも一度は冷や汗をかく場面に遭遇します。

この記事では、20年近くLinuxサーバーを運用し、3,100名以上のエンジニアを指導してきた経験から、私自身がサーバーを「壊した」失敗談と、そこから得た5つの教訓をお伝えします。

【この記事でわかること】

・Linuxサーバーを壊した経験が成長の転機になる理由
・現役講師がSE時代に経験した5つの失敗と具体的な教訓
・失敗を「次に活かす」ための3つの実践的な習慣
・検証環境で安全に失敗を積み重ねる方法


Linuxサーバーを壊して初めて分かった5つのこと|現役講師が語る失敗の活かし方
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

失敗した人だけが手に入れるスキルがある

セミナーで3,100名以上を指導してきた中で、成長が速い人に共通するポイントがあります。それは「過去にサーバーを壊した経験がある」ことです。

意外に思うかもしれません。でも、これは事実です。

教科書を100回読むより、一度の障害対応で学ぶことのほうが圧倒的に多い。なぜなら、障害が起きた瞬間は「二度と同じことを繰り返したくない」という強烈な感情が伴うからです。感情を伴った記憶は定着します。

逆に、失敗を一度も経験していない人は、どこかで大きな事故を起こすリスクを抱えています。小さな失敗を早い段階で経験し、そこから学ぶ。この積み重ねが、現場で信頼されるエンジニアを作ります。

SE時代に経験した5つの失敗と教訓

私がSE時代(2001年~2006年)に実際に経験した失敗を、そのまま紹介します。どれも当時は本当に焦りましたが、今振り返ると全てが貴重な学びでした。

1. iptablesの設定ミスでリモート接続を遮断した

入社して間もない頃、ファイアウォールの設定変更を任されました。iptablesのルールを追加する際、既存のルールを確認せずにINPUTチェインのデフォルトポリシーをDROPに変更してしまったのです。

# 当時の私がやってしまったこと(絶対に真似しないでください) # iptables -P INPUT DROP # SSH接続用のルールを追加する「前に」デフォルトをDROPにした # → 自分自身のSSH接続も即座に切断された

SSHで接続していたので、ポリシーを変えた瞬間に自分の接続も切れました。リモートからは復旧できず、データセンターまで出向いてコンソールから直接操作する羽目になりました。

教訓:ファイアウォールの変更は、必ず「許可ルールを先に追加してからデフォルトポリシーを変更する」。順序を間違えると自分自身を締め出す。

2. dfコマンドを見ていなくてディスクが100%になった

お客様のWebサーバーを運用していた時のことです。ある月曜の朝、「サイトが表示されない」と連絡を受けました。原因は、ログファイルが肥大化してディスク使用率が100%に達していたことでした。

# ディスク使用状況の確認 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 20G 20G 0 100% /

Apacheのアクセスログとエラーログが数GBに膨れ上がっていた。logrotateの設定が無効になっていたことに気づいていなかったのです。

教訓:ディスク容量の監視は「仕組み」で行う。人間の記憶に頼ると必ず見落とす。dfコマンドの定期実行と閾値アラートは、サーバー構築直後に設定すること。

3. chmodで再帰的にパーミッションを壊した

テスト環境だと思って実行したchmod -Rが、実は本番環境だった。これは本当に血の気が引きました。

# 私がやってしまったコマンド # chmod -R 777 /etc/ # /etcディレクトリ配下の全ファイルのパーミッションが777に…

/etc/shadowのパーミッションが変わり、sshdが起動しなくなりました。さらに、/etc/sudoersが777になったことでsudoも動作しなくなった。復旧にはシングルユーザーモードで起動し、手作業で主要ファイルのパーミッションを一つずつ戻す必要がありました。

教訓:「-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

バックアップが1週間分まるごと取れていなかったことに気づいたのは、障害が発生してリストアしようとした時でした。バックアップは「取れていること」を確認するまでがバックアップです。

教訓:cronジョブは登録後に必ず実行ログを確認する。「手動で動いた」は信用しない。cron環境と対話シェル環境は全く違う。

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

先輩に「設定を変える前にcpを打つのは呼吸と同じだ」と叱られました。この一言が、その後の20年の運用人生で一度も忘れたことのない教えになっています。

教訓:設定ファイルを編集する前に、日付付きのバックアップを必ず取る。これは技術ではなく「習慣」の問題。習慣がなければ、いつか必ず取り返しのつかないミスをする。

Linuxサーバーを壊して初めて分かった5つのこと|現役講師が語る失敗の活かし方 - 解説1

失敗を「次に活かす」ための3つの習慣

失敗は、ただ反省するだけでは意味がありません。次に同じ失敗をしないための「仕組み」に落とし込むことが大切です。

1. 検証環境で「安全に壊す」練習をする

本番で壊すのは論外ですが、検証環境で意図的に壊すのは最高の学習方法です。

私のセミナーでは、受講生に「まず壊してみてください」と伝えることがあります。例えば、検証環境でchmod 000 /etc/passwdを実行するとどうなるか。ログインできなくなる? suコマンドが使えなくなる? 実際に試してみると、教科書で読んだ知識が一気に実感に変わります。

VirtualBoxやWSL2があれば、壊しても数分でリセットできる環境が手に入ります。失敗のコストがゼロの環境で、どんどん壊してください。

2. 障害対応を「再現手順」まで書き残す

障害が起きた時、「何をしたら直ったか」だけをメモする人が多いのですが、それでは不十分です。「何をしたら壊れたか」を再現手順として書き残すことが重要です。

再現手順があれば、次に同じ状況に遭遇した時に「あ、これは前に見たパターンだ」と即座に判断できます。さらに、チーム内で共有すれば、他のメンバーが同じ失敗をするのを防げます。

3. 他人の失敗事例を自分のチェックリストに加える

自分で全ての失敗を経験する必要はありません。先輩や同僚の失敗事例を聞いたら、それを自分のチェックリストに加えてください。

私は今でも、サーバーの設定変更前に以下の確認を行っています。

バックアップ:設定ファイルの日付付きコピーを取ったか
切り戻し手順:失敗した時に元に戻す手順を書いたか
影響範囲:この変更で他のサービスに影響が出ないか
作業環境:本当に作業対象のサーバーにログインしているか
実行タイミング:利用者が少ない時間帯を選んでいるか

このチェックリストは、自分の失敗と先輩たちの失敗から作り上げたものです。20年かけて少しずつ項目が増えていきました。

Linuxサーバーを壊して初めて分かった5つのこと|現役講師が語る失敗の活かし方 - まとめ

まとめ

失敗の内容 得られた教訓
iptablesで自分を締め出した 許可ルール追加→ポリシー変更の順序を守る
ディスク100%でサービス停止 監視は「仕組み」で行い、人間の記憶に頼らない
chmod -Rでパーミッション破壊 -Rオプション実行前にパスを3回確認する
cronジョブが実は動いていなかった 登録後にログで動作確認するまでが設定作業
バックアップなしで設定ファイル上書き cpコマンドは設定変更前の「呼吸」にする
Linuxのスキルは、教科書だけでは身につきません。失敗から学ぶ力こそが、現場で通用するエンジニアの条件です。

「失敗が怖くてサーバーを触れない」という方もいるかもしれません。でも、検証環境なら何度壊してもやり直せます。大切なのは、失敗を恐れることではなく、失敗を「記録し、仕組みに変え、二度と繰り返さない」ことです。

まずは検証環境を1つ用意して、今日紹介した5つの失敗を自分で再現してみてください。教科書で読むのとは比べものにならない学びが得られるはずです。

失敗しても大丈夫な環境で、Linuxを基礎から学びたい方へ

「本番で失敗する前に、安全な環境で実力をつけたい」「基礎からやり直したいけど、何から始めればいいか分からない」——そのような悩みは、正しい手順で体系的に学べば必ず解決できます。
ネットの断片的な情報に頼るのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。


無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。


Linux無料マニュアル(図解60P) 名前とメールで30秒登録