ファーストサーバで大規模データ削除

システムトラブル

とりあえずメモ．

ネットで話題の例の奴．完全に出遅れた上に，多すぎて網羅しきれん．
http://support.fsv.jp/info/nw20120625_01.html
http://it.slashdot.jp/story/12/06/25/0723232/
http://it.slashdot.jp/story/12/06/22/090229/
http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/
http://ict.pken.com/2012/06/first_server_list/


http://internet.watch.impress.co.jp/docs/news/20120623_542371.html
http://internet.watch.impress.co.jp/docs/news/20120625_542602.html
http://www.itmedia.co.jp/news/articles/1206/24/news004.html

  • 操作ミスで大規模に全削除
  • ファイルの復元は不可能．
  • バックアップもない．

すごいなー．*1NTTデータのdoblogでも，一応復元はしたぞ．一応．

ヒドイと思うと共に，今のIT業界の状況からすれば，いずれどこかでこういう事態になるだろうとは予想されていたことだし，起こるべくして起こったという気もする．*2


関連

naoyaのはてなダイアリー「ファーストサーバ社の障害に関して」

http://d.hatena.ne.jp/naoya/20120626/1340716917

Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB

Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB

http://www.amazon.com/dp/B007X6SMD6/
プログラミング Google App Engine

プログラミング Google App Engine


ついでにぐぐってみた．

NISTによるCloud Computingの定義： http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment
models.

この後にfive essential characteristics 他の説明がつらつらと並ぶ．クラウド・コンピューティングで重要なのは（おそらくは大規模な）共有の各種リソースが利用できることとか，スケーラビリティーとか，そのリソース変更がオンデマンドで即時に可能なこととか，そっち方面かな．実際には仮想化も入ってくるけど，それは実装であって定義ではないのだろう．

分かってる人が読んでると「ふむふむ．ああ、なるほどなー」と思えるくらいに素直な文章だけど，正確に訳せと言われると，辞書で語義を一々確認しながらになるので割と大変．

naoyaのはてなダイアリー「先の記事への反応に関して」

http://d.hatena.ne.jp/naoya/20120627

レンタルサーバーのように具体的なシステムあるいは事業形態があって、それに対して進化した、明確に線引きができる異なる形態のシステム/事業であるところの AWS や Google App Engine、Heroku、あるいは国内の複数 IaaS/PaaS サービスなどが存在する状況において、昔からある前者を「クラウド」と呼んで全部を一緒くたにする議論は、さすがに大ざっぱすぎるのではないか、と言ってるんです。

ユーザー視点でみたら、裏の技術がどうのこうのなんて関係ないというのは、その通りだと思います。

ちょっと脱線するけど，さすがにこの主張は暴論だと思うんですね．

たとえば「ガソリン車でもハイブリッドカーでも，同じ自動車だからユーザーすれば関係ない」というのは，運転して移動する部分に関しては同じでしょう．でも本体価格や車体重量や故障原因や修理方法やメンテナンスや燃費に関しては違ってくるのです．お金を湯水のごとく使える大金持ちならいざしらず，一般のユーザーにとってはその違いは無視して良いものではありません．

「（サーバーの）裏の技術がどうこうなんて関係ない」なんて言ってる経営者は，「金をどれだけ無駄づかいしても，データが全部消失して事業が立ちゆかなくなっても，その結果として会社が倒産してもオレの責任じゃねえ」と言ってるようなものですよ．そんな無能で無責任な経営者は自分なら願い下げです．

まあ、自分のブログを見ていただいている方々は、ここを外すような方々ではないのであんまり声を大きくして言っても意味がないのかもしれないんですが･･･。

同意．

novtan別館「クラウドに誘われて」

http://d.hatena.ne.jp/NOV1975/20120627/p2

普通に考えて、集中管理になにか重大な問題が出たらにっちもさっちもいかないだろうし、SLAが高いサービスはそうならないために多大なコストをかけている。逆に言うと、安いクラウドは早い安いが信条であり安心安全は二の次なのである、という真実。
もちろん、エンジニアはそれを理解している。クラウドだから障害に強いという思い込みはないだろうし、万が一に備えた（それはその鯖屋が潰れる、あるいは法的な問題で移設が必要になるということも想定される）対策をきちんと考えていくものだ。

ところが、経営層はそのへんを理解していないことが多い。結果として、コスト削減ができますよ、とか自社でダウンタイム０のシステム作るよりも楽ですよ、とかにつられちゃう。もちろん、一面的にはそれは正しいのだけど、じゃあシステム部門はお役御免だよね、と思っちゃったらもうアウト。

全く同感．

「経営者ってそこまでバカなの？だったら死ねよ！」とは常々思ってることだけど，技術の理解も金勘定も契約も経営者の基本スキルだと思うんだけどなあ．安いのには安いなりの理由があって，規模のメリットが出るから安い*4とかでない限りは，安かろう悪かろうというのはほぼ真実．*5

http://b.hatena.ne.jp/entry/www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/

  • id:X-key IT系サービスで「稼働率100％保証」ってところで眉に唾しなきゃ。「一般的なバックアップというのは、我々のような低価格の料金で提供するのは難しい」なのにお客様によるバックアップ作業不要を謳うのはまずいでしょ
  • id:gokino 同業としては「現場の作業員かわいそう」と思うのと同時に、やっぱり安かろう悪かろうだったんだな、と納得してる。
  • id:jtw はてぶのコメントを眺めていると、素人目線ではレンサバもクラウドなんだなーと実感。/分かってない人が書いた記事に納得する人がいっぱいで・・・とても面白い。
  • id:pplaceCEO 何事も大事なものは手元にってことだな。　これで、変な知識だけ得た人が「クラウドは危険でしょ〜」みたいなこと言い出したら泣ける。
  • id:houyhnhm 民法ならともかく、商法範囲で出来る泣きは知れたもの。／クラウドって、そんな普及のさせ方だっけ。安い、は分かるけどなあ。
  • id:naoya いつからただのレンタルサーバがクラウドって言われるようになったんだろう
  • id:chihhi1105 ↓サイボウズをファーストサーバで動かしてた企業はファーストサーバのバックアップ機能がKill状態になって自力バックアップ不可だったと聞いたが/ただのレンサバをクラウドと呼ぶのはやめてほしい
  • id:tmtms ファーストサーバを「クラウド」って言い始めたのは誰？ / "「雲」が消えるかのごとく消失" 言いたかっただけちゃうんかと…
  • id:hobo_king クラウドとかまた言葉だけ一人歩きして中身は変わらずのレンサバ。他と違うバックアップの定義……重過失というか一種の詐欺でしょこれ。
  • id:mohno “可能性”はともかく、実際に誰かが裁判を起こすことになるんだろうか。/“レンタルサーバー”が“クラウド”だったら、私は10年来のクラウドユーザーだな:-p
  • id:fragilee この話で「クラウド」って単語持ち出すのちょっと違うと想ぅデスが・・・＞＞
  • id:Hiro0138 クラウド関係のパンフ読んで大抵はデータセンタの紹介だったりするからなぁ(パンフはもちろんゴミ箱逝き)
  • id:rgfx や、ほんとクラウドなのに「待機"系"サーバがある」ってなんぞそれ。ネットワークや電源ならいざしらず。基本DHTで生きてるサーバ間を渡り歩くもんじゃなかったっけ。

それはマスコミの十八番，詭弁という奴だ．

  • id:contractio うぉぉぉぉぉぉぉぉ....「おっしゃっているような一般的なバックアップというのは、我々のような低価格の料金で提供するのは難しい。サーバー内の別のディスクでとることを、我々はバックアップと考えています」
  • id:REV .「おっしゃっているような一般的なステーキというのは、我々のような低価格の料金で提供するのは難しい。成型肉を鉄板で焼くことを、我々はステーキと考えています
  • id:rti7743 雲はそこにあるけど、雲をつかむのは大変なんだよっ 　というか、同一筐体バックアップはやめれ

HDDの大容量化に伴い，「HDDのバックアップをHDDで取る」という考えが出てきたのは事実．

だったら，そのための構成とソフトウエアの開発が必要でだな，日本企業ではそこまで対応しきれんような．ここが「日本製クラウドもどき」が「真のクラウド」になれない理由だと思う．

同一筐体となると「バケツで核燃料再処理して効率化」レベル．「学歴不問・未経験者歓迎」で集めた素人鯖缶と素人マネージャーが，現場判断で「効率化」した結果だったりしないのか．

  • id:multiplex00 「ヤフーがケツ持ちするからどんどん損害賠償請求していこう！」まで読んだ
  • id:tatsunop 「ヤフー子会社であったことが不幸中の幸い」ってあるけど元はKUBOTAの子会社だったわけで、そこから方針が変わってこうなったのかどうかまで突っ込んで欲しかったなぁ。

要するにヤフー叩き記事なのかなあ．

この事件自体はあんまりヤフーと関係ないような気がするし，いざという時にトカゲの尻尾切りをするための子会社化なんだもの．

  • id:name-25137412 日経によるまとめ。「クラウドサービスは企業情報システムに投資できない、あるいはＩＴ（情報技術）に疎い事業者が手軽に活用できるサービスとして普及した」ってのはどうなのよと思うけど。
  • id:shuu-ryouzen 日経によるファーストサーバのデータ消失事件のまとめ記事。概要を把握するのにちょうどいい。しかし「ファーストサーバ データ消失オフ」にまで言及しているのはマジでワロタ（笑）
  • id:yoko-hirom 非IT技術者には分かりやすい記事。待機系の他にバックアップ系も備えていたが，すべて本番系と同じサーバーにあったとのこと。だが，直接の原因は操作員のミス。人為的ミスをどう防ぐか。それこそ，IT技術の出番。
  • id:yasu-hide 分かってない奴に分かった風な記事を書かせるな
  • id:flowrelax サーバ会社も信用ならないとしたらどこにデータを置いておけばいいのか。自分で管理するしかないということか。サーバ会社にもよるんだろうが、信用していいのか悪いのか事前に判別するのは困難。

結構難しい問題だけど，「稼働率100％保証」なんて言ってる時点で，その業者は信用に値しない．

バックアップについては，どのくらいの頻度で，何をどのデバイスに，どのようにバックアップしているのか，どこに何個まで保管しているのかくらいは，書面で確認しておくべきだった．ここは基本的なバックアップをしてなかったし，マニュアルでのバックアップもできなかったらしい．論外なレベル．

「格安」だとそうでしょうね．

  • id:tamtam3 ここで煽ってる連中も、GmailやEvenoteのバックアップ取ってない。それがクラウドなんだよね

消えても困らない程度のデータだからね．*6

それでも重要なE-mailアドレスとかくらいはPC上のメーラーや携帯電話にコピーしてあるし，人によっては全E-mailがPC上のメーラーにもコピーされている．Evernoteについても同様．それに昔はメモなんて散逸してなくなるのが普通だったし，PCのHDDがクラッシュした場合も同様だったので，信頼性が増しこそすれ下がることはない．

さらに消えたら絶対に困るようなデータなら，二重三重のコピーを用意するもの．

http://support.fsv.jp/info/nw20120625_01.html

大規模障害の概要と原因について（中間報告）
2012年6月25日　2：00

6月20日に発生した大障害について、最新の状況を下記の通りご報告いたします。
なお、FAQを6月25日 9時ごろ公開予定です。あわせてご覧ください。
データの消失について
■ 障害の概要

6月20日（水）17時ごろ、脆弱性対策を特定のサーバー群に対して実施しました。

脆弱性対策は更新プログラムを利用して一括して対象とするサーバー群に対して実施するという運用を以前から行っており、今回も同様に作業を実施しました。

実施にあたっては検証環境において動作確認を行い対象サーバー群に問題が発生しないことを確認したうえで、本番環境で実施するという手順を取っております。

しかしながら、更新プログラム自体に不具合があったことに加えて、検証環境下での確認による防止機能が十分に働かなかったことと、メンテナンス時のバックアップ仕様の変更が重なり、今回のデータの消失（バックアップデータの消失を含む）が発生いたしました。
■ 障害の原因
原因1：脆弱性対策のための更新プログラムの不具合

脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。

そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。
原因2：メンテナンス時の検証手順

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

システムを含むデータのバックアップは毎朝6時に取得しております。

しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。

そのため、今回のメンテナンス実施において、対象サーバー群のデータ消失と同時にバックアップ領域のデータも消失したという事象に至っています。

通常の状態

今回の障害の原因
■ 暫定対策

サービス再開に必要な場合、および緊急メンテナンスが必要な場合など止むを得ない場合を除き、当面の間はメンテナンス作業を停止いたします。また、止むを得ずメンテナンス作業を行う場合には、ダブルチェックを欠かさず細心の注意を払って作業を実施いたします。
メンテナンス運用手順を修正し、対象外サーバーの確認作業を追加します。
通常のバックアップ以外ではバックアップ領域に修正を加えられないように仕様を修正します。

■ 今後の事故究明と再発防止策

第三者による事故調査委員会を6月30日までに立ち上げ、事故要因を徹底究明し、再発防止策を策定いたします。
ファイルの誤参照の障害について

復旧作業において専用サーバー、共有サーバーでそれぞれ障害が発生いたしましたので、下記の通りご報告いたします。
■ 障害の概要

データ消失の後、データ復旧作業を実施。6月21日（木）9時ごろにデータの復旧プログラムにより消失データを復旧し、リカバードファイルとしてお客様に提供しました。
しかしながら、専用サーバーのお客様より、専用サーバー内において情報にアクセス権限を有していなかった者からも参照できる状態になっているとの報告があったため、リカバードファイルの提供を22日（金）21時ごろ停止し、状況の確認を行ったところ、専用サーバー内において、アクセス権限を有していなかった情報についても参照が可能な状態にあったことが判明しました。

上記、問題の発覚を受け、共有サーバーにおいても、リカバードファイルの提供を即時停止し、現在状況の確認を行っております。
■ 障害の原因
原因：データ復旧手順の不備

弊社にて消失ファイルを復旧しようとし復旧プログラムを実行しましたが、復旧プログラムの仕様への理解が不十分であったため不適切なリカバリーファイルが作成されてしまい、その復旧ファイルの内容を確認せずにお客様に提供してしまったことが原因です。
■ 影響範囲

現在調査中です。

http://www.loft-prj.co.jp/lofta/schedule/perN.cgi?form=2&year=2012&mon=7&day=14

ファーストサーバ データ消失オフ
「データはどこへ消えた？」

【出演】集まって頂いた被害者の皆様、ロフトグループウェブ担当、ほか

2012年6月20日夕刻に発生した障害により、サーバ初期化・データ消失という前代未聞空前絶後の無限地獄に我々を叩き込んだ“実績と信頼の”ファーストサーバ。
被害に遭った会社／団体は5,000とも6,000ともいわれ、かく言う我々ロフトグループも本稿執筆時（６月末日）にはまだまだ死線をさまよっている最中でございます。
と、そんな阿鼻叫喚のハンバーガーヒルを駆け抜けたサーバ管理者の皆様！ここはひとつ、未だ癒えぬ生傷を握りしめ、酒を酌み交わそうではありませんか!!
一体なぜ我々はあの戦場へ駆り出されなければいけなかったのか。あの時、それぞれの戦線では何があったのか。MacBook Airが当たるキャンペーンはどうなったのか。そして、我々は今後どうするべきなのか──。
そんなよしなし事を語り合ったり、心ゆくまで愚痴をこぼし合ったりしながら、名刺や杯を交換したいと思います。なお、皆様のご苦労をねぎらう意味を込めてチャージも最安値に設定いたしました。
そう、我々は、同じ戦場を戦い抜いた戦友なのですから！

・内容（予定）
被害状況を振り返ってみよう
皆さんの体験談発表会
消失データ供養会
睡眠不足解消法自慢
今後の対策をとことん考える
名刺交換会
ほか

※被害に遭わなかった方のご参加も、もちろんOKです。
※基本的には飲み会です。お気軽にご参加ください。
※当日は皆様の貴重な体験談を伺おうと思いますが、イベントにご参加頂けない方や事前にお聞かせ頂ける方がいらっしゃいましたら、下記までメールでお送りください。
galaxy_tegami@yahoo.co.jp
※内容が変更になる場合もございますので、ご了承ください。

OPEN & START 24:00
チャージ￥500（飲食代別。当日のみ）

「ファーストサーバ事件で情報漏洩の2次被害、2300社に影響か」

http://itpro.nikkeibp.co.jp/article/NEWS/20120629/406461/

ファーストサーバのサービスでは、1台の物理サーバーにつき最大で60契約を収容している。平常時はある顧客は他の顧客のファイルにアクセスできないように制御されているため、情報漏洩は発生しない。

　ところが6月20日の大規模障害でファイルが消失したため、可能な範囲でファイルの復元を試み、復元できたものを顧客に提供していた。この時に、ある顧客に提供したファイルに別の顧客のファイルが混入したまま提供してしまった可能性があるという。

　発表文では、「1者あたりの混在先は最大で6者である」と説明している。つまり、ある顧客に提供された復元ファイルを閲覧しようとすると、自社が保有・管理するファイル以外の、他社のファイルも見ることができる可能性があるという。ファーストサーバは、該当する顧客に個別に連絡し、復元ファイルの削除を依頼するとしている。

　ファーストサーバは漏洩した復元ファイルの内容を明らかにしていないが、個人情報などが含まれる可能性もある。

それは……予想される展開ではあるけど，やっちゃいかんだろ．

「天に召されたデータに献杯！」 あの日、何が起こったのか ―― ファーストサーバデータ消失オフレポート

http://www.atmarkit.co.jp/fnetwork/tokusyuu/73fsv/01.html
追記

「ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 」

http://itpro.nikkeibp.co.jp/article/NEWS/20120731/413084/
さらに追記．

運用を全部手動でやる「手順書」があっただけではないかな．ツール無しで手動で管理なんてアホすぎるんだが．
それにもっと大きな問題は「バックアップがなかった」ということ．

*1:要するに「rm -rF」の悪夢を管理しているサーバー全部に適用したようなもんか．

*2:http://d.hatena.ne.jp/JavaBlack/20120312/p1

*3:こうやって比較すると，すんなり完全復旧させてるMSがスゲー優秀に見えてくるから不思議だ．たしかに一応はMSも世界有数のソフトウエアベンダーなんだけどね．

*4:たとえばパッケージソフトが特注品より安いとか．MS-WindowsにしろMS-Officeにしろ，同様のソフトを特注するより格段に安くなる．

*5:高くても悪いことはあるけどね．多重下請け構造の丸投げビジネスに，この傾向が強い．途中のピンハネに費やされた分だけ高くなってるだけで，品質の悪さは変わらない．

*6:そもそもファーストサーバはクラウドじゃないし．それ以上にGoogleなりEvernoteなりの技術がファーストサーバより格段に高いというのがあるのだが．