検証したのに冗長ルータが本番環境では切り替わらなかった話

もう10年ぐらい前の話なので懺悔として記載します。

背景

まだ駆け出しのネットワークエンジニアだった私は、先輩から「こういうルータ作ったんだけど動作検証しといて」と資料一式を渡されました。

店舗の重要性が増してきたため、店舗のWAN回線を冗長化したいという商談でした。既存環境の設計書やコンフィグもあり、追加WANルータのコンフィグも既に先輩が作ってくれていました。私は試験仕様書を書き、検証環境を組み、冗長化試験を行いました。特にコンフィグを訂正することもなく試験は完了したため、先輩に引き渡しました。なのに・・・本番環境ではうまく動かなかったのです。

直接の原因

詳細は覚えてない部分もありますが、一言で言うと「顧客側の環境を検証で再現できていなかった」ということに尽きます。確か経路情報だったと思いますが、コンフィグの中で顧客L3#1を直接指定しているところがあり、本来は追加ルータでは顧客L3#2に指定する必要がありました。その設定ミスにより経路情報が途絶えてしまいました。

もっとも動作検証のときなので本番業務を停止した状態で行っており、たいした影響もなく、コンフィグを1行修正するだけで直りました。めでたしめでたし・・・・
だったらこんな記事書いてないんですよねえ（涙

影響範囲

この店舗回線冗長化は、実は全国の約300店舗で実施予定であり、検証結果を持って全300台のルータへの設定投入が完了しているうえに、既に現地の設置担当者へ配送済みなのでした。つまりー、この設定ミスを修正するには、日本全国を回る必要があり・・・・？？！？！？？

回避策

さすがにそれは忍びねえということで、設置担当者への設置手順書を修正し、現地の接続動作確認前にコンフィグを修正してもらう手順を追加しました。大変ご迷惑をおかけしました・・・

原因の深堀り

• 新規導入するWANルータの検証ばかりに目が向いており、既存顧客ルータを試験するという意識がなかった。そもそも、既存顧客L3がどういう状態であれば正常なのかということも理解できていなかった。（ルータを超えて疎通確認さえできればよいと思っていた。）
• 顧客L3のコンフィグや設計書を貰えていなかったため、検証環境の顧客L3想定ルータは、一般的なL3を想像してコンフィグを自作していた。 当然、顧客L3と同一機種を用意する方法もお金も時間もなかった。
• 検証環境では顧客想定ルータに試験PCを直接接続していたが、このときは経路情報の交換ができていなくても通信ができてしまう環境だった。本番環境ではさらにその先にL3があることで経路情報が必要となり、障害が発覚した。

さらに深堀り

• 既存環境や顧客環境は、これまで担当してきた先輩がよく知っているのだから貰った情報で問題ないだろうと思い込んでしまった。（実際には先輩も知らない部分があった）さすがに先輩に「この情報ほんとに合ってます？」と聞くわけにもいかず。顧客担当者とも面識がない状態だった。
• 責任分界点があるのだから、自社のルータで障害が起きれば責任をもって対処するが、顧客側で何か問題があったとしたらそれは顧客側で対処すべき、という甘えがあった。
• 開発環境の顧客側L3をどこまでこちらで検証すべきか？ という議論ができていなかった。そもそも社内検証であり、検証項目は顧客担当者にレビューしてもらうものでもなかった。

その他の反省点

• プロジェクトスケジュールの都合なのか、社内検証をもってキッティングを開始してしまっていた。そもそも先行店舗での実環境試験を行い、それにOKが出てからキッティングを開始すべきだった。

その後どうしたか

責任分界点は切ったうえでなるべく踏み込む

お金を頂いて作業する以上、責任範囲を明確にすることは最重要ですが、その上でそこを踏み越えて相手環境にもお世話をするようになりました。いわゆる「ポテンヒットを無くす」というやつです。（まあ、どうせヒットが出ると怒られるのはこちらなので・・・
ベンダーつぎはぎだらけのネットワークで、全体設計者などどうせいないので、俺がネットワークの全体設計者だ！という気概だけは見せるようにしました。それが要因で次のお仕事を頂くこともありましたので、ありがたい限りです。

接続仕様書を書くようにした

こちらのネットワークの基本設計書とは別に、接続仕様書として、IPアドレスやHSRPのIDなど、こちらが想定している顧客側パラメーター欄を設け、お客様 （の技術担当者） にレビューしてもらうようにしました。関係が良ければ直接資料を修正してもらったり、そうでなければこちらでヒアリングした結果を埋めたりしました。埋まらなかったとしても「このパラメータはうちは認識していないまま作業をしてますからね、それが原因で障害が起きても知りませんよ」という逃げ道を作ることができました。こうして大人は汚くなっていくんだ・・・

所感

ネットワークの検証環境はアプリとは違って、全く同じ環境を作れるというのは稀です。物理的・金銭的な制約がありますし、WAN回線なんて顧客と同じものをいちいち自社に引くことはできません。かといって、お客様に全部用意しろというのも酷な話です。
どうしても本番環境でないと正確な試験ができない項目はありますが、だからといって検証環境は大体でいいやという考え方では検証の意味がありません。
なので、ファームは本番と同一にしますよ、この機器は同一プロトコルが使える機器で代用しますよというような論点をまとめ、試験仕様書の最初のページでは「検証環境では何が確認できて、何が本番でしか試験できないのか？」を記載し、社内にもお客様にも合意を取ります。
その中で、「いやそれは検証が甘いのではないか？」という意見が出れば、機器を用意するなり期間を設けるなり、交渉の余地ができます。また、本番接続試験で失敗したとしても、「ここは検証環境では検証できていない部分です」という説明ができれば、そこそこ見逃してもらえお客様の負担も多少は減るのではないかなと思います。

よきネツエンライフを！