障害管理

読み：しょうがいかんり　／　英語表記：Fault Management

性能・監視・運用

障害管理とは、ネットワークやシステムの異常を検知し、影響と原因の切り分けを行って正常な状態への復旧を図る管理活動である。発生した事象や対応内容を記録し、再発を防ぐための調査と改善にもつなげる。

イマシルちゃんの解説

障害管理は、機器や通信の異常を見つけてサービスを正常に使える状態へ戻すための活動だよ。
「Webサイトが開かない」という連絡だけでは、回線やサーバなどのどこに問題があるかは分からないよね。
そこで監視の通知や機器の記録を集めて、困っている範囲と原因の候補を調べるんだ。
複数の機器へ同時につながらないなら、共通して通る回線に問題があるかもしれないよ。
業務への影響に応じて優先順位を決め、必要なら別の担当者や保守会社と協力して対応するんだ。
直した後は利用者の操作でも正常に動くことを確かめて、経緯を記録しておくことが大切だよ。

より深い解説

異常の発見から正常化までを扱う

障害管理は監視画面で異常を見つけることだけを指すわけではない。異常がどこで起きているかを調べ、業務への影響を判断し、必要な対応を進めて結果を確認する。ITU-T X.700では、障害管理に異常動作の発見、分離、修正を含めている。ログの収集や異常通知、診断のための試験などがその手段になる。

障害は電源故障のように持続する場合もあれば、回線が短時間だけ切れるように一時的な場合もある。担当者が確認した時点で正常に見えても、利用者の申告が誤りとは限らない。発生時刻の記録や通信統計がなければ、一時的な現象の原因を調べにくい。

構成管理は接続関係や設定を把握するための情報を提供する。性能管理は応答時間の悪化や資源の不足を把握する。例えば回線の混雑がサービス停止を引き起こす場合には、性能の測定と障害への対応の両方が必要になる。管理領域は役割を整理するものであり、実際の対応を互いに切り離すものではない。

異常を見つける方法を組み合わせる

管理側から一定の間隔で状態を問い合わせる方法をポーリングという。SNMPでインタフェースの状態を読む方法や、通信への応答を定期的に確かめる方法がある。一方、機器側から状態の変化を通知する方法もある。両者を組み合わせると、それぞれの見落としを補いやすい。

方法	得られる情報の例	判断するときの注意
定期的な問い合わせ	装置の応答やインタフェースの状態	確認の間隔より短い異常を見落とすことがある
SNMPのTrap	リンクの断など機器で起きた事象	通知が届かない可能性もある
Syslogによる記録の収集	認証の失敗や設定変更とエラーの記録	記録する項目や重要度は機器によって異なる
利用者に近い位置からの動作確認	Web画面の表示や名前解決の成否	試した経路と操作の範囲でしか確認できない

RFC 3416で定められた上表のSNMP通知には、通知に対する応答がない。同じ仕様のInformは受信側からの応答を伴う通知だが、経路が切れていれば確実に届けられるわけではない。通知が来ないことを正常の証拠にせず、定期的な確認や通知元の生存確認も行う。

監視側から応答がない場合にも、対象装置の故障と即断してはいけない。途中の回線や管理用の経路、アクセス制御、監視装置自身の不調が原因となることがある。またpingに応答してもWebアプリケーションが正常に動くとは限らない。装置の状態を調べる監視と、必要なサービスの動作を確かめる監視を分けて考える。

通知と現在の状態を区別する

ログに一つの出来事が記録されたことと、対応すべき異常が現在も続いていることは異なる。対応が必要な異常状態を表すアラームでは、対象、種類、重要度、発生時刻、現在の状態などを管理する。リンクが切れて戻った場合には、発生の記録と解消した状態の両方を把握する必要がある。

RFC 8632の管理モデルは、装置側の異常が解消された状態と、運用担当者が通知を確認した状態を別々に扱う。担当者が「確認済み」にしただけでは設備の異常は直らない。逆に設備が正常に戻っても、原因や利用者への影響の確認が残る場合がある。

優先順位は機器が付けた重要度だけでは決められない。予備機の片方の故障と、本番サービスを提供する唯一の回線の故障では影響が異なる。利用者数、重要な業務の停止、代替手段の有無、放置した場合の影響を合わせて判断する。

大量の通知から共通する原因を探す

一つの上位回線が切れると、その先にある多数の装置から応答がなくなる。装置ごとの通知を別々の故障として扱うと対応が重複し、重要な事象を見失いやすい。発生時刻や接続関係、事象の種類を組み合わせて関連を調べることを相関分析という。Ciscoのネットワーク管理資料も、ログや通知の関連付けと優先順位付けを扱っている。

例えば「支店内の全スイッチが応答しない」という通知が集まった場合は、共通する拠点ルータや拠点間回線も調べる。拠点ルータの外側だけが不通なら、内部のスイッチがすべて故障したとは考えにくい。ただし共通していることだけで原因を断定せず、別経路からの確認や回線状態の記録で確かめる。

機器ごとに時計がずれていると前後関係を誤るため、RFC 5905などで定義されるNTPを使って時刻を合わせておく。通知の受信時刻は事象の発生時刻と異なることもある。最初に届いた通知が原因とは限らないので、各機器の記録と時刻のずれを踏まえて時系列を組み立てる。

計画作業で発生する通知や、原因が分かっている二次的な通知は整理する。ただし通知を抑制する範囲と終了時刻を決め、事象の記録は追跡できるようにする。監視を止めたまま戻し忘れると、次の異常の発見が遅れる。

仮説を立てて確認の範囲を狭める

調査では、いつから何ができず、どこではできているかを確認する。同じ拠点の全端末で失敗するのか、特定の利用者だけなのか、IPアドレスで接続できても名前で接続できないのかといった違いが手掛かりになる。既知の接続関係や直前の変更履歴も参照する。

例えば、端末から同じネットワーク内の相手には接続できるが拠点外へ出られないなら、端末の接続だけでなくゲートウェイや経路を調べる。名前を使った接続だけが失敗するならDNSに関わる通信と応答を確認する。このように仮説ごとに確かめる条件を決め、結果によって次の候補を絞る。

調査の前後ではログや統計、実施したコマンドとその結果を記録する。再起動によって一時的な情報が失われることもあるため、業務上許される範囲で証拠を確保してから操作する。複数の設定を同時に変えると、何が改善につながったか判断しにくくなる。

担当者の権限や知識だけで解決できないときは、上位の担当者や専門部署、通信事業者などへ対応を引き継ぐ。この連携をエスカレーションという。発生時刻、影響範囲、確認した事実、実施済みの操作を渡せば、同じ調査の繰り返しを減らせる。

業務の再開と原因への対処を分けて考える

根本的な修正を待たずに影響を軽減する措置を暫定対策という。予備回線へ切り替える、問題のある装置を迂回する、直前の設定変更を戻すといった方法が考えられる。業務への影響が大きい場合は、調査と並行してサービスを使える状態へ戻すことを優先する。

ただし症状が消えても根本原因が取り除かれたとは限らない。例えば再起動で一時的に通信できるようになっても、資源を消費し続ける不具合が残っていれば再発する可能性がある。業務を再開した判断と、原因に対する恒久的な対応の完了は別に記録する。

正常化の確認は監視画面の表示だけで終えない。影響を受けた経路から必要な操作が成功するか、応答時間やエラーが元の状態へ戻ったかを確認する。対応中に変えた設定や代替経路も構成情報へ反映し、残ったリスクと追加作業の担当を明確にする。

監視と対応の経路も設計する

業務用ネットワークと同じ経路で装置を監視していると、その経路の故障によって情報収集も操作もできなくなる。業務の通信経路と独立した管理経路を用意する方式をアウトオブバンド管理という。Ciscoの構成例のように、管理用の別ネットワークやコンソールへの接続などを利用する。主な経路が使えなくても状態確認や復帰操作ができるようにする。

通信経路を分けても同じ電源や設置場所を使っている場合があるため、共通する故障要因も確認する。管理経路には強い操作権限が集まるので、接続できる担当者と機器を限定する。別経路が用意されていても利用方法が共有されていなければ緊急時に役立たない。

対応後は障害の開始、発見、対応開始、サービス再開の時刻を残す。例えば発見までが長かったのか、連絡に時間が掛かったのか、復帰手順が複雑だったのかによって改善策は変わる。記録から監視の対象や間隔、連絡体制、手順、構成を見直すことが次の障害への備えになる。