障害発生時の初動とは

障害対応というと、 「どのコマンドを実行するか」 「どの機器が故障したのか」 といった技術的な切り分けを想像しやすいでしょう。

もちろん技術調査は重要です。 しかし実際の現場では、その前に整理しなければならない情報があります。

• 何ができないのか
• いつから発生しているのか
• 誰に影響しているのか
• どこまで影響しているのか
• 現在も継続しているのか
• 障害直前に変更作業がなかったか
• 誰へ連絡する必要があるのか

初動で最も重要な3つの目的

障害初動では、細かいコマンドを覚える前に、 何のために初動を行うのかを理解しておきましょう。

まず全体の流れを理解する

ネットワーク障害が発生した場合は、 大まかに次の流れで初動を進めます。

実際には、これらを完全に順番どおり行うとは限りません。 大規模障害では、影響確認をしながら同時に責任者へ連絡する場合もあります。

重要なのは、 技術調査だけに集中して、影響確認や報告を忘れないこと です。

最初の5分で確認すること

障害連絡を受けたら、 まず最低限次の項目を確認します。

1. 何ができないのか確認する 「ネットワークが使えない」という表現だけで判断せず、 Web閲覧不可、業務サーバーへ接続不可、拠点間通信不可など、 実際の症状を確認します。
2. 発生時刻を確認する 正確な時刻が分からない場合でも、 「10時頃」「最後に正常だったのは9時45分」など、 可能な範囲で時間を絞ります。
3. 現在も継続しているか確認する 一時的な通信断だったのか、 現在も通信できないのかを確認します。
4. 影響している利用者・端末を確認する 1台のみなのか、 同一部署なのか、 複数拠点なのかを確認します。
5. 直前の変更作業を確認する ネットワーク設定変更、サーバー作業、 ファイアウォール変更、回線工事などがなかったか確認します。
6. 障害規模に応じて連絡を開始する 重大な影響がある場合は、 原因が分かるまで待たず、決められた連絡先へ共有します。

影響範囲を確認する

初動の中でも特に重要なのが 影響範囲の確認です。

同じ「サーバーにつながらない」という申告でも、 影響範囲によって原因候補は大きく変わります。

「誰が使えないか」だけでは不十分

影響範囲は、複数の軸で確認すると整理しやすくなります。

事実と推測を分ける

障害対応では、 確認できた事実と まだ確認していない推測を分けることが重要です。

報告の表現も変える

ログ・状態・時刻を残す

障害中の機器状態は、 復旧操作によって変化することがあります。

そのため、緊急性とのバランスを取りながら、 調査に必要な情報を可能な範囲で保存します。

ネットワーク機器で残したい情報の例

コマンド結果はコピーして残す

画面を見て終わるのではなく、 必要に応じてテキストファイルや作業記録へ残します。

10:18
対象機器：SW01

確認結果
・Gi1/0/10：down
・Gi1/0/11：up
・Gi1/0/10は10:12頃にlink downのログあり

対応
・利用者へLANケーブル状態を確認依頼
・現時点では設定変更なし

直前の変更有無を確認する

障害が発生したときは、 直前に何か変わっていないか を確認します。

変更作業と障害発生時刻が近い場合、 強い手がかりになることがあります。

エスカレーションする

自分だけで解決できない場合や、 影響が大きい場合は、早めにエスカレーションします。

原因が分からないからといって、 「調査中です」だけを伝えるのでは不十分です。

最低限伝えたい情報

エスカレーション例

【事象】
大阪拠点から本社業務サーバーへ接続できません。

【発生時刻】
10:05頃から。10:00時点では利用できていたとのことです。

【影響範囲】
大阪拠点の複数端末で発生しています。
東京拠点からは同じサーバーへ接続可能です。

【確認済み】
・大阪拠点内の端末間通信：正常
・大阪拠点ルーターLAN側：到達可能
・本社宛てping：失敗
・大阪－本社間のWAN状態を現在確認中

【変更】
現時点でネットワーク変更作業の情報はありません。

【現在の対応】
大阪拠点ルーターおよびWAN回線を確認しています。

障害初動でやってはいけないこと

障害を早く直したい気持ちが強いほど、 初動で不要な操作を行ってしまうことがあります。

障害初動で使える確認テンプレート

障害連絡を受けたときに、 次の項目を埋める形で整理すると、 情報の抜け漏れを減らせます。

【障害初動メモ】

■ 事象
何ができないか：

■ 発生時刻
発生時刻：
最終正常時刻：
検知時刻：

■ 継続状況
現在も発生中：
一時的に復旧：

■ 影響範囲
利用者：
端末：
部署：
拠点：
サービス：

■ 正常な範囲
正常に利用できる端末：
正常な拠点：
正常なサービス：

■ 直前の変更
ネットワーク変更：
サーバー変更：
回線・設備作業：
その他：

■ 確認結果
1.
2.
3.

■ 取得した情報
ログ：
コマンド結果：
監視アラート：

■ 実施した対応
1.
2.

■ 現在の判断
確認済み：
未確認：
原因候補：

■ エスカレーション
連絡先：
連絡時刻：
共有内容：

障害初動の具体例

次のような障害連絡を受けた場合を考えてみましょう。

この段階では、まだ原因は分かりません。

次のように初動を進めます。

この時点で言えること

初動報告例

【事象】
営業部端末から業務サーバーへ接続できない事象が発生しています。

【発生時刻】
10:15頃に利用者から申告。
最終正常時刻は現在確認中です。

【影響範囲】
営業部の複数端末で発生しています。
技術部端末からは同サーバーへ接続可能です。

【確認結果】
・営業部PC → デフォルトゲートウェイ：ping成功
・営業部PC → 業務サーバー：ping失敗
・技術部PC → 業務サーバー：接続可能

【変更情報】
10:00頃に営業部VLANに関係するACL変更作業が実施されています。

【現在の対応】
ACL設定および対象通信の通過状況を確認中です。

【原因】
現時点では未確定です。

このように、 原因を断定しなくても十分に有効な初動報告ができます。

障害対応では「復旧」と「原因調査」を分けて考える

障害対応では、 原因を完全に突き止める前に、 業務影響を減らすための復旧対応が必要になる場合があります。

現場で使える障害初動チェックリスト

自分の言葉で説明する課題