自分の手を汚さない人達って、いるよね。

Episode1

この夏にSIerになりたがりの某通信会社でアルバイトした。某金融機関のデータセンタに常駐して、ネットワークの運用管理である。
※　このSIerになりたがりの某通信会社という語は、ここの正規従業員の方が言っていた言葉である。

で、SIerになりたがりの某通信会社の正規従業員が、ネットワークの設計と機器の導入をしているのだが、運用管理は、エンドのお客様からは某通信会社の従業員と見えるが、その実態は業務委託できた協力会社の人ということである。

これが理由なのかわからないが、

• 運用を考慮していないネットワーク設計
  • 管理ネットワークを設けず、FireWallの外側のメンテナンスはすべてシリアル接続
  • 管理ネットワークを設けず、FireWallの内側のメンテナンスはすべてユーザトラフィックの流れる経路を利用
  • ポートディスクリプションを設定しない
• 運用を考慮していないケーブル配線
  • 24回線や12回線などのマルチケーブルを利用せず、同一経路の複数回線もすべて単線のCAT5eケーブルで敷設
• 運用を考慮していない機器設置
  • 管理ネットワークを設けず、FireWallの外側のメンテナンスはすべてシリアル接続
  • 管理ネットワークを設けず、FireWallの内側のメンテナンスはすべてユーザトラフィックの流れる経路を利用
• メンテナンスを考慮していないドキュメントフォーマット
  • 任意のスイッチのポート収容図のパッチケーブルを、ローカル側とリモート側というカテゴリでなく、特定のラックを基準にカテライズしている。そのラックのある位置から遠くのラックに収容してあるスイッチの場合、ローカルと思ったのがリモートで、リモートと思ったのがローカルで、という勘違いが起きる。
  • しかも、判りにくいとは思っていたんですよ、なんて、あたかも以前から判っていたようなことを言っていて、でも、改良しない。

になっていることが多い。

まぁ、自社の正規従業員がメンテナンスするなら、
  「こんなやり方じゃ、やりにくいよ!。」
という議論にもなるだろうが、下請けに任せると、そんな文句は出てこない、とか、聞こえない、とか、届かない、ということになるのだろう。あるいは、
  「そのために雇ったんだから、面倒なことをやれ!。」
とでも考えているのだろう。そういえば、ケーブルのナンバリングも、まず自分たちでやらないことを前提にスケジュールしていたっけな。

それで、入社以来5年も6年も仕事をこなしてくれば、このような運用を考慮していない設計・導入でも問題ないと思い込んでしまうのだろう。馬鹿だな。

で、提案をしてみた。

• FireWallの外側の機器だけでも、管理ネットワークを設けよう
• 接続先機器のホスト名をポートディスクリプションとして設定しようよ
• パッチケーブルのカテゴライズを、ネットワークラック側・サーバ側ではなく、ローカルポート側・リモート側にしようよ

結果は、ポート収容図については可であったが、そのほかは否である。理由としては、

• 管理ネットワークの必要性はわかるが、今からではお客様に構築費用請求できない。だからといって、自社負担もしない。そこで構築しない、
• ポートの接続先管理が完璧でないので、ディスクリプションもやらない。ポート収容図を見れば二段階の手間がかかるけれど判るから、それで対応。

である。

設計時から運用と管理ネットワークを考慮していればこんなことにはならないはず。設計時に気づいていない、というだらしなさなんだね。当然どう乳児に設定していれば費用は予算どおり、後からの持ち出しもない。自分たちが気付かず阿呆なことしておいて、
 「今からではお客様に構築費用請求できない。だからといって、自社負担もしない。そこで構築しない。」
という。馬鹿だな。

通信会社だからWAN回線の運用ノウハウはあるんだろうけれど、顧客ネットワーク・LAN管理なんてのはやったことないに等しい素人知識なんだね。でも自分が知らないということを知らない。下請けよりは頭がいいとでも考えているようだ。

こちらのアイデアをパクって来た

お客様のWAN回線は、耐障害性を考慮し二重化している。こりゃ、回線業者としてこの某社は儲かっちゃうね。ということは30箇所からある拠点にはWAN側ルータが2台づつある。スイッチのポートディスクリプションはやらないというのに
  「telnetで接続したときにどちらのルータか、バナーでわかるようにWAN網の名前も書いて。」
というオーダーがきた。これこそ、ホスト名はバーナで表示するように設定してあるのだから、ネットワーク構成図で二段階の手間がかかるけれど判る。手間は一緒だけれど、一方は自分たちがあまりいじらないところなのでしない。一方は時々見るところで、しかもこの時々なので間違いやすいから、ということなのだろう。どうせいじるのは一緒なのだから両方やるのが正解だろう。 OSPFやEIGRPの知識があっても、運用という立場にないからその必要性のレベルが判らないのだ。

しかも、こちらの「ディスクプションを利用しよう」というアイデアを聞いてから、後から言ってきた。
  「あっ、そういえばこんな便利な方法があった。使ったことがあまりないから忘れていた機能だ。」
という程度のことだろう。ディスクリプションもバナーの件も、設計時から考慮しとく内容だろう。「やってみてからあったほうがよいと」判りましたってこともあるだろうが、考慮漏れである。ディスクリプションもバナーも事前の打合せ内容だろう。それをやっていないのである。

実際にやらない人たちがことを決めるのが変！

しかも、運用業務は請負である。お客様は直接手を下さない。ということは直接手を下すものが便利なようにするのが本筋だろうが、運用をやったこともない者同士だけで、ディスクリプション設定の必要性を議論し、接続先管理が完璧でない、という理由でしないという。

たとえ接続先管理が不十分でも、いまの二手間・三手間かける方法がずいぶん解消される。やるだけの価値はある。大体、Telnet接続しない者がディスクリプションの内容云々論じることがおかしい。こちらは毎日の業務ですぐに必要を感じたから提案しているのだ。

それに、接続先管理が不十分というのも、接続先管理もシステム構築サイド・サーバ管理者と、どこをどうつなぐかをきちんと管理すればよいだけのこと。この管理担当が、

• 床を這いずり回って接続先を確認する

という泥臭いことを避けている限り、接続先管理は不十分のままだ。