山田英司氏は「現時点で33の自治体で一部のデータが復旧できていない」と発言しており、4日の問題発生から2週間経過しても全面復旧の見通しはまだ立っていない。Jip-Baseは2011年に稼働を開始した自治体専用の共同利用型クラウド基盤サービス(IaaS)で、70団体が1318個の仮想OSを稼働させている。Technologiesが担当する。4日に問題を起こした「Jip-Base」は自治体専用の共同利用型クラウド基盤サービスで、現在、70団体の業務システムが複数の仮想環境上で動作しているこれまでの時系列説明。EMC社製ストレージに異常が発生し、全国53の自治体・団体のシステムに影響が出た。LUNとよばれる論理区画が次々とオフラインになり、これによってサーバー側からアクセスができなくなり、システムが停止状態となった。翌5日に原因がストレージのファームウェアにあることが判明、夕方にはファームウェアップデートとEMC側エンジニアによるスクリプト処理でLUNのオンライン化を進めた。Jip-Baseの共通ストレージがファームウェアのトラブルにより、LUN(論理領域)がオフラインになったストレージのファームウェアトラブルであったため、9日中の復旧を行うと当初発表したものの、仮想OSの業務データへのアクセスに問題があると判明。調査に時間を要するために9日までに全面復旧が間に合わないことが判断した。仮想OSごとの復旧作業が進められた結果、16日までに70%のシステムについて、問題のストレージから仮想OS情報と業務データの復旧が行えた。残りの30%には問題があったが、そのうち半分はバックアップからの復旧データを元に仮想OSの立ち上げが確認でき、IaaSとしての回復がなされている。復旧が不可能と判断した(具体数は明かさなかったが、他のバックアップからの復旧ができたケースもあるとしている)。IaaSとしての性格上、個別の業務システムの全面復旧ができたか判定はできないと、システムとしての全面復旧に関しては言及を避けた。トラブルシュートは共有ストレージを回復させて仮想OSが起動したものが70%。問題があったものの、バックアップがあって稼働したものが15%。残りの15%はバックアップがないというという問題があり、これは運用監視に問題があったシステムそのものやクラウドに対する問題点が浮かび上がる質疑応答で日本電子計算はJip-Baseの本番環境とは別のファームウェア更新などに対する検証環境がなく、重要と思しき情報だけをDellから受け取る体制になっていると回答。今回の障害の発端となったファームウェア情報は5日になって知った。ファームウェアアップデート情報を能動的に取得せず、ベンダー任せにしていたという。「仮にアップデート情報を受け取っていても(クリティカルな問題でないと判断して)アップデートしなかった可能性がある」という。日本電子計算の神尾拓朗部長(公共事業部基盤サービス統括部)また、サーバーはDell以外のマルチベンダーで構築していた。これに対しては「FCの一般的なコマンドで運用しているので(サーバーベンダーが異なっていても)問題ない」と回答。確かに規格上は問題ないだろうが相互運用性問題があるので、厳しい要件を乗せるIaaSならば検証環境が必要だったのではないかと感じた。IaaSである以上、インフラまでが責任分担点となる。ところがOSイメージを含むバックアップが何らかのソフトウェア上のトラブルで一部行われておらず復旧が大幅に遅れている。「監視システムに問題があった」(神尾氏)とのことで、責任問題という面で言えばこれも日本電子計算のクラウド運用に問題があったと言える。クラウドを使う利用者(あるいは委託管理するSIer)側としては、クラウドの喪失という想定される事態に対しての対策が甘かったところがあると感じている。Jip-Baseはあくまでインフラ提供(IaaS)であり、データの保全に関しては利用者側に責任がある。現時点でも問題のある自治体があり、最低でもデイリーのバックアップと緊急時の避難計画を用意しておかなければならないと思った。関する手続き」が行えないようだ。Agreement)を追求するだけでなく、トラブル発生時の第2プランを含めた提案ができる業者に発注するとともに、定期的な「避難訓練」が必要と感じた。