20-1
20-1
十一月半ばから、ＣＪ案件の海外拠点のＬＡＮ切り替えも始まって、十二月前半で全ての拠点の切り替えが終わり、このプロジェクトは完了になった。設計の段階で、最初の都の想定に間違いがあって、設計とヒアリングをやり直したポリシーベース・ルーティングを実装するのだから、海外拠点のＬＡＮ切り替えでまた何かトラブルが起こるだろうと構えていたのだが、拠点のお客さんが渋滞で時間通りに来られなかった、などの海外拠点の工事ではよくあるちょっとした問題があっただけで、全てトラブルなく無事に切り替え終わった。
岸谷にとっては、このプロジェクトが、まっさらな一から新規にネットワークを構築するプロジェクトで、他のネットワークからマイグレーションする、という工程も含んでいたわけだから、ほぼノートラブルで終えたことは、先輩社員、課長陣に評価は高かったようだ。岸谷は、間宮さんがいてくれたから、と何度も言ってくれていたようだが、国内のルーターの初期不良や、そのほか海外の回線のデリバリ遅延も多少あったし、それに都の設計ミスもあったのに、岸谷がＰＭとしてお客と良好な関係を築けていたから、さして問題にならなかった。都の設計ミスの修正も、プロジェクト進行にマイナスにならなかったのもの、ＰＭの力によるところが大きかったろう。問題が起きた時に、常に落ち着いて対応できるのは、すごいな、と都は素直に思った。都は、ちょっとしたトラブルでも、すぐに慌ててしまう。性格の問題もあるだろうけれど、これが必要な時期に大人になることを決断し、大人になった人間と、必要な時期に大人にになることを拒否し、大人になりきれていない人間の違いなのかと、卑屈に考えてしまう。
今年はカレンダー的に、有給をちょっと使えば、年をまたいで２週間丸々休める曜日の並びになっていて、そろそろ年末の休みはいつからにしようかという話が周りで出始めた頃、都は久しぶりに受信する送信者のメールが、受信トレイにあったのを見つけた。ＳＩ、ＮＩどちらも含む、とある案件の総合ＰＭをしている、都が所属している部署とは別部署の社員からだ。この案件の国内のネットワークが大きく構成変更となるプロジェクトに、ちょっとしたきっかけで都は巻き込まれることになり、以降この案件のルーティング設計については、都がＳＥのように動いていた。ＳＥのように、というのは正式にアサインされたこともなければ、正式にプロジェクトメンバーに名を連ねているわけでもない。なんとなくこの別部署の社員のお抱えＳＥのような形で動いている、という感じだ。
都が正式にＳＥとしてアサインされている、特殊な体制をとっている案件のＰＭも別部署なのだが、このメールの送信者の社員は、そのＰＭと同じ部署、同じ課長配下だった。都の稼働はこの別部署の課長配下のものがある、ということで、都が派遣社員として所属している部署の、直属の課長は了承済みなので、その別部署の他の社員が相談事を振ってきて、ある程度稼働が嵩んでも問題にはならない。もちろん、巻き込まれ工事がとんでもないことになった時から、一応、その部署の課長から、都の直属の課長へのエスカレーションは、後付けでされていたようだが、それでも正式なアサインメントはないままだ。むしろそれだから自由に動けている、自由に動かせる、という利点もあるようだ。
その国内ネットワークの大きな構成変更の時、新規で構築し、以降最重要拠点となった、北陸にあるデーターセンターに、ようやく本番回線の準備が出来たので、ＷＡＮ開通と、ＷＡＮ切り替えを年明け早々にやるから、一緒にやるか、という勧誘だった。ちゃんとした感じのメールではなく、いっしょにやらなーい、といったかなり気軽な感じで書いてきているが、この統合ＰＭは最初からそうで、いつもこの調子だった。
都は、ようやくですねー、日時決まったら教えてくださいー、とこちらかなり軽い感じで、全部ひらがなで書き送った。するとすぐ返事は来て、日付はすでに決まっていて、来年年明け第二土曜日とのことだ。土曜の日中に切り替えるから、予定を空けておいてくれ、という返事が来た。すでに都がＳＥをすることが決定事項になっていることに、都はちょっと笑ってしまったが、この件は自分で決着をつけたいというのもあって、やるか、と聞かれれば、やる、と答えるつもりだったけれど、その前に決められていた。
本来この北陸のデーターセンターには、本番回線、つまり都が勤める通信キャリアの、国内部署が所有するインフラで開通する予定だった。しかし、このデーターセンター付近に、またこのキャリアの光回線のインフラがなく、都たちのキャリアのＭＰＬＳのノードまで、光回線を自前のインフラだけでは持ってくることが出来なかった。そのため、仮回線として、地域の電力会社のインフラを使い、都たちのキャリアのインフラとＶＰＬＳで相互接続し、それらの両端、つまり電力会社のインフラの終端には客宅ルーター、キャリア側のインフラの終端にプロバイダエッジルーターを接続し、Ｌ２ＮＮＩを擬似専用線のように使うという、かなりトリッキーな回線の敷設の仕方をした。
お客の利用上は問題はないのだが、保守が複雑になる問題がある。見た目の回線は一つなのに、実際は、プロバイダエッジルーターの構内配線、都たちのキャリアのインフラ網、都たちキャリアと電力会社の相互接続ノード間を接続する回線、電力会社のインフラ網、さらに電力会社の客宅最寄のノードから客宅への回線、と障害が起きた時の、保守区分が違う被疑箇所が多くなり、また箇所によってはどちらが一次に保守を対応するのか、など詰めなければいけない問題は多かったと聞く。それでも多くの国内、国際拠点を持ち、いくつものＳＩサービスや特別保守サービスを、都が派遣社員として務める通信キャリアから買っている、ということで、このトリッキーな敷設の仕方の仮回線でも、お客のデータセンター移設スケジュールに合わせてなんとか敷設する、という手段が取られた。
このお客の本社にあったデータセンター機能のほとんどを、北陸のデーターセンターへ移行させる、というものがそもそもこのプロジェクトの根幹だった。どの企業でもあの震災以来、ディザスタリカバリについては真剣に検討が始まっていて、このお客も実行に移すことになった、というものだった。
最近になってようやく、プロバイダエッジルーターから客宅まで、都たちの通信キャリアのインフラだけで専用線を引けるよう、光ケーブル敷設などの設備が整ったので、この仮回線を本番回線へ引き直す、というのが、今回の工事だ。
しばらくメールのやり取りが、統合ＰＭと続いた。誰もＣＣされておらず、かなりくだけた調子でのやり取りになっている。この統合ＰＭも都のことを、みやみや、と呼ぶので、文頭にはいつもそうある。統合ＰＭは上野と言ったが、統合ＰＭの部署の人たちが、皆苗字で彼女を呼ばず、名前で真希さん、と呼んでいるので、都も真希さんと、呼んでいた。歳は大して変わらないが、都の方が一つ二つ下に見えるだろう。
先に回線の試験を独立してやりたい、それから切り替えしたいという上野の意向は都も同じだった。北陸のデーターセーターへ設置したルーターには空きインターフェイスが一つある。このインターフェイスを、客宅ルター上で別のＶＲＦとしてコンフィグすれば、実通信には全く影響を与えずＷＡＮ開通試験が可能になる。それでも新しくアサインしたＷＡＮ側のセグメントは、プロバイダエッジルーター上で、このお客のＶＲＦに乗ってしまい、網を伝播し各拠点に流れてしまう。ＷＡＮ側のセグメントだから、影響もないし、ＢＧＰを張るにしても、客宅ルーターは一つのＡＳ番号だが、プロバイダエッジルーターにはＡＳオーバーライドという、複数の客宅ルーターのＡＳ番号が同じでも、プロバイダエッジルーターで、客宅ルーターへ広告しようとするルートに、ピアのＡＳと同一ＡＳが含まれる場合、そのＡＳをプロバイダエッジルーターのものに書き換える、という機能を有効にしているので、どちらのピアへも同じルートを流してしまうが、客宅ルーターでＶＲＦを分けているから問題はない。しかし、念のためプロバイダエッジルーター側も、ダミーのＶＲＦを作ってもらった方が、完全に切り離せるので良い。
客宅ルーター、プロバイダエッジルーターともに別ＶＲＦでＷＡＮ開通試験をし、完了後、旧回線のインターフェイスを閉塞、旧物理ＷＡＮインターフェイスを紐づけているコンフィグがあれば変更し、両ルーターで実ＶＲＦに切り替え、実際の客宅ルーターの旧回線を抜去する、最後に不要となった旧ＷＡＮ用のコンフィグ消し込む、という段取りで行こうとなった。これの方が間違いがなくて良い。ＶＲＦをどちらかで一緒にしておくと、念の為ルートフィルタをしなくてはならなかったりと、気を使う場所が増える。そうするよりＶＲＦをプロバイダエッジルーターでも客宅ルーターでも別物にして試験する方が安全だ、という話にもなった。
都が担当するグローバルＭＰＬＳでは、３つのメーカーの筐体がプロバイダエッジルーターとして採用されていて、うち２つは海外オフショアセンターに書き込み権限が完全に移行してしまっているのだが、あと一つは、海外オフショアセンターで元々扱ったことのないメーカーのものだったこともあり、数は少なくなってしまったが、まだ東京に残っているプロバイダエッジルーター担当で、引き続き書き込み権限を持っていて、海外オフショアセンターも実質工事は彼らに実施してもらっている。こういう細かいステップに分けてＷＡＮ開通をするときは、彼らの方が慣れているし、意思の疎通も取りやすい。幸い、北陸のデーターセンターの旧回線が収容されているプロバイダエッジルーターも、新しい回線が収容される予定のプロバイダエッジルーターも、東京のプロバイダエッジルーター担当が書き込み権限を持つメーカーの筐体だった。本来国内の回線は国内網のプロバイダエッジルーターへ収容するのだが、この本番回線はグローバル網の西日本のプロバイダエッジルーターへの収容となっていた。
こういった複数のステップを踏む必要のあるＷＡＮ開通工事は、ステップ工事、と呼ばれ、これを実施するには、工事内容を示した簡単な図と、ステップ毎のパラメーターをプロバイダエッジルーター担当のエンジニアに提示する必要がある。都は、別部署にＰＭが立ち、今でも東京で客宅ルーターの設計コンフィグを担当することになっている別プロジェクトのＳＥをしているが、このプロジェクトでは、ＷＡＮ開通は常にステップ工事でやることになっているので、ステップ工事のために提出必要な資料作成は慣れたものなので、申請必要な資料は都が作ることになった。
この回線切り替え工事は、通常の都たちの部署へのオーダー工事なので、都が所属する部署で、ＰＭ、ＳＥが立つ。しかし、そのＰＭは直接営業やお客に連絡を取るのではなく、別部署の総合ＰＭと連絡を取りながら案件を進めていく形になる。このような場合、客宅ルーターの設計、コンフィグは別部署のＳＥがやることが多く、都の部署のＳＥはそれを流し込んだり、基本的な試験をしたりだけになる。
都はたまたまこのグローバルＭＰＬＳの部署の人間で、専用端末へのアクセスがあるので、客宅ルーターのコンフィグ、設定作業ついては全部都がやることになる。ただし、別部署のＳＥとして、だ。プロバイダエッジルーター担当への資料も都が作成してしまうので、本来のＳＥは、それの担当間の受け渡しや、おそらく都が現場作業員として入ってしまうので、作業当日、遠隔で出来る作業でサポートをやってもらう形になる。こういう他部署のエンジニアが出張ってくるような工事だと、都たちの部署ではＳＥは名前だけアサインされるだけで何もせず、ＰＭ一人で、全部賄ってしまうことが多い。おそらく今回もそうだろう。
都たちの部署へオーダーはもう出ているというので、都はオーダーシステムから、このお客の管理ＩＤで検索をして、一番新しいオーダーを調べると、確かにグローバルＭＰＬＳ網のノードからの既存回線の廃止と、同ノードからの新規回線の廃止新規のオーダーが出ている。ルーターは既存転用となっている。既にＰＭ、ＳＥはアサインされていた。ＰＭは２年目の社員で、都とはよく話す植松だったから、進めるのに連携面での問題はなさそうだ。
ようやく本物の冗長試験が出来るね、と上野のメールにあった。そう、一年半前、この北陸のデーターセンターを、お客ネットワークへ導入する大きなネットワーク構成変更工事のたった２週間前、何となく都はこの工事に巻き込まれた。もう８月も終わろうかという頃だった。全く既存のネットワークも何も知らない状態でだ。最初は設計相談だけだと思って、軽く聞かれたことについて答えるだけで、都も特に設計について深く調べもせず最初の一週間は過ぎた。そしていよいよ切り替え工事の５日前、上野はこう言ってきた。
「ところでさあ、テストどうする？」
つまり、構成変更工事の一週間前になって、工事に参加してくれ、と突然言われたのである。何の準備もしていないし、既存の構成すらきちんと把握していない。今まで本社のデータセンターと東京のデーターセンターに、国内網と、グローバル網が接続している形だったが、これに北陸のデーターセンターを追加し、本社からグローバル網への接続は廃止、この北陸のデーターセンターからグローバル網へ接続させる、という構成変更だった。国内網からグローバル網へのデータ通信は、本社のデーターセンターを通過し、国内網からグローバル網への音声トラフィックは東京のデータセンターを通過し、など細かい通信制御が掛けられていたものを、この北陸のデーターセンターが入ったことにより、本社のデーターセンターに残置するサーバーやインターネットゲートウェイへのルートを、北陸に移すサーバー類へのルートから分離したり、本社データセンターを通過していた国内拠点とグローバル拠点間の通信を北陸データーセンター経由へ変えたりなどの変更が必要だった。
新規のルーターでは、既にＷＡＮ開通や基本的なコンフィグは終わっていて、都が実質するのは設定変更や設定追加になるが、それを９台やらないといけなかった。各データーセンターのコアスイッチのコンフィグ変更も少しあるが、それはお客の設計責任になっているので、上野がお客と相談しながら実施するという。既存のルーターには明らかに無駄なコンフィグ、あるいはすでに使われていないが残ってしまっているコンフィグなどがあって、それが設計の理解の邪魔にもなるので精査もしたかったが、そんな時間はなく、とにかく新しい構成に合わせたフィルターやルーティングを追加するしかない。本社、北陸のデータセンター、および東京のデーターセンターが接続する国内網はＬ２網なこともあり、本社と北陸データーセンターの国内網側のＷＡＮエッジルーターは、ＷＡＮ側もＬＡＮ側もＯＳＰＦ、ただし、ＷＡＮとＬＡＮとの間でルート制御を行えるように、プロセスＩＤを分けるという設計が採用されていた。グローバル網側のＷＡＮエッジルーターでは、プロバイダエッジルーターとの間はＢＧＰ、ＬＡＮ側がＯＳＰＦになっている。ヒアリングシートのようなものもなく、都は上野とこれはどうするんだ、あれはどうするんだ、というようなやり取りだけで設計していった。もっとも、プレフィックスについては、かなりきちんと管理されていて、このプレフィックスはこういう経路で、あのプレフィックスはああいう経路で、というやりとりだけで設計の意図は理解できた。
しかし、さらに問題はあった。この北陸データーセンターと本社データーセンターとの間に、お客自身で敷設した、Ｌ２網があって、この２拠点を都たちのキャリアとは別のキャリア網でつないでいる。網といっても、実質この２拠点だけだから、専用線のようなものだ。このお客自身で引いた本社と北陸のデーターセンターを繋ぐこの回線は、何の目的だと、都が上野に聞いたら、多分バックアップ、というひどく緩い回答が返ってきた。それはいい加減と言えばそうだが、かなり強固な信頼関係がお客とこの上野との間にできていて、あまりガチガチに決めてやらない、という今までの経緯もあったようだ。この２拠点間の通信だけをバックアップすれば良いのか、それとも例えば北陸データーセンターの国内網側の回線で断があった場合、国内拠点とグローバル拠点間通信を、この渡りを使い、本社データーセンターを経由して通信できるようにするのか。それで設計は全く変わってしまう。
上野が都の席へ来て、どんな感じ、と都の設計の進捗を聞きに来た時に都はそれを聞いた。上野はその場でお客へ電話をかけ、電話の向こうも、どうしようか少し迷ってから、つまり決まっていなかったということなのだが、国内拠点とグローバル拠点間通信をバックアップするようにと答えた。この時点で、工事日まであと３日だった。
この時期、都は都のメインのタスクである、別部署がＰＭを立てている案件のＳＥ業務が多かったので、この部署が入っている、都が現在通勤しているビルとは、別駅のビルのオフィスに都の席を作ってもらって、そこへ常駐していた。だから上野は以前からちょくちょく都の席へやってきた。それは相談だったり、雑談だったりだ。こちらのオフィスには女子は少ないし、上野の部署も女子は上野だけだったので、女子が増えて嬉しかったのかな、くらいに都は考えていたし、都も気さくに上野が話しかけてくれるのは、自分のプロジェクトのＰＭ以外は知らない人ばかりの環境の中だったから、嬉しかった。その流れで、なんとなくなのか、あるいは計画的になのか、上野は都をこのプロジェクトに巻き込んだ。
検証などをしている時間はないから、とにかく大きく構成が変わる、ルートの制御を本社から北陸へ移行しないければいけない、その二点に集中して設計をしていった。北陸、本社データセンターでは、プロセス違いのＬＡＮのＯＳＰＦから、プロセス違いの国内側ＷＡＮのＯＳＰＦへ、外部ルートとして再配送するときに、どこのデーターセンターから出たか、どういうプレフィックスか、それらがわかるように、ＯＳＰＦタグをつけて、他のデーターセンターのＷＡＮ側のＯＳＰＦでそれらを受信したら、タグに応じてデーターセンタ内へ再配送時の重み付けや、拒否、許可、などをしてルートを制御している。東京のデーターセンターは内部のプロトコルがｉＢＧＰなので、タグからコミュニティに、あるいはコミュニティからタグに付け替えることで、同様の操作をしている。
これらの既存設計を踏襲して、設定変更用のコンフィグを書いていく。本社残置になるプレフィックスは本社専用であるということと、何のプレフィックスかがわかるようにタグを分け、本社を通って、国内国際と行き来していたタグは、北陸の経由という意味合いに変えて行く。加えて、本社と北陸データーセンターの間の渡り専用線を終端しているルーターも、同様に、ＷＡＮ、ＬＡＮでＯＳＰＦのプロセスが別になっているから、交換するルートを外部ルートとして、タグを利用し、意図的にルートの許可、拒否、重み付け変更などを実施する。
北陸のデータセンターでは、グローバル網に接続しているルーターが一台、国内網に接続しているルーターが一台、北陸のデーターセンターと本社のデーターセンターを直結している回線のルーターが一台ある。本社では、国内網に接続しているルーターがメイン、バックアップで二台、北陸のデーターセンターと本社のデーターセンターを直結している回線のルーターが一台、東京のデーターセンターでは、国内網に接続しているルーターがメイン、バックアップの二台、グローバル網へ接続しているルーターが一台。ルーターだけ取り上げると最終的にはこういった構成になるが、これだけ相互再配送ポイントが多いと、当然同じルートが双方向からやってくる箇所があるし、障害発生箇所によっては、通常ＬＡＮからＷＡＮへ再配送しているルートを、ＷＡＮからＬＡＮへ再配送しなくてはならないポイントも存在する。ＢＧＰの部分も問題だが、ＯＳＰＦの部分はもっと問題だ。都は、メトリックで重みが異なるものがやってくるから、メトリックの違いで、意図通り優先できる、と机上だけで計算し、三日でなんとか設計と、コンフィグを完成させた。火曜と木曜は徹夜をし、朝一度帰ってシャワーだけ浴びてもう一度出社して、金曜の夕方までになんとか設計と、ルーティング確認のためのテストプランを考え終わった。プレフィックスごとに経路制御をしているので、東京データセンターのデータ、国内拠点の音声、などと言った感じで分けられているプレフィックスを使って、それぞれの拠点からその到達性と通過経路を確認すれば良かった。
しかし、このときに都は重大な間違いを犯している、というより重大な仕様を知らなかったことに後で気がつくことになる。そして、２０時間以上、データセンター内に缶詰状態になっても、とりあえずルーティングを安定させるだけで、何も問題が解決せずに作業を終えるしかなかった、あの一年半前の夏の、長い工事が始まるのだった。