20-4
20-4
トラブルが解消せずに工事が終わっているので、月曜に代休を取るわけにもいかず、都は定時通り出社した。徹夜続きで、疲れてはいるし、元気もないが、関わってしまった工事の、自分の設計とコンフィグでトラブってしまったのだ。たとえそれがどんなに大きなネットワークの、重要な切り替えなのにも関わらず、全く事前に何も知らされないまま、たった１週間で準備しろという、とても都のスキルに見合わない仕事だったとしてもだ。はっきり断れなかった都が悪いと言えばそうだろう。こんな状況では、体調が悪いと休むわけにもいかない。上野だって、北陸から帰ってきて朝から出社しているだろう。上野は統合ＰＭだから、本案件に仕事を絞れたとしても、お客対応だけではなく、サーバー関連で入っていたベンダーのマネージメント業務だってあるはずだ。
都が派遣社員として勤める、この通信キャリア内の少しややこしいルールで、他部署からこのビルへ常駐している都の席は、上野たちの席とは別の階にあった。そのため、上野が今日出勤しているのかどうかは、辺りを見回したところでよくわからない。上野のスケジュールを見てみると、休みにはなっていない。上野はスケジュールをかなりこまめに入れるタイプなので、おそらく出社しているだろうし、先週末の工事については上野から声をかけてくるだろう。都はそう思って、まずは自分のメールチェックを始めた。メールチェックが終わる頃、私用のスマートフォンに上野からＳＭＳがきた。
みやみやってさあ、ホットコーヒーにミルク多めだったよね？
朝の挨拶も何もすっ飛ばして、いきなりこれだった。都がこの頃常駐していた、上野の部署が入っているビルの２階には、カフェがあって、時折上野に誘われて、一緒にコーヒーを買いに行ったりしていた。上野がカフェにコーヒーを買いに行くついでに、都の分も買ってきてくれる、ということなのか、何か他に意図があって、都のコーヒーの好みを聞いているのかがよくわからなかったので、都は、そうだ、という旨を、朝の挨拶一緒に返した。上野からは、りょーかい、とひらがなで返ってきた。真夏でもホットコーヒーを飲む女、と上野から言われた記憶がある。
上野と同じ部署の社員がＰＭを務める、特殊体制をとるプロジェクトの工事が、２週間後の金曜の夜にあるので、都は事前に用意してあるコンフィグのチェックに手をつけ始めた。本当は先週に一度チェックをしたかったのだが、上野の工事がいきなり入って、その準備に稼働の９５パーセントを持って行かれてしまったから、この工事のコンフィグは作成自体が終わっていることもあって、チェックを後回しにしていた。試験用のマクロの動作確認もしないといけないのだが、これも後回しになっている。この工事もかなり大きい構成変更なので、事前準備をかなりしっかりやった。シュミレーター上で環境を作り、何日もかけて検証をして設計をし、コンフィグを作成、ＰＭとのレビューも済ませたものだが、都の作るコンフィグは何度か見直さないと、小さいミスが所々に出るので、それを工事までに潰しておく必要がある。かなり入念に準備したものでも、工事まで時間的に余裕があれば、稼働の空きがある時に、日や週を明けて作成済みのコンフィグを何度か再チェックする。これは当時も今も都はやっている。特に、ディスプレイ上では発見できなかったミスが、印刷して紙媒体にすると発見できたりするので、再チェックは稼働の無駄と馬鹿にはできない、と都は思っていた。
先週末の工事は、都の普段の、石橋を三回叩いても渡らないような、下準備にかける稼働の多さから考えると、ありえない工事だった。もうあのネットワークを触ることがあるかどうかはわからないが、今度関わる機会があれば、きちんとした準備期間が欲しい。しかし、都は結局根本原因がわからなかったのだ。果たして時間をかけても、本当に都に設計ができるのかどうか。
都がコンフィグの見直しをしていると、席の島の端から上野が、おはよー、と挨拶をしながらやってきた。複数のドリンクを持ち帰りで買った時に、カフェがつけてくれるダンボール製の、カップが四つ嵌められるトレイに、二つのカップが入ったものを両手で持っている。空いたホルダーには、上野の財布や携帯が乗っていた。
都が座っている一角は、他部署やグループ会社からこのビルに常駐している人や、業務委託の会社の人のために用意された一角で、都の両隣、両斜め前、それに目の前も空席で、都は一人で島にぽつん、といることが多い。このフロアで都と同じ業務をしている人はおらず、他人と話すこともほとんどないから、都は時々、職場で一人きりで放置されているような気がして、とても寂しかった。おかしなものだ。都は一人でいるのが好きなはずだ。それだからこそ、兄の結婚で兄との同居が終わった時、実家に帰らず一人暮らしを始めたのだ。父が亡くなった後、母が年老い、持病に苛まれるようになっても、一人暮らしをやめていない。何人か付き合った男たちとも、愛し合う時は、決して自分の部屋には入れず、外じゃなければ相手の部屋か、ホテルだった。そこまで一人が好きなのに、話せる同僚が近くにいない職場環境が寂しいなんて、おかしなことこの上ない。都は、本当に自分は勝手な人間なのだと思った。
「いやー、週末はお疲れさまでした。」
上野はそう言いながら、都の隣に座って、段ボールのトレイからカップを一つとって都に渡した。都がこのカフェのコーヒーでは、いつもミルクポーションを２つ使うのを覚えていてくれて、それももらってきてくれていた。都は、買ってきてくれたことに礼を言って、財布を隣の空き席に置いてあるハンドバッグから取り出そうとすると、上野は奢りだからと、手を振って否定した。
「まあ、お礼にしちゃあ、安すぎなんだけどさあ。」
上野はそう言いながら笑った。都はすみませんと頭を下げてから礼を言った。都がコーヒー中毒と言って良いくらいコーヒー好きなのは、わりと知られていて、間宮さんに何か頼みたいときはコーヒーを買ってけ、とか、何かしてもらったらコーヒーを差し上げなさいとか、まるでお供え物のように冗談で言われることもあり、それらの申し出を遠慮しながら都自身も笑いながら受け取ってしまう。
それからコーヒーを飲みながら、上野と二人で、先日のトラブルは結局何が原因なのかという話をした。都は、自分にはさっぱりだ、ということと、もし根本原因を探ったり、対策をきちんと取る設計の修正を行うのであれば、一から環境組んで、検証からやって設計しないとダメだろうという話をした。
「それさあ、もーしわけないんだけど、お願いできないかなあ。」
上野はまた気軽な感じで頼んできた。それは単に本当にお願いしているだけなのか、都が断らないという確信を持って、言っているのかはわからなかった。ただ、上野も、ちょっとやってくれ、でやれるようなものではなかった、ということは十分理解しているようだった。
「いいですよ。」
都も都で、気軽に引き受けてしまった。上野はこんな風に人と気軽な関係を作って、人を乗せるのが上手いのかもしれない。いや、コーヒーを奢ってもらって、都が断りづらくなっているだけなのかもしれない。そもそも都は頼まれると断れない性格だ。しかしその一方で、なんとか自分の力で、このわけのわからないトラブルの原因を突き止めて、どんな障害が起きても、きちんとバックアップが出来、復旧後は設計通りのルーティングへ戻る設計へ修正したい。そう思っていたのも事実だ。だから、願っても無い機会だと、勢い余ってしまったところもあっただろう。
引き受けることになった都は、とにかく一から順に検証していかないと、正直トラブル原因は分かりかねる、だから設計がまとまるまでかなり時間がかかると思って欲しい、どれくらい時間がかかるかは見当がつかない、という旨上野に話した。上野は了承した。報告書というもののほどでもないが、今回断からの復旧時にルーティングが自動で正しく戻らなかった原因を、お客へ報告する必要があるから、今日の午後くらいにちょっとヒアリングさせて欲しい、と上野は言った。都も何が原因かと言われれば、何だかわからないから、適当になりかねないですよと、都は予防線を張った。
「その辺はだいじょーぶ。あたしが上手くやるから。」
そういうと上野は豪快な感じで笑うので、都もつられて大笑いしてしまった。上野は、上野のマネージャーから、都のマネージャーの末谷へ、この件で都の稼働を大幅に取ってしまうことについてエスカレーションをちゃんとしておくと言ってくれた。それはありがたくもあったが、これで逃げ道は塞がれた、とも言えた。
上野が自席へ帰った後、結局都は、他の仕事はひとまず置いて、この問題から取り掛かることにした。
一体何がいけなかったのか。都は作業用ＰＣから、通常端末へ移しておいた、最後に取得したログをもう一度見直していった。トラブル時は、相互再配送ポイントでＯＳＰＦプロセスの再起動を実施しないと、設定した通りのメトリックでルーティング出来なかったのだ。原因は何なのか。特に、北陸データセンターと東京データセンターは、ＷＡＮもＬＡＮも、プロセスは違うといえどＯＳＰＦだ。メトリックでルーティングが出来ないなんて、そんなバグでもあるのか。都は、色々検索の単語の組み合わせを変えながら、インターネットで検索をしてみるが、どうも似たような事例は見つからない。検索下手の都だから、結果は怪しいのだが、とにかく都には見つけることが出来なかった。
そもそも、ＯＳＰＦを、プロセスを分けて回す時は、何か制約でもあるんだろうか。ふと都はそう考え直して、検索してみた。すると、すぐに引っ掛かった。文字通り、異なるプロセスの間で、ＯＳＰＦのルートの再配送について、という内容だ。しかも都が実際に触っているルーターのメーカーのサイトだ。都は、鳥肌がたった。そのリンクを開いて、内容を読めば読むほど、もっと鳥肌が立って、都は左手で右腕をこすらないといられなくなった。その時都が受けた衝撃は、体中を戦慄が走った、というのがぴったりだった。
同一筐体上で、ＯＳＰＦを複数の異なるプロセスで運用した場合、そのプロセス同士はお互いを、異なるプロトコルとみなす。そのため、その異なるプロセスに同一ルートがある場合、ルートの優先度はＡＤ値のみの比較となり、ＡＤ値が同一であれば、早い者勝ちになる。そういう仕様となっていた。つまり、異なるプロセス上のＯＳＰＦルート同士では、メトリックを比較しないのだ。都は、あの２０時間以上の工事の中で、嵌ったトラブルの原因に、色濃くかかっていた霧が晴れて行き、隠れていた景色が全て見えてくるような気さえした。何か清々しい空気が都の中を吹き抜けていくような感覚すらある。だから、優先したくない方のプロセスを再起動すると、優先したい方が古いルートとなり、設計通りにルーティングが戻る、ということが起こっていたのだ。
音声プレフィックスが、非対称になってしまったのも、本社データセンターか、北陸データーセンターのどちらかの、国内共有Ｌ２網のＷＡＮエッジルーターで、ＬＡＮ側のルートが古い状況であり、且つ、ＬＡＮからＷＡＮへの再配送時に、音声プレフィックスが何か他のプレフィックスと、同じ扱いで良いという設計になっていて、それに紛れて国内共有Ｌ２網へ強いメトリックで再配送されてしまっていたとすれば、国内共有Ｌ２網に下がっている通常の国内拠点のＷＡＮエッジルーターでは、単純なメトリック勝負の結果、東京データーセンターのルートを選ばなくなってしまう。
こんな基本事項も知らずにやっていたのだ。これではトラブルしか起こらない。この原則を頭に入れて設計しなければいけなかったのだ。しかし、都が手をつける前の、北陸データーセンターの導入以前のトポロジー、本社データーセンターと、東京データーセンターとで、国際網と国内網をつないでいた頃の設計を見てみると、今も踏襲している、東京データーセンターの国内共有Ｌ２網側のＷＡＮエッジルーターの設計では、ＬＡＮ側のｉＢＧＰと、国内網側のＯＳＰＦで、必ずＬＡＮ側のｉＢＧＰが勝つようなＡＤ値操作がしてあるが、本社データーセンターの国内網側ＷＡＮエッジルーターの、ＷＡＮ側のプロセスと、ＬＡＮ側のプロセスでは、ＡＤ値の差分付けは行っておらず、冗長のためＷＡＮとＬＡＮから同じルートがくるような場合、早い者勝ちになって、意図通りルーティング出来ないことになっていたように見える。当時はこれで上手く行っていたのだろうか。それとも潜在的な問題が北陸データーセンター移行まで明るみに出ずに済んだのだろうか。運用フェーズで、回線故障などがあった時、復旧時にルーティングが戻らなかった場合、保守でＯＳＰＦプロセスの再起動をやるのは、基本動作の一つだろう。そのため表面化しなかっただけ、という可能性はある。
都は、一つずつ検証を進めていく方向をとることにした。シミュレーターのパレットを開き、まずは、国内共有Ｌ２網に下がる拠点を表すルーターを一つ置く。国内共有Ｌ２網はＬ２網だからスイッチングハブで表現すれば良い。本社データーセンター内のルーター群として、国内共有Ｌ２網側のＷＡＮエッジルーターをメインとバックアップ、それにコアスイッチを表すルーター、インターネットゲートウェイを表すルーター、合計４台のルーターを置く。まずはこの構成だけで設計をしていく。
この構成で通信必要なルーティングを確認するための、疎通確認と通過経路確認のマクロを作り、設計、コンフィグ完了後に正常性を確認する。問題なければその後、本社データセンターの国内共有Ｌ２網の、ＷＡＮエッジルーターのメイン機で、ＷＡＮ、ＬＡＮの断試験、復旧試験をしていく。この本社データーセンターと国内拠点だけの環境であれば、ほぼ今のままのコンフィグで問題はなかった。
ここまで上手く行ったら、次は東京データーセンターをこの環境に足していく。東京データーセンターの、国内共有Ｌ２網のＷＡＮエッジルーターのメイン、バックアップ、コアスイッチ、国際網側のＷＡＮエッジルーター、東京データーセンターの音声用ゲートキーパー、それぞれを表すルーターを置いて、東京データーセンターを模する。東京データーセンターを表すルーターは計５台。国際網はＬ３網なので、１台のルーターで表現し、ループバックアドレスを、ＢＧＰのルーターＩＤ用に使うものとは別に２つ用意し、国際拠点のデータプレフィックスと、音声用プレフィックスをその２つで表現する。東京データーセンターを含めると、疎通確認、通過経路確認のプレフィックスが増えるので、疎通確認、通過経路確認のマクロも増やす。冗長試験も、東京データセンターの、国内共有Ｌ２網のＷＡＮエッジルーターのメイン機で、ＷＡＮ、ＬＡＮそれぞれの断試験、復旧試験を追加する。
東京データーセンターを模した環境を追加しても、やはりそれほど大きくコンフィグをいじる必要はなく、通常時のルーティングに問題はなかったし、合計４箇所になった冗長試験も、断試験、復旧試験ともに問題なかった。ここまでは問題ないだろうと、事前に想定していた。まだトポロジーとしては単純だ。検証に取り掛かった一日目はここまでで終わった。他の業務もこなしながらだから、結局自宅へ帰ったのは日付が変わってからになった。一日目から飛ばし過ぎな気もしたが、根本原因ははっきりしたのだ。出来るだけ早く、問題を解決する設計を完成させたかった。
二日目、北陸データーセンターを環境に入れていく。まずは専用Ｌ２網は無しにして、国内網へ接続するルーター、コアスイッチ、国際網へ接続するルーターを表す、３台のルーターで北陸データーセンターを構成する。通常状態でのルーティングは、実際にコンフィグしたものでほぼ問題なかった。これで国内拠点と国際拠点間のデータ通信は、北陸データーセンターと、東京データーセンターとでメイン、バックアップになる。音声通信は、メイン、バックアップがデータ通信と逆になる。そして、さらに冗長試験を追加する。北陸データーセンターの国際網側ＷＡＮエッジルーターの、ＷＡＮ、ＬＡＮそれぞれの断試験、復旧試験を追加する。もちろん国内拠点、国際拠点の音声通信の冗長確認のため、東京データーセンターの、国際網側ＷＡＮエッジルーターの、ＷＡＮ、ＬＡＮそれぞれの断試験、復旧試験も追加する。
国際網側のそれらに加えて、北陸データーセンターの国内共有Ｌ２網側のＷＡＮエッジルーターは１台しかないが、ここが断になった時に、国内拠点が、東京データーセンター、国際網と通り、北陸データーセンターへアクセス出来るようにさせるという、最終的には３番目のバックアップルートとなる、この回り込みルートも上手く行くか試験しておく必要があるので、北陸データーセンターの国内共有Ｌ２網側ＷＡＮエッジルーターの、ＷＡＮ、ＬＡＮそれぞれの断試験、復旧試験も追加する。これで、冗長試験は１０箇所となる。
ここで、さすがに色々と想定してなかったトラブルが起きた。実際にはやっていない断試験ばかりだが、もしこれらのどれかをやっていたら、さらにトラブルになったということだ。検証の冗長試験で上手く行かない場面に遭遇すると、都は工事当日の、あの絶望的に解決策が見つからないという状況の心理状態を思い出して、緊張で手が震えてしまいそうになる。既存踏襲したコンフィグにも不備があり、トラブル起因になっていることを発見した。そもそもトラブルとなる設計を抱えていた、ということだ。そう言えば上野が、本社データーセンターに国際網が接続されていた頃、本社近くに建設される外環道の工事のため、光回線をキャリア側で敷設し直さなければいけない時があって、その断発生時にルーティングがおかしくなったトラブルがあったという。再現させることが、つまりもう一度実際に断を起こすことが出来なかったことと、また当時北陸データーセンターへの移行も計画されていたこともあり、原因についてはうやむやとなったという。
国際網側のＢＧＰについては、ルート受信時の重みづけの設計を追加したり、北陸データーセンターであれば、同一プレフィックスがＯＳＰＦからの再配送にも、ＷＡＮからの受信ルートにもある場合、どちらかで拒否したり重みづけの差分をつけたりが必要になった。国内共有Ｌ２網側のＷＡＮエッジルーターでは、ＬＡＮのプロセスからＷＡＮのプロセスに再配送する時、たとえ同じプレフィックスのバックアップルートだとしても、タグを付け替え、本来のそのルートの出自では、その付け替えたタグを拒否するようにしたり、付け替えたタグの場合は、本来のタグとは処理を変更したりしないといけなかったりもした。これは東京データーセンターの国内共有Ｌ２網側のＷＡＮエッジルーターでも事情は同じだった。そのような様々な対策が不足していたことも、追加された冗長試験を実施することで発見出来た。
東京データーセンターの国際網のＷＡＮエッジルーターのＬＡＮ側はｉＢＧＰなので、ＷＡＮ側のｅＢＧＰとのルート差分をつけるには、ＡＤ値ではなく、ＢＧＰのベストパス選択の順序を上手く使ってやれば良い。しかし、国内共有Ｌ２網側のＷＡＮエッジルーターでは、ＬＡＮ側のｉＢＧＰはＷＡＮ側のＯＳＰＦより一律で強くなるように、ＯＳＰＦ側のＡＤ値を操作している。国際網側からのルートが強いべきか、国内共有Ｌ２網からのルートが強いべきかを考慮して、ＬＳＡのソースを絞って、ＡＤ値を変更するように、設計を考え直す必要もあった。
それは北陸データーセンター側も似たようなもので、国際網側のＷＡＮエッジルーターで、国内共有Ｌ２網側から来るルートを優先させるのであれば、まず北陸データーセンター内において、ＯＳＰＦのメトリック勝負で勝つようにした上で、その特定のルートのみ、国際網のＷＡＮエッジルーターで、ＡＤ値がｅＢＧＰよりも勝つようにしたりなど、設計上の工夫が必要になってくる。
それでも、ここまで大体１０日程度で設計はまとまったし、冗長試験も１０箇所きちんと断も復旧も上手く行くようになった。途中で他の案件の、週末の夕方から翌朝までかかる工事は、同等といっていいくらいの複雑さだったが、こちらは準備をきちんとしていたので、何のトラブルもなく、線表の予定時刻通り無事完了した。
都は、環境を加えていくごとに、プレゼンテーションファイルにネットワーク図を作り、ポイントとなる設計やコンフィグについて、各ルーターを指す吹き出しなどへ書き足していった。最終的に、それがルーティングマニュアルになれば、自分でやった設計だが何のために施したのか忘れてしまった時も、見返せば良いし、担当者が変わった時も、この資料があれば理解の一助にはなるだろう。しかし、ポイントとなる箇所が多く、とても一枚のネットワーク図にまとめることは不可能で、結局経路制御や処理が異なるプレフィックスごとに、スライドを作っていかなくてはならなかった。
いよいよ、北陸データーセンターと東京データーセンターとを結ぶ、専用のＬ２網を検証環境に追加する。専用のＬ２網は、国内共有Ｌ２網とは別のスイッチングハブで表現し、北陸データーセンター、本社データーセンター、それぞれの専用Ｌ２網用のＷＡＮエッジルーターとして、ルーターを２台追加すれば良い。しかし、都がオフィスで使っている通常端末のスペックでは、シミュレーターでこの環境を再現するのには無理があり、動作がもっさりとしてしまうから、一つ一つの確認に時間がかかるようになってきた。冗長試験は、北陸データーセンター、本社データーセンターの専用Ｌ２網の、ＷＡＮエッジルーターのＷＡＮ、ＬＡＮそれぞれの断試験、復旧試験を追加するので、計１４箇所になる。さらに、本来二重障害はサポートしない、というのが表向きではるが、ルーティングの正常性を確認する意味もあり、二重障害のパターンも３つ追加し、合計１７の冗長試験になった。そこまでやる必要があったのかどうかは微妙と言えばそうだが、とにかく想定外のトラブルをこれ以上出さないためには必要だと判断した。１７箇所もあるので、番号を振って、順にこなしていくことにした。１７番目まで上手く行けば、設計も大丈夫だという判断が出来る。
しかし、この専用Ｌ２網を環境に追加してからが、この検証は本番だった。まず、今までの検証で得た知識や経験を生かして、コンフィグを作成したが、工事当日に入れたコンフィグとは相当に異なるものになった。それは設計そのものを丸ごと変更したといって良いくらいだ。そこからさらに微調整をして、通常時のルーティングで問題が起こらなくなったら、これで検証環境はひとまず完成になる。ここから、１７箇所の冗長試験を一つずつ実施していく。
いざ冗長試験に取りかかってみると、３番目まで上手くいっても、４番目でループし出したり、その４番目の冗長試験の問題を直すと、今度は６番目まで上手く行くが、７番目で、復旧時に非対称ルーティングが発生したり、と躓きながらでしか進めない。しかも、その７番目の冗長試験の問題を解消すると、今度は２番目の障害試験で通信が止まってしまったりと、せっかく進んだ道を戻らなくてはならなくなったりもした。一旦止めたタグを通すことにしたり、通していたタグを止めたり、メトリックを変更したり、ＡＤ値変更の対象を追加したり。冗長試験で失敗するたびに、設計通りにならない通信の、通過経路がおかしくなるポイントを探し出し、必要な変更を実施して行く。しかし、いくつかの失敗した冗長試験を成功させるために変更した箇所で、今度はそれが原因で上手く行かない冗長試験が出てきたりと、悩ましいことも、頭を抱えてしまうことも多く、自宅で検証している時などは、もう分かんない、と泣き言を喚いてしまうこともあった。
国際網側は、ＢＧＰのスタンダード・コミュニティを通す仕様なのは知っていたから、既存では使われていなかった、スタンダード・コミュニティをプロバイダエッジルーターへ伝播させることにもして、それを使って、北陸データーセンター、東京データーセンターの、国際網ＷＡＮエッジルーターで、同一プレフィックスを制御することを可能にし、制御を調整する幅を広げたりした。実際の工事の前から心配された通り、お客が敷設した、この本社データーセンターと北陸データセンターを接続する専用のＬ２網が、ルーティングを複雑にしてしまっている。
都は、普段あまり仕事を時間で切って計画的にはやらないのだが、この時は、特に北陸データーセンターを検証環境に追加するあたりからは、１５時までは、元々正式にアサインされているプロジェクトの業務、１５時から２１時までは、この検証作業、そして、同じシミュレーターを自宅のＰＣにも入れてあるから、進んだところまでの環境ファイルを暗号化し自宅へ送り、自宅へ帰ったら、さっさとシャワーとご飯を済ませて、オフィスから送った環境で始めて３時半まで検証を続ける。そして自宅で設計の進んだ環境を会社の自分のメールアドレスへ暗号化して送り、次の日は、と言ってももう「当日の朝」なのだが、会社でその環境から始める。これを毎日繰り返した。もちろん、自宅で検証をやっている間のお金は発生しないが、とにかくこの設計をなんとかやり遂げたい、という思いだけで動いていた。とても会社でやっているだけでは終わらないし、毎日終電ギリギリまでやるよりも、この方が検証時間を増やすことが出来る。シミュレーターの環境ファイルが、セキリュティ的に問題があるかどうかというのは微妙だが、ホストネームは全部Ｒと番号だけで、例えば北陸データセンターの国際網側ＷＡＮエッジルーターはどれかなどは、都の頭の中に入っているだけで、マスクされていると言えた。プライベートアドレスだけで構成されたネットワークなので、インターネットだけは適当なアドレスで表現しておいて、このネットワークが何かは他人には想定出来ないようにはしてある。
自宅では、スノコの上のマットレスに敷きっぱなしの敷布団の上に、すごく厚みのある技術書を机にして、その上にノートＰＣを乗せ、あとはマウスパッドやコーヒーカップを置くトレイなども敷布団の上に置いて、布団の上で作業をした。３時半を過ぎたら、コーヒーカップを片して、ノートＰＣを閉じ、部屋着を着ているのであれば、着ているものを全部脱いで、そのまま毛布と布団をかぶってしまえば良い。そんな生活をしばらく続けた。
冗長試験の番号の２桁目までいくようになると、流石に１桁目の冗長試験へ戻るようなことはあまりなくなった。しかし、この辺りから、かなり特殊な設計を持ち込まないといけなくなってきた。送信元から何ホップも先の遠い目標をターゲットとした、トラッキングを仕掛けたり、しかもそのトラッキングのために、わざわざそのトラッキングの送信元と宛先間のトラフィックを曲げるためにルーティングの制御を追加したり、他経路で回り込まないようにしたり。別のルーターでは、トラッキング対象への到達性がなくなったら、それをトリガーに、通常時には存在しない、集約ルートのスタティックルートを書いて、トラフィックが正しいバックアップ経路へ回るようにしたり、到達性が戻ったら、コンフィグを元に書き換えるようにしたり。そんなようなことをしないといけなくなってきた。
もっとも二重障害には対応しない、と言い切ってしまえば、苦労して入れる必要もないコンフィグもあるのだろうが、ネットワーク全体としての設計の正常性を保つには、想定外の障害があった場合、障害からの復旧時に自動で設計通りのルーティングへ戻る必要がある。そのため全く不要かというと、そうでもない。想定外の障害が発生し、復旧時にきちんとルーティングが戻らないと、お客の業務に影響が出るのはもちろん、これだけ複雑な構成と設計だから、保守では解決できず、構築へエスカレーションされてしまう。エスカレーションされた時に慌てて考えても、有効な策や案は安易には浮かばないだろう。
検証を始めたのが、８月の最終週、そしてようやく１７箇所の冗長試験全てをクリアできる設計まで持ってきたのは、１０月の２週目だから、約一ヶ月半かかって、修正設計は完成した。自室で検証作業を始めた時は、何も着ないで作業できたが、設計が終わる頃には、丈の長い部屋着をワンピースのように着ないといけない気温になっていた。設計しながら作ったプレゼンテーションファイルは、結構なスライド数になった。
「やったあ！」
設計が完了した翌日出社して、都はようやく終わったことを、時間がかかってしまったことへの謝罪とともにＳＭＳで上野へ伝えると、そう返ってきた。上野は時々、様子を見に都の席まで来ていて、その都度、こういう問題があって、こうしないといけない、などと都は途中経過を説明はしていたが、最終設計について少し説明したいから、時間ある時に都の席まで来て欲しいと伝えると、上野は了解と来る時間を返してきた。実際に来た時は、またホットコーヒーを都のために、ちゃんとミルクポーション２つをつけて買ってきてくれた。
この検証作業をやっている間も、このお客の東京データーセンターや北陸データセンターに、新しいプレフィックスを追加する設定変更工事があって、それも都がＳＥをやった。上野はこの一ヶ月半の間、都を急かすこともなかったし、お客からも急かされてはいないようだった。しかしそれは上野がうまくお客をなだめていてくれただけなのかもしれない。あるいはお客自身が、北陸データーセンターと本社データセンターを冗長目的のため別網を使い接続したことで、お客自身で想定していたよりも、設計が複雑になってしまったことを理解してくれていたのだろうか。何れにせよ、上野とお客の関係が良好だったからこそ、都は検証と設計に集中することが出来たのだろう。お客がどう思っているかなどは、上野は都にあまり話さなかった。恐らくは都に変なプレッシャーを与えないよう気を遣ってくれていたのだと思う。
そして、この最終設計を設定変更という形で、実施する機会がやってくることになった。新しいプレフィックスを本社データーセンターに、また追加する設定変更工事が予定されており、その時に、この修正設計も一気にやらせてもらうことで、お客と合意が取れたと言う。都は、前回の、あのデーターセンターに２０時間以上籠った工事が終わったら、髪を切りに美容院へ行こうと思っていたが、こんな事になってしまったので、行けていなかった。髪の毛がだいぶ伸びてしまっていたから、毎日前髪を脇へ流して、ピンで何箇所か止めていかないといけなかったが、この設定変更が上手く行ったら、切ってさっぱりするんだと決めていて、それを目標にしているようなところさえあった。
以前の設計担当者が作ったルーティングマニュアルが見つかったというので、上野がそれを都に共有してくれた。都が作ったものよりもスライド数が多かった。細かく端から端まで見てみたが、事前にこれがあっても、都はトラブルになっただろう。何故なら、そこにはＯＳＰＦの異プロセス間の、相互再配送時における注意事項が書かれていないのだ。この資料を作った人のスキルが非常に高くて、そんなことは常識だと思っていたのか、それともたまたまそれを意識しなくても、当時の工事では上手く行ったのかは判然としない。しかし、都は既存踏襲としていた設計に対してもかなりの修正をしたので、本当にこの基本原則を前任者がわかっていたのかは微妙な気がする。何れにせよこの北陸データーセンターの導入で、設計はきちんと時間をかけて大きく見直さなければならなかったのだ。