2022年8月12日

昨年にはdocomoが1日以上、2018年にはSoftBankでも4時間以上のサービス停止が発生したり、KDDIに限った話ではありませんがインターネット接続や携帯通信サービスの普及以来、通信障害が与える範囲が有線接続による固定回線しかなかった時代に比べると広大になっています。SoftBankの場合は、ネットワークの中枢部に設置されたLTE交換機内のTLS証明書の有効期限が切れたために発生した障害ですが、docomoの場合は端末の位置情報を管理するサーバのリプレース、KDDIの場合はVOLTE交換機のメンテナンスといずれもネットワーク中枢に設置されたサービスの肝になる機器の運用に関わるミス・不具合が原因でした。

これらの通信障害に限らず、この種の大規模なトラブルが発生した場合に「事前のテストなどの準備が甘かったのではないか」といった内容の批判があがってくることが多いと思います。この批判自体は決して間違ってはいないのですが、規模の大小はあれネットワーク運用に関わる領域で仕事をしている身としては「それはその通りなんだけど…」という気持ちも湧いてきます。というのも、サーバやクライアント、ネットワーク機器が数台といった小規模のシステムであれば、手近で調達できる機器でテスト環境を用意して、想定作業のテストを行うのもそれほど難しいことではありませんが、稼働中の巨大なシステムのテスト環境はかなりハードルが高くなります。

使用する機器の台数ももちろんですが、1台で数十万円や百万円単位の機器が必要な場合は、移行後の環境のコールドスタンバイ用に何台か余剰の機器が用意できているならともかく、実機が余っていることはまずないでしょうし、手軽にテスト機として購入してもらえるものでもないでしょう。加えて携帯通信ネットワークに関わるシステムの場合、仮にインフラ側のテスト環境を構築できても、そのテスト用の携帯ネットワークに接続させるための端末（SIM）の用意も面倒くさそうです。

このように、必要な機器と同等の環境を仮想マシンで構築できる場合はまだましですが、実環境と同等規模やレベルで事前準備や検証を行うことは簡単ではなさそうです。こうなると事前準備を可能な限り入念に行ったとしても、これは言い過ぎかもしれませんが、本番の実作業がぶっつけ本番と大差ないといってもいいのかもしれません。

もちろん、こういった事情があるから失敗や事故が起こっても構わないという訳ではありませんが、インフラ絡みの仕事は何の事故も起こらず安定して稼働しているのが当たり前で褒められることはまずあり得ないのに、ちょっとしたトラブルから大規模な障害まで一度発生すると非難は当然されるし、障害の原因を特定してトラブル発生前の状態に復旧できても、トラブル発生の原因追及で責められる類の仕事だなとあらためて確認した出来事でした。

2022年8月