深夜の障害対応で学んだこと——Linuxエンジニアが「修羅場」から身につける冷静さの作り方

HOMEリナックスマスター.JP 公式ブログLinux学習ガイド > 深夜の障害対応で学んだこと——Linuxエンジニアが「修羅場」から身につける冷静さの作り方
宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
「深夜2時に電話が鳴る。サーバーが落ちた。原因不明。」

Linuxエンジニアなら、一度はこの瞬間を経験するか、想像したことがあるはずです。練習環境での作業とは違う、本物の緊張感。マニュアルに書いていない状況。上司や顧客が待っているプレッシャー。

この記事では、20年以上Linuxサーバーを運用してきた経験から、深夜の障害対応という「修羅場」が実はエンジニアを最も成長させる場である理由と、その場面で冷静でいられる人が事前に身につけていることを解説します。

この記事のポイント

・深夜障害で「冷静な人」は特別な才能があるのではなく「手順が体に入っている」だけ
・障害対応の最初の5分が全体の時間を決める——初動の型を持っているかが鍵
・「修羅場」はエンジニアとして最速で成長できる場。正しく記録し次に活かす
・20年の現場で一番焦った瞬間と、そこから得た教訓を紹介する


深夜の障害対応で学んだこと——Linuxエンジニアが「修羅場」から身につける冷静さの作り方
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

深夜に呼び出された夜のこと

私が現役のSEとして働いていたのは2001年から2006年5月まで。その間、何度か深夜の障害対応を経験しました。

今でも記憶に残っているのは、お客さんのWebサーバーが深夜に突然応答を返さなくなった夜のことです。当時はまだLinuxサーバーの運用経験が数年程度で、「原因が分からない障害」に直面したのはほぼ初めてでした。

電話を受けた瞬間、頭が真っ白になりました。「まず何をすれば良いのか」が分からなかったのです。SSHで接続しようとしても繋がらない。pingは通る。でも何も分からない。

先輩エンジニアに電話して助けてもらいながら、なんとか復旧させましたが、その後が本当の学びでした。「なぜ自分は最初の5分で何もできなかったのか」を徹底的に考えたのです。

冷静な人が持っている「初動の型」

セミナーで3,100名以上を指導してきた中で、障害対応に強いエンジニアと弱いエンジニアの違いを長年観察してきました。その結論は単純です。

「冷静な人は、才能があるのではなく、初動の手順が身体に染み込んでいる。」

パニックになる理由は「何をすれば良いか分からないから」です。逆に言えば、最初にやるべきことが決まっていれば、深夜2時でも人は動けます。

1. まず「現状把握」だけに集中する

障害対応で一番やってはいけないのは「原因が分からないうちに直そうとすること」です。私が現場でよく見かけるのが、焦りから「とりあえずサービス再起動」をしてしまうパターンです。

再起動で直ることもありますが、直った場合でも「なぜ直ったか」「同じことがまた起きないか」が分かりません。さらに悪いのは、再起動によって「障害の証拠(ログ)」が消えてしまうケースです。

# 最初にやること: 現状把握のコマンド群(RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済み) # 1. システムログの直近を確認する journalctl -xe --no-pager | tail -50 # 2. ディスク使用量を確認する(満杯が原因のことが多い) df -h # 3. メモリ使用量を確認する free -h # 4. 負荷状態を確認する uptime # 出力例: 02:14:32 up 42 days, 3:22, 1 user, load average: 24.53, 22.18, 18.41 # ← load averageがCPUコア数を大きく超えていたら負荷異常 # 5. プロセス状態を確認する ps aux --sort=-%cpu | head -20

この5つを「順番に実行する」と決めておくだけで、深夜の障害対応の初動は別物になります。手順が決まっていれば、頭が混乱していても身体が動くのです。

2. 「作業ログ」を残しながら動く

障害対応中は、自分が何をしたかを記録しながら動くことが重要です。これを聞くと「そんな余裕はない」と言う人が多いのですが、実はこれをやらないと後で二重苦になります。

一つ目の苦しみは「何が原因だったか分からなくなる」こと。二つ目は「次に同じ障害が起きたときに、また一から調べることになる」ことです。

# scriptコマンドで作業ログを自動記録する script -a /tmp/incident_$(date +%Y%m%d_%H%M).log # ここから実行したコマンドとその出力が全て記録される # 作業終了時に exit で記録を終了する # 記録したログを確認する cat /tmp/incident_20260429_0215.log

私が現場でやっていたのは、作業用ターミナルとは別に「メモ用のウィンドウ」を開いておくことです。コマンドを実行するたびに「14:23 df -h 実行 → /var が95%使用」のように時刻付きでメモしていました。

