2012年06月26日

ファーストサーバ事件に見る騒動への違和感と「教訓」

今回の騒動では、「データ復旧が〜」「損害賠償が〜」に話題が集中しています。確かにデータを取り戻せないのは痛い。サーバ上に置かれていたデータは膨大で、かつデータベースのような動的に変化するデータだったので、「ユーザ側でバックアップ取っとけよ」という主張にも限界があると私は思います。
けれど、データ復旧に話題が行くばかりで、ではこれからどうするの?
自分は第二第三のファーストサーバ事件が起こる可能性は高いと思います。
今回のきっかけは、ちょっとの人為的ミスでしたから。
やっぱり重要なのは「教訓」。

本文中でも、ファーストサーバの暫定的対策として以下のことが書かれています。
1)サービス再開に必要な場合、緊急メンテナンスが必要な場合などやむを得ない場合を除き、当面の間はメンテナンス作業を停止。2)メンテナンス運用手順を修正し、対象外サーバの確認作業を追加。3)通常のバックアップ以外ではバックアップ領域に修正を加えられないように仕様を修正。


これは、失敗とその後の再発防止、そして他のサーバ会社や企業内ネットワークでの事故予防にとって重要な指標になるのではないでしょうか。
今回のファーストサーバの事件はそれを思い起こさせてくれたと感じます。


ファーストサーバ、大規模障害の概要と原因を中間報告――複数要因が重なりデータ消失

Yahoo! JAPANの子会社で、レンタル・サーバ・サービスを展開するファーストサーバは6月25日、同月20日に発生した同社サーバの大規模障害について、その概要と原因の中間報告を発表した。また併せて、障害発生後、ファイルの誤参照の障害も発生していたことも明らかにした。

 中間報告によると、同社は6月20日17時ごろ、メンテナンス作業の一環として、更新プログラムを利用した脆弱性対策を特定のサーバ群に対して実施した。だが、1)更新プログラム自体に不具合があったことに加え、2)検証環境下での確認による防止機能が十分に働かなかったことと、3)メンテナンス時のバックアップ仕様の変更が重なり、バックアップ・データの消失を含む今回のデータ消失が発生したと説明する。

 上記の3つの要因が重なったことにより、今回の大規模障害とそれに伴うデータ消失が発生したもよう。ファーストサーバでは、それぞれの障害原因について、次のように述べる。

●障害の原因
 同社では、脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成していた。今回も更新プログラムを作成した。そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバ群を指定するための記述漏れがあったとしている。

 メンテナンスに際しては、検証環境で動作確認を行うという手順が定められていた。だが、プログラム実行後の動作確認を行う対象は、当該メンテナンス対象サーバ群を確認すれば足りると認識し、検証環境下で対象サーバ以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定し、本番環境での実施が行われた。

 メンテナンス時のバックアップ仕様については、同社ではシステムを含むデータのバックアップは毎朝6時に取得していたという。しかしながら、脆弱性対策のメンテナンスに関しては、対象サーバ群とそのサーバ群のバックアップ領域に対して同時に更新プログラムを適用するという構造で実施していた。そのため、今回のメンテナンス実施において、対象サーバ群のデータ消失と同時にバックアップ領域のデータも消失したという事象にいたったとしている。

 脆弱性対策のためのメンテナンス実施後にハードウェア障害が発生し、バックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻り、脆弱性対策がなされていないシステムが動き続けていたということが過去に発生。その反省のもと、バックアップをしてあるシステムについても、メンテナンスを同時に実行する仕様に変更したという。

 同社はまた、暫定対策についても明らかにしている。1)サービス再開に必要な場合、緊急メンテナンスが必要な場合などやむを得ない場合を除き、当面の間はメンテナンス作業を停止。2)メンテナンス運用手順を修正し、対象外サーバの確認作業を追加。3)通常のバックアップ以外ではバックアップ領域に修正を加えられないように仕様を修正。

 なお、第三者による事故調査委員会を6月30日までに立ち上げ、事故要因を徹底究明し、再発防止策を策定するとしている。

●ファイルの誤参照の障害
 ファーストサーバによると、共有サーバと専用サーバの復旧作業において、それぞれで障害が発生していたという。

 同社ではデータ消失の後、データ復旧作業を実施。6月21日9時ごろにデータの復旧プログラムにより消失データを復旧し、リカバードファイルとして顧客にデータを提供した。

 だが、専用サーバの顧客より、専用サーバ内において情報にアクセス権限を有していなかった者からも参照できる状態になっているとの報告があり、リカバードファイルの提供を22日21時ごろに停止。状況の確認を行ったところ、専用サーバ内において、アクセス権限を有していなかった情報についても参照が可能な状態にあったことが判明したという。

 上記の問題発覚を受け、共有サーバにおいてもリカバードファイルの提供を即時停止し、現在状況の確認を行っていると説明している。なお、影響範囲も現在調査中だとしている。

 同社は25日より今回の大規模障害に関するFAQサイトを立ち上げている。障害詳細やサポート、今後の対応、損害賠償などのカテゴリ別に情報が提供されている。
(Computerworldより)


posted by カミガタ at 09:23| Comment(0) | TrackBack(2) | エンタープライズ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック

親会社のヤフー自らファーストサーバ障害の損害賠償の支払いを含めた話し合いをユーザー企業と開始
Excerpt: これはスピードあって、誠意ある対処ですね。本当なら。 ファーストサーバ障害:親会社のヤフー自ら補償などの顧客対応を開始 レンタルサーバ事業者のファーストサーバが顧客のメールおよびウェブデータを消失..
Weblog: コンピュータの話題をBlogで
Tracked: 2012-06-27 11:57

ハダカになったツケは大きい。全裸社長辞任
Excerpt: 何ともバカなことをしたものです。 安定した業績を上げていたこの会社の社長は、露出狂のMだったのでしょうね。 社員だけでなく、サーバを借りている人も気の毒です。 (ITMediaより) 公然わいせつで..
Weblog: 買物ステーションBlog
Tracked: 2012-06-28 02:35

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。