03-03
「で、あとは冗長についてなんですけど、ちょっと営業の図は情報が足りていなくてですね…。」
下山はそう言いながら半分腰を上げて持っていたペンを指示棒がわりに使い、日本の本社拠点らしき場所を指した。
「まあ、ここが本社で今はこの本社にサーバー類が集中しているらしいんですが、この図でルーターが描かれているもう一つの日本の拠点、場所は石川だそうなんですが、そこにいくつかサーバーを移転し且つディザスタリリカバリサイトのようにするそうです。」
都は頷いて了解を示した。
「この２拠点、図にはないんですけど、裏で他キャリアのＬ２回線で繋がるそうです。」
下山は持っていたペンで図上の２拠点間を行き来させ、線が繋がることを表現していた。新しい石川の拠点は完全なディザスタリリカバリサイト、つまり普段は休眠していて災害時のみ稼働する拠点ではなく、平時でも役割があり稼働している通常の拠点ということになる。そして本社はこの石川拠点のバックアップとしても機能する。異拠点冗長というのは地理的に離れたこの２拠点が裏でも接続され相互にバックアップするいうことだ。よくある運用なので特段珍しいものではないが、設計にはそれなりに注意が必要になる。
「その裏で繋ぐ予定のＬ２回線って、この２拠点を繋ぐだけですか？それとも他の拠点もぶら下がったりするんでしょうか。」
都は気になって聞いた。他の日本の拠点群は簡易サービスで今回新設するＭＰＬＳ網に接続するはずだがそれは図から見る想定でしかない。もしかしたらこのＬ２回線に拠点が下がってくるかもしれない。都たちの部署の責任区分範囲からすれば気にしなくても良いのだが、異拠点冗長の設計においてはネットワークの構成、トポロジーはできるだけきちんと把握しておくほうが良い。そうしておけば何かしらトラブルが起きた時にも役に立つ。
「あくまでこの２拠点を接続するためだけだそうです。」
下山も気になってそこは聞いたそうで、この本社と石川をバック・トゥ・バックで繋ぐＬ２回線に他の拠点は下がらないとのことだった。もし下がるようなら設計はより複雑になるのは想像がついたのでまず確認したと言う。
「石川の拠点は全くの新しい拠点、っていう理解で良いんですか？そうするとこの拠点だけは既存のルーターのコンフィグからじゃわからないですよね。」
都は聞いた。
「そう。だからまずここ以外の拠点の既存コンフィグを使って中身を埋めたヒアリングシートを作成します。そしてそれに石川の拠点を空欄で加える。そうすればお客さんも他の拠点を参考にして必要なパラメータを埋めやすいだろうという期待を持っています。」
新規のお客さんにヒアリングシートのフォーマットは分かりづらいことが多く、空のヒアリングシートをメールで送り埋めて返送するように依頼しても、すんなり一二回の往復で済むことはほとんどない。プレゼンテーションファイルでプロバイダエッジルーターと客宅ルーター、お客機器からなる構成図を作成し、どんなことを聞いているのか矢印や吹き出しなどを使って説明したりと、手の込んだ補助資料を作らないといけない場合もある。逆にこちらがヒアリングシートを送る前から実現してほしいルーティングを説明した図がお客から送られてきて、それを元にヒアリングシートの中身をこちらで埋めて確認のためだにけそれを送ることもある。
場合によりやり方はいろいろだが、ただパラメータを埋めてくれとお客へ投げっぱなしでは本来のお客の意図とは合っていない埋め方をされてしまって理解の齟齬が隠れ、結局ＬＡＮ接続時にトラブルになることは多い。なのでヒアリングは多少稼働を多めに掛けてもきちんとやっておくべきだと都は考えていた。ただ手をかけ過ぎると責任区分境界が曖昧になり、本来お客さん自身でやるべきところにも無償で手を差し伸べてしまうことになりかねない。そうしてしまうと、その後プロジェクトが進む中で過度な要望をお客から招きやすくなり、構築が終わって保守フェーズへ移ってもそれが続き是正が難しくなる。運用担当に負荷がかかるだけではなく、運用の問題にもかかわらずいちいち構築時の担当に問い合わせが来るようになり、結果的に自分の首を絞めることになる。その辺りのバランスを取るのは難しかった。そこはプロジェクトマネージメントとして考えなければならない点だが、都は大の苦手だった。