「Linuxの作業記録を残す習慣が現場の評価を変える理由」については、「Linuxの作業記録を残す習慣が現場の評価を変える理由|historyとscriptの活用法」でも詳しく解説しています。

3. 「切り分け思考」で範囲を絞る

障害が起きたとき、初心者は「全部を一度に調べようとする」ことでパニックになります。ベテランは「まず範囲を絞る」ことから始めます。

・サーバー全体が落ちているのか、特定のサービスだけか
・サービスが落ちているのか、繋がらないだけか(ポート確認)
・最近デプロイや設定変更はあったか
・ディスク・メモリ・CPUのどこかが限界に達していないか

この「Yes / No で絞る」思考は、実は練習環境でも意識的に鍛えられます。エラーが出たときに「なぜ出たか」を一つずつ潰す習慣が、障害対応のスピードを決めます。

「修羅場」が最速の成長環境である理由

正直に言います。私がLinuxエンジニアとして大きく成長したのは、順調に作業できた日ではなく、「大変だった日」の翌日です。

深夜の障害対応という「修羅場」には、通常の学習では絶対に得られないものがあります。それは「本物のプレッシャー下での判断経験」です。

何百時間かけて教科書を読んでも身につかない「障害の匂いを感じる感覚」——どのログが重要で、どの数字が異常なのかを直感的に判断する力は、修羅場を経験した人だけが持てるものです。

ただし条件があります。「修羅場を記録して振り返ること」です。

振り返りで「経験」を「知識」に変える

障害対応が終わった後、多くのエンジニアは「終わった、疲れた、寝よう」で終わります。でも、そこから30分だけ振り返りをするかどうかで、次回の対応速度が劇的に変わります。

# 振り返りメモのテンプレート(障害対応後に必ず書く) # [発生日時] 2026-04-29 02:14 # [症状] WebサービスへのHTTPアクセスが全滅 # [原因] /var/log のディスク使用率が100%になりApacheがログ書き込み失敗で停止 # [対応] 古いログファイルを圧縮・削除してディスクを解放し、Apacheを再起動 # [再発防止策] logrotateの設定を見直し、/var の使用率80%でアラートを設定 # [次回の初動改善] df -h を最初のチェックリストに追加する

このメモを溜めていくと、「自分専用の障害対応事例集」が完成します。私は現役のSE時代、こういったメモをテキストファイルに溜め続けていました。3年後に見返したとき、自分の成長がはっきりと見えて、それが自信になりました。

「Linuxの作業ミスを繰り返さない人がやっていること」については、「Linuxの作業ミスを繰り返さない人がやっていること」も参考にしてください。

深夜障害を「一人で抱えない」という判断

最後に、経験から伝えたいことがあります。

深夜の障害対応で「一人でなんとかしよう」としすぎると、判断ミスが起きます。特に疲れているときほど、「これで大丈夫か」の確認を怠ります。

私がSE時代に学んだのは「判断に自信がないときは、先輩や同僚に一言確認する勇気を持つこと」でした。30秒の確認が、1時間の後戻りを防ぎます。

今の時代であれば、チームのSlackやメッセージで「今こういう状況で、こう対応しようとしているが問題ないか」と投げることに躊躇しないでほしいのです。「自分で解決しなければ」というプライドが、障害を長引かせることがあります。

受講生からよく聞かれる質問が「障害対応中に質問するのは恥ずかしくないですか」というものです。私の答えは毎回同じです。「恥ずかしいのは、一人で抱えて対応が遅れることです」と。

まとめ

深夜の障害対応から身につくものは、技術的な知識だけではありません。

・初動の型を持つことで、プレッシャー下でも身体が動く
・「現状把握」を最初の5分でやり切る習慣が対応速度を決める
・作業ログを残すことで、振り返りと次回の改善が可能になる
・切り分け思考で範囲を絞ってから手を動かす
・一人で抱えず、確認の勇気を持つ

修羅場は怖いですが、正しく経験すれば最速の成長機会です。次の障害対応の前に、この記事で紹介した「初動の型」を一度整理しておいてください。

Linuxサーバーが遅いと言われたときの切り分け思考については、「Linuxサーバーが遅いと言われた時に見るべき5つの指標」も参考にしてください。

障害対応で「焦らない」技術の基礎、身についていますか?

深夜の障害対応で冷静でいられるかどうかは、Linuxサーバーの仕組みを体系的に理解しているかどうかで決まります。断片的なコマンドを覚えるより、「なぜそうなるか」を理解できている人が現場では圧倒的に強い。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

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

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

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

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

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

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

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

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

この記事を書いた人

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

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

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


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