インフラエンジニアの障害対応とは？切り分けの進め方と報告書の書き方

「サーバーにつながらない」「サービスが遅い」。システムに障害が起きたとき、原因を突き止めて元に戻すのがインフラエンジニアの障害対応です。慌てやすい場面だからこそ、決まった流れと切り分けの型を知っておくと、落ち着いて対応できるようになります。

ここでは、インフラエンジニアの障害対応を、対応の流れと、原因を絞り込む切り分けの進め方から解説します。障害報告書の書き方に加えて、障害対応で評価される人の動き方もまとめました。

インフラエンジニアの障害対応とは？

障害対応の目的

障害対応とは、システムが正しく動かなくなったときに、元の状態に戻し、同じことが起きないようにする仕事です。目的は、次の3つです。

目的	内容
早く元に戻す	利用者や業務への影響を、できるだけ短くする
原因を突き止める	なぜ起きたのかを調べ、事実にもとづいて説明できるようにする
再発を防ぐ	設定や手順、監視を見直し、同じ障害が起きないようにする

大切なのは、原因の調査より先に、まずサービスを元に戻すことを考える点です。原因が分からなくても、切り替えや再起動などの暫定の対応で、先に影響を止めることがあります。

障害対応の流れ

障害対応は、一般的に次の流れで進めます。

段階	やること
1. 検知	監視のアラートや、利用者からの問い合わせで障害に気づく
2. 初動	影響の範囲を確かめ、上の担当者や関係者に第一報を入れる
3. 切り分け	どこに問題があるかを絞り込む
4. 復旧	切り替えや再起動などの暫定の対応で、サービスを元に戻す
5. 原因の調査	ログや設定を調べ、根本の原因を突き止める
6. 恒久の対応	設定の修正や機器の交換など、根本から直す
7. 報告	障害報告書をまとめ、再発防止の策を決める

職場によって細かな手順は違いますが、多くの現場で初動の報告と記録を早く行うことが求められます。

若手と経験者の役割

立場	主な役割
1〜2年目の若手	アラートの確認、手順書にそった一次対応、上の担当者への報告、対応の記録
経験を積んだ担当者	切り分けと復旧の判断、原因の調査、関係者への説明
リーダー・設計の担当者	恒久の対応と再発防止策の決定、構成や監視の見直し

最初は一次対応と記録が中心でも、経験を積むほど判断を任される場面が増えます。運用保守の仕事

全体は、［運用保守エンジニアとは］で解説しています。

障害の切り分けの進め方

切り分けの基本の考え方

切り分けとは、問題のある場所を少しずつ絞り込んでいく作業です。まずは、次のような点を確かめて、範囲を狭めましょう。

確かめること	例
いつから起きているか	何時ごろから、ずっとか、ときどきか
どこで起きているか	1台のサーバーだけか、全体か。特定の拠点だけか
誰に影響があるか	すべての利用者か、一部の利用者だけか
直前に何か変わったか	設定の変更、パッチの適用、機器の交換などがなかったか

とくに「直前に何が変わったか」は、原因に近づく大きな手がかりになります。作業の記録や変更の履歴を必ず確かめましょう。

層ごとに確かめる

ネットワークからアプリまで、下の層から順に確かめると、抜けなく切り分けられます。

層	確かめること	使う道具の例
物理	機器の電源、ケーブル、ランプの状態	目で見る、機器の管理画面
ネットワーク	相手と通信できるか、どこで止まっているか	ping、traceroute
サーバー	CPU・メモリ・ディスクに余裕があるか	top、free、df
サービス	サービスが動いているか、ポートが開いているか	systemctl、ss
アプリ・ログ	エラーが出ていないか	journalctl、ログファイルの確認

たとえば「Webサイトが見られない」とき、pingが通るならネットワークは生きている、と分かります。次にサーバーの資源、サービスの状態、ログへと進めば、原因のある層を順に絞り込めます。

Linuxのコマンドは、［Linuxのコマンドとは］で紹介しています。

切り分けで気をつけること

気をつけること	理由
一度に1つずつ変える	複数を同時に変えると、何が効いたのか分からなくなる
やったことを時刻つきで記録する	報告書を書くときや、引き継ぐときに必要になる
再起動の前に状況を残す	再起動するとログやメモリの状態が消え、原因が分からなくなることがある
決められた手順と判断の範囲を守る	本番の環境で、自分の判断だけで設定を変えない

慌てると、手順を飛ばしたり、記録を忘れたりしがちです。分からないときは、早めに上の担当者に相談することも、障害対応の大切な動きです。

障害報告書の書き方と、評価される障害対応

障害報告書に書く項目

