今日の恭麿
HIEDA NET Corpration
 > これは変だよ  > フューズが切れたときに・・・


 

フューズが切れたときにどうするか?ということの考察。

FUSEが切れたとき、そのFUSEが悪いのですかね? ここを見誤ると、

  • FUSEが切れなくなるまで、FUSEを交換する。
というオバカなことをする。かつて、電子機器修理をしていたときに、別な部署から、
  • 「何度もFUSEを交換しましたがすぐに切れます。」
という修理依頼がきた事がある。一回目のFUSE切れのときに持ってくれば、OUTPUTトランジスタの交換で、時間も費用も早く・安くすんだであろうことは想像がつく。何度もFUSEを交換ということは、その交換回数 × FUSEが切れるまでの時間 短絡状態の回路に電流が流れたので、電源トランスまで焼き切れてしまい、時間も費用もずいぶんかかったということがある。

一般の人は別にして、この企業では電子機器の取り扱いを従業員が知っていなければならないのに、それを周知していない・従業員教育をしていない、ということがわかる。それをしていればかかる費用は発生しなかったのだ。

FUSEは回路保護装置(部品・回路)である。FUSEから先の内部で障害が発生し、回路が短絡と同等状態と見なせる場合に、それ以上に障害を拡大させないために、FUSEで回路を遮断するするのだ。

さてここから先の話は、読者に多少の想像力とスキルを要求する。

今まで述べたFUSEの話をたとえとして用いる。

何らかの障害対処をするときに、何の対処もとらずに、うまくいくまでただただ同じことを何度も繰り返す、という人たちがいる。ひとつでも少しでも、何らかの対処・変更を1つずつしてあたらないと何の解決にもならないということがわかっていないらしい。無駄に時間だけが過ぎてゆく。

エピソード1

たとえば、Windows上でJP1やOpenViewを動かして、

  • 今まで取得してきたファイルが「用無し」となり、ハードディスクのごみとなっていても、かたずけない
  • パーテーションがCドライブとDドライブと分けられていて、Cドライブは「空きがない」と警告が出ていて、Dドライブは未使用だとしても、Dドライブを使用しようとしない、
  • OSの構成をデフォルトのままで、環境変数TEMPとTMPが狙っている先がCドライブのどこかだったり、pagefile.sysがでっかくCドライブにいたり、
ということをしていて、監視対象機器の全MIB取得を試みて、メモリ参照エラーなどが出て、成功しないときに、
 「ハードディスクをフォーマットして、バーテーションを再度設定し、OSを再インストールしてから、環境変数TEMPやTMPをD:\TEMPに設定したり、ページングファイルをD:\に移動する、取得データはD:\workにするなど、構成をカスタマイズ(チューニング)し、きれいな状態でアプリを再インストールしたら?」
というアドバイスに耳を貸さず、
 「何とかのデータは退避させていないから云々・・・」
などと、さっさとやればすぐ済むことをしないで、できない理由・やらない理由をあげるばかりの言い訳をして、汚れた壊れた状態で全MIB取得を試みてはまた失敗する、ということを四ヶ月繰り返してきているのに、何の進歩もないというのは、

バッカじゃ、なかろうか!

と思う。メンバー個人のスキルにも問題があるだろうが、このようなまともなことが通らない組織の運営のほうが大きな問題だ。

※ 実際に作業をした方を問題にしているのではないこと注意。

なんで失敗するのか?を目的にするのは、手段と目的を取り違えることだが、全MIB取得を目的としていてゴールに達成できないときに、まず起きている障害を回避しないと、

ゴールにたどり着けないじゃないか!

ということに早く気づくかないといけない。それを
 「もう時間がないから・・・」
 「OSの障害切り分けは目的ではないので・・・」
などと言っていても、根本的に環境を整備せず、失敗がまた起こるという可能性が高いのに、全MIB取得を試み、やっぱり失敗した、ということを繰り返す。急がば回れで、ハードディスクをフォーマットして、バーテーションを再度設定し、OSと再インストールして構成をカスタマイズ(チューニング)し、きれいな環境を用意すべきじゃないか?

土台(プラットフォーム)が曲がっている上にまっすぐ柱を立てようとするにはとてもエネルギーが要るが、土台がきちんと水平と垂直がわかるようになっていれば、まっすぐに柱を立てることも簡単だ。

ハードディスク容量は有限だ!

Network Analyzerなどの測定器で取得したデータはそのままにしておかず、別媒体にコピーしたら消去すべし!


エピソード2

たとえば、webサーバー(+ WMS)で己自身の名前解決に失敗する場合、訳もわからず、さまざまに設定変更をしても、何の解決にもならない。ホスト名表示に在ってはならない重複があるような、おかしな振る舞いがあるときに、その時点でホスト名を含めたTCP/IP設定をまずまともに設定されているかどうかを確認しないといけない。おかしいことをおかしいと気づかないといけない。しかし、その確認をしないで、あてずっぽにwebサーバー(+ WMS)の各設定ばかりを闇雲に変更しても、解決できない。必要なのは、

  • ここがおかしければこうなる、という正確な知識
  • こんな振る舞いをするのは多分ここがおかしいんじゃないかな、という正しい・まともな仮定条件を設定できる推理力・想像力
  • 更にそれを積み重ねても矛盾のない話を構成できる論理的な思考力
である。こうした力を、生まれもって効率よく身に付けられるセンスを持った方もいれば、相当な努力を必要とするものもいる。それは個人差である。相当な努力を必要とする種類の人たちが、こうした力を身に付けられるかどうかは、人に求めるものではなく、本人の努力以外に解決策はない。書籍やインターネット検索もせず、安易にどうすればいいの?と結果ばかりを先に求めるのは、何の解決にもならない。更に、その安易な姿勢を指摘されると、立腹する・ふてくされるというのでは、救いようがない。結果をどうしたら得られるか? 結果にたどり着くプロセス自分で考えられないとエンジニアと称してはいけない。
 「どこをクリックしたらいいですか?」
 「次へをクリックしていいですか?」
程度は、自分で解決できなければならない。その程度を質問するようではエンジニアではない。当然、間違ったクリックをすれば、怒られる。

安易に人生の先輩を辞書代わりに使おうとする態度はとても失礼なことなのだが、それにも気づいていない。失礼なことをされて怒るのは理不尽なことではなく当然である。自分が失礼なことをしているのに、先輩に怒られて
 「すぐ怒る。やさしくない。」
と非難する人のほうが、よっぽど理不尽で勘違いをしている。

1ステップずつ、手順が済むごとに、

そこまでの正常な動作を確認してから、次に進め!


全て終えてから確認すると、正常動作しなかったときに、どこが原因なのか探すのに苦労するぞ!


11 MAY 2004 追記:
 世の中、情報は必要なときに向こうからやってくるものだ。昨日の日経ITProが
このような記事を載せている。是非目を通しておいて貰いたい。
11 MAY 2004 追記:ここまで
21 MAY 2004 追記:
 更に、お勧めリンクとして、 第14回 教えられ上手になるテクニックを掲げる。是非目を通しておいて貰いたい。
21 MAY 2004 追記:ここまで

初出:17 APR 2004
更新日:21 MAY 2004



 (C)2003 HIEDA NET Corporation All rights reserved.