ネットワーク管理者の日々の業務には、ユーザーからの問い合わせに対する処理も含まれる。たとえば、公開しているWebページのコンテンツの内容については、それぞれの担当者に転送するにしても、リンクエラーなどに関してはネットワーク管理者が状況を確認して対処を行なうことになる。
ところが、いろいろ調べていくと、何のことはない、リンク先のURLが次のようになっていたという経験を持っている管理者はどれくらいいるだろうか?
http://ntsrv/index.html
この“ntsrv”とは、内部のネットワークに繋がっているサーバの名前らしい。社内でテストする分にはこの名前だけでリンクを貼ることができ、一見問題がないように見えたので、そのまま公開されてしまったらしい。本来なら“ntsrv.hogehoge. co.jp”のようにドメイン名を付加した形に修正する必要があるものだ。さらにネットワークの構成にもよるが、会社のDNSに登録して外部からアクセスできるようにファイアウォールの設定をする、といった手続きが必要になるはずである。
ここで挙げた例は実に単純なトラブルなのだが、なぜこれでエラーになるのか、コンテンツの作成者にはなかなか理解してもらえない場合がある。自分のところでは見えているのだから、見えないユーザーの設定がおかしいのだ、といった極端な結論になってしまうことも実際にあるようだ。
分かりにくいネットワーク技術
DNSのおかげで、多くのユーザーはIPアドレスなどという非人間的な数字の羅列の存在など知ることなしに、気楽にWebを表示し、メールを出すことができる。DNSという言葉自体、一度も聞いたことがない人のほうが多いだろう。そもそもDNSのようなネットワーク関連の技術は、一般のユーザーがネットワークを利用するうえでは理解する必要がないことがユーザーにとってのメリットなのだ。
しかし、Webコンテンツを作成するとなると話は別だ。社内ネットワーク上のテスト環境ではうまくいっていたリンクを外部からうまく参照させるためには、DNSを知っていればドメイン名も必要だということが理解できるが、それを知らなければ「いまの環境で繋がるものがなぜ繋がらないのか」ということが理解できないだろう。先のようなURLが登場することも、自然のなりゆきかもしれない。
例にあげたトラブルは比較的実害が少ないといえばそれまでだ。しかし、本文中のWindows 2000が原因のトラブルも、突き詰めて考えれば根幹の部分は同じようなものではないだろうか。
コンテンツ作成者や一般ユーザーへのネットワーク技術の啓蒙活動や研修などを普段から行なっておけば、多くのトラブルを減らすことが可能だろう。これが管理者の業務かどうかは意見が分かれるところだが、どうせ遅かれ速かれ引っ張り出されることになるはずだ。管理者に必要な仕事として、常日頃からユーザーとコミニュケーションをとり、ときには講習会を開くなど考えてもいいのではなかろうか。
