「カオスモンキー」を実装し、効果的に対応する例はありますか？

Jeff Atwoodは最近、Netflixの「Chaos Monkey」の実装に関するブログ投稿を書きました。非常に高レベルの記事です。システムをテストするためにこの手法を実際に実装した人がいるかどうかは興味があります。

私が本当に求めていることは、システムがクラッシュする部分をアーキテクチャが生き残ることができるようにするために、どのような戦略を実装していますか？

分離と正常な劣化が一般的な戦略です。（別の用語は分離に似ていると思われるかもしれませんが、私はOOD / Pなどの小規模でそれを見る傾向がありますが、概念は同じです。）

システムのさまざまな部分を相互に分離するため、一方がダウンしても、他の部分は引き続き要求に応答できます。同様Netflixのブログと検索はまだ大丈夫だと思うストリーミング、働いていなかった場合は、。これは、一方のボトルネックまたは無能力化が他方に影響を与えないほど十分に分離された検索とストリーミングを意味します。

グレースフルデグラデーションでは、何かの最適な実装が利用できない場合、他に何かを記入する必要があります。Netflixの投稿から再び、彼らはあなたが見て、好きなものを見てから、見るもの。そのシステムがダウンしている場合、全体的に人気のあるものの推奨を表示することにフォールバックします。ポイントは、何もエラーを表示するのではなく、プランAが失敗したときに何かを実行または表示するプランB、プランCなどを用意することです。

実装が一般的であるかどうかにかかわらず、クライアント側での正常な劣化の一般的な例の1つは、WebサイトでのJavaScriptの使用です。ブラウザのjavascriptが無効になっているか、単に使用できない場合でも、サイトのページはそれなしで正常に動作するはずです。それほど高速でも滑らかでもないかもしれませんが、使用できなくなるのではなく動作するはずです。

ただし、これらは非常に一般的なアイデアです。ほぼすべてのプロジェクトは、提供するサービスとサブシステム、およびそれらの間の依存関係に応じて、それらを異なる方法で実装します。