1

カオス エンジニアリングの手法は、非常に広く使用されるようになっています。一般的な例の 1 つは、Netflix のChaos Monkeyです。ただし、Chaos Monkey はランダムなターゲットに対してアドホックに実行されることがよくあります。特定のサービスの回復力を強化するために、一般的なCI/CD パイプラインでカオス実験がどのように機能するのか興味があります。

  • カオス実験は (通常) 完全に機能する環境を必要とするため、いつ実行するのでしょうか? テストと並行して実行しますか、それともダウンストリームで実行しますか?
  • すべてのコミットでカオス実験を実行しますか、それともいくつかのコミットでのみ実行しますか?
  • カオス実験を実行できる時間はどれくらいですか? たとえば、60 分間の CPU スパイクは、「フェイル ファスト」アプローチを妨げる可能性があります。
  • カオス実験でパイプラインが失敗することはありますか? 「失敗」とはどのようなものでしょうか？
4

1 に答える 1

1

私たちはカオス エンジニアリングの取り組みを始めたばかりですが、あなたの質問についていくつか考えを述べさせていただきます。

実験には、少なくとも 3 つの異なるクラスがあります。

  • 基盤となるインフラストラクチャが自動的に処理すると予想されるインスタンス/コンテナの強制終了。
  • 低速または利用できない依存関係など、高レベルだがかなり局所的な障害。
  • データセンターやリージョンのダウンなどの大規模な障害。

ビルド パイプラインの場合、通常はソフトウェア自体が障害に対応する役割を果たしているため、スイート スポットはその中間 (つまり、高レベルだが局所的な障害) になります。たとえば、ソフトウェアには、トリップ、スロットリング、自動フェールオーバーなどのサーキット ブレーカーが含まれている場合があります。それらがソフトウェア機能である場合、機能する場合と機能しない場合があり、ビルドによってそれが明らかになるはずです。

障害に対する回復力がシステム要件である限り、そうです、失敗した実験はパイプラインに失敗します。たとえば、ビルド 392 には正しく機能するサーキット ブレーカーがあり、ビルド 393 にはないとします。ビルドが要件を満たしていない状態になるため、これは失敗です。

于 2017-05-05T20:37:10.397 に答える