再現性のない/ランダムに発生するバグを修正するにはどうすればよいですか？

数日前にバグが発見された多言語のウェブサイトがあります。他の言語のデータを他の言語で表示し、英語などのデータの混合も選択されていましたが、ページにも他の言語のデータが表示されていました。それはまれですが、ウェブサイトに存在します。これは常に発生するわけではないため、コードを調べても役に立ちません。

問題をタイムリーに見つけるための提案はありますか？ここで戦略を求めています。

最初のステップは、このタイプの問題を引き起こす可能性のあるものを試行し、特徴付けることです。これは、コードのセクションに正しい言語を選択することに関連しているため、次のことを考慮することから始めます。

• 言語はどのように検出されますか？ HTTPリクエストからの情報に基づいていますか？セッション情報に基づいていますか？またはデータベースフィールドに基づいていますか？本質的に、これはアプリが各セクションの言語を選択する方法に関連する問題になりますか？
• 言語はどのように表示されますか？ プロパティファイルまたはデータベースからプルしていますか？正しい言語への参照が何らかの方法で失われている可能性はありますか？表示される混合言語は常にサイトのデフォルトですか？
• クライアント環境と相関関係はありますか？ これは最初の箇条書きに関連していますが、もう少し先に進みます。ダウンストリームキャッシングプロキシが原因で、奇妙なレンダリングの問題が発生しました。通常、これらの種類の問題は、ページ全体が古くなっているか、あるユーザーのページを他のユーザーに提供している（恥ずかしい）ものです。
• スレッドローカル値を使用していますか？ リクエストが複数のスレッドで処理される場合、スレッドローカル値には、その時点で動作しているスレッドに基づいて異なる情報が含まれます。Webサーバー環境では、プラットフォームの仕様の一部である場合を除き、処理を開始したスレッドが処理を完了したスレッドと同じであると想定することはできません。サーバーライターは、スレッドの小さなプールを再利用し、それらをチャンクで多重化すると、より多くの要求を同時に処理できることを発見しました。リクエストの開始から終了まで1つのスレッドがある場合でも、サーバーはそのスレッドに他のリクエストを同時に多重化している可能性があります。スレッドローカルの代わりに、その値を要求またはセッション属性にバインドすることを検討してください。

さて、何がうまくいかない可能性を特定したら、今度は、何がうまくいかなかったかを調べるために必要なデータがあることを確認します。

• 問題のある領域で大量のログを記録します。これは、Log4JやLog4Netのようなツールが本当に輝く場所です。このログフレームワークなどのログフレームワークを使用すると、構成ファイルを変更することで、他のすべてのノイズを抑えながら、特定のカテゴリのログを有効にできます。疑わしいものが問題である可能性があるかどうかを判断するために、新しいロギングステートメントを導入する必要があります。また、HTTPアクセスログに、各リクエストについて必要なすべての情報（Cookie、HTTPヘッダーパラメーターなど）が含まれていることを確認してください。
• 問題をシミュレートしようとします。これは散発的に発生するため、発生時のサーバーの負荷はどのくらいですか？さまざまな言語からの多数の同時リクエストに見舞われていますか？その場合、テスト環境でそのような負荷をシミュレートしてみてください。JMeterに似たツールが必要かもしれません。また、偽のクライアントのIPアドレスをスプーフィングできるようにする必要があります。IPアドレスは、アドレスの最初の2つのセグメントに基づいてIPがどの国/地域であるかを把握できるように分割されていることに注意してください。
• 問題はテスト環境でも散発的に発生しますが、実際の原因に絞り込むと、結果を歪曲して、実際の原因よりも頻繁に発生させることができます。さらに、ログファイルをより簡単に確認して、そこから学習を試みることができます。
• 繰り返しのプロセスなので、我慢してください。バグを再現し、ログを確認し、見つかった内容に基づいてテストを調整することになると思われる種類の負荷を誘導する必要があります。重要なことは、問題を特定することです。そのため、実際の問題の発生頻度を減らすだけの簡単な修正を行う衝動に抵抗してください。

最後に、問題の再現方法と原因を把握できるまで問題を絞り込んだら、コードで問題を強制できる最小の自動テストを作成します。問題を1つのクラスに絞り込んだ場合、またはクラスのペアが正しく機能しない場合は、そのレベルで再現します。100個のスレッドを生成する必要はありません。問題を100％発生させることができる最小のテストを実行するだけです。

今、あなたはそれを修正することができ、それが再びあなたを噛むために戻ってこないことを合理的に確信することができます。

バグは非生産的ではありません。あなたはまだそれを再現する方法を見つけていません。

Random（）ステートメントの戻り値に基づいて例外をスローしない限り、バグはランダムではありません。

これはセマンティクスのように見えるかもしれませんが、自分にこれを伝えることは精神的に安心です。

複雑な競合状態などが原因でのみ発生するバグを再現する方法を見つけることは、非常に困難でイライラします。

それを見つける方法については、より多くの情報を提供できる場所でアプリケーションのロギングをオン/追加します。

次に、バグを見ている人（開発者、QA、エンドユーザー）に、バグが発生した時点ですぐに報告するよう伝え、ログを調べます。他の情報を求めてください。バグはいくつかの異なるシステムの相互作用または競合状態が原因でのみ発生する可能性があります。

うまくいけば、リードを見つけることができるでしょう。

問題が発生したことを認識することができるコード内の場所を見つけて（たとえば、メソッド内の一貫性のないパラメーター）、コードにチェックを追加し、デバッグログに追加情報を追加できます（スタックトレース、オブジェクトなど）セッションへの追加など）

少しの運でこれを行うと、発生に関する情報を取得し、問題に戻る方法を推測できます。

再現が同じ手順で失敗することがある場合は、自動化が役立ち、それを自動化してループに入れる必要があります。50,000回実行すると、発生する可能性が非常に高くなります。

この問題を明示する条件を特定するためのパターンを見つけてください。これは、失敗する（または一貫性のない動作をする）コードのセクションに向けられるはずです。

問題が発生していることを検出できますか？その場合、その時点でのシステムの状態に関する情報を確実にダンプできますか？

これらの質問の両方に対する答えが「はい」である場合、実際にエラーが発生したときにできる限り多くの情報を記録するようにコードをインスツルメントし、待機します。

これは、他の人が提案したものに代わるものではありません（コードが表示されている状態に到達する方法を推論する必要があります）が、バグを自由に再現できない限り、出現する機会を無駄にしないことをお勧めします。