12-03
12-03
「…はい。はい、そうです。あ、はい、私になります。…はい、現着連絡ですね。…まだラックの前までは行かれていらっしゃらない、ということでよろしいでしょうか。」
岸谷は、相手が今日の国内客宅ルーター設置の現場作業員だったらしく、会社名を名乗って電話に出た後、国内の工事ではテンプレートとも言って良いやり取りをしばらくしていた。ちょっと言葉遣いや聞き方が、不慣れかな、と思われる節もあったが、とにかくはきはきと、例の通る声で堂々としゃべるので、ベテランとは言わないけれど、ちょっと慣れた人、という印象を与えかねないだろう。電話を切ってから、岸谷は秋田に、現場作業員がお客さんビルに着いたところで電話をくれた、これから入館し、ラック前に着いたら再度連絡もらえる、という旨を報告していた。
新入社員が、国内の客宅ルーター設置の工事統制を、担当チームの派遣社員についてやる時は、丸椅子などをメンター役の派遣社員の机に持ってきて、その隣でやるのが慣例になっていた。ちょっとしたイレギュラー対応に限らず、あまり聞きなれない言葉や事柄を、現場作業員などから聞かれた時や、もちろんトラブルに当たった時など、すぐに相談出来るし、専用端末のターミナルウィンドウを共に覗き、確認コマンドやその見方などについて直接教わることもできる。都の隣の席に座る派遣社員は、今日は一日休みだということで、メンター役の秋田の真後ろの席ということもあり、岸谷はそこへ座って今回の工事統制をやることになった。
岸谷は一旦自席にシンクライアント端末を取りに戻ると言って、少し小走りに都の席の島から離れていった。専用端末は都の隣の席にもあるので、それを使うと言う。通常端末の方は、個人に貸与されるので、使用者のカード認証がないとログインできないが、専用端末は、工事を担当する社員・派遣社員にはほぼ一人に一台貸与されているものの、基本的に共用端末なので、ログインパスワードさえ知っていれば誰でも使えた。
都は、岸谷が自席へ戻った後、都が入っているメーリングリストが途中からＣＣされ始めた、保守担当とお客とのメールの新着を知らせるポップアップを目にした。基本、保守とお客のメールには、都たち構築の人間はＣＣされることはない。される時は、保守担当から構築担当にサポートを求められる時と決まっていた。都は気になってしまい、そのメールを開いた。このメーリングリストのお客案件は、東京にＳＥを置く案件、と言うだけではなく、設計も特殊、体制も特殊で、何でも例外が通ってしまう案件になっていて、一向に通常フローに乗らない案件として部内で知られた案件だった。メールに目を通していると、少し離れたところから、良く通る女子の電話口の声が聞こえたきた。岸谷は、おそらく自席で別件に捕まって、それに対応しているうちに、現場作業員から連絡があり、電話で話しながらこっちへ向かっているのだろう。ちょっと後ろを向くと、岸谷が右腕でシンクライアント端末と、ノートを抱え、左手でＰＨＳを耳に当てて話しながら歩いてきていた。
「…はい、少々お待ちください。」
そう言いながら岸谷は、ごとん、と音をさせながらシンクライアント端末を机に置くと、ノートをそれほど慌てた様子もなく広げて、ページをめくっていき、おそらく今日設置する客宅ルーターを接続すべき回線の、回線ＩＤを書いてあるページにたどり着いた。
「お待たせいたしました。では、読み上げをお願いします。」
岸谷は落ち着いた様子で、そう電話の向こうに言うと、しばらく無言でいた。ノートを指でなぞりながら、電話の向こうの読み上げを聞いているようだ。
「はい、その回線です。それでは、ラックマウントをお願いいたします。ラックマウント終わりましたら、ルーターの電源を入れていただいて、付属のＬＡＮケーブルで、ルーターのギガビットイーサーネットの０／１と、ＯＮＵを繋いでもらえますでしょうか。…はい、そうですね、ケーブルの接続終わりましたら、再度ご連絡いただけますでしょうか。はい…。はい、構いません。はい、よろしくお願いいたします…。失礼いたします。」
そう締めて電話を切ると、岸谷は秋田に、現場作業員がラック前まで到着したことと、回線ＩＤの照合が取れたので、ラックマウントを始めてもらったことなどを報告していた。電話でのビジネス喋りっぷりがすごいので、電話を切った後との喋る調子の違いがひどい。
「さすがはったりの岸谷だなあ。ずいぶんこなれた感じだったよ。」
秋田は、岸谷がスムーズに作業員への指示を行えていたことを、からかい半分で褒めていた。岸谷が、電話の受け答えや、相手がお客でも物怖じしない受け答えをすることは、他の社員・派遣社員にも知られていた。岸谷は、そのことについて先輩社員に言われた時、私何でも知ってます、という体で喋ってますと、一度冗談で言ったところ、誰かが「はったりの岸谷」と言う変な呼び方をし出したらしい。そう言う揶揄はモラハラとかパワハラとかに繋がるんじゃないかと、気を使ってもらえるのであまり言われはしないが、それでもたまに言われることがあると、昨日都は岸谷から聞いていた。本当に言われているのを実際に聞いて、都は笑ってしまった。
「ふんふん。」
岸谷は片手にＰＨＳを持ったまま、腰に両拳をつけて少し自慢げに軽く踊っている。本当に物怖じしないし、年齢に関係なく、人の輪の中に入っていける性格なのだろう。都はそんな岸谷がちょっと羨ましかった。秋田と岸谷が、また冗談のやり取りを始めたところで、あまり鳴ることのない、都のＰＨＳが鳴った。
「はい、間宮です。」
都は事務的に電話に出るのが苦手で、どこか甘い調子になってしまう。相手が男子だった時に、これが時折間違った誤解を生むことがあったので、気をつけないといけないと思い、電話に出る時には一呼吸置いてから出るようにしていた。
「あ、間宮さん、大森ですー。お疲れさまですー。」
相手は保守の部署の人間だった。都がＳＥをやっている、東京でＳＥを置く案件というのは、設計の複雑さや、お客の注文の多さなどの理由で、構築時に通常のフロー、つまり海外オフショアセンターで構築の全てを実施する、という流れから除外され、特殊なフローを取っている。こういう案件は保守に入っても、特別な体制がとられている。そのお客の保守をマネージメントする担当者がアサインされ、一貫した対応や月次報告などを行なっていて、担当者はカスタマーマネージャー、ＣＭと呼ばれている。電話をかけてきた相手は、都がＳＥをやっているある案件のＣＭで、さっき都が目を留めた保守関連のメールに、都が入っているメーリングリストをＣＣしてきたのは、この大森だ。
「あー。お疲れさまでーす。」
間宮は愛想良く返した。正直、構築担当に何でもかんでも保守担当から問い合わせが来るのは、稼働の問題もあるし、嫌だなと思うこともないことはない。それは保守に閉じてやってよ、と感じるような、果たして構築に問い合わせる必要があったのか疑問に残る問い合わせもあるから、忙しければ、苛つくこともあるし、愛想も悪くしてしまって、何かを聞きづらい空気にしてしまおうかと、嫌な気持ちも起こってきてしまう。しかし、ネットワークの構築というのは、実は長い道程の最初の部分だけしか見ていなくて、その後、２４時間３６５日、保守が見ているからこそサービスは成り立っているのだ。そう考えると、保守が困った時に、出来るだけ保守に協力することは、ネットワークを本当に構築するということの一部でもあると思うし、構築時には発覚しなかった問題や、当初想定しなかった問題に当事者として当たって、吸収し、その後の設計に活かすことだって出来る。構築サイドからも、保守を頼らなければいけない時もあるのだから、そういう時に協力的にやって欲しいのであれば、向こうから頼られた時も、協力的にしておくべきだ。
人によっては、保守部門に対して喧嘩腰の人もいるし、もちろん保守部門の人にも構築部門に対して喧嘩腰の人はいる。それにネットワークの基本事項について、まるで質問箱のように構築に聞いてくるような人もいるので、確かにあまり何でもかんでも頼みごとを引き受けているのも、正しくないと言えばそうだ。しかしそれでも、都は出来るだけ、保守からの問い合わせについては、協力的にやろうと思っていた。
大森は今話せるかどうかを都に確認してから、本題に入った。先ほど都が入っている構築のメーリングリストをＣＣしたメールについてだった。これは、都が連休中に工事をする予定のお客とは、別のお客なのだが、こちらも偶然同じくヨーロッパ拠点のトラブルだった。
このお客はヨーロッパに拠点が相当数散在しているのだが、都が勤めるキャリアのＭＰＬＳ網には、２つのデーターセンターがメイン、バックアップで接続しているだけで、そのデータセンター配下に数十のヨーロッパ拠点が、別の現地キャリア網を介して接続している。先日、このメイン側のデーターセンター内の、お客のコアスイッチの更改があったそうなのだが、それ以降、お客のＬＡＮから見て想定通りのルーティングになっていない、というトラブルだ。都たちの客宅ルーターから見ると、どちらのデーターセンターに設置してある客宅ルーターからも、ＬＡＮは設置場所データーセンターのお客コアスイッチと、もう片方のデーターセンターのコアスイッチに接続している。お客のヨーロッパ網から、コアスイッチを介して見ると、都たちの網へ向けて４本のパスがあるかたちだ。
客宅ルーターとコアスイッチ間のルーティングはｅＢＧＰなので、ＷＡＮもＬＡＮもＢＧＰになる。都たちの客宅ルーターは、メイン、バックアップで異なるＡＳ番号をアサインしてある。お客のコアスイッチはどちらのデーターセンターでも同じＡＳ番号のアサインだ。客宅ルーターとコアスイッチ間の４本のパスについては、メインのデーターセンターの客宅ルーターからコアスイッチへのパスがベストパス、メインのデーターセンターの客宅ルーターからバックアップのデーターセンターのコアスイッチへのパスが２番目の優先度、バックアップ客宅ルーターからメインのデーターセンターのコアスイッチへのパスが３番目、バックアップ客宅ルーターからバックアップのデーターセンターのコアスッチへのパスが４番目のパス、となるように、２台の客宅ルーターからメトリックにて４段階の差分をつけて、お客のコアスイッチへルートを広告していた。
客宅ルーター同士はｉＢＧＰどころか物理的にも接続していない。都たちの網から見ればパスは２つのみだ。客宅ルーターが、お客コアスイッチからルートを受け取る時は、それぞれで、メイン側のデーターセンターのコアスイッチから受信するルートがベストパスとなるようにだけ操作すれば良いのだが、設計上統一を図りたかったからなのか、ルーティングを資料に落とした時にわかりやすくするためなのか、コアスイッチへ広告する時と同様に、４段階で受信ルートにメトリックを付与していた。これでもそれぞれの客宅ルーターで、メインのデーターセンターのコアスイッチからのルートがベストパスにはなる。網への広告時には、バックアップ客宅ルーターからＡＳパス長を長くすることで、メイン側に寄せるようにしている。
このヨーロッパのデータセンター拠点は、都がこのお客案件の担当ＳＥとなる前から、この設計だった。都が担当するようになってからは、回線の単純増速と、網への広告ルートの増減程度の設定変更しかやっていない。都は、設計は把握しているが、こういう設計にになった背景や経緯は全く知らなかった。
「それで、ですねー、お客さんのスイッチをリプレイスしてから、お客さんから見て上りのルートがバックアップ側によってしまう、って言ってるんですね。こっちは何も作業してないから、お客さんの作業起因でしょう、で突っ返しているんですが、向こうは交換前のスイッチと新しいスイッチで基本的にはコンフィグ変えていない、って言ってですねー…。」
「基本的に。」
都はそこを笑いながら復唱してしまった。電話の向こうの大森も笑っていた。基本的じゃないとこが違っていて、そこでしょう、という話をして、また電話越しに二人で笑ってしまう。
「で、ログを送ってきたんですね。お客のコアスイッチのルーティングテーブルだと思うんですけど。」
保守の人間もルーティングテーブルの出力はある程度理解が出来るので、それがルーティングテーブルだとわからないわけはない。しかし、そのログは都が入っているメーリングリストがＣＣされる前に、保守宛に添付されたものらしく、都は見ることは出来ない。
「あー…。じゃ、ちょっと見ますよ。送ってもらえます？」
都は大森の意を察して言った。
「ほんとすいません、いつもいつも…。」
大森はありがたがるような調子で謝るので、都は否定を返しておいた。
「ちょっと待ってください…。えー…。はい、今送ったんですけど、見れます？」
大森がそう言った時には、都のメーラーには新着メッセージが届いていた。都が入ったメーリングリストがＣＣされる前のメールを、都個人宛に転送だけしたものらしい。本文は引用だけで、添付ファイルがある。都は見られる旨電話口に返してから、添付ファイルを開いた。客宅ルーターとして、都が勤めるこのキャリアが提供している筐体と同じメーカーのコマンド出力だ。ルーティングテーブルではなく、ＢＧＰテーブルの出力ログだった。ルーティングテーブルであれば、すでにＢＧＰのベストパス選択が終わってしまった、最終的なベストパスのみしか見えず、複数のピアからもらった、同じＢＧＰルートについての複数の候補は見えなくなっている。しかし、ＢＧＰテーブルであれば、複数のピアから同じルートをもらっている場合、それらが全て見え、ＢＧＰの代表的なアトリビュートや、どの候補がベストパスとして選ばれたかを確認することができる。
都たちの客宅ルーターから受信したＢＧＰルートだけではないので、若干見辛いが、都たちの網のＡＳ番号が、ＡＳパスに入っているルートを一つ選んで見てみると、確かに、メイン側データーセンターの客宅ルーターのＡＳ番号が最初のＡＳになっているルートと、バックアップ側データーセンターの客宅ルーターのＡＳ番号が最初のＡＳになっているルートとがあり、メトリックは、メイン側データセンターの客宅ルーターからのルートの方が軽いのだが、このお客のスイッチでは、ベストパスはメトリックが重い、バックアップ側データーセンターの客宅ルーターからのルートになってしまっている。
「そーですねー…。確かに、バックアップ側からもらっているルートをベストパスにしてしまっていますね。。。これ、このスイッチがＭＥＤを評価出来てないんじゃないですかね。」
ＢＧＰテーブルで見る限りは、メトリックより上のタイブレークになる値は何もついていないように見える。一度一つルートを選んで、ＢＧＰルートの詳細情報をもらって見た方が良いのだろうか。しかし、それを見ても、細かい属性が見えるだけで、もしその細かい属性がＢＧＰのベストパス選択に影響を与えているのであれば、それはもう設定の問題なので、今度はお客のコンフィグをもらって見なければいけない。それは避けたい。
都は大森に、このヨーロッパ拠点の設計方針は、都たちの客宅ルーターから、お客スイッチへルート広告時にメトリックで差分を付与し、あとは、そのメトリックをお客のＬＡＮで正しく評価して、ルーティングするようにするというポリシーになっていて、構築当初からお客との間で合意されているはずだ、ということを説明した。
「なので、お客さんがスイッチ更改してから、バックアップ側にルート寄るようになったのであれば、お客さんの新しいスイッチが、メトリックを正しく評価できていないので、それが設定なのか、不具合なのかわからないですけど、解消してください、としか言いようがないかなー、って感じですねー…。」
都は何か自分の回答にすっきりしない感覚を抱えながらも、ひとまずそう回答した。
「そーですよねー…。りょーかいです、わかりました。すいません、いつもいつも。ありがとうございます。ちょっとその方向でもう一度突っ返して見ますね。」
大森はそういうと、最後に電話を切る挨拶をした。やはり、大森の方でも何かすっきりしない感じがあるのは、その言葉の調子から明らかだった。
都が電話を切ると、隣で岸谷が、現場作業員と電話をしているのが聞こえた。岸谷が統制している、国内案件の客宅ルーター設置工事は、いつの間にか接続試験、ＷＡＮ開通試験まで無事終わったらしく、岸谷は電話の向こうに、お客のＬＡＮを接続試験が今日あるのかどうか聞いている。グローバル案件の場合、ＷＡＮ開通と、ＬＡＮ切り替えが別日であっても、ＰＭやＳＥがスタンバイして、対応することが多いが、国内案件の場合、この客宅ルーター設置の時にお客のＬＡＮを接続試験しない場合は、後日お客自身で実施してもらい、不具合発生の際は、営業なり保守担当者になり、問い合わせることになる。国内案件の場合、事前にお客試験があるかどうかも、都の同僚である担当者たちには伝わってこないことが多く、ほとんどの場合、今岸谷がそうしているように、現場作業員が、当日のお客側の立会い者と確認を取る。岸谷が統制している案件は、これからお客がＬＡＮを接続をして、試験を実施するようだ。
都は、通常端末でブラウザを開き、ＢＧＰ、ベストパス選択、という言葉をスペースで区切って検索した。客宅ルーターの筐体のメーカーサイトで、このアルゴリズムを説明するページが、候補の上の方にあったのでそれを開いた。覚えていないうちは何度も見たページだ。今は頭に入っていることばかりなので、読み飛ばしてスクロールしていく。都は、ＢＧＰの設計でＭＥＤと呼ばれるメトリックを、お客の希望がない限りは、使わない。希望があっても、ベストパス選択のタイブレークでも下位のものであることもあり、ＭＥＤは想定通りに効かないことが多い、と一度は説得を試みる。また、ＭＥＤの使用を意図していない時に、ＭＥＤにより想定外のルーティングになってしまったりすることもある。都はＭＰＬＳサービスのエンジニアなので、基本的にＡＳを跨ぐことのできない属性を、別の拠点でのベストパス選択に影響を与えるために使うことに、違和感も懸念もあった。
使っていないが故にちょっと不案内なところもあるので、今一度ＭＥＤの項をよく読んでみる。すると、隣接するＡＳが同じＡＳでなければ、ＭＥＤが評価されない、とある。都は、そもそもこのメイン・バックアップの客宅ルーターの設計が、ＬＡＮのＢＧＰドメインにとって、メトリックが評価できない設計になっていることに気が付いた。メイン、バックアップの客宅ルーターはそれぞれ別のＡＳ番号がアサインされているのだから、客のコアスイッチから見れば、同じルートが、別の隣接ＡＳから受信されていることになる。そのため、こちらからＭＥＤをベストパス選択のため、４段階に分けて広告したところで、メインとバックアップのルートとでは、意図通りにはベストパスを選択されることはない。
都は一瞬、これは当初からの設計ミスなのか、と不安と緊張が走った。しかしすぐに、おそらく、このことは既知の問題で、合意済みの事項なのだろうと思い直した。何故なら、何年もの間、この設計でずっと運用されてきたのだ。お客スイッチを更改する前も、回線断やメンテナンスなどで、何度かは更改と同じ状態、つまり客宅ルーターとお客コアスイッチの間が、一度断になって復旧した、ということがあったはずだ。ここ数年は、きちんとお客スイッチで、ＭＥＤが軽いルートをベストパスと出来ていたということだ。
読んでいたＭＥＤの項目を読み進めると、異なる隣接ＡＳから受け取ったルートのＭＥＤを評価させるためには、デフォルトでは入っていないコマンドをコンフィグする、とあった。都は、間違いなく問題の原因は、お客が更改後のスイッチで、これを失念していることだと思った。しかし、一度試してみないといけない。都はこのコマンドを使ったことがなかった。ルーターは、網を表す１台、メイン、バックアップの客宅ルーターそれぞれ１台、それとお客コアスイッチの１台、計４台で良い。これならシュミレーターで短時間で出来るだろう。都は大森に電話をかけた。相手はすぐ出たので、今話せるか確認を取ってから、話を始めた。
「さっきの件ですけど、やっぱりお客さんの新しいコアスイッチで設定が足りてないっぽいので、これから簡単な検証をして確認してみます。…はい、そーですねー。で、想定通りの結果であれば、それが足りてないよ、と指摘してやれると思います、結果出たらお知らせするので、その結果を持って、お客さんに返してもらうでも良いですか？」
「ありがとうございます！お忙し中すみません、これ、実は一週間くらい言われていて、その都度、こっちは何もしてない、そっちのせいだ、で突っ返しているんですけど、向こうも諦めないんで、何かこれだ！、と言えるものがあればひじょーに助かります！」
先ほどどは大森の声の調子が変わったので、やはり何かこちらが悪くないという決定打が欲しかったのだろう。都は１時間くらいかかるかも、と言ったところ、全然大丈夫なので、ゆっくりやってくださいと言ってもらえた。都はその気遣いに礼を言ってから電話を切った。すると、ちょうど隣の岸谷が、電話の向こうに少々お待ちください、と言っていた。椅子を回転させ、秋田の方を向いて状況の報告を始める。
「秋田さん、お客さん通信が出来ないって言ってます。」