この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
深夜の障害対応で、そう思いながら一人で抱え込んでしまった経験はないでしょうか。
この記事では、20年以上Linuxサーバーを運用し、セミナーで3,100名以上を指導してきた経験から、私が障害対応を一人で抱え込んで復旧を長引かせてしまった失敗と、そこから学んだ「エスカレーションの技術」について解説します。
この記事のポイント
・障害対応が長引く原因の多くは技術力ではなく相談タイミングの判断ミス
・一人で悩む時間を区切ってエスカレーションする基準を持つ
・systemctl statusとjournalctlの出力を添えて正確に状況を伝える
・「聞く力」も現場で評価される実務スキルの一つ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜエンジニアは障害対応を一人で抱え込んでしまうのか
現場でよく見かけるのが、障害が発生した瞬間に「自分の手に負えないと思われたくない」「呼び出すほどの事態か判断できない」という迷いから、一人で調査を続けてしまうエンジニアです。特に経験の浅いうちは、先輩を深夜に起こすことへの申し訳なさや、自分の技術力を疑われることへの不安が先に立ち、報告や相談のタイミングを逃してしまいます。私自身、若手の頃はまさにこのタイプでした。分からないことを「分からない」と言えず、調べれば自分だけで何とかなると思い込んでいたのです。しかし障害対応の現場では、この判断が復旧までの時間を大きく引き延ばす原因になります。技術力よりも先に、相談のタイミングを見極める力が問われる場面が、実務には数多くあります。
興味深いのは、経験を積んだエンジニアほど早い段階で周囲を巻き込むという事実です。ベテランは自分一人の視野には限界があることを知っているので、原因の候補が複数考えられる時点で、迷わず他の人の目を借りようとします。逆に経験の浅いうちほど「自分で完結させたい」というプライドが先に立ち、相談のハードルを自分で高くしてしまいがちです。この違いに気づいてから、私は相談することを「弱さの表れ」ではなく「復旧を早めるための技術」として捉えるようになりました。
深夜のApache障害を一人で抱え込んで3時間を無駄にした話
1. 「もう少しで分かりそうな気がする」の罠
ある夜、担当していた本番サーバーのApacheが応答を返さなくなりました。エラーログを見ても原因がはっきりせず、私は「もう少し調べれば分かりそうだ」と思い込み、一人で設定ファイルとログを行ったり来たりしながら調査を続けました。実際には、その「もう少し」が1時間経っても2時間経っても続いていました。2. 3時間後にようやく相談した結果
結局、上司に連絡を入れたのは障害発生から3時間後でした。事情を説明すると、上司は5分ほどログを見ただけで「これはメモリ不足でworkerプロセスが起動できていない」と見抜きました。私が3時間かけても分からなかった原因を、経験のある人はわずかな時間で特定したのです。この時、悔しさよりも先に「なぜもっと早く相談しなかったのか」という後悔の方が大きかったのを覚えています。3. 「聞くのが恥ずかしい」の正体
振り返ってみると、私が相談をためらった理由は「自分で解決できないと評価が下がる」という思い込みでした。しかし実際に評価を下げたのは、原因が分からないまま抱え込んで復旧を3時間も長引かせたことの方でした。エンジニアの現場では、分からないことを分からないと言えることの方が、よほど信頼につながります。この経験以来、私は障害対応において「相談する勇気」を技術力と同じくらい大切なスキルだと考えるようになりました。エスカレーションの基準の作り方
一人で抱え込まないためには、感覚ではなく明確な基準を先に決めておくことが重要です。私が実務で使っているのは「一次調査は15分まで」というシンプルなルールです。15分調査しても原因の見当がつかない、あるいは復旧の見込みが立たない場合は、その時点で必ず相談するというルールを自分に課しています。相談する前に、次の2つのコマンドの出力は必ず手元に用意しておきます。これがあるかないかで、相談される側の理解速度がまったく違います。
# systemctl status httpd * httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: failed (Result: exit-code) since Tue 2026-08-19 02:14:32 JST Process: 8821 ExecStart=/usr/sbin/httpd (code=exited, status=1/FAILURE)
# journalctl -u httpd --since "20 min ago" Aug 19 02:14:30 web01 httpd[8821]: AH00020: Configuration Failed Aug 19 02:14:30 web01 httpd[8821]: (12)Cannot allocate memory: AH00020 Aug 19 02:14:32 web01 systemd[1]: httpd.service: Failed with result 'exit-code'.
実務で使える「エスカレーション報告」の型
セミナーで3,100名以上を指導してきた中で、受講生からよく聞かれる質問が「相談する時に何をどう伝えればいいのか分からない」というものです。私が実務で使っている報告の型は次の4項目です。・いつから：障害を検知した時刻と、分かっている発生時刻
・何が：影響が出ているサービス・機能とその範囲
・何を試したか：自分で確認・試行した内容と、その結果（うまくいかなかったことも含める）
・今どう考えているか：自分なりの仮説と、次に何をしようとしていたか
この型で伝えると、相談される側は「何も調べずに丸投げしてきた」とは受け取りません。むしろ「ここまで調べた上で判断に迷って相談してきた」ことが伝わり、信頼につながります。受講生からよく聞かれる質問が「相談すると評価が下がるのでは」という不安ですが、実際には手ぶらの丸投げではなく、この4項目を揃えて相談できる人ほど、現場での評価は高くなります。
「原因が分からない」まま時間だけが過ぎる時の対処法
一人で調査を続けているうちに、エラーメッセージからは何も手がかりが得られず、時間だけが過ぎていくことがあります。こうした状況で有効なのは、次の3つの行動です。1つ目は、調査した内容と結果を時系列でメモに書き出すことです。頭の中だけで考えていると同じ確認を繰り返してしまいますが、書き出すことで「まだ確認していないこと」が見えてきます。
2つ目は、直近の変更履歴を洗い出すことです。障害の多くは、直前に加えた設定変更やデプロイが引き金になっています。
# find /etc -mmin -180 -type f /etc/httpd/conf.d/vhost.conf /etc/sysctl.d/99-custom.conf
3つ目は、15分ルールに従って、この時点で必ず一度相談することです。原因が分からないという事実そのものが、すでに相談すべきタイミングのサインです。「原因が分かってから相談しよう」と考えている限り、その相談は永遠に来ません。
本記事のまとめ
障害対応の現場で本当に差がつくのは、コマンドやログの知識量だけではありません。一人で抱え込む時間をどこで区切り、誰にどう伝えるかという判断力です。私自身、3時間も一人で抱え込んで復旧を長引かせた失敗があったからこそ、15分ルールとエスカレーション報告の型を自分の中に持つようになりました。次に深夜の障害対応に当たる時は、まずsystemctl statusとjournalctlの出力を手元に用意し、15分経っても原因が見えなければ迷わず相談してください。それはあなたの技術力を疑われる行動ではなく、むしろ現場で信頼されるエンジニアが必ず身につけている習慣です。
| やりたいこと | コマンド |
|---|---|
| サービスの状態と終了コードを確認する | systemctl status httpd |
| 直近のログをまとめて確認する | journalctl -u httpd --since "20 min ago" |
| 直近に変更されたファイルを洗い出す | find /etc -mmin -180 -type f |
| エスカレーション報告に含める4項目 | いつから／何が／何を試したか／今どう考えているか |
関連記事：ssコマンドでポートの利用状況を確認する方法
一人で抱え込む前に、まず体系的な知識の土台を作りませんか？
エスカレーションの判断力も、その土台には基礎知識の裏付けが必要です。まずは全体像を整理された教材で把握してください。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxのaliasを知らずに同じ長いコマンドを3年間打ち続けていた話｜現役講師が語る「小さな効率化」を後回しにした代償
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます