IEEE のネットワーク規格

作成日:2010-05-15
最終更新日:

ネットワーク設定の失敗とネットワーク規格

IEEE という文字を見たことがあるだろうか。 通常、アイトリプルイーと読むこの4文字は、 アメリカに本部をおく電気・電子・情報関係の団体である。 Wikipedia による IEEE(ja.wikipedia.org) も参照のこと。

さて、ある人から聞いた話を紹介しよう。かりにこの人を A さんとする。 A さんがネットワークの技術者として働いていたときの話である。 同僚とともに、ある顧客向けシステムの立ち上げを現地で行い、 ネットワークの設定をすることになった。 予定では1日でできるところが、 どういうわけかネットワークがつながらず、その日に終わらなかった。 原因がどうしてもわからない。

翌日になっても原因がまったくわからず、行う調査がみごとに空振りで 時間が無為に過ぎていった。

3日めに突入した。本番は翌日である。だからこの日に動かさなければどうしようもない。 顧客からはケチョンケチョンに言われるし、勤務先の本社からも怒りの電話がかかりまくる。 どうしようもないプレッシャーを感じながら、 何度も確認したシステムの設定マニュアルを再度見た。 すると、マニュアル表記の設定と実際のシステムの設定が異なることに気づいた。 マニュアルには、設定する文字列は IEEE の 802.2 とあるが、 A さんたちはこれを 802.3 だと見間違えていて、 誤ってシステムに 802.3 と設定していたのだった。 マニュアルの通り 802.2 と設定し直したところ、 システムは正常に動いた。

失敗の原因と再発防止策

なぜこのような誤りが起こってしまったのだろうか。 それは、逆説的なようだが、A さんたちがネットワークのプロだったためである。 ネットワークのプロは、数々の規格を覚えている。 その中でもっとも大事な規格はイーサネットの規格である IEEE 802.3 である。 だから、設定すべき文字列は 802.3 だと思い込んでいたのだ。 ところが、実際に設定すべき文字列は 802.2 だった。 IEEE 802.2 はあまり知られていないが、 イーサネットや、イーサネットとは異なるネットワークの一種であるトークンリングなど、 各種ネットワークをまとめる上位規格である、 論理リンク制御 (Logical Link Control) を表している。 このシステムは、イーサネットのほかにトークンリングも含めて管理するシステムだったので、 上位システムとしての規格を指定する必要があったのだ。

では、再発防止のためには何をすればよいのか。それは難しい。 マニュアルをよく見る、ということは言えても、 一度痛い目に会えばわかるが初めての体験でうまくいくようにするのは大変だ。 802.3 のような文字列を覚えなければよい、というのは全くの誤りだ。 プロであれば当然のように覚えなければいけない。 だからといって、プロならば 802.2 まで覚えなければいけない、 というのも別の極端な意見だ。 プロでも覚えることには限界がある。 802.2 より重要なことは当時でも多くあった。

一つの方策は、推理力を磨くことである。ネットワークが機能しない場合、 何が原因なのかを追っていく力を身に付けることである。 ネットワークの例では、問題はプロトコルなのか、ポート番号なのか、たんなる断線か、 などなど、ネットワークの階層を手がかりにして類例から原因を探り、 想像を働かせることがプロの必要条件となるだろう。

別の方策としては、絶えず条件を疑うことだろう。 当然という思い込みを見直すことが、結局は早くなるということだ。

私の失敗談

先に偉そうに述べたが、自分はネットワークのプロではない。 それどころか、仕事のプロというには恥ずかしいことをやらかしている。 その失敗を話そう。

最近、あるシステムを勤務先で導入した。そのシステムは、 あるハードウェア1台とサーバ1台、クライアント複数台から構成される。 ハードウェアがスイッチを押されるなど、適当なタイミングで起動されると、 ハードウェアからサーバにデータが転送され、 さらにサーバから各クライアントに、 データが転送されサーバに保管されたことを知らせる、 という仕組みである。 上記システムの管理ソフトウェアが導入された日、 システム技術者が来社し、設定して正常に動作することを私が確認した。

その翌日か翌々日のことである。どういうわけか、ハードウェアを起動しても、 サーバにデータが転送されない。故障ではないかと思い、 わたしも技術者のはしくれであるから、 管理ソフトウェアの設定を見たり、設定したりしていたが、 全く状態が変わらず、データが転送されないままである。

故障に気づいた日は解決を諦め、翌日午前中も確認したが、 やはり動作しない。ついに営業を呼んだ。 営業は、本日導入システムの技術者を向かわせるという。 技術者が30分後に到着し、あちこち調べてもらった。30分してもわからないようだ。 その技術者は会社に携帯で電話をずっとかけたままだ。

私は立会を中止し、調査作業を技術者にまかせ、別の仕事を 30 分行った。 30 分後、再度私が技術者に確認したところ、原因がわかったという。 プロトコルが誤っていた、というのだ。詳しくいうと、 初期設定時は、ハードウェアとサーバの間は、 http で通信を行っていた。 しかし、故障した状態では、プロトコルは http ではなく https になっていた、 という。https はセキュアなプロトコルであるが、 ある種の証明書がなければ使えない。なぜプロトコルが変わっていたかわからないが、 ともかく、その設定だったために動かなかった。http に戻したら、正常に動作した。

ということで、推理力をつけよう、絶えず疑おう、ということは、 自らへの戒めでもあるのだ。(2010-05-15)

まりんきょ学問所品質の部屋 > IEEE のネットワーク規格


MARUYAMA Satosi