アカウント名:
パスワード:
銀行などシステム障害がニュースになって思った事。
障害はコントロールできない
特にハードはどういう壊れ方をするか予想がつかない。対して障害対策は単なる二重化など、想定している障害の具体化が不十分
ここからは試案だけど、アクティブなアプローチとかあっても良いかと思う。例えばハニートラップよろしく、わざと弱い部分を作って置き、そこで検知されたら広範囲で交換するとか。まぁ、保証期間とか消費期限とかをうまく使って。
今回の様に、故障が広範囲に及ぶまで耐えるシステムより、小刻みに不具合を出すけど、全体のダウンタイムは小さく抑えるシステムがこれから有効なんではないか、と。
セールス用のバズワードに使えるかな?
「アクティブなアプローチ」の例として、Netflixでは、Chaos Monkeyというツールを作って、常時意図的にシステム障害を起こし続けているそうです。
これは、システム障害が起きてもサービス全体が停止しないようなアプリケーションを開発するように、開発者を条件付けるための仕組みといえます。
銀行の基幹系や航空会社の運航システムのように、部分的な誤りも許容できないシステムでは、いくらか異なるアプローチが必要になろうとは思います。ただ、考え方は使えるかもしれません。
昔のホストからそんなことやってるでしょ。それに今だってサポート期間があって壊れる前に更改してるよね?
壊れ方が予想がつかないとか言っておきながら弱いところから異常が起きると仮定しているところが草
システムのどの部分がどう壊れるのか予想がつかないんだから、今回もやったように、アナログ運用でも回せるように準備しておくのが、一番臨機応変に対応できるよね。
客:は? 何いってんの? 不具合でないシステムを作れよ。
> 客:は? 何いってんの? 不具合でないシステムを作れよ。1台だけで運用するってことになる。こんなこという客はお断りですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
そろそろ障害のコントロールを考える時期かと (スコア:1, 興味深い)
銀行などシステム障害がニュースになって思った事。
障害はコントロールできない
特にハードはどういう壊れ方をするか予想がつかない。
対して障害対策は単なる二重化など、想定している障害の具体化が不十分
ここからは試案だけど、アクティブなアプローチとかあっても良いかと思う。
例えばハニートラップよろしく、わざと弱い部分を作って置き、
そこで検知されたら広範囲で交換するとか。まぁ、保証期間とか消費期限とか
をうまく使って。
今回の様に、故障が広範囲に及ぶまで耐えるシステムより、
小刻みに不具合を出すけど、全体のダウンタイムは小さく抑える
システムがこれから有効なんではないか、と。
セールス用のバズワードに使えるかな?
NetflixのChaos Monkey (スコア:1)
「アクティブなアプローチ」の例として、Netflixでは、Chaos Monkeyというツールを作って、常時意図的にシステム障害を起こし続けているそうです。
これは、システム障害が起きてもサービス全体が停止しないようなアプリケーションを開発するように、開発者を条件付けるための仕組みといえます。
銀行の基幹系や航空会社の運航システムのように、部分的な誤りも許容できないシステムでは、いくらか異なるアプローチが必要になろうとは思います。ただ、考え方は使えるかもしれません。
Re: (スコア:0)
昔のホストからそんなことやってるでしょ。
それに今だってサポート期間があって壊れる前に更改してるよね?
Re: (スコア:0)
壊れ方が予想がつかないとか言っておきながら
弱いところから異常が起きると仮定しているところが草
Re: (スコア:0)
システムのどの部分がどう壊れるのか予想がつかないんだから、
今回もやったように、アナログ運用でも回せるように準備して
おくのが、一番臨機応変に対応できるよね。
Re: (スコア:0)
今回の様に、故障が広範囲に及ぶまで耐えるシステムより、
小刻みに不具合を出すけど、全体のダウンタイムは小さく抑える
システムがこれから有効なんではないか、と。
客:は? 何いってんの? 不具合でないシステムを作れよ。
Re: (スコア:0)
> 客:は? 何いってんの? 不具合でないシステムを作れよ。
1台だけで運用するってことになる。
こんなこという客はお断りですね。