大規模障害に対する見る目の違い

今回はメカAGさんのブログからご寄稿いただきました。

大規模障害に対する見る目の違い

「大規模障害の概要と原因について（中間報告）」2012年06月25日『ファーストサーバ サポートWEB』
http://support.fsv.jp/info/nw20120625_01.html

「大規模障害の概要と原因について（中間報告） ファーストサーバ サポートWEB」『はてなブックマーク』
http://b.hatena.ne.jp/entry/support.fsv.jp/info/nw20120625_01.html

このブックマークのコメントの内容で、その人がどれだけプロかわかるな。まず一番の素人は「なぜ更新プログラムの確認をもっと慎重にしなかったんだ」という批判。まあ気持ちはわかるが、プログラムにバグがあるのはあたりまえで、問題の本質じゃない。

次に「本番環境とバックアップ環境に対してなぜ同時に更新したんだ」という批判。同時にやったら同時に障害が起きる可能性があるだろ、と。まあこれはその通りである意味正しいのだが、これも本質じゃない。「今回のケース」は防げるかもしれないけど、またいつか防げない別なケースに見舞われる。

「そもそも待機系をバックアップと呼ぶのはおかしくね？」と指摘している人が正解。これが本質だと思うのだよね。データのバックアップが別途必要。そして1世代では危険。バックアップの直前に何らかの理由でデータが消えたら、消えた状態がバックアップに上書きされる。やっぱ最低でも2世代は必須だろう。

でもファーストサーバの今回の件を「信じられない杜撰さ」とか言ってる人たちは、モグリ…。

　＊　＊　＊　＊　＊

どうして現状のような仕組みになっているのだろう？想像するに最初は図のバックアップ環境というのは、あくまでデータのバックアップだったのではなかろうか。

しかし何度かトラブルを経て、その度にバックアップ環境から本番環境へデータを移し、必要な設定も再度行うという手間をかけることで、客からも「トラブルからの回復が遅い」とクレームをつけられ、「それならバックアップ環境がそのまま動くようにすれば、迅速に回復できる」と、誰かが思いついてしまったのではなかろうか。

そうなるとレポートにもあるように、バックアップ環境に切り替えた瞬間に脆弱性のパッチが当たっていない状態で動作してしまうことが問題になり、今度はバックアップ環境にもパッチを当てることにした…。

　＊　＊　＊　＊　＊

なんかどんどん危うい方向へ進んでいった結果、とうとう崖から落ちてしまったという感じ。たぶんこの危うさを指摘した技術者はいたことだろう。しかしきっと「事前に更新プログラムのチェックをきちんとやること」という精神論で、無視されたのだろう。

チェックや検証を厳密にすることでバグがないプログラムを作れれば世話はない。バックアップというのは、予期せぬことが起きた時のため存在するわけで。とはいえ結構こういうのってあるよねぇ。最終的な対策が「気をつける」っなってるのって。結果がここまで破滅的でないなら、それでいいと思うけど。