障害が落ち着いたら、障害報告書をまとめます。一般的には、次の項目を書きます。

項目	内容
概要	何が起きたかを、1〜2文で
発生と復旧の日時	起きた時刻、気づいた時刻、元に戻った時刻
影響の範囲	どのサービスの、どの利用者に、どんな影響があったか
時系列	検知から復旧までに、誰が何をしたか
原因	なぜ起きたのか
対応の内容	暫定の対応と、恒久の対応
再発防止の策	同じことを起こさないために、何をいつまでに変えるか

報告書を書くときのポイント

報告書は、技術に詳しくない人も読みます。次の点を意識しましょう。

• 事実と推測を分けて書く
  「〜と考えられる」と「〜を確認した」を混ぜない。
• 時刻は正確に書く
  対応の記録をもとに、分単位で書く。
• 読む人に合わせた言葉を使う
  専門用語には短い説明を添える。
• 人を責めない
  「誰が間違えたか」ではなく「なぜ間違いが起きる仕組みだったか」を書く。

とくに再発防止の策は、「注意する」で終わらせず、手順や監視、仕組みをどう変えるかまで書くと、報告書の価値が上がります。

障害対応で評価される動き方

障害対応では、原因を突き止める技術の力だけでなく、次のような動き方が評価されます。

動き方	内容
早めに報告する	自分で抱え込まず、決められた時間までに上の担当者や関係者へ伝える
記録を残す	時刻つきの記録で、対応の流れを誰でも追えるようにする
再発防止を提案する	報告書に、手順や監視の見直しを具体的に書く
仕組みを良くする	手順書を直したり、監視の設定を足したりして、次の障害に備える

同じ障害を二度起こさないための改善まで手を伸ばせる人は、運用保守の中でも頼られ、構築や設計の仕事を任されるきっかけにもなります。

構築・設計へ進む方法は、［インフラエンジニアの上流工程とは］で解説しています。

障害対応の経験を転職で伝える

障害対応の経験は、転職でも評価されやすい経験です。職務経歴書や面接では、次の順に伝えると分かりやすくなります。

順番	伝えること
1. 状況	どんなシステムで、どんな障害が起きたか
2. 自分の役割	一次対応、切り分け、報告など、自分が担当したこと
3. 行動	どう切り分け、どう元に戻したか
4. 結果と改善	復旧までの時間や、再発防止のために変えたこと

構築の経験がない場合の伝え方は、［構築経験なしでも転職できる］で紹介しています。

インフラエンジニアの障害対応でよくある疑問

障害対応が怖い…慣れる？

慣れます。最初は誰でも緊張しますが、流れと切り分けの型を覚え、経験を重ねるほど落ち着いて対応できるようになります。過去の障害報告書を読んで、どんな障害が起き、どう対応したかを知っておくのも効果的です。

夜中の障害対応ってある？

24時間動くシステムを担当していると、あります。シフトの夜勤で対応する職場や、待機の当番が呼び出される職場があります。

夜勤の働き方や、日勤の仕事へ移る方法は、［インフラエンジニアの夜勤とは］で解説しています。

原因が分からないときはどうする？

まずはサービスを元に戻すことを優先し、分かっている事実と、まだ分からないことを分けて報告しましょう。原因の調査は、ログを残したうえで、メーカーのサポートや経験のある担当者の力も借りて進めます。

障害対応の力はどうやって伸ばせばいい？

仕事の中では、障害のたびに「なぜ起きたか」を調べ、報告書を読む習慣をつけましょう。仕事の外では、自宅やクラウドに環境を作り、わざとサービスを止めて切り分けを練習する方法もあります。

練習の環境の作り方は、［インフラエンジニアのポートフォリオの作り方］で紹介しています。

まとめ

障害対応は、決まった流れと切り分けの型を知っておくことで、落ち着いて進められる仕事です。

この記事のポイントは次のとおりです。

• 障害対応の目的
  早く元に戻し、原因を突き止め、同じ障害が起きないようにすること。
• 障害対応の流れ
  検知・初動・切り分け・復旧・原因の調査・恒久の対応・報告の順に進める。
• 切り分けの進め方
  いつ・どこで・誰に・何が変わったかを確かめ、物理からアプリまで層ごとに絞り込む。
• 障害報告書
  事実と推測を分け、時系列と再発防止の策まで具体的に書く。
• 評価される動き方
  早めの報告と記録、再発防止の提案、手順や監視の改善まで手を伸ばす。

障害対応の経験は、インフラエンジニアとして長く役立つ力になります。次の障害のときは、対応の流れを意識しながら、時刻つきの記録を残すところから始めてみてください。