「障害対応って大変そう…」「実際、何をするの？」

インフラエンジニアの仕事で避けて通れないのが障害対応。システムに問題が発生したとき、迅速に原因を特定し、復旧させる必要があります。

この記事では、障害対応の基本的な流れと心構えについて、初心者向けに解説します。

障害対応とは？

システムの「緊急事態」に対応すること

障害対応とは、システムやサービスに問題が発生したときに、原因を調査して復旧させる作業のことです。

「サーバーが落ちた」「Webサイトが表示されない」「ログインできない」など、ユーザーに影響が出ている状態を解消します。

障害の種類

障害対応の基本フロー

障害対応は、基本的に以下の流れで進めます。

Step1：検知・認識

まず、障害が発生したことを認識します。

• 監視システムからのアラート
• ユーザーからの問い合わせ
• 自分で気づく

監視システムを適切に設定しておくことで、ユーザーより先に障害を検知できます。

Step2：影響範囲の確認

何が、どこまで影響を受けているかを確認します。

• どのサービスが停止しているか？
• どれくらいのユーザーに影響があるか？
• 全面停止か、一部機能だけか？

影響範囲によって、対応の優先度が変わります。

Step3：一次対応（暫定対応）

まずはサービスを復旧させることを優先します。根本原因の調査は後回し。

• サーバーの再起動
• サービスの再起動
• ロールバック（前の状態に戻す）
• 問題のあるサーバーの切り離し

「原因は後で調べる、まず止血する」という考え方が大切です。

Step4：原因調査

サービスが復旧したら、なぜ障害が起きたのかを調査します。

• ログの確認
• リソース使用状況の確認
• 直前の変更作業の確認
• 外部要因の確認

Step5：恒久対応

原因が特定できたら、再発防止のための対策を行います。

• バグの修正
• 設定の見直し
• リソースの増強
• 監視の追加

Step6：報告・振り返り

障害の内容と対応を記録・報告します。

• 障害報告書の作成
• 関係者への報告
• 振り返りミーティング（ポストモーテム）

障害対応で使うコマンド

Linuxサーバーでよく使う調査コマンドを紹介します。

サーバーの状態確認

# CPU・メモリの状態をリアルタイム確認
top

# ディスク使用量の確認
df -h

# メモリ使用量の確認
free -h

# サーバーの稼働時間と負荷
uptime

プロセスの確認

# 動いているプロセス一覧
ps aux

# 特定のプロセスを探す
ps aux | grep nginx

# プロセスの強制終了
kill -9 [PID]

ログの確認

# システムログを確認
less /var/log/messages
less /var/log/syslog

# 最新のログをリアルタイムで見る
tail -f /var/log/messages

# エラーを含む行を検索
grep -i error /var/log/messages

ネットワークの確認

# 通信できるか確認
ping [IPアドレス]

# ポートが開いているか確認
ss -tuln
netstat -tuln

# 外部への接続確認
curl -I https://example.com

障害対応の心構え

障害対応で大切なマインドセットを紹介します。

1. 落ち着くこと

焦ると判断を誤ります。深呼吸して、冷静に状況を把握しましょう。

2. 復旧を最優先にする

原因究明より、まずサービス復旧。ユーザーへの影響を最小限にすることが最優先です。

3. 一人で抱え込まない

わからないことはすぐに相談。チームで対応することで、解決が早まります。

4. 記録を残す

何をいつ行ったか、メモを取りながら対応しましょう。後の報告や振り返りに役立ちます。

5. 変更は一つずつ

複数の変更を同時に行うと、何が効果があったかわかりません。一つ変更して様子を見るを繰り返します。

障害を防ぐために

障害対応も大切ですが、そもそも障害を起こさないことがベストです。

事前にできること

• 監視の充実：異常を早期に検知
• 冗長化：1台が落ちても影響しない構成
• バックアップ：データを定期的に保存
• 変更管理：変更は計画的に、手順書を作成
• ドキュメント整備：構成図や手順書を最新に保つ

まとめ

この記事のポイントを整理します。

障害対応は、インフラエンジニアにとって避けられない仕事です。最初は緊張しますが、経験を積むことで冷静に対応できるようになります。

基本的な流れを頭に入れておき、いざというときに落ち着いて動けるようになりましょう！