パスワードを忘れた？ アカウント作成
Close
4494495 story
バグ

ファーストサーバ、大規模障害の中間報告を発表 185

ストーリー by hylom
同様の構成を取っているところは結構あるんじゃないかと思ったり 部門より
あるAnonymous Coward 曰く、

先日ファーストサーバで大規模な障害が発生しましたが、その概要と原因についてファーストサーバー側が中間報告を公表しました。

バックアップデータまでも消失した原因は、バックアップ環境を待機系のように運用していたためのようです。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ファーストサーバ、大規模障害の中間報告を発表 More

  • バックアップの定義 (スコア:5, すばらしい洞察)

    by Anonymous Coward on 2012年06月25日 17時42分 (#2180398)

    リアルタイムで待機系に反映されるものを、「バックアップ」と称するのはやめた方がいいですね。
    ミラーリング／レプリケーションでしょう。

    バックアップと言う以上は、ある程度の世代管理がなされていて、任意の世代に戻せないと。

    • 同感。
      まさか本当にデータのバックアップを取らずに作業していたとは。

      確かに、システムのバックアップではあるが…

      シェア
      親コメント

  • 合点がいかない (スコア:5, すばらしい洞察)

    by t-wata (10969) on 2012年06月25日 19時33分 (#2180468) 日記

    説明にいくつか合点のいかない点があります。
    1. 事前告知無しに午後5時にメンテナンスしている点。
        いくら緊急でも午後5時にメンテナンスなんてありえないでしょう。
        しかもそんな緊急パッチなら再起動も入るはずで事前告知無しはありえないはずです。
    2. 脆弱性対処でファイル削除している点
        一体どう言うパッチあてすると、(ディレクトリごと)削除がいるのでしょう？
    3. 削除コマンドの停止漏れ
        具体的にどういうことなのかわかりません。しかも検証で対象サーバの方は正常に処理が終了して検証をパスしたように書かれていますが、同じ処理がターゲットではうまく行って非ターゲットだけで全損なんてどうやったらありうるのでしょう？
    4. 検証環境での検出漏れ
        検証環境でも、非ターゲットサーバーはバグにより全損していたはずなのに気づかないとかあるのでしょうか？
        もし気づかなかったとしたらなぜでしょう？
    5. FSではバックアップは同一サーバー上に置かれる、という説明書きがあったはずですが、なぜ今さら(待機系と思しき)バックアップサーバなんて話を持ち出しているのでしょう？

    今後他の管理者が似たようなことをしないよう、ぜひ真実を明らかにして欲しいですね。

    • たぶん、ポイントは１番で全てな気がする。

      1. 事前告知無しに午後5時にメンテナンスしている点。

      中間発表を読むと、

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

      ってことで、たぶん普段から告知無しでメンテナンス当ててると思う。
      なんでんな無茶が通ってたかって言うと、できるだけセキュリティパッチは早く当てたいって事と、検証環境があるから油断してるって事じゃないかな。
      んで、「2. 脆弱性対処でファイル削除している点」と「3. 削除コマンドの停止漏れ」とはたぶん同じで、パッチを当てるためのスクリプトの雛形に、環境をまっさらにしてから当てる、みたいな無茶なのが入ってるんじゃないかなあ。（ちょっと想像しづらいけど）
      んで、「サーバー群を指定するための記述漏れ」ってあるけど、たぶん逆だったんじゃないかなあ。
      対象サーバ以外に、当てるってやるになってた。んで、検証対象サーバはパッチが当たってない（当てる前と同じ）ので、動いてる動いてるとスルー。「4. 検証環境での検出漏れ」ね。
      　# 「5. FSではバックアップは同一サーバー上に置かれる」ってデータと、待機系とはたぶん別なんでしょう。
      　# さすがにバックアップシステムがなきゃ100%は謳えないと思うので。

      暫定対応に色々書いてありますが、待機系はその意味合い上、同時にパッチが当たっても特に問題ないんじゃないかと思います。オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。
      だから、ポイントは「検証環境があるからと、気楽にシステムに手を入れてる」ところと、「検証環境で何か問題が起きていないかのチェックが形骸化していること」じゃないかなあと。
      不注意がおきやすい環境で、チェックも入ってなかったら、そりゃいつか起きるだろうと。

      まあ、良い機会だからインフラ関連を刷新するべくみんな稟議を通そうぜ！
      いまならまともなディザスタリカバリの仕組みを作り込んでも無駄扱いされることは無かろう:-P

      シェア
      親コメント

      • 起きるべくして起きたってのは同意です。しかしどんな運用をしていたのかは明らかにしてほしいですね。他にもやってるところあるでしょうし、検証や運用に甘い考えを持った人を納得させるための材料にもなるので。
        個人的には、
        ・メンテナンスは意図的なものだったのか？
        ・本当に検証環境でテストしたのか？
        ・そもそも本当に検証環境（と呼んで良いもの）があるのか？
        という点を疑っています。
        例えば、検証環境と呼んでいるものが、実は本番DMZにあるデモサーバーの事で、そしてそのデモサーバーで検証するつもりが、（kousokubusさんの言うような感じで）デモサーバー以外の本番環境で処理が動いた、というような可能性です。
        これなら通常の業務システムでは負荷が高くなりやすい午後5時なんて時間に作業した事も、検証環境で検出できなかった事も説明がつきます。またこれが本当なら、杜撰な管理を責められるため隠そうとしたとしても不思議ではありません。
        またバックアップサーバへのパッチ適用は私も同じ考えで、同時に適用する事は問題ないと考えます（Act-Actなクラスタは当然として、Act-Stanbyでもパッチレベルを同一にするのは当然のこと）。
        問題なのは作業前にデータをバックアップしていないことであって、待機系に同時適用したことは全く問題じゃないはずです。にも関わらず待機系をバックアップと呼び、話にあげてきたのは、万全を期していた、というような印象を与えたかったと予想します。

        ただ、削除については非常に謎が多いです。kousokubusさんの言う「環境をまっさらにする」ならバックアップからコピーで戻すんじゃないですかね。
        もともときれいさっぱり何も無い場所に、パッチ当てかメンテかでファイルができ、削除するとまっさらになる、ってのはちょっと考え辛いです。

        「削除コマンドの停止漏れ」は考えられるとしたら、
        find $TMP/ -type f -exec rm -f {} ¥;
        rm -rf $TMP/*
        みたいな処理で、if [ -z "$TMP" ]みたいな条件が抜けていた、とかでしょうか。それでも一体何を削除する必要があったのか不明です。
        「脆弱性対策」ってのは方便の可能性があるので、話半分に信じるとしても、何をやろうとしたらこんなことが起こるのか、皆目見当がつかないです。

        シェア
        親コメント

    • Re:合点がいかない (スコア:3)

      by denchu (6847) on 2012年06月25日 20時07分 (#2180483)

      2. 脆弱性対処でファイル削除している点
          一体どう言うパッチあてすると、(ディレクトリごと)削除がいるのでしょう？
      3. 削除コマンドの停止漏れ
          具体的にどういうことなのかわかりません。しかも検証で対象サーバの方は正常に処理が終了して検証をパスしたように書かれていますが、同じ処理がターゲットではうまく行って非ターゲットだけで全損なんてどうやったらありうるのでしょう？

      私もこの点はよくわかりません。
      パッチを当てた後、パッチファイルを削除しようとして rm -rf / tmp とでもやったんでしょうかね?
      それでも「削除コマンドの停止漏れ」が意味不明ではありますが。

      シェア
      親コメント

    • CGIとかの修正して、検証環境のディレクトリを全部にxcopyしてしまいました（汗

      検証環境＝作業者環境
      プログラム＝コピーバッチファイル
      バックアップ環境＝待機環境

      とか。
      説明文面から、UNIX管理者的なプロトコルが通らない気がします。

      シェア
      親コメント

  • 金言 (スコア:4, 興味深い)

    by Anonymous Coward on 2012年06月25日 18時04分 (#2180409)

    RAIDはバックアップの代替ではない。
    バックアップもRAIDの代替ではない。

  • 脆弱性対策という、批判にくい作業中の原因不明＆不運＆半ば不可抗力の出来事だった事にして対外説明しよう、と。それで、本当の原因は何なんだ？　脆弱性対策だというならCVEでどの脆弱性だったのか、それでパッチ作成者のミスだというなら他でも出るはずだからデータが消える仕組みに対する技術的詳細を公表すると共に作成者に連絡して広く注意を促すべきだが、そうしない。つまり、脆弱性対策なんかじゃない、と。というか管理系作業手順のミス実行以外に考え付かんな、ここまで破壊的な結果をもたらすのは。「消えちゃった」じゃなくて、「ミスって豪快に消しちゃった」か「潰したデータでバックアップしちゃいました」か「バックアップから復旧した事がありませんでした。できると思ったけど実際にはバックアップが取れていませんでした」だろ？　もう「賠償請求を回避する」事しか考えていないのだろうが。

    ジオシティーズは2009年7月にデータ消失やっているし、その遥か昔…あれは20世紀だったか…にも消失をやっている。管理者のスキルが低いなと感じたな。トラブル対応慣れしてない、修羅場をくぐっていないって感じ。ユーザーによるデータバックアップの必要性を説明する代わりに、メリットばかりを強調したために被害が広がった。消失事故後に慌てて”データは各自でバックアップするのが当然です”みたいな説明してたっけ。過去の大ミスから教訓を得ないのは最悪だな。なら、また繰り返すだろう。

    今回は、流行のクラウドなんてフリーのサーバー同然の補償しかないというのが「偉い人」への教訓になったんじゃないかな。それにしても疑問なんだが、技術者なら何でサーバーぐらい自分で立てられないのかな。クラウドでコストダウンじゃなくて、クラウドで銭失い＆過労死＆倒産、だろう。
    • 自宅鯖だからこそ、気軽にupgradeするし、RAIDの片肺でもまあいいかって休日まで待てるんですよ。自社鯖なんて十分な設備投資と機能する交代勤務体制が無ければ本気で過労死します。昔と違って鯖の稼働率が事業に直結するんで普通の会社が鯖運用なんてそう簡単に手が出せるものじゃ無いです。だからといって値段だけ見てサービスの中身を吟味しないとこんなことになるわけで。
      シェア
      親コメント

  • ここが変だよファーストサーバー (スコア:2, 興味深い)

    by Anonymous Coward on 2012年06月25日 18時15分 (#2180423)

    ・脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成
    ・ファイル削除コマンドを停止させるための記述漏れ
    ・メンテナンスの対象となるサーバー群を指定するための記述漏れ
    ・検証環境下で対象サーバー以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定
    ・脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、
    メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生
    ・脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用

  • バックアップ環境を待機系のように運用していたためのようです。

    「のように」というよりは、普通の待機系にしか見えないんだけど...。じゃなきゃ、

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

    なんて話は出てこないと思うんだが...。

  • ステージング環境まで用意しろとは言えないけど、擬似とはいえスタンバイとアクティブの両方にやっちゃうってのは致命的かも。
    せめて片方ずつという運用にしとかないと・・・。

    もしかしてそれが範囲に関するミスってことなんだろうか。

    # 自分は一度環境作ったらもうひとつ同じ環境つくって、予算が可能であればハードディスクぶっこ抜いたりして切り替えや復帰が出来るか確認してるんだけどそういうのってあんまりやんないのかな

    • # 自分は一度環境作ったらもうひとつ同じ環境つくって、予算が可能であればハードディスクぶっこ抜いたりして切り替えや復帰が出来るか確認してるんだけどそういうのってあんまりやんないのかな

      普通、SIの現場なんかだと、テストの一環として、障害の検出とかがちゃんとできるとか、
      障害時に系切り替えがちゃんとできるかとかは、一通りやると思います。

      テストの9割は異常系と、教わってきました。

      シェア
      親コメント

  • バックアップサービスとかあるみたいだけど (スコア:1)

    by Anonymous Coward on 2012年06月25日 18時43分 (#2180440)

    そのオプションを選んでてもインチキやってバックアップ取ってなかったってこと？詐欺じゃん。

    • Re:ISMSってなんでょう? (スコア:1)

      by develop (22404) on 2012年06月26日 2時09分 (#2180659)

      障害を起こさないようにするルールの定義(一般化されてるルールの中から取捨とカスタマイズ)
      障害が起きた際のルールの定義(一般化されてるルールの中から取捨とカスタマイズ)
      それらの学習ルールの定義(一般化されてるルールの中から取捨とカスタマイズ)
      それらの監視ルールの定義一般化されてるルールの中から取捨とカスタマイズ)
      といった俺々ルールですよ？

      しかもそこで作られた自分ルールさえも中小の偉い人は守りません。
      監査システムなんてもはや飾りです。

      シェア
      親コメント

  • 誰も書いてないようなので (スコア:1)

    by Anonymous Coward on 2012年06月25日 23時13分 (#2180577)

    ささやき えいしょう いのり ねんじろ

      おおっと

typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy