すぐに手をうつべきクラウドを使った災害対策(その2:安否確認システム)

カテゴリー: 技術情報   パーマリンク
このエントリーをはてなブックマークに追加

今回は大地震等の発生時に、最初に行う必要がある安否確認のシステムについてふれます。

安否確認システムは自社でお持ちの場合と、サービスを使われている場合の双方があるかと思います。今回首都圏のお客様では、特に安否確認システムが十分に機能しなかったとの声を聞きました。

それはなぜか?
システムを模式的に書くと以下のような構造になっているからです。(説明のため簡略化していますので厳密な構成ではありません)
安否確認システムの模式図

今回安否確認システムのサーバそのものは、停電に遭遇したり、地震の衝撃でHDDが破損したりするようなこともない限り、動いていたことが多かったのではないでしょうか?しかしシステム全体で見ると、携帯電話へのメールが届かずに確認がとれないということが大半のケースであったのではないかと思われます。今回の震災では、地震発生当初、NTTドコモでは最大90%の通話制限をかけ、メールは30%の通信制限を行ったとの発表がされています。au、ソフトバンクモバイルでも同様にメールが届きにくい状況であったことは皆さんご存じのとおりです。私の会社携帯はNTTドコモですが、地震発生直後から夕方ぐらいまでは定期的に数通一気にメールが届く状況になっており、東京にいる私から関西へ送ったメールは夜遅くに関西に届くなど、通信制限だけでなくリレーサーバのメールキューに溜まったメールの再配送処理に相当な時間がかかっていたと類推されます。そのため、図の③の部分で制限をかけた結果、携帯電話網内のメールリレーサーバに相当数のメールが溜まり、それを吐き出す能力にも限界があるため、一定期間の遅延が発生したのであろうと思われます。

しかし、インターネットは総じて強かった。インターネットはデータパケットをルーティングするので、どこかの経路が生きていればデータが届きます。災害発生当初は限られた通信路にデータが集まりすぎることで(輻輳:ふくそう といいます)データが欠落し、最悪の場合タイムアウトが発生する可能性がありましたが、NTTグループをはじめとする第1種通信キャリアの方々の素早く、大量人員投入をするといった復旧への努力のおかげで、大地震ではありましたが早々に物理的な通信線が順次復旧していき輻輳も気にしなくていいレベルに戻りました。システム的な改善点としては、自社の努力ではコントロールできない携帯電話網及びそのメールリレーサーバの能力に頼っているところを排除すればよいわけです。即ち、メールでURLを送りつけるというPUSH型の仕掛けにするのではなく、次回もし何かあった際には従業員にこのURLに自分自身で能動的にアクセスしてほしいというPULL型の仕掛けに変更すればよいことになります。今回も携帯電話がかからないとか、メールを送ってもそれが届くまでに遅延が発生したとかいうこともあり、一方でインターネットが災害に強かったということもあってfacebookやTwitter、mixiのようなソーシャルメディアへの書き込みで自身の安否を伝え、間接的にでも自社のライン管理職に無事が伝わったというケースが相当数あったと理解しています。

なるほどシステム的にメールが届かなかったから安否確認ができなかった。それはそうですが、もう1つ人的なシステム上の問題がここには残っています。確かに携帯電話も通話及びメール規制をかけられ、実際にメールが届くのが遅延していました。一方、多くの従業員が取引先へ連絡はしても、会社に対して安否確認のアクションを起こさなかった、というような企業文化ではなかったでしょうか?

もちろん、BCM(Business Continuity Management)の中で有事には必ず何らかの手段で会社に連絡をするということが従業員に徹底され、訓練されている会社ではそのようなことはなかったかもしれません。しかし、新入社員、中途入社の仲間含めて同じ危機意識でいつもいるように組織が成熟された状態になるには普段から有事の行動について周知徹底し続ける必要があります。今回のような震災があった時には、各人の危機意識が高まっているタイミングですから、改めて有事の際には自身及び家族の無事を会社の然るべきラインに伝えるように努めることを周知徹底するいい機会だと思います。今回単発で周知徹底を行うだけでなく、是非継続的な教育・訓練の機会をもって頂ければ幸いです。

安否確認がうまくいかなかった会社のおさらいをしますと、インターネットは生きており、実は安否確認システムも生きていた。しかし、そこへアクセスするURLを従業員は知らず、携帯電話へのメールで知らされる仕掛けになっていた。そのメールが来るまで、携帯電話がつながらない以上、会社へ何も報告することができなかった。というのが今回起きた典型的な事象かと思われます。この場合安否確認システムは生きていたわけですから、従業員が大きな地震に遭遇したり、何か有事に遭遇した際には会社に電話報告するというルールを徹底し、電話がつながらない場合は安否確認システムもしくは会社の掲示板のURLを従業員の携帯電話のブックマークに入れさせるか、緊急時に見るカードを配布するなどバックアッププランを周知するということが求められるのではないでしょうか?もちろん、この安否確認システムや会社の掲示板、場合によってはソーシャルメディアを正式に連絡経路として取り込むのもセキュリティポリシー上問題なければ有用な仕掛けであることは今回実証されたわけです。

今回のポイントは情報システムだけで全てを解決しようとするのではなく、従業員への日々の教育によって有事の際に実効性のある安否確認が可能になるということです。是非そのあたりの見直しをかけて頂ければ幸いです。

あれっ、そういえば今回はIIJ GIOは全く関係ありませんでしたね。
あえて言うなら、例えば安否確認システムをIIJ GIOホスティングパッケージサービス上にインストールして頂ければ、有事で負荷が増えた際にすぐにリソース増強がオンラインで可能です。また、関西の設備を選択可能なため、東京電力、東北電力管内の電力不足に影響を与えないというメリットがあります。このあたりのメリットをさらに享受できるシステムについて、次回以降で見ていきましょう。

文責:IIJ GIOマーケティング部 部長 米国DRII CFCP 小川晋平

コメントは受け付けていません。