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

ファーストサーバ、大規模障害の中間報告を発表」記事へのコメント

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

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

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

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

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

      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" ]みたいな条件が抜けていた、とかでしょうか。それでも一体何を削除する必要があったのか不明です。
        「脆弱性対策」ってのは方便の可能性があるので、話半分に信じるとしても、何をやろうとしたらこんなことが起こるのか、皆目見当がつかないです。

        親コメント
        • by Anonymous Coward

          >Act-Stanbyでもパッチレベルを同一にするのは当然のこと
          これは正答でもあり誤答でもあり。

          他でも書いたけど、パッチに不具合があったら?
          その時点で本番系・待機系両方停止するだろうに。

          ”まったく同時にあてる”のは馬鹿のやること。

          片方にあてて、問題なければもう片方にもあてる。
          数分や数時間のパッチレベルの差のために何時間も両方停止する危険冒すの?

          • by Anonymous Coward

            > 片方にあてて、問題なければもう片方にもあてる。
            > 数分や数時間のパッチレベルの差のために何時間も両方停止する危険冒すの?

            まったくもって同感。

            つーか、私の感覚だと、待機系に適用してひと通りの検証をこなしてから、稼働系にあてる(検証用環境が用意できないプアーな環境なもので)もんだと思うのですが‥‥.たとえ、検証用環境が用意できるとしても、いきなり稼働系って怖くないですか?

            • by Anonymous Coward

              「待機系に適用してひと通りの検証をこな」すのに数分しかかからないなんてことあります?
              もしあったとしても、その間に稼働系が落ちたらどうするんですか?落ちないことを祈る?
              今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか?

              • >その間に稼働系が落ちたらどうするんですか?

                待機系にパッチ当ててる最中に稼動系落ちる(故障する)確率と。

                本番系と待機系両方に同じ操作で両方落ちる確率とどっちが高い?

                「待機系に適用してひと通りの検証をこなす」やらないであてたら・

                検証もしないで両方当ててるだけ。
                業務停止の確立があがるだけだろうに。

                馬鹿も休み休み言ったほうがよろしいかと
                親コメント
              • セキュリティ脆弱性を放っておくのは確かにバカだが、脆弱性ってそんなにすぐに突かれるものではない。
                (脆弱性を突いた攻撃のほとんどはそんなに簡単に成功するものではないから。)
                それよりも危険なのは、今回のように余裕こいてるくせに焦って脆弱性を修正しようとすることだと思います。
                親コメント
              • by Anonymous Coward

                >稼動系落ちる(故障する)確率
                元コメ>今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか?

                これは考えなくて良いと?
                ファーストサーバは過去にそれにやられてるみたいですよ?

                あなたのコメントの内容からすると、結局「運」の問題ってことですか?

                そうでないなら、是非、完全無欠な手順をご享受下さい。

              • 前にも他にも書いてますが、
                >今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか?

                待機系に当てる→待機系を本番系に昇格→元本番系(現待機系)に当てるの順が普通でしょうに。

                この順で普通に両方にパッチがあたるので、
                待機系に切り替わっても問題ないだろうに。

                同時にやったら、なにかあったときに同時に落ちるだけ。
                待機系用意する意味がない。
                親コメント
              • by Anonymous Coward

                >脆弱性ってそんなにすぐに突かれるものではない。
                >ほとんどはそんなに簡単に成功するものではない

                その前提が破られたらしょうがないから諦めると。
                やっぱり『運』って感じか。

              • その『運』を引き寄せるために、人事を尽くさないといけないのだな。

                今回のは、人事を尽くしていたとは、到底言えない。
                親コメント
      • たぶん、ポイントは1番で全てな気がする。

        比較として適切かどうかはわからないけど、例えば、Google のサービスを使っていて、メンテナンスの連絡を受けたことは無いなぁ....

        かといって、Google が脆弱性対策のメンテナンスを一切やっていない、とは考えづらい。

        メンテナンス作業で、一時、サービスが利用できなくなる、というのであれば、通知があるのは普通だし、Google では見たことは無いけど、普通の Web サービスとかで、「この間はアクセス出来ません」というメールはよく見る。逆に、サービスの利用に問題がないけど、この間にメンテナンスします、という連絡は見たことが無い。

        もし、今回のファーストサーバのメンテナンスが、本来、サービスの利用に影響が無いものであったら、事前通知なし、という事も有り得なくはないかなぁ、と。

        ただ、コンシューマ向けでないサービスで、しかも、免責事項で「データのバックアップは自分でね」と言っているサービスで、今回の作業に事前通知が不要だと判断しているのだとしたら、余程の自信があるか、浅はかなのか、あるいは、リスクを承知して無視していたのか、などと思いますが。

        なんせ、「SLA 100%」を謳っているから、メンテナンスでサービスを止める訳にはいかないし....。でも、本当にあんな構成で、SLA 100% を真顔で言っているのだとしたら、ちょっと....

        親コメント
        • by Anonymous Coward

          >本当にあんな構成で、SLA 100% を真顔で言っているのだとしたら、ちょっと....
          「お客様向け全サーバに対してホットスタンバイマシンを用意しておりますのでSLA100%です」(ドヤァ

          #ホットスタンバイをバックアップと、RAIDをバックアップと、システムから取り外した控えのデータをバックアップと呼ぶのをやめよう運動

        • by Anonymous Coward

          毎月5%のキャッシュバック付きSLA100%は如何でしょうか?

      • by Anonymous Coward

        >待機系はその意味合い上、同時にパッチが当たっても特に問題ないんじゃないかと思います。
        アウト。

        検証環境で不具合が起きないからって、本番で絶対起きないなんて事はない。
        (オペミスに限らず、パッチ自体の環境依存バグもあり得る。)

        その場合に待機系に一緒に宛ててたら一緒にアボン。なんの為の待機系?

        不通は待機系->(問題なければ)本番 または 本番系->問題なければ待機系
        の手順を踏む。

        fsの”過去に待機系にあて忘れて不具合の残ったシステムが動いた事がある”は
        ”(問題ないとなってから)宛て忘れたのが悪い”だけ。

        そもそも待機系から宛てれば”過去に待機系にあて忘れて不具合の残ったシステムが動いた事がある”
        もあり得ない。

      • by Anonymous Coward

        実際のところ告知は無かったんですかね?
        「たぶん」とか「だろう」ではなく当事者の情報希望。

      • by Anonymous Coward
        >待機系はその意味合い上、同時にパッチが当たっても特に問題ないんじゃないかと思います。
        スラドですらこれか。

        >オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。
        なんのための仕組み?待機系の本質的な目的は?

        #本番系に何か(障害、オペミスも含む)あっても待機系に切り替えて業務停止時間を最小にする#

        だろうに。
        同時に操作してたら、同時にとまるから業務停止する。待機系の意味がない。
        あなたもファーストサーバと同レベルだよ。
        • by Anonymous Coward

          >>オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。
          >なんのための仕組み?待機系の本質的な目的は?

          0day攻撃のウィルスによって本番系が動作不能になった時、
          すぐさま待機系に切り替わって同じウィルスにやられる。

          という状況は考えられませんか?
          そんなの考える必要がありませんか?
          ファーストサーバは過去にそれにやられてるみたいですよ?
          どう思います?
          どうすればよかったんですか?

          • >そんなの考える必要がありませんか?
            はい、まともな管理者、まともな手順踏んでれば考える必要ありません。

            まともな管理者なら

            先に待機系にパッチ→不具合ないことを確認→トランザクション同期→待機系を本番に昇格→もと本番の現待機系にパッチの手順を踏みますから。

            待機系にパッチが当たってないことはありません。
            そもそも本番からも当てません。

            0dayだろうが、オペミスだろうが、パッチバグだろうが。
            ”業務をとめない”のが待機系を用意する目的だろうに
            親コメント
    • by denchu (6847) on 2012年06月25日 20時07分 (#2180483)

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

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

      親コメント
      • by Anonymous Coward
        とあるスクリプトのエラー処理で、 rm -rf ${hoge}* というコードが動いたけれども、hogeを設定する前だったので、ファイルシステムがメルトダウンするという目に遭ったことはあります。 それでも「削除コマンドの停止漏れ」が意味不明だね。
      • by Anonymous Coward

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

        私もこの点はよくわかりません。
        パッチを当てた後、パッチファイルを

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

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

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

      親コメント
      • by Anonymous Coward

        rm -fr .. って、実際にすっからかんになるまで結構時間かかるような
        気がするんだよね。だから肝のファイルを上書きしたせんも捨てられないが、
        「削除コマンド」って報告に書いてあるからなぁ。

        まあファイルシステムなんて 1セクター潰すだけでおじゃんに
        なったりするからなぁ。

        • by Anonymous Coward

          やってみろよ…一瞬だぞ…。
          泣くぞ、ほんと

      • by Anonymous Coward

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

        どの辺が?

    • 校正漏れなんでしょうけど、責任感が感じられない記述。
      データ漏れで2次災害にもなっていますし、
      セキュリティホールを放置していたころと変わらないダメさ加減ですね。

    • by Anonymous Coward

      >    検証環境でも、非ターゲットサーバーはバグにより全損していたはずなのに気づかないとかあるのでしょうか?
      非ターゲットのサーバが一台もない検証環境だったんでしょう。

      • by Anonymous Coward

        たぶん

        >、プログラム実行後の動作確認を行う対象は、あくまでも当該メンテナンス対象サーバー群を確認すれば足りるとされていた

        から。

        http://support2.fsv.jp/info/nw20120625_01.html [support2.fsv.jp]
        の「原因2」のところ。

        • by t-wata (10969) on 2012年06月26日 15時18分 (#2181019) 日記

          その説明は、
          検証環境の対象サーバーは無事だったので検出できなかった
          検証環境の非対象サーバーまでみていれば検出できていたがそこまではしていなかった
          という風に読み取れますが、本当でしょうか?
          検証後、商用への適用まで1日以上置くはずですし、切り戻し手順の確認のため、何度か実行するはずです。
          検証環境の他のサーバーが全壊しているのに、その間誰も気づかないとか考え辛いです。
          それに検証環境が複数あるなら、商用展開前にまずは検証環境の他のサーバにもパッチを当てようとするはずです。
          検証で検出できなかったと言う説明には違和感を感じます。

          親コメント
          • by Anonymous Coward

            >という風に読み取れますが、本当でしょうか?

            意味としてはそいう言うことだと思います。
            本当かどうかは分かりませんが、これまでの(訂正も含めての)発表を真実と考えるべきでしょう。
            「本当はこうなんだろう?」は話題として面白いですし、/.らしいですけどね。

            >検証後、商用への適用まで1日以上置くはずですし、切り戻し手順の確認のため、何度か実行するはずです。

            http://support2.fsv.jp/info/nw20120625_01.html [support2.fsv.jp]
            「原因3」のところを読むと、
            過去にパッチの当て遅れで被害にあったことがあるようで、今回は急いだということかと思います。

            >検証環境の他のサーバーが全壊しているの

            • by Anonymous Coward

              1.>過去にパッチの当て遅れで被害にあったことがあるようで、今回は急いだということかと思います

              2.>バックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し

              そもそも②は”宛て忘れたのが悪い”のであって1、”だから同時に当てちゃえ”って素人以下の集団かよ。
              原因に対する対策が間違ってる。今回はオペミスだけど、パッチにバグがあったら?
              結局待機系もアボンだよね。業務とまるじゃん。

              待機系ってのは本番に何かあっても待機系に切替て業務をとめない為にあるんじゃないのか?

              • by Anonymous Coward

                >そもそも②は”宛て忘れたのが悪い”

                別コメでも指摘されていますが、一方にパッチを当てて問題ないことを確認してから
                もう一方に当てるのが、正しいかどうか分かりませんがまともな手順だと思います。
                確認するためにはタイムラグが発生します。
                「当て忘れた」わけじゃないでしょう。

                >今回はオペミスだけど、パッチにバグがあったら?

                いや、今回のはパッチにバグがあったんですよね?
                それを検証環境で検出できなかったという手順の不具合だと思っています。
                もちろん「バックアップが存在しない」ことが一番の問題でしょうが。

                検証せずいきなり待機系にパッチを当てたっていうんなら確かに素人。でもそんな情報ありました?

                引用が前後しますが
                >結局待機系もアボンだよね。業務とまるじゃん。

                是非、完全無欠な手順を提示して下さい。
                その方が参考になります。

              • by oyajismel (32045) on 2012年06月26日 21時22分 (#2181295) 日記
                >検証せずいきなり待機系にパッチを当てたっていうんなら確かに素人。でもそんな情報ありました?

                まともな検証せず、本番系と待機系同時にあてたといってますよ。

                http://support2.fsv.jp/info/nw20120625_01.html
                >対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。

                で、わざとわかりにくくなるようにFSVは書いてますが。

                パッチの不具合ではなく、
                パッチを自動更新するためにFSVが作成したpg(バッチやシェルと思われる)
                の不具合です。
                >脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための”更 新 プ ロ グ ラ ム を 作 成 し て お り 、”今回も更新プログラムを作成しています。

                ただのオペミスです
                親コメント

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

処理中...