もぎょ

もぎょ

往復

　　 ∧　∧
　　(　´･ω･`) oＯ(・・・・。)
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／

6：00　起床
8：40　出社
9：00　会社到着
24：00　帰宅
25：00　就寝

　　　
　 ＜⌒／ヽ-、_＿_ oＯ(・・・・・。)
／＜_/＿＿＿＿／

ぶっ飛び3

ファーストサーバぶっ飛び事件の報告が上がってきたようだ。

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

感想としては、「やってしもうたか。(´・ω・`)」といったところだ。
僕も現場の人間だから「ああ～」と思う部分がある。

原因1：脆弱性対策のための更新プログラムの不具合
脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。

これ、何か「ソフトウェアにバグでもあったのかな」って思わせるようにゴニョゴニョ書いてあるけど、ようするに「コマンドの打ち間違え」だろ。
ここに書いてある「更新プログラム」って、人が手で打ち込むコマンドを前もってスタンバイしておくだけのシロモノだから「プログラム」などと呼ぶのはおこがましい。
「下準備でミスりました」ってだけなんだから、「コマンドの打ち間違え」と何ら変わらん。

まあ、実際のところ、こういうミスはあり得るんだよな。
僕も経験がある。「あっ！？」と思ったら消えちまった、みたいな。
ウェイトレスが滑って転んで客の頭にホットコーヒーをぶっかけるようなもの。
今回、ここまでの被害になっちまったのは運が悪かったとしか……。

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

デグレードチェックが甘かったんだな。これも仕方が無い。(´＞ω＜`)
「対象サーバはＡサーバです」って言ってるんだから、みんなＡサーバはしっかりチェックするけど、他のＢサーバやＣサーバはチェックしないのよ。
他の対象外サーバのチェックまでやってたら、時間がいくらあっても足りない。
「どうしてもやって欲しいなら工数を10倍払えよ」ってことになる。
と言っても、普段から値下げ合戦している業界だから、そんなコストはとても払えない。
これは仕方無い。

ただし、これって多分、「午前中に検証環境でテストして、午後に本番適用」とか、それくらいの短期間で一気にやったんだな。一週間くらい様子を見れば気づけた可能性が高かったのに。
きっと、忙しかったのだろう。
我がサービスの場合、「ステージング環境」と呼ばれる検証環境と本番の中間ステップがあって、そこで一週間様子見することになってるから、ここは安心だな。

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

これはバックアップじゃなくて「コールドスタンバイ」って言うんだよ。(´＞ω＜`)
バックアップは最初から無かったのだ。。。

まあ、バックアップは出来ないから無かったんだろう。
サーバ規模が巨大になるとバックアップするのも一苦労になる。1日でバックアッププロセスが終わらないくらい負荷も出てくるから、バックアップってのはイメージより難しいのよ。
もちろん、最初からバックアップ負荷を計算して分散設計になっていれば大丈夫だけど、それだどハードウェア等の費用が2倍、3倍になっちまう。予算が無かったんだな。

だが、稼働系と待機系を同時に消したのは痛かった。
しかし、文章を見ると「昔、稼働系だけにパッチを適応して、待機系に適応するのを忘れるという障害があったことへの対応」というのがある。
コレ見ると「あちゃ～」だな。

「問題があるから何か対応しなければいけない！⇒対応したらもっと悪くなりました」

こういうことがあるんだよ。我が社でも沢山ある。
「問題に対する攻撃的姿勢だけが強烈で、改善策を出す能力が無い」って姿勢の人がいると、社内の雰囲気が悪くなって「こんなことやっても無駄だよなぁ」「何もしない方がマシだよなぁ」と大勢の社員が思いつつも、改悪を実行。
結果グダグダ。
よくある話。



以上、僕の感想を言うと、「重過失致死」
トラック運転手が居眠り運転して小学生の列に突っ込むようなもの。
そりゃ過失は過失だけど「100％防ぐ手段を示せ！！」って言われても、う～んってところ。

原発もそうだけど、やっぱ世の中に安全神話なんて無いんだな。(´・ω・`)

ぶっ飛び2

ファーストサーバぶっ飛び事件はまだ全容が見えないな。

いずれＩＴｐｒｏとかでも特集が組まれるだろうから、
随時追っていきたい。

それはそうと、今回の件がクラウド業界全体を揺るがすものであるのは確実だな！！

今のＩＴ業界は「クラウド」っていう言葉自体が一人歩きしていて、
意味も分からずクラウドクラウドって言っている人も多い。
実際、クラウドって言葉の定義自体、今となってはハッキリしないものだろう。

クラウドの本当の意味はとりあえず置いておくとして、
僕の思う「クラウド」の特徴として特筆すべき点を挙げる。
それは、

クラウド：複数の企業で1台のマシンを使う。

ということだ。
それに対し、昔ながらの専用機というのは、

専用機：1つの企業で1台のマシンを使う。

となる。
僕はこの違いを重視したい。

今回、確かに大災害になったけど、これは別に

クラウド＝脆弱
専用機＝強固

って意味にはならんよ。
システムの保守性、完全性、強度は両者全く互角。
だから、「自分もクラウドサービス使ってる。もしかしたら自分のデータが消えるかも。」って思うのは早とちり。
安全性は変わりません。

じゃあ、何が問題なのかっていうと、
専用機をぶっ壊した場合は、その専用機を使っていた企業1社に対し賠償すれば良い。
しかし、クラウドをぶっ壊すと、今回のケースだと5000社に対し賠償となる。

5000社も相手に賠償なんて出来るわけねーだろ！！

つまり、クラウドという技術そのものは別に問題無い。
既にコストが許す限りの精一杯に十分な保守水準を達成している。

逆に言うと、コスト競争で安値合戦をするとそれだけヤバイってことだが、それは置いておいて。
とにかく、十分十分と言いつつ、やっぱり万が一って事がある。
そして、その万が一の際に、これだけ規模が大きくなると賠償が出来ない。つまり、

万が一の際に、会社が責任を負いきれないような巨大な責任を軽々しく背負ってしまう

という、経済的・法律的・政治的な部分に問題があるものだと思う。



じゃあ、どうすりゃいいの？って話になる。

天地がひっくり返っても100％絶対安全ってのを技術的に達成するのは不可能。
どうしても想定外の事態というものはある。

となれば、僕が思いつく対策というのは「保険」だな。

保険会社が企業向けに「クラウド保険」みたいなのを作って、
万が一の際は保険金で賠償出来るようにしておくこと。

鉄道業界だと、鉄道で大事故やらかした時に備えて保険が用意してあるって聞いたことがある。
同じことをＩＴ業界向けにやってくれ。

これをやってくれれば、ＩＴ会社は

・お客様のデータは死んでも守ります。
・万が一、死んでも守れなかった場合は、保険金で賠償します。

って言えるだろ。



全く、これから未来が開けるはずだったクラウド商売に、
とんでもない冷や水がぶっかかったもんだぜ！！

白雪

ハニーと映画「スノーホワイト」を観てきたにゃん。

王道的なファンタジーだったな。
誰が観てもハズレが無いようなストーリーだったと思う。

次はディズニーアニメを見に行かなきゃな。

ぶっ飛び

ファーストサーバで大規模なデータ障害、顧客データが消失

サーバホスティング事業を手掛けるファーストサーバは、提供中の一部のサービスで大規模なデータ障害が発生し、顧客のデータが消失したことを明らかにした。

　対象サービスは「ビズ」「ビズ2」「エントリービズ」「EC-CUBEクラウドサーバ マネージドクラウド」および、これらのサービスを利用したオプションサービス。(1)サーバ上にアップロードされたデータ(FTP、ファイルマネジャーなど)、(2)コンフィグレータ設定を含むデータ、(3)メールボックス内のデータ――が消失し、サーバを随時初期化して提供しているという。

http://www.atmarkit.co.jp/news/201206/22/firstserver.html

どひゃ～。

ホスティングサービスなのにデータぶっ飛ばしちゃったんだな。
バックアップも効かないのか。
それは困る。(´・ω・`)

僕が関係している会社の業務で言うところの

・基幹伝送ファイルが全部ぶっ飛び
・全サービスのＤＢがぶっ飛び
・ファイル掲示板の全ファイルがぶっ飛び
　⇒業務続行不能

ってくらいの破壊規模か。
そんなことになったら……、怒られるのう。(´・ω・`)



どうやらこの「ファーストサーバ」って、企業向けが多いようだ。

だから、通販事業を行っている会社で「客から商品を注文して金も受け取ったけど、データがぶっ飛んだので、何の商品を誰に発送して良いか不明になった」「通販サイト自体が完全にぶっ飛んだので、事業が継続不可能になった。」とか、こういう状況になってるらしい。
事業終了、会社解散になるくらいの完全ぶっ飛びだ。

ユーザ数は5万人っつーから、結構な人数の失業者が出現してしまいそうだな。

ＩＴ業界にとっては、原子力発電所がメルトダウン起こしたような歴史的災害だわ。

これは困った。(´・ω・`)

台風

　　/　　 /　　/　 /
　　＿n＿
　／//|ヾ＼　/　/
　⌒⌒|⌒⌒
/　　 |∧_∧　/　 /
　　　|･ω･`)
　/　 Oと　 )　/　/
　　　 しーＪ｡｡｡｡｡

早めに帰って来れて良かったお。