データ消失事故から2年！ファーストサーバ、再生への第一歩 第1回

前代未聞のデータ消失事故の真実を追う

データ消失！あのとき、ファーストサーバになにが起こったか？

今から2年前の2012年の6月20日、レンタルサーバー会社のファーストサーバは、大規模な顧客データの消失事故を引き起こした。あのときなにが起こったか？　ファーストサーバのさまざまな部門の担当に、当時の状態を振り返ってもらった。

ファーストサーバは今も変わらずビジネスを展開している

　ファーストサーバの顧客データ消失事故に関するドキュメンタリーを書きたいと思った。事故の原因究明や責任の所在を明らかにするのではなく、当事者の話を積み上げていくような記事が書きたいと思った。

　そして、今回ファーストサーバの全面的な協力により、事故当時から現場を統率してきた現代表取締役社長の村竹昌人氏をはじめ、営業、開発、運用、マーケティング、広報、サポート、管理など各部門の担当者に話を聞くことができた（以下、敬称略・役職は現職）。

今回、取材に対応してくれたファーストサーバのメンバー

　事故から2年間の間、ファーストサーバはひたすら事故の影響を受けたユーザーへの対応と再発防止体制の拡充を続けてきた。事故処理のために多くの時間が費やされ、新しいサービスを一切投入されなかったのだ。こうした状況を悲観し、会社を辞めた人もそれなりにいた。なにより、クラウドサービスの認知と普及が一気に進んだこの2年間、新しい取り組みがまったくできなかったのは、サービスプロバイダーとして痛恨の極みとも言えるだろう。

　一方で、理解しておきたいいくつかの事実もある。顧客データを消失したサービスは、契約数で見れば全体の1割弱だったこと。事故の影響で解約率が上昇したのは、事故後の2ヶ月間だったこと。そして、なにより多くのユーザーがいまだにファーストサーバのサービスを使っており、同社が利益を出し続けていることなどだ。大手新聞の紙面をにぎわせた大規模な事故であったにもかかわらず、ファーストサーバはきちんと生き残り、今も変わらず中小企業の顧客にサービスを提供し続けている。

　同社の運命を変えた2012年6月20日。あの日、なにが起こったか？　現場の担当者はどう思ったのか？　再発防止のために何から始めたのか？　私はまずここからスタートしなければ、前には進めないと思った。せっかく治りかけてきた傷のかさぶたをはがし、塩を塗りこめるような取材がスタートした。

混乱のきわみだった6月20日の事故当時

　まず事故についておさらいしておこう。事故の発生は2012年6月20日の午後5時頃で、対象は、同社の「ビズ」「ビズ2」「エントリービズ」「エンタープライズ3」「EC-CUBEクラウドサーバ（マネージドクラウド）」などの各サービスになる。

　事故の原因は、メールシステムの障害対策のため、対象サーバーに対してメンテナンスを行なう際に利用した更新プログラムに不具合があり、上記のサーバーのデータを削除してしまったというもの。具体的な不具合は、メンテナンスの担当者が以前に使っていた更新プログラムを改変した際に、「対象外のサーバー群についてファイルの削除を行なうコマンド」を削除し忘れたことだ。これにより、更新対象外のすべてのサーバーのデータがプライマリ／バックアップ共に削除された。

　まずは運用担当のメンバーから社内のメールが見られないというクレームが上がり、サーバー側で作業をしていた担当が監視アラートに気がついた。フロア全体が総立ちとなる、修羅場の始まりだった。当時、社長室長として現場の指揮にあたった村竹昌人氏（現代表取締役社長　以下、社長室村竹）は事故の当時をこう振り返る。

社長室村竹：どうやらデータを消したらしいというアラートが社内で上がったのが18時前。当時、私は（前社長の）磯部とミーティングしていたのですが、報告を聞いても、運用担当に話を聞いても要領を得ない。尋常じゃないこと以外は、なにが起こったかわからなかった。特定範囲のお客様のデータが全部消えたという話は、まさに想定外だったので、「本当に消えたの？」「バックアップは？」と同じ質問を何度もした記憶があります。

「本当に消えたの？」「バックアップは？」と同じ質問を何度もした記憶があります」（村竹氏）

　このように事故直後は相当混乱したようだ。どのサービスが対象で、どの顧客に影響が出ているのか、なによりどのデータが削除されたのかを把握するのが先決ということで、関係者を集めてホワイトボードに書き出していったが、なかなか状況がつかめなかった。最初の1時間くらいはそんな感じだったという。

社長室村竹：こうした緊急かつ重大な事態にどのように対応するかというマニュアルがなく、磯部と連絡をとって、当日に対策本部を作りあげて、情報収集と応急措置の検討からスタートした。でも、手探りだったので、とにかく時間がかかりました。

あらゆる復旧手段を試した結果の「第2事故」

　一方、初動の段階で情報収集に時間がかかった運用側だが、バッチの誤動作でデータを削除したことわかった段階で、影響範囲が特定できるようになった。当時、サービス開発系のエンジニアを統括していた藤原一泰氏（事業開発部　部長　以下、開発担当藤原）は、事故当初の様子をこう語る。

開発担当藤原：バッチが原因とわかった段階で、担当のオペレーターは作業を終了させました。その後、コードをレビューして、影響範囲を特定。サービスを使っているお客様のリストを全部出しました。それと並行し、削除したデータを復旧するためのデータサルベージの業者に手当たり次第、問い合わせをかけ、自らもデータ復旧の方策を検討しました。

「データサルベージの業者に手当たり次第、問い合わせをかけ、自らもデータ復旧の方策を検討しました」（藤原氏）

　当時、ファーストサーバのサービスでは、同一筐体内のディスクにデータがバックアップされるという構成になっていた。この構成がバックアップとして不備であるという点はあとから指摘されることだが、当時はまずこのバックアップ用のディスクからのデータ復旧が最優先課題だった。問い合わせをかけた業者からは、やはりHDDをもらわないと復旧できるか調べるのも難しいという答えが返ってきたからだ。

開発担当藤原：OSからの削除コマンドが走ってはいたものの、HDDの物理プラッターにはデータが残っているだろうという推測のもと、バックアップ用のディスクを保全することにしました。そこで、データセンターにおいて、リードオンリーでHDDをマウントし直した後、都合700～800本のHDDを物理的に保全する作業を進め、サルベージ業者に復旧可能かを調べてもらうと共に、自身でもディスクの中のメタデータの復元や、カービングなどの処理は試してみました。

　しかし、データ復旧の検証を進めていた開発・運用担当部門では、残念な「第2事故」を引き起こすことになる。

開発担当藤原：ある復旧ツールを動かしたところ、見た目上はファイルがまとめて復元されました。そこで、勇み足になって、いくつかのお客様のデータをリカバードファイルとして戻したのですが、実際はファイルシステムに一部不整合が出てしまい、本来アクセス権のない人が情報を参照できるようになってしまいました。

　この結果、復旧したデータをすぐに取り下げ、ユーザーにはデータの破棄を依頼。さらに公開していた際にアクセスしたログを洗い出す必要が出てしまったという。

（次ページ、鳴りやまない電話とFAX！長期戦の様相へ）