5

私は現在サーバーアプリケーションに取り組んでおり、一定レベルのサービスを維持することに同意しています。保証したいサービスのレベルは次のとおりです。サーバーがリクエストを受け入れ、サーバーがクライアントに確認応答を送信した場合、サーバーがクラッシュした場合でも、リクエストが発生することを保証します。リクエストは長時間実行される可能性があり、確認応答時間は短くする必要があるため、リクエストを永続化し、クライアントに確認応答を送信してから、リクエストを実行するためのさまざまなアクションを実行することで、これを実装します。アクションが実行されると、それらも永続化されるため、サーバーは起動時にリクエストの状態を認識します。また、ログの正確性をチェックするための外部システムとのさまざまな調整メカニズムもあります。

これはすべてかなりうまく機能しているように見えますが、フォールトトレラントコードをテストするのは非常に難しいため、確信を持ってこれを言うのは困難です。これまでに2つの戦略を考え出しましたが、どちらも完全に満足のいくものではありません。

  • 外部プロセスにサーバーコードを監視させ、外部プロセスがテストの適切なポイントであると判断した時点でサーバーコードを強制終了します。
  • 特定の既知の重要なポイントをクラッシュさせるアプリケーションのコードを追加します

最初の戦略に関する私の問題は、外部プロセスがアプリケーションの正確な状態を知ることができないため、コード内で最も問題のあるポイントに到達していることを確認できないことです。2番目の戦略に関する私の問題は、フォールトテイクをより細かく制御できますが、オプションのコンパイルなどを使用しても、アプリケーション内にフォールトを挿入するコードが好きではないことです。フォールトを見落とすのは簡単すぎるのではないかと心配しています。注入ポイントとそれを本番環境に滑り込ませます。

4

4 に答える 4

3

これに対処するには 3 つの方法があると思います。可能であれば、依存性注入またはファクトリ オブジェクトを使用してこれらの統合中に壊れたアクションを生成する、これらのさまざまなコードの統合テストの包括的なセットを提案できます。

次に、アプリケーションをランダム kill -9 で実行し、ネットワーク インターフェイスを無効にすることは、これらのことをテストする良い方法かもしれません。

ファイルシステムの障害をテストすることもお勧めします。その方法は OS によって異なります。Solaris または FreeBSD では、ファイルに zfs ファイル システムを作成し、アプリケーションの実行中にそのファイルを rm します。

データベース コードを使用している場合は、データベースの失敗もテストすることをお勧めします。

依存性注入の別の代替手段であり、おそらく私が使用するソリューションはインターセプターです。コードでクラッシュ テスト インターセプターを有効にできます。これらはアプリケーションの状態を認識し、上記の失敗を適切なタイミングで導入します。作成したい場合があります。既存のコードを変更する必要はなく、ラップするためのコードを追加するだけです。

于 2010-05-03T09:26:15.030 に答える
2

最初のポイントに対する考えられる答えは、コードの問題のある部分に影響を与える可能性が高まるように、外部プロセスで実験を増やすことです。その後、コア ダンプ ファイルを分析して、コードが実際にクラッシュした場所を特定できます。

もう 1 つの方法は、ライブラリまたはカーネルの呼び出しをスタブ化することによって、つまりアプリケーション コードを変更せずに、可観測性および/またはコマンド可能性を高めることです。

ウィキペディアのフォールト インジェクションページ、特にソフトウェアで実装されたフォールト インジェクションセクションでいくつかのリソースを見つけることができます。

于 2010-05-03T09:36:21.637 に答える
2

フォールト挿入に関するあなたの懸念は、根本的な懸念ではありません。そのようなコードがデプロイされるのを防ぐための簡単な方法が必要なだけです。これを行う 1 つの方法は、フォールト インジェクターをデバッガーとして設計することです。つまり、障害はプロセスの外部のプロセスによって注入されます。これにより、すでに一定レベルの分離が提供されています。さらに、ほとんどの OS は、特別に有効にしない限り、デバッグを防止するある種のアクセス制御を提供します。最も原始的な形式では、それを に制限することでrootあり、他のオペレーティング システムでは特定の「デバッグ権限」が必要です。当然、本番環境では誰もそれを持っていないため、フォールトインジェクターは本番環境で実行することさえできません。

実際には、フォールト インジェクターは特定のアドレス、つまり関数やコード行にブレークポイントを設定できます。次に、特定のブレークポイントに 3 回到達した後にプロセスを終了するなど、それに対応することができます。

于 2010-05-03T09:52:57.527 に答える
1

私はジャスティンと同じことを書こうとしていました:)

テスト中に置き換えることをお勧めするコンポーネントは、ロギング コンポーネントである可能性があります (ある場合は、実装することを強くお勧めします...)。エラーを生成するコードに置き換えるのは比較的簡単で、通常、ロガーは現在のアプリケーションの状態を知るのに十分な情報を取得します。

また、テスト コードが本番環境に移行しないことを確認することも実行可能であるように思われます。ただし、条件付きコンパイルはお勧めしませんが、構成ファイルを使用してログ コンポーネントを選択します。

「ランダムな」キルを使用すると、エラーを検出するのに役立つ場合がありますが、非決定性があるため、体系的なテストにはあまり適していません。したがって、自動テストには使用しません。

于 2010-05-03T09:37:25.103 に答える