利用者たちに混乱が巻き起こったJCOMの大規模障害──その原因から、忘れがちなBCPの観点を問い直す

「システムに問題はない」と「サービスが使える」は違う

　今回の事例には、もう一つ重要な論点がある。それは、「システム監視」と「サービス監視」の違いである。

　システム監視においては、それぞれのサーバーが起動しているか、CPUやメモリに異常がないか、ネットワーク機器が応答しているか、といった内部の状態を見る。しかし、内部の機器の状態は「正常」だと確認されても、利用者側がサービスにアクセスできるとは限らない。今回、高負荷が発生したDNSは、利用者が目的のサービスへ到達するために必要な入口の一つである。個々のサービスを構成するシステム自体は動作していても、入口が機能しなければ、利用者から見れば「サービスが使えない」状態なのだ。

　そこで必要となるのが、利用者と同じ位置からサービスを確認する、サービスの「外形監視」である。これは、実際に外部から接続してみることで、名前解決ができるか、ログインできるか、主要機能が利用できるかを継続的に確認することを意味する。機械が正常かを見る監視から、「顧客がサービスを使えているか」を確認する監視への転換ともいえる。危機管理においては、この視点の違いが初動速度を左右することになる。

最初に障害に気づいたのは誰か？

　本件のさらに興味深い点は、JCOMだけでなく、同社のサービスを利用する各地のケーブルテレビ事業者にも影響が広がったことである。

　JCOMの公式Xによる障害告知は、10時24分だったと整理されている。一方、飯能日高テレビの障害情報を見ると、10時00分時点ですでに「上位回線側での障害が発生しております」と利用者向けに案内している。その後、11時、12時、13時と情報を更新し、14時にはJCOM側の障害であることを明記している。この事案は、JCOM単体だけでなく複数組織にまたがる障害として問題化されたのだ。

　サービス提供の構造が複雑になると、障害を最初に認識する組織と、原因を調査する組織と、顧客へ説明する組織が一致しなくなる。また、それぞれの組織が持っている情報も異なる。この状態で「原因が完全に分かってから発表する」という方針を取れば、情報発信は必然的に遅くなる。必要なのは、原因の確定を待つことではなく、「現在確認できている影響」と「現在調査していること」を切り分けて発信する仕組みである。