ネットワーク管理(障害管理編)


目次

はじめに
障害管理体制の整備
障害管理で使うツール類


一つ前へ

はじめに

 ネットワーク管理で、もっとも頭の痛いのが障害管理であろう。ネットワークやシステムの障害をみつけ、システムを復旧させて通常の運用状態に戻す作業である。
 ネットワークの障害は、ユーザからの「XXと通信ができない」という報告によって明らかになることが多い。一口に「通信ができない」といっても、管理者の立場からみると次のようにいろいろな原因が疑われる。
□ネットワークは正常に動いているが、通信相手のシステムが稼働していない。
□ネットワークも通信相手のシステムも正常だが、サービスを提供するプロセスが起動されていない。
□通信相手のシステムに到達するまでのネットワークに障害がある。
□ローカルのネットワークがうまく動作していない。
□使用中のシステムのEthernetケーブルが外れている
 素早く復旧するには、障害の状況をよく観察、調査して原因を特定しなければならない。障害は時刻や状況を選ばずに発生する。事実、深夜にサーバがクラッシュしたり、仕事の締切直前にネットワークが故障したりすることもよくある。したがって、現在の障害管理では、いつでも迅速に対応できる体制を整備する必要がある。

障害管理体制の整備

 まず、障害管理体制をどのように作ればよいかを考えてみよう
●障害の一元管理
 ネットワークにおける障害管理とは、日常的に使っているネットワーク環境を安定した状態に保つことである。
 この期待に応えるには、ルータやスイッチなどのネットワーク機器だけでなく、ネットワークに接続されたシステム、とくにサーバ群や、ユーザが使うPCやワークステーションなどの障害にも対応できるような "一元処理体制" を整える必要がある。障害の性質によっては、ネットワーク機器とシステムの双方を操作、調整することで復旧することも多い。
 現在のネットワーク環境では、ネットワークだけ、あるいはシステムだけを障害管の対象とすると多くの不都合が生じてしまう。管理対象のネットワーク規模が大きくなればなるほど、管理作業の分業化が進む。ネットワーク機器とシステムを、別々のグループが管理することも多い。しかし、これらのグループが相互に連絡せずに管理作業をおこなうような体制は望ましくない。グループを分けたとしても、両者のあいだで情報を共有したり、協力して作業を進めるべきである。
 障害管理作業をとして、現在のネットワーク環境の構造的な問題点が明らかになることもある。このような場合、ネットワークの構成変更や、将来的なネットワーク導入計画へのフィードバックが求められることもある。したがって、障害管理に携わるグループは、ネットワークの構成設計を担当しているグループと密接に連携できる体制を整える必要がある。
 以上の点をまとめると、管理体制を作る際のポイントは次のようになるだろう。

1.障害管理グループが、ネットワークおよにシステムのどちらに発生した障害にも対応できる体制を作る。
2.障害管理グループは、ネットワークの構造的問題点を解決するために、ネットワーク構成を設計するグループと連携して作業を進める。

●フロントエンドとバックエンド
 障害管理には、次のようなさまざまな作業がある。

◆ユーザからの報告を受け、発生した障害を確認する。
◆障害が発生した現場に赴き復旧作業をおこなう。
◆障害の原因を解明する。
◆障害の原因解析をもとに、障害に対するシステムの改善方法を検討する。
  
 このように、できるかぎり迅速に対応すべきものと、時間をかけてじっくり取り組んだほうがよい作業が混在している。そこで、障害管理グループを構成する際は、人的な余裕があれば全体を2つのグループに分け、障害復旧を担当する "フロントエンド・グループ" と、原因解析などの比較的時間に余裕のある作業を担当する "バックエンド・グループ" を作ったほうがよい。
 この2つのグループに属するスタッフを定期的に入れ替えるようにすると、副次的な効果がある。

◆現場での障害復旧は、一般にストレスのたまる作業である。深夜や早朝の作業も多く、ユーザからの苦情を直接聞く立場になることもある。このような作業をつねに担当するのは、精神衛生上あまりよくない。ローテーションにより、定期的に別の仕事に携わることができるので、ある程度はストレスの蓄積を抑えられる。
◆バックエンド・グループの作業を担当することで、システム全体、あるいは使用している技術を理解する機会が得られる。このような知識は、障害復旧の際にも大変役に立つ。

●メンテナンス・アワー
 最近は、業務に直結するネットワーク利用が増えてきたので、サービスをむやみに停止することは避けねばならない。ソフトウェアのバージョンアップなどの作業も就業時間内にはできず、深夜や週末にまとめておこなう体制になっているところが多い。しかし、セキュリティ・ホール対策のためのバージョンアップなど、緊急性を要する作業もある。このような場合のために、作業を迅速に進める体制を整える必要がある。
 このようななかで考案されたのが、 "メンテナンス・アワー" である。これはいわば定期点検のようなもので、事前に決められた日時であれば、ユーザーに通知したうえでシステムを停止できるような体制である。
 管理者はもちろん、ユーザや管理職の合意を得たうえでこのようなメンテナンス・アワーを決めておけば、システムの保守管理のための時間が確保できる。

●トレーニング
  障害管理の一環として、必要な知識を修得するためのスタッフのトレーニングについても検討する必要がある。
 たとえば、ネットワークやシステム管理関連の会議や展示会などに併設されるセミナーやチュートリアル、あるいはベンダー各社が主催するセミナーなどにスタッフが参加できるようにしておいくとよい。
 自由にクラッシュさせることのできるシステムを用意するのもよい。マニュアルを読むだけでなく、なにをしたらシステムがダウンするのか、どのようにすればファイルシステムが復旧できるのかを体験することも重要である。ソフトウェアのテストなどにも使えるように、通常利用しているシステムと同じ構成にしておくとよい。

●管理のアウトソーシング
 従来はシステム管理の委託が主流であったが、最近ではネットワーク管理のアウトソーシングも可能になってきた。ベンダーの管理会社やシステム・インテグレータ、あるいはネットワーク管理専門のベンチャー企業が、この種のサービスをおこなっている。
 これらのサービスは、管理業務に新たな人員を採用できなかったり、ネットワークの拡大によって管理作業のオーバーヘッドが増えたようなところで有効だろう。

障害管理で使うツール類
 当然のことながら、障害管理ではいろいろなツールを用いて復旧作業をおこなう。以下では、一般的なツールについて説明する。

●ネットワーク構成図
 障害管理では、管理対象のネットワークの構成情報が不可欠である。一般には、SNMPのNMSが表示するネットワーク構成図でもよい。しかし、障害の影響が広範囲におよぶ場合には、この種の構成図は役に立たない。万一に備えて、ネットワーク構成情報をファイルに記録しておいたり、紙に印刷したものを保管しておくとよい。

●古典的ツール
 ネットワークの障害管理における古典的ツールには、

◆ping
◆traceroute
◆telnet

などがある。
 一般には、まず ping で障害が発生していると思われるシステムへのネットワーク到達性を調べる。反応がなければ、同じセグメントの別のシステムに対して ping を実行する。それでも反応がなければ、traceroute を使って途中のどのゲートウェイまで到達できるかを調べ、障害箇所の特定に務める。途中経路まで到達していれば、最後に到達できたルータに telnet でログインして、状況を調べればよい。
 システムが ping には反応するが、特定のサービスが使えない場合にも、telnet でそのシステムにログインして状況の把握に務める。sendmail や WWW サーバ、POPサーバなどの管理では、telnet を用いてそれらサーバのポートに直接接続し、プロトコルで規定されているコマンドを入力して反応をみるといったこともする。
 ping や traceroute でも問題が特定できなければ、そのシステムが設置されているところまで足を運んで調べるしかない。一般に、同一セグメントのほかのシステムまで到達できるのなら、障害はそのシステムで発生しているはずである。
 このように、障害の症状をとりあえず把握するためならば ping や traceroute、telnet でも十分役に立つ。

●ラップトップPC
 ネットワーク機器を直接保守する場合には、その機器のコンソールに端末を接続して状態を調べることが多い。それに備えて、ラップトップPCと RS232C ケーブルを用意しておくとよい。ルータなどのコンソールとして利用するだけなので、i286の旧いラップトップPCに端末エミュレータを入れておくだけで十分だ。
 RS232C ケーブルは、ストレート接続とクロス接続の2種類を用意し、コネクタ形状を変換するアダプタも準備しておく。DSub-25、DSub-9 のそれぞれオス、メスの変換コネクタがあると重宝する。
 ラップトップPC、ケーブル、変換コネクタをまとめておけば、いざというときに迅速に対応できる。

●トラブルチケット
 多くの組織で障害管理に使われているツールの1つがトラブルチケット(trouble ticket)システムである。とくに大規模な組織内ネットワークをもつ企業では、このシステムを利用しているところが多い。また、ネットワーク管理グループが多人数だったり、地理的に分散した複数の管理グループがあったり、あるいは3交替制などで24時間管理をしているような場合にもよく使われている。

トラブルチケット・システムとは

 トラブルチケット・システムは、もともと大規模なシステムの保守管理やカスタマ・サービス、ヘルプディスク・サービス(help-disk service)で利用されていた情報管理システムである。
 その考え方自体はごく単純である。障害に関する各種の情報を1つのデータ(チケット)として記録し、これにもとづいて障害管理作業を進める。典型的な作業手順は次のようになる。

1.チケット生成
 障害がみつかると新しいチケットが作られる。通常、チケットには以下の情報が記載される。
◆障害の発見者
◆障害の発生時刻
◆障害の状況

 この段階のチケットは "オープン(open)" と呼ばれる。

2.チケットの割当て作業
 オープンなチケットは、障害に対処する作業者に割り当てられることもある。この段階で、チケットは "割当て済み(assigned)" になる。作業者は、チケットに記された情報をもとに障害復旧作業をおこない、チケットに作業ないようの記録を追加していく。

3.チケットの再割当て
 いったん割り当てられたチケットが別の作業者に割り当てられることもある。この場合には、割当てを変更した理由をチケットに記録したうえで、いったんオープンの状態に戻し、再度割り当てをおこなう。

4.チケットのクローズ
 障害復旧作業が完了した段階で、チケットの状態は "クローズ(close)" になる。

 以上の手順は概要であり、実際に利用されているシステムの多くは環境に合わせてカスタマイズされている。たとえば、チケットの状態がより細かく定義されていたり、障害対応の優先度やチケットの状態が変わった時刻などの情報が記録されていたりする。

トラブルチケット・システムの利点

 障害管理におけるトラブルチケット・システムの利用には、下記のような利点がある。

◆障害対応の見落としが減る
復旧し忘れた障害が発見しやすくなる。チケットに状態遷移の時刻が記録されていれば、割当て後一定時間が経過しても解決されていない障害をみつけやすい。つまり、障害への対応状況の把握が容易になる。これは、カスタマー・サービスなどでトラブルチケット・システムが使われる大きな理由の1つである。

◆障害の解析に役立つ
管理対象のネットワークで、障害の種類や頻度、障害が多いシステムなどを解析する場合、トラブルチケット・システムに蓄積された記録が役に立つ。このような記録は、システムの再設計や構造的要因による障害を解決する際の参考にもなる。

◆人事管理に役立つ
復旧作業に要した稼働時間の計算や、障害対応に関するスタッフごとの得意、不得意などの見極めにも便利である。また、障害管理スタッフの増員の必要性を示すデータとしても使える。

トラブルチケット・システムの実際

 トラブルチケットとして、いろいろなものが使われている。
 一番単純なのは、連番を付けたファイルに情報を記録していく方法である。労力もそれほどかからず、特別なソフトウェアも不要なので、管理対象が小規模なネットワークで、それほど大きな障害が発生しない場合にはすぐに利用できる。
 WWWシステムを使ったシステムも簡単に作れる。データーベースサーバをバックエンドに用意し、データベースとのインターフェースを作成する。トラブルチケットへの入力、情報の追加、一覧表示などをおこなえるようにしている組織も多い。


●その他の便利な道具

 Ethernet モニターなどのデータリンク・モニターは、ネットワークの正確な状態を把握する際に便利である。ただし、高価なので、いきなり購入するのでなく必要に応じてレンタルするとよいだろう。
 携帯電話やポケットベルなどを用いて、管理者とつねに連絡がとれる状態にしておくことも重要である。ポケットベルは、SNMPのNMSなどにドライバを設定し、ネットワークに異常が生じたときにNMSからポケットベルに直接通知する仕組みにしておくと便利である。利用料金も安価なので、ネットワーク管理によく使われている。


一つ前へ