先従隗始・温故知新

はてダからの引っ越し(http://d.hatena.ne.jpのURLからここへ自動転送されます)。元サイト:アニメイレコムhttp://kasumin7.web.fc2.com/ire/

元サーバーサイドSEとしては、仰天というか失笑もの


場末の、個人がフリーランスでやってるような、サービスじゃあるまいし…LINUXのさ…
冗長構成をどこで崩した?
データが消えるようなメンテナンスってどういうんだ???かつてのAAACAFEとかああいうレベルだな…


小林製薬はとっとと再アップロードしてるし
ロフトはいつまでも簡易HTMLのままだし
IT体制は各社で差異が大きいね。要は単なる領域貸しで、ページの作成やアップと保守は各社めいめいで行うタイプか。


…ま、『ダメなサーバ屋』の淘汰が進むことは間違いないし、業界の自主的なスケーラビリティ向上努力にもつながる(ってか経産省とか総務省とかシャシャり出てきてもぜんぜんダメな業界だからw)。



B&B双方が、ゆるみすぎていたのだからいいお灸だよ。サーバサイドも、クライアントも、請けっぱなし、任せっぱなしじゃ、痛い目を見るのはハッキリした…
原発事故や大津波被害と同じだよ。政府と電力にお任せしてるから原発が爆発まで行ったわけだよ。大津波がきてもなお現地民は笑っててさ…そんなだから行政側もケースバイケースではあるがちゃんと津波対策してなかったわけで。ホスト側もクライアント側もすっかり慢心していたわけ。津波?どうせこねえよ 原発?爆発するわけねえよ と。(そしてそのノリで再稼働しちゃったわけ)


・クライアント側は、いいサービスを見抜くリテラシーを鍛えることといいコーディネイターに頼ること。
・サーバー側は、いいサービスを実現するための聡明さを磨く、および社内の費用対効果の理解力向上に努める(ミートホープみたいなんじゃ困るんで)


いやホント元サーバーSEの視点で、AAACAFEのさる対応が思い出されるようでは…クボタだかSBだか知らんけどファーストサーバー、ダメダメっすよ…


余談ではあるが東電はじめ電力各社と2ちゃんねる系の姿もすっかり一致してるから困りもの(「市場独占だから、憎いだろうけど使ってね」的な態度…こないだのまとめブログ締め出し騒動でも「2chさまに謝れば2ch転載を使わせてやる、たとえまとめブログは悪くなくてもなケケケ」みたいな殿様レス工作をいっぱいやらせてたもんな…値上げにせよ再稼働にせよ態度がソックリだろ)いずれ原発爆発みたいな顛末を2ch系も必ずやらかすだろうよ。

http://www.j-cast.com/2012/06/22136778.html
「ファーストサーバ」のレンタルサーバーで障害が発生したのは2012年6月20日。ウェブやメールが利用できなくなった。この日の夕方以降、「メールが見られない」「物販サイトなのにつながらないなんて」といった書き込みが少しずつ増えていった。最初のアナウンスから3、4時間経過してもファースト社から詳しい説明が出なかったため、「状況報告が遅い」といらだつコメントも出てくる。だが問題はすぐに解決しなかった。

日付が変わって21日の深夜3時30分、ファースト社は顧客のデータが消失したと発表。原因は「メンテナンス作業において用いる特定の管理プログラムにバグ」があったためとし、作業を進めた結果「サーバーを初期状態に戻」してサービスを再開するとした。ここから可能な限りデータを復旧するそうだ。

サーバー上にアップされたデータや、メールボックス内の一部データ、さらにデータベースも消失したと説明している。障害発生後のメールは受信できていない。現時点では、復旧の可否や復旧の度合いについて「お約束できる状況にはなく、長期間を要する可能性」もあるという。

障害が起きたサービスの中には、企業内でスケジュールや勤怠管理、情報共有を目的に使われるグループウエアや、インターネット通販サイトの運営支援も含まれる。サーバーが初期化されたうえ、仮に消失データが元に戻らないとなれば、ネット通販業者にとっては顧客データをはじめ営業の根幹をなす情報が消滅した恐れもある。

被害はファースト社の顧客企業に広がった。小林製薬は6月21日、商品のブランドサイトや携帯サイトが多く閲覧できない状態になっていると発表。同社広報に取材すると「22日中をメドに全面復旧にこぎつけたい」と話した。「ファースト社に対して補償を求めるか」との問いには、「現時点ではサイトをすべて再開させることが先決」とこたえるにとどめた。東京・新宿にあるライブハウス「新宿ロフトを運営する「ロフトプロジェクト」のサイトは、現在もテキストのみのサイトで「仮運営」している状態だ。


情報システムに詳しい数人に聞くと、サーバーの障害で初期化まで行きついたうえバックアップも消失したとみられることに、一様に驚きをみせた。そもそもバックアップのデータは、万一を見越して別のサーバーや安全な場所に保管しておくはずなのに、同時に消えてしまうとはありえない対応というのだ。外部サーバーを使っている会社によっては、常に最新データのバックアップを自社サーバーに保管してリスクをヘッジするところもある。

だが、ユーザー数が5万に達し、うち企業や官公庁の契約割合が8割、「稼働率100%」をうたうファースト社を信頼して、データ運営を任せていた利用者は少なくないだろう。


http://www.asahi.com/national/update/0622/TKY201206220517.html
全国の企業や自治体など約3万の取引先のうち、映画館「109シネマズ」や小林製薬大阪市の水族館「海遊館」など約5千に影響が出たという。

 ファーストサーバは、企業などがホームページを運営するためのサーバーを貸し出している。20日にウイルス対策などで一部のシステムを更新したところ、プログラムに欠陥があり、データが消えたという。


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

 同社は6月20日午後5時50分ごろに障害の発生を認識し、翌21日未明にメンテナンスに用いる管理プログラムにバグがあったことを確認。同時に顧客データが消失したことも確認した。現在(1)と(3)については専門企業を交えて復旧作業を行っているものの、(1)は全く復旧できておらず、復旧には「長期間を要する可能性もある」(同社)という。(3)は一部の顧客に対して「可能な限り復旧した状態で」提供し、今後も復旧を進めるとしている。

 障害の影響を受けたオプションサービスは「サイボウズ Office for ASP」など。サイボウズはこれを受け、22日付で自社サイトに「ファーストサーバ様インターネットサーバー障害について」という注意書きを掲載。障害によって同社製品のライセンスキーが分からなくなったユーザーには無償で再発行を行うとしている。

 6月22日午後11時30分時点で、ファーストサーバの対象サービスは再設定した上でユーザーに提供済み。オプションサービスではサーバー証明書、バーチャルドメイン、Urchinサービス、簡易バックアップサービスの再設定が完了したという。「Cloudmark Authority for ASP」とサイボウズ Office for ASPは再設定作業中で、Cloudmarkについては同日中に完了するとしている。


http://japan.zdnet.com/datacenter/analysis/35018450/
レンタルサーバ事業のファーストサーバ、障害で顧客のデータを消失
http://japan.zdnet.com/datacenter/analysis/35018459/
ファーストサーバ障害問題:「顧客のデータ消失は前代未聞」--ITR内山氏
 プログラムのバグが原因だとすると、あくまでも推測だが、人為的なオペレーションミスが疑われる。バックアップしたときのファイルが空ファイルだったとか、である。
本当に、データを消失したとなると、ユーザー企業は今後事業者と契約を交わす際に、SLAを慎重につめなくてはいけなくなるだろう。バックアップを何カ所で取っている事業者なのかなどである。

 今回の話が広く知れ渡ると、ホスティングやハウジングといったサービスをユーザー企業が改めて見直すきっかけになる可能性が出てくる。結局は、自社でバックアップを取る必要があるとの結論に至ることもあるだろう。


 ◇


2012/06/25追記
なんか…こんな低レベルのバッチしか書けない奴らがなんでクラウドサービスなんか提供してるの…大手データセンター経験者のおれがサブチーフで入社したらサービスクオリティ一気に2段階以上アップするわwww
・相互照らし合わせチェックしてない(余裕がないのはスキルレベルか人員数か)
・というか自分が書いたバッチを読み直したのか?
・テスト環境(モックアップ)を作り、テストサーバーで実行してみてない
RM消してないとか、BKPに手を出すRMとか…むしろ超一流の手品師だわ。おれにはマネできんw

http://www.j-cast.com/2012/06/25136915.html
原因については、これまでの調査で、脆弱性対策のためにサーバーに適用した更新プログラムで「ファイル削除」コマンドの停止指示が漏れていたうえ、本来であれば対象サーバーにのみプログラムが適用されるはずが、対象範囲の指示も指定されていなかったため、すべてのサーバーに不具合のあるプログラムが当てられてしまったことが判明。さらにバックアップ環境にも影響が及んでしまったため、バックアップデータの消失につながってしまったという。


http://www.itmedia.co.jp/news/articles/1206/25/news036.html
(1)更新プログラムに、ファイル削除コマンドを停止させるための記述漏れと、メンテナンス対象となるサーバ群を指定するための記述漏れがあった。

(2)更新プログラムは検証環境で動作確認を行うという手順だったが、動作は対象サーバ群を確認すればよいとされていたため、更新プログラムの記述漏れによって対象サーバ以外にも影響が及んでいることが確認できず、本番環境で実施され、全サーバに適用されてしまった。

(3)データバックアップは毎朝6時に実施していたが、バックアップからのリストア後に脆弱性が巻き戻ってしまうのを防ぐため、脆弱性対策は対象サーバ群とバックアップに対して同時に更新プログラムを適用して実施していた。このため、対象サーバ群と同時にバックアップデータも消失した。

 ──と説明している。これまで同様の原因による障害が起きたことはなかったという。


 共有サーバサービスとクラウドサーバサービスについては「極めて遺憾ではございますが、データ復旧を行うことは不可能と判断いたしました」としてデータ復旧を断念。専用サーバサービスも、データ復旧に数カ月以上かかる上、復旧できたとしても部分的なものにとどまるという。

ギガテラレベルだと、どんだけ高速なハードでも全クラスタ復旧にはもーーーーーーのすごい時間がかかるから。現状、そのせいでHDDTVレコーダのデータサルベージは不可能。


要はさ、SEなら誰でもわかってるはずだけど
RAIDなんすよ。サービスって。


・サービス規模を拡大すればするほど、故障率も上がり、万一の賠償額も増え、障害発生時の手が回らないぶりも過熱する


明らかに「営業が、できもしない量の仕事を取ってくる、社長もそれを奨励している、ブラック企業」だなあ。
おれこんな会社ぜったい入りたくないし、入ってしまったら1ヶ月以内にやめる。
東京都心の銀行系や通信インフラ系とかいった超大手の環境にしかいたことがないから、なおさらこんなアブナイ企業にいたくないわー


SEってのは、他人様のシステムを見積もって、要件を定義する仕事だぜ。
自分たちの「無理、できる」の閾値を設定もできない企業なんて、SEですらないよ。インテグレートのレベルじゃない。