アカウント名:
パスワード:
説明にいくつか合点のいかない点があります。1. 事前告知無しに午後5時にメンテナンスしている点。 いくら緊急でも午後5時にメンテナンスなんてありえないでしょう。 しかもそんな緊急パッチなら再起動も入るはずで事前告知無しはありえないはずです。2. 脆弱性対処でファイル削除している点 一体どう言うパッチあてすると、(ディレクトリごと)削除がいるのでしょう？3. 削除コマンドの停止漏れ 具体的にどういうことなのかわかりません。しかも検証で対象サーバの方は正常に処理が終了して検証をパスしたよ
たぶん、ポイントは１番で全てな気がする。
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" ]みたいな条件が抜けていた、とかでしょうか。それでも一体何を削除する必要があったのか不明です。「脆弱性対策」ってのは方便の可能性があるので、話半分に信じるとしても、何をやろうとしたらこんなことが起こるのか、皆目見当がつかないです。
＞Act-Stanbyでもパッチレベルを同一にするのは当然のことこれは正答でもあり誤答でもあり。
他でも書いたけど、パッチに不具合があったら？その時点で本番系・待機系両方停止するだろうに。
”まったく同時にあてる”のは馬鹿のやること。
片方にあてて、問題なければもう片方にもあてる。数分や数時間のパッチレベルの差のために何時間も両方停止する危険冒すの？
> 片方にあてて、問題なければもう片方にもあてる。> 数分や数時間のパッチレベルの差のために何時間も両方停止する危険冒すの？
まったくもって同感。
つーか、私の感覚だと、待機系に適用してひと通りの検証をこなしてから、稼働系にあてる(検証用環境が用意できないプアーな環境なもので)もんだと思うのですが‥‥．たとえ、検証用環境が用意できるとしても、いきなり稼働系って怖くないですか？
「待機系に適用してひと通りの検証をこな」すのに数分しかかからないなんてことあります？もしあったとしても、その間に稼働系が落ちたらどうするんですか？落ちないことを祈る？今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか？
＞稼動系落ちる（故障する）確率元コメ＞今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか？
これは考えなくて良いと？ファーストサーバは過去にそれにやられてるみたいですよ？
あなたのコメントの内容からすると、結局「運」の問題ってことですか？
そうでないなら、是非、完全無欠な手順をご享受下さい。
＞脆弱性ってそんなにすぐに突かれるものではない。＞ほとんどはそんなに簡単に成功するものではない
その前提が破られたらしょうがないから諦めると。やっぱり『運』って感じか。
比較として適切かどうかはわからないけど、例えば、Google のサービスを使っていて、メンテナンスの連絡を受けたことは無いなぁ....
かといって、Google が脆弱性対策のメンテナンスを一切やっていない、とは考えづらい。
メンテナンス作業で、一時、サービスが利用できなくなる、というのであれば、通知があるのは普通だし、Google では見たことは無いけど、普通の Web サービスとかで、「この間はアクセス出来ません」というメールはよく見る。逆に、サービスの利用に問題がないけど、この間にメンテナンスします、という連絡は見たことが無い。
もし、今回のファーストサーバのメンテナンスが、本来、サービスの利用に影響が無いものであったら、事前通知なし、という事も有り得なくはないかなぁ、と。
ただ、コンシューマ向けでないサービスで、しかも、免責事項で「データのバックアップは自分でね」と言っているサービスで、今回の作業に事前通知が不要だと判断しているのだとしたら、余程の自信があるか、浅はかなのか、あるいは、リスクを承知して無視していたのか、などと思いますが。
なんせ、「SLA 100%」を謳っているから、メンテナンスでサービスを止める訳にはいかないし....。でも、本当にあんな構成で、SLA 100% を真顔で言っているのだとしたら、ちょっと....
>本当にあんな構成で、SLA 100% を真顔で言っているのだとしたら、ちょっと....「お客様向け全サーバに対してホットスタンバイマシンを用意しておりますのでSLA100%です」（ドヤァ
#ホットスタンバイをバックアップと、RAIDをバックアップと、システムから取り外した控えのデータをバックアップと呼ぶのをやめよう運動
毎月5%のキャッシュバック付きSLA100%は如何でしょうか？
>待機系はその意味合い上、同時にパッチが当たっても特に問題ないんじゃないかと思います。アウト。
検証環境で不具合が起きないからって、本番で絶対起きないなんて事はない。（オペミスに限らず、パッチ自体の環境依存バグもあり得る。）
その場合に待機系に一緒に宛ててたら一緒にアボン。なんの為の待機系？
不通は待機系->（問題なければ）本番 または 本番系->問題なければ待機系の手順を踏む。
fsの”過去に待機系にあて忘れて不具合の残ったシステムが動いた事がある”は”（問題ないとなってから）宛て忘れたのが悪い”だけ。
そもそも待機系から宛てれば”過去に待機系にあて忘れて不具合の残ったシステムが動いた事がある”もあり得ない。
実際のところ告知は無かったんですかね？「たぶん」とか「だろう」ではなく当事者の情報希望。
＞＞オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。＞なんのための仕組み？待機系の本質的な目的は？
0day攻撃のウィルスによって本番系が動作不能になった時、すぐさま待機系に切り替わって同じウィルスにやられる。
という状況は考えられませんか？そんなの考える必要がありませんか？ファーストサーバは過去にそれにやられてるみたいですよ？どう思います？どうすればよかったんですか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
合点がいかない (スコア:5, すばらしい洞察)
説明にいくつか合点のいかない点があります。
1. 事前告知無しに午後5時にメンテナンスしている点。
いくら緊急でも午後5時にメンテナンスなんてありえないでしょう。
しかもそんな緊急パッチなら再起動も入るはずで事前告知無しはありえないはずです。
2. 脆弱性対処でファイル削除している点
一体どう言うパッチあてすると、(ディレクトリごと)削除がいるのでしょう？
3. 削除コマンドの停止漏れ
具体的にどういうことなのかわかりません。しかも検証で対象サーバの方は正常に処理が終了して検証をパスしたよ
起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:5, 興味深い)
たぶん、ポイントは１番で全てな気がする。
中間発表を読むと、
ってことで、たぶん普段から告知無しでメンテナンス当ててると思う。
なんでんな無茶が通ってたかって言うと、できるだけセキュリティパッチは早く当てたいって事と、検証環境があるから油断してるって事じゃないかな。
んで、「2. 脆弱性対処でファイル削除している点」と「3. 削除コマンドの停止漏れ」とはたぶん同じで、パッチを当てるためのスクリプトの雛形に、環境をまっさらにしてから当てる、みたいな無茶なのが入ってるんじゃないかなあ。（ちょっと想像しづらいけど）
んで、「サーバー群を指定するための記述漏れ」ってあるけど、たぶん逆だったんじゃないかなあ。
対象サーバ以外に、当てるってやるになってた。んで、検証対象サーバはパッチが当たってない（当てる前と同じ）ので、動いてる動いてるとスルー。「4. 検証環境での検出漏れ」ね。
# 「5. FSではバックアップは同一サーバー上に置かれる」ってデータと、待機系とはたぶん別なんでしょう。
# さすがにバックアップシステムがなきゃ100%は謳えないと思うので。
暫定対応に色々書いてありますが、待機系はその意味合い上、同時にパッチが当たっても特に問題ないんじゃないかと思います。オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。
だから、ポイントは「検証環境があるからと、気楽にシステムに手を入れてる」ところと、「検証環境で何か問題が起きていないかのチェックが形骸化していること」じゃないかなあと。
不注意がおきやすい環境で、チェックも入ってなかったら、そりゃいつか起きるだろうと。
まあ、良い機会だからインフラ関連を刷新するべくみんな稟議を通そうぜ！
いまならまともなディザスタリカバリの仕組みを作り込んでも無駄扱いされることは無かろう:-P
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:3)
起きるべくして起きたってのは同意です。しかしどんな運用をしていたのかは明らかにしてほしいですね。他にもやってるところあるでしょうし、検証や運用に甘い考えを持った人を納得させるための材料にもなるので。
個人的には、
・メンテナンスは意図的なものだったのか？
・本当に検証環境でテストしたのか？
・そもそも本当に検証環境（と呼んで良いもの）があるのか？
という点を疑っています。
例えば、検証環境と呼んでいるものが、実は本番DMZにあるデモサーバーの事で、そしてそのデモサーバーで検証するつもりが、（kousokubusさんの言うような感じで）デモサーバー以外の本番環境で処理が動いた、というような可能性です。
これなら通常の業務システムでは負荷が高くなりやすい午後5時なんて時間に作業した事も、検証環境で検出できなかった事も説明がつきます。またこれが本当なら、杜撰な管理を責められるため隠そうとしたとしても不思議ではありません。
またバックアップサーバへのパッチ適用は私も同じ考えで、同時に適用する事は問題ないと考えます（Act-Actなクラスタは当然として、Act-Stanbyでもパッチレベルを同一にするのは当然のこと）。
問題なのは作業前にデータをバックアップしていないことであって、待機系に同時適用したことは全く問題じゃないはずです。にも関わらず待機系をバックアップと呼び、話にあげてきたのは、万全を期していた、というような印象を与えたかったと予想します。
ただ、削除については非常に謎が多いです。kousokubusさんの言う「環境をまっさらにする」ならバックアップからコピーで戻すんじゃないですかね。
もともときれいさっぱり何も無い場所に、パッチ当てかメンテかでファイルができ、削除するとまっさらになる、ってのはちょっと考え辛いです。
「削除コマンドの停止漏れ」は考えられるとしたら、
find $TMP/ -type f -exec rm -f {} ¥;
rm -rf $TMP/*
みたいな処理で、if [ -z "$TMP" ]みたいな条件が抜けていた、とかでしょうか。それでも一体何を削除する必要があったのか不明です。
「脆弱性対策」ってのは方便の可能性があるので、話半分に信じるとしても、何をやろうとしたらこんなことが起こるのか、皆目見当がつかないです。
Re: (スコア:0)
＞Act-Stanbyでもパッチレベルを同一にするのは当然のこと
これは正答でもあり誤答でもあり。
他でも書いたけど、パッチに不具合があったら？
その時点で本番系・待機系両方停止するだろうに。
”まったく同時にあてる”のは馬鹿のやること。
片方にあてて、問題なければもう片方にもあてる。
数分や数時間のパッチレベルの差のために何時間も両方停止する危険冒すの？
Re: (スコア:0)
> 片方にあてて、問題なければもう片方にもあてる。
> 数分や数時間のパッチレベルの差のために何時間も両方停止する危険冒すの？
まったくもって同感。
つーか、私の感覚だと、待機系に適用してひと通りの検証をこなしてから、稼働系にあてる(検証用環境が用意できないプアーな環境なもので)もんだと思うのですが‥‥．たとえ、検証用環境が用意できるとしても、いきなり稼働系って怖くないですか？
Re: (スコア:0)
「待機系に適用してひと通りの検証をこな」すのに数分しかかからないなんてことあります？
もしあったとしても、その間に稼働系が落ちたらどうするんですか？落ちないことを祈る？
今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか？
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:1)
待機系にパッチ当ててる最中に稼動系落ちる（故障する）確率と。
本番系と待機系両方に同じ操作で両方落ちる確率とどっちが高い？
「待機系に適用してひと通りの検証をこなす」やらないであてたら・
検証もしないで両方当ててるだけ。
業務停止の確立があがるだけだろうに。
馬鹿も休み休み言ったほうがよろしいかと
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:1)
(脆弱性を突いた攻撃のほとんどはそんなに簡単に成功するものではないから。)
それよりも危険なのは、今回のように余裕こいてるくせに焦って脆弱性を修正しようとすることだと思います。
Re: (スコア:0)
＞稼動系落ちる（故障する）確率
元コメ＞今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか？
これは考えなくて良いと？
ファーストサーバは過去にそれにやられてるみたいですよ？
あなたのコメントの内容からすると、結局「運」の問題ってことですか？
そうでないなら、是非、完全無欠な手順をご享受下さい。
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:1)
＞今回のようなセキュリティパッチなら、待機系に切り替わったとたんに同じ攻撃でやられませんか？
待機系に当てる→待機系を本番系に昇格→元本番系（現待機系)に当てるの順が普通でしょうに。
この順で普通に両方にパッチがあたるので、
待機系に切り替わっても問題ないだろうに。
同時にやったら、なにかあったときに同時に落ちるだけ。
待機系用意する意味がない。
Re: (スコア:0)
＞脆弱性ってそんなにすぐに突かれるものではない。
＞ほとんどはそんなに簡単に成功するものではない
その前提が破られたらしょうがないから諦めると。
やっぱり『運』って感じか。
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:1)
今回のは、人事を尽くしていたとは、到底言えない。
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:1)
たぶん、ポイントは１番で全てな気がする。
比較として適切かどうかはわからないけど、例えば、Google のサービスを使っていて、メンテナンスの連絡を受けたことは無いなぁ....
かといって、Google が脆弱性対策のメンテナンスを一切やっていない、とは考えづらい。
メンテナンス作業で、一時、サービスが利用できなくなる、というのであれば、通知があるのは普通だし、Google では見たことは無いけど、普通の Web サービスとかで、「この間はアクセス出来ません」というメールはよく見る。逆に、サービスの利用に問題がないけど、この間にメンテナンスします、という連絡は見たことが無い。
もし、今回のファーストサーバのメンテナンスが、本来、サービスの利用に影響が無いものであったら、事前通知なし、という事も有り得なくはないかなぁ、と。
ただ、コンシューマ向けでないサービスで、しかも、免責事項で「データのバックアップは自分でね」と言っているサービスで、今回の作業に事前通知が不要だと判断しているのだとしたら、余程の自信があるか、浅はかなのか、あるいは、リスクを承知して無視していたのか、などと思いますが。
なんせ、「SLA 100%」を謳っているから、メンテナンスでサービスを止める訳にはいかないし....。でも、本当にあんな構成で、SLA 100% を真顔で言っているのだとしたら、ちょっと....
Re: (スコア:0)
>本当にあんな構成で、SLA 100% を真顔で言っているのだとしたら、ちょっと....
「お客様向け全サーバに対してホットスタンバイマシンを用意しておりますのでSLA100%です」（ドヤァ
#ホットスタンバイをバックアップと、RAIDをバックアップと、システムから取り外した控えのデータをバックアップと呼ぶのをやめよう運動
Re: (スコア:0)
毎月5%のキャッシュバック付きSLA100%は如何でしょうか？
Re: (スコア:0)
>待機系はその意味合い上、同時にパッチが当たっても特に問題ないんじゃないかと思います。
アウト。
検証環境で不具合が起きないからって、本番で絶対起きないなんて事はない。
（オペミスに限らず、パッチ自体の環境依存バグもあり得る。）
その場合に待機系に一緒に宛ててたら一緒にアボン。なんの為の待機系？
不通は待機系->（問題なければ）本番 または 本番系->問題なければ待機系
の手順を踏む。
fsの”過去に待機系にあて忘れて不具合の残ったシステムが動いた事がある”は
”（問題ないとなってから）宛て忘れたのが悪い”だけ。
そもそも待機系から宛てれば”過去に待機系にあて忘れて不具合の残ったシステムが動いた事がある”
もあり得ない。
Re: (スコア:0)
実際のところ告知は無かったんですかね？
「たぶん」とか「だろう」ではなく当事者の情報希望。
Re: (スコア:0)
スラドですらこれか。
＞オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。
なんのための仕組み？待機系の本質的な目的は？
＃本番系に何か（障害、オペミスも含む）あっても待機系に切り替えて業務停止時間を最小にする＃
だろうに。
同時に操作してたら、同時にとまるから業務停止する。待機系の意味がない。
あなたもファーストサーバと同レベルだよ。
Re: (スコア:0)
＞＞オペレーションミスへの対応だとか、データの履歴を取るための仕組みじゃないですし。
＞なんのための仕組み？待機系の本質的な目的は？
0day攻撃のウィルスによって本番系が動作不能になった時、
すぐさま待機系に切り替わって同じウィルスにやられる。
という状況は考えられませんか？
そんなの考える必要がありませんか？
ファーストサーバは過去にそれにやられてるみたいですよ？
どう思います？
どうすればよかったんですか？
Re:起きるべくして起きた人災だと思う（Re:合点がいかない (スコア:1)
はい、まともな管理者、まともな手順踏んでれば考える必要ありません。
まともな管理者なら
先に待機系にパッチ→不具合ないことを確認→トランザクション同期→待機系を本番に昇格→もと本番の現待機系にパッチの手順を踏みますから。
待機系にパッチが当たってないことはありません。
そもそも本番からも当てません。
0dayだろうが、オペミスだろうが、パッチバグだろうが。
”業務をとめない”のが待機系を用意する目的だろうに