<< 1999年7月3日開催 第4回 NT-Committee2 関東勉強会 講演資料 >>
システム管理者の基本作業としてトラブル対応があります。
ネットワークとかハードウェアとかを構築しているので「作ったからには責任を持つ」という考えは分かりますが、既に構築されているシステムに対して新規に配属になったとか、OSやらアプリケーションやらの動作については、勉強しておく必要があります。
まずは、何が起こっているかを正確に把握し、「そのトラブルは至急対応する必要があるかどうか」を見極める必要があります。
トラブルを報告してくる人は十中八、九は「至急対応してくれ」と言ってきます。
暇な場合は即対応すればいいのですが、他の作業を抱えている場合は優先度付けが必要になってきます。
まずは、何が起こっているかを正確に把握しなくてはなりません。
何が起こっているかとか何をしたら起こったかということが、(本当に)正確に把握できれば殆どの場合は解決したも同じです。
状況を正確に把握しないで勝手な先入観で対処してしまい、かえって被害を大きくすることもままあります。
私達が実際に使用してる障害票を見て下さい。
主にハードウェアトラブル対応時に使用していますが、必要最低限の聞き出す事項が並んでいます。
相手の名前とか部署とかは、改めて聞くまでもないですが当たり前の項目を聞いている時間で相手の気持ちが落ち着いてきて、トラブルの状況を正確に話せるようになります。
また、トラブルの発生には人為的ミスが絡んでくることが多く、連絡者は「ひょっとして私が悪いことをしてしまったのだろうか」と思い込んでいる場合もあります。
これは「何をしましたか」と聞いたときに「何もしていない」と答える姿勢に如実に現れています。
何もしなければ何も起こりませんから、何かをしている場合が多いです。
殆どの場合は連絡者が当事者のですが、その人を責めてもトラブルは解決しませんので、迅速に対応するために「どこに責任がある」かとか「誰のせい」だとかの質問は絶対してはなりません。
そして「そのトラブルは至急対応する必要があるかどうか」を見極める必要があります。
トラブル対応には大きく分けて「即座に対応しなければならない場合」と「その人個人のことなので状況を良く聞いて適切に対応する場合」があると思います。
トラブルを報告してくる人は十中八、九は「至急対応してくれ」と言ってきますが、他の作業も抱えているので優先度付けが必要になってきます。
トラブルにはハードウェア障害とソフトウェア障害があります。
ハードウェアが故障していればどんなにソフトウェアの設定を見直しても無駄です。どうやってハードウェア障害とソフトウェア障害を見分けるか。これは、「確実に動作しているハードウェアと交換する」ことです。
ネットワークも同様にして「確実に動作しているハードウェア・ソフトウェアと交換する」ことで、故障の範囲を狭めていくことで、故障個所が分かるでしょう。
電話のみで対応を済ませたりせずに必ず現場に足を運びます。
トラブルが一度起きたと言うことは、同じ様なトラブルがまた発生する可能性があるわけですので、なぜ発生したかを追求しておく必要があるからです。
ケーブルが抜けていたといったトラブルなら挿して下さいとの指示で一件落着と思われがちですが、もう一歩突っ込んでなぜ抜けてしまったかを調査しておきましょう。ジャックの爪が折れていて抜けやすくなっていたとか、ケーブルが机に引っかかっていて抜けやすくなっていたとか、対処療法でなくて根治療法を心がけましょう。
プリンタのトラブル連絡が入ったら最初にすることは、そのプリンタのスプールを確認することです。印刷エラーがあったらまずそれを削除する。次のスプールを見ていてプリントできたら「もう一度印刷してもらえますか」と返答する。その作業をしている間に「3番プリンタジャムっているかも知れないから見てきて」と部下を現場に行かせます。これは実際にジャムっているかどうかが問題ではなく、「システム管理者の人はちゃんと対応しくれる」という姿勢を見せるためです。
プリンタの印刷に関するトラブルの殆どは、プリンタ自身にあります。紙のジャム、紙切れ、トナー切れが殆どのトラブルを占めるでしょう。この程度のトラブル解決には特別な技能は必要ないので、現場の利用者に対応してもらうのが一番です。トナーは再利用が叫ばれていますので、回収箱を用意する場合もあるかも知れません。プリンタに搭載されているメモリ以上のデータを受け取ると、ハングアップするプリンタも希にあります。大容量な画像でも印刷したらハングアップするのか、それとも少しづつでも印刷するのかを事前に確認しておく必要があります。
また、Ａ３用紙がないプリンタでＡ３を印刷しようとするとハングアップするプリンタもありますので、事前に確認が必要です。Ａ３用紙が印刷出来るプリンタで印刷していたがそのプリンタがなんらかの理由で使用できないので別のプリンタに印刷したが、そのプリンタはＡ３未対応だったという場合もあります。
プリントサーバのスプールドライブの容量不足により、プリントが出来ない場合もあります。スプールドライブは、インストール時の標準ではシステムドライブに設定されているため、「OSインストール+ページファイル容量」しか用意していないとアッと言う間に容量不足になります。これはスプールドライブを変更することで解決できます。
WindowsNT3.51 では、デフォルトで %SystemRoot%\Spool\Printers\
配下に作成されますので、レジストリを変更します。
HKEY_LOCAL_MACHINE ハイブの
SYSTEM\CurrentControlSet\Control\Print\Printers
にデータタイプが「REG_SZ」で、名前が「
DefaultSpoolDirectory 」のキーを作成します。そのキーの値に設定したパスがスプールディレクトリになります。マシンを再起動し、正しくスプールディレクトリとして動作していることを確認しておきましょう。
WindowsNT4.0
では、スタートメニュの設定からプリンタを選択し、[ファイル]-[サーバのプロパティ]にて詳細設定タブにあるスプールフォルダにディレクトリを入力します。
また、スプールフォルダにはゴミが残っている場合があります。プリントキャンセルしたりプリント中にサーバがダウンしたりした場合に残ることがあるようです。ファイルの作成日付を確認し、古いファイルは消してしまう定常作業の時間を考えましょう。
まず、サーバとクライアントは電気的に接続できていなければ、絶対アクセスできません。
これは当たり前ですが、その当たり前を見落としてしまい散々サーバやクライアント設定を見直したりして無駄な時間を使うことがままあります。
サーバにアクセスできなくなってという連絡を受けたら、最初にやることはネットワークのLANケーブルをたどって電気的に接続出来ているかどうかを確認することです。
まず、PCのNIC(Network Interface Card:LANカード)のLEDを確認します。LEDは通常緑色で点滅していると思いますが、そうでなかった場合、
1)NICが故障している
2)LANケーブルが断線している
3)HUBのポートにケーブルが刺さっていない
4)HUBが故障している
が考えられます。HUBのポートランプが緑色で点滅していない場合も、同じ理由です。
PCとHUBが離れていて、ケーブルをたどれる状態ではない場合(多くの現場はそうですが)、接続されていると思われるHUBのランプを自分は見て、利用者にPCの電源を投入してもらいます。電気的に接続されている場合はNICがOSから認識されていなくてもランプは点灯します。
電気的な配線に問題ないことが分かったら、次はクライアントのネットワークの設定を見直す必要があります。
最初に使うコマンドはipconfigコマンドです。コマンドプロンプトから「ipconfig /all」と入力し、クライアント機のIPアドレス、サブネットマスク、デフォルトゲートウェアを確認して下さい。WINSを導入している場合は、WINSサーバのアドレスも確認します。
次に、pingコマンドを使用します。
1)「ping localhost」と入力します。 Replyが返ってくればネットワークドライバは正常動作しています。返ってこなかった場合、OSがNICを認識していません。NICドライバの再インストールを行いましょう。
2)「ping クライアントのIPアドレス」と入力します。Replyが返ってくればNICは正常動作しています。
返ってこなかった場合、NIC自身の故障が考えられます。NICを取り外し、正常なマシンに取り付けて動作確認を行います。それでもダメだった場合はNICの故障と判断していいでしょう。
3)「ping サーバのIPアドレス」と入力します。
Replyが返ってくればクライアントとサーバはソフトウェア的に接続できています。Exploerのネットワークの接続でパスに\\IPアドレスと入力し、ユーザIDとパスワードを問い合わせてくるようでしたらそれは繋がっていると言うことです。返ってこなかった場合は、どこかのルーティング情報が間違っている可能性があります。
4)「ping
サーバのコンピュータ名」と入力します。Replyが返ってくればクライアントとサーバは名前解決の上で接続できています。さっきのトラブルは気のせいとして片づけても構わないです。返ってこない場合は、名前解決が出来ていないということになりますが、なぜ名前解決が出来ないかについては、多くの原因が考えられますのでここでは省略します。
また、以下のことも同時に確認していくと、トラブルの原因がよりハッキリすると思います。
1)問題のPCが接続されているHUBに接続されている他のPCはサーバにアクセス出来ているか。
2)問題のPCが接続されている周りの人は、他のPCはサーバにアクセス出来ているか。
電話で対応せざるを得ない場合は、先ずpingを打ってもらうしかありません。ですが電話口で「ピング打ってみて」では通じないので、「スタートメニュからプログラムをたどってコマンドプロンプトを選択して下さい。ぴー・あい・えぬ・じー・スペース・［アドレス］・エンターと入力して下さい。」と伝えた方がいいでしょう。合わせて、exitで抜けるということも。
遠隔地のマシンのコンソールをまさに自分のマシンの表示させて、まるでロボットアームのように操作できたらいいなぁと思うことがよくある。リモートコントロールソフトとは、離れた場所にあるリモートマシンのデスクトップ画面を、自分のマシンにウィンドウ表示させて、リモートマシンの操作を可能にするソフトウェアです。自分のマシンのディスプレイにはリモートマシンとローカルマシンの両方の画面を表示されます。このソフトウェアのネックは画面情報を送信するのでそれなりの帯域が必要(128K程度ないと実用にならない)だと言うことと、このソフトウェア自身が最大のセキュリティホールになるということです。定期的にユーザIDとパスワードを変更する必要があります。
1)VNC(Virtual
Network Computing from AT&T Laboratories Cambridge)
「VNC」の最大の特長は、フリーソフトながら対応プラットフォームが多いことです。LinuxなどのUNIX系OS、Windows(95/98、NT、CE)、Macintosh及びJavaに対応し、互いに異なるプラットフォームのマシンをリモートコントロールできます。MacintoshをWindowsから操作したりその逆も可能です。コントロールされる側のマシンに常駐またはサービスとしてソフトウェアを動作させ、コントロールする側のマシンにはコントロールソフトを起動させます。メニューコマンドで[Send
Ctl-Alt-Del]などの特殊キーの組み合わせを送信することもできます。HTTPプロトコルにも対応しており、ポート番号5800でアクセス可能です。
英語圏のソフトウェアなので、Webを見ただけじゃあインストール方法とか使い方がよく分からないと思います。インストール手順はここに。
2)DeskTopOnCall
VNCが専用のコントロールソフトを必要とすることに対して、DTOCはコントロールする側のソフトはWebブラウザです。つまり、コントロールされる側で動作しているソフトがHTTPサーバになるという感じです。コントロールされる側のOSはある程度限定されますが、コントロールする側はJAVAを動作せられるブラウザがあれがいいことになります。DTOCは商用パッケージですが、インターネットから時間制限付きの体験版をダウンロードできるので試しに使うことが出来ます。
他にもたくさんのリモートコントロールソフトがありますので、各自で探してみるといいでしょう。
システム管理者も医者と同じで、治療(手術?)が終わって完治してもその後の様態は気になるモノです。
場合によっては再発防止策が必要な場合もあるでしょうし、たまたまその人だけ発覚したがいずれ広まる可能性のあるトラブルに対しては事前に手を打たねばなりません。
どんなトラブルにも言えることですが、誰が悪いかをハッキリさせていけません。
誰が悪いかをハッキリすることによってそのトラブルが解決できたり今後の再発が防止できることは希です。医者がどんな酔っ払い患者に対しても平等に扱うように、システム管理者はシステムに巣くう病気を治す医者と心得るべきです。
また、常に最終的に迷惑する人の事を考えて対応するようにしましょう。
一般的にはそのPCがネットワークサーバに接続できないと、その本人の仕事が止まり、そのプロジェクトの進捗に影響を与え、その先にあるお客様が迷惑することになります。
自社内の社内システムであった場合も、その本人への影響は目で見える形で現れますが目に見えない形で会社全体に影響が及ぶはずです。警官が社会に与える影響を考えて行動するようにシステム管理者は会社に与える影響を常に頭において行動するようにしましょう。
最後に、同じトラブルは二度と起こさないために何らかの手を打ちましょう。風邪を引いたらか薬を飲むのでなく風邪を引かない体質作りが本来システム管理者が目指すところです。一度発生したトラブルは出来る限り克明に記録し、どうして起きてしまったのか、どうすれば起きなかったのか、を常に考えるようにしましょう。大抵のトラブルは何度でもおこるものなので、トラブル対応をルーチンワーク化し、システム管理者は次期システムの企画書とか全社的なネットワーク一新プロジェクトに参画するとか、本来の作業に一日も早く戻れるように。
<< 1999年7月3日開催 第4回 NT-Committee2 関東勉強会 講演資料 >>