新しく配属されてきた技術者「あの…すみません、ちょっと質問いいですか？このやり方だと○○が起きるとデータがバックアップも含めて全部消えちゃう気がするんですが…」
古参管理職「うむ、そういうことが起きないように、十分注意する、それだけだ」
新しく(ry「はあ…(ここではそういうもんなんだ…)」

　＊　＊　＊　＊　＊

福島原発事故で、ベントしたら1号機が爆発してしまったのに、なぜ3号機もベントして爆発させたのだという非難の声があった。素人目には一見信じられないほど馬鹿な行いに見える。なんでプロの技術者がこんなことを！と。

でも違うと思うんだよね。あの時の3号機は爆発の危険を犯してでもベントしなければ、もっと大変なことになっていたのだろう。実際ベントできなかった2号機が、炉心の破裂で一番放射性物質をまき散らしたのだし。

　＊　＊　＊　＊　＊

追記

なんで「削除停止コマンドの記述漏れ」が検証環境でチェックできなかったか疑問だったのだが、

「ファーストサーバ社データー大量消失事故原因を公開。更に顧客DB情報流出の可能性も？」2012年06月25日『NAVER まとめ』
http://matome.naver.jp/odai/2134034723695240101

rm -rf ($hoge)/($hogehoge)
例えばこんな感じで環境変数の指定をして居なかったということ・・・

こんな感じか。検証環境ではちゃんと環境変数を指定してたのね。

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

専用サーバならHDD自体が個別だから、全部復活させても問題無い気がするのだが(共有サーバだと他のユーザーのファイルまでごっちゃに復活させてしまうから無理ですな)、システムに関するファイルまで復活させちゃったということなのかな。パスワードファイルとかw。それともはるか昔に別なユーザーが使っていたファイルまで復活させてしまったとか。う～む、なかなか大変ね。同情を禁じ得ない。

　＊　＊　＊　＊　＊

障害発生からの回復のスピードで、「この企業はちゃんと自社で対策していた」みたいなことを書いている人たちがいるけど、サイトの作りによって違うよね。静的なコンテンツしか置いてないなら、ファイルをアップロードし直せばいいだけなんだから。サーバー上のデータベースにしかデータがないサイトが悲惨なわけで。

　＊　＊　＊　＊　＊

追記2012-06-26

「ファーストサーバ障害、深刻化する大規模「データ消失」」2012年06月26日『日本経済新聞』
http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/

なんかこの記事は上記の中間報告と微妙に内容が違うんだよな。中間報告では検証環境、本番環境、バックアップ環境の3つで、検証環境を除けば2系統だ。そして本番環境からバックアップ環境へ毎日6時にコピーが行われると説明している。

ところがこの日経の記事だと本番系、待機系、バックアップ系の3系統あり、本番系からバックアップ系へ毎日6時にコピーが行われるという説明になっている。中間報告は説明を省いたのかもしれないけど、なんか日経の方が間違ってる気も個人的にはする。待機系ではなくてバックアップ系なら、脆弱性パッチを当てる必要ないわけで。

中間報告の内容はよくできてる気がする。いまのところ辻褄の合わない部分は見当たらない。

日経の記事は「外部サーバにバックアップする」というファーストサーバの記述を現状と違うと指摘し、ファーストサーバ側もそれは認めている。ただこの部分もそれほど本質ではない気がするのだが。もちろんバックアップは地理的に離れていたほうが安全なのは確かだが(火災や地震など)、この点についていえば「低料金でそこまでするのは無理」というファーストサーバの言い分の方に軍配を上げたくなる。

ただ気になるのは「数年前までは記述の通りだった」とファーストサーバ側が発言している点。「記述の通り」というのが何を意味するのかはっきりしない。地理的に離れた場所のサーバにバックアップを行なっていたのか、本番系、待機系の他に独立したバックアップ系が数年前はあったのか。

答えてるファーストサーバの人もなんか混乱している気がしないでもない。ただもし数年前は3系統あったのに、コストダウンのためなどで2系統に減らしてしまったのなら、問題な気がする。記事の記述はそういう話ではなく、バックアップ先が外部か内部の同一の場所かを問題にしてるのだけど、なんか話がうまくつながらないんだよね…。まあなにか根拠があるというのではなく俺のまったくの想像なので、念のため。

実際問題として毎月数千円の料金のサービスにテープによる世代バックアップを期待するのは無理だろう。10倍とか100倍の料金をとってしっかりとしたバックアップをとるサービスの選択肢を用意し、顧客にもそれぞれのメリットとデメリットを説明の上で選択させるべきだった。100倍だって技術者を一人雇うことを考えれば、それほど高いとは思えない。

上にも書いたが静的なコンテンツとしてしか利用しないならバックアップなしの安価なサービスでいいし、サイボウズなどの重要な業務データなら、数千円は安すぎる。今回の最終的な問題の帰着点はここ。

参考サイト:
「立て！ デスマーチは終わりだ。終点がサーバールームとは上出来じゃないか。ここへ来い」… – 蒼海の一粟＠Tumblr
http://enzoruka.tumblr.com/post/17258249066

執筆： この記事はメカAGさんのブログからご寄稿いただきました。