debugging - 本番環境でのみ発生するバグを解決するためのさまざまな方法論

Question

サポートおよびバグ修正環境全体に比較的慣れていない若いプログラマーである私は、今日まで、Websphere 環境でのみ発生し、ローカルホスト テスト環境では発生しないバグに遭遇したことはありませんでした。このバグ レポートを最初に受け取ったとき、ローカルホストのテスト環境で再現できなかった理由がわかりませんでした。何が起こるかを確認するために Websphere のテスト環境を試してみることにしましたが、問題なくバグを再現することができました。問題は、Websphere テスト環境を変更してビルドできないことです。変更できるのはローカル環境のみです。このハンディキャップを考えると、この種のバグを解決するためにどのような方法論が存在するのでしょうか。それとも、方法論はまったくありますか？このような問題にアプローチする方法に関するアドバイスやヘルプはありますか?

Answer 1

• テスト環境へのフル アクセスのキャンペーン。微調整、再デプロイ、再試行ができると、大きな違いが生まれます。アクセスできないと、仕事をする能力が大幅に制限されることを説明するのは完全に合理的です。
• 十分なログがあることを確認し、構成可能にします。数日前に発生した問題であっても、顧客から報告された問題を突き止めるのに十分な期間、ログを保持してください。
• 最終的に問題を診断し、なぜそれが特定の環境でのみ発生するのかを診断したら、それを文書化し、ローカル システムが同じように動作するように説得してください。これにより、次回同じ問題の別の症状を診断しやすくなります。

Answer 2

要するに、方法論は、環境間の違いと、どの環境が問題を引き起こしている可能性があるかを分離して理解することです。

1. ローカル ビルドを確認します。Test および Prod と同じバージョン (コードとデータベース) であることを確認してください。もしそうなら、あなたが見ている問題に影響を与える可能性のある環境の違いは何ですか? (マルチコア、負荷分散、オペレーティング システムのバージョン、第 3 ライブラリのバージョン)。デバッガーでローカルに実行しないでください。リリース ビルドを実行していることを確認し (それが Test および Prod にある場合)、ソースからビルドするのではなく、ローカルでデプロイすることもできます。

2. 特定のデータが問題の原因であるかどうかを確認してください。可能であれば、データベースのコピーを Test から Local にプルして、問題を再現できるかどうかを確認してください。

3. 他の開発者に確認してください。彼らが再現できるかどうかを確認してください。彼らの環境の問題。QA 担当者に確認し、そのような問題の原因について考えてもらいます (多くの場合、彼らは「同様の」問題を見て、手がかりを与えてくれる可能性があります)。

その時点で、何も役に立たない場合、私は通常、禅の深い状態に入り、自分が欠けているものを理解しようとします. しかし、違いがあるはずです。それを見つけなければなりません。

Answer 3

科学的方法は常に適用されます。最初に仮定を確認してください。システムが異なる場合、問題はある種の暗黙のデフォルトの違い、または何らかの機能の異なる実装にある可能性があります。

すべてのデバッグ プロセスにおいて、ローカリゼーションが重要です。まず、問題の領域を特定する必要があります。OS、パッチ、ライブラリ、およびメイン ソフトウェア自体がすべて同一である場合、それはおそらくシステム設定 (ソケット、ファイル記述子などの制限) です。十分な i ノード、スペース、およびメモリが残っていることがわかっている場合、それはリソースの問題ではありません。コンピューターがインタラクティブな指示に対してほとんど応答しない場合は、負荷が高すぎるか、暴走プロセスが発生しています。すべてのプロセスを実行するために必要なものを覚えておいて、必要なものが確実に得られるようにします。

コードが本番システムの負荷を処理できない場合もあります。ロック メカニズムは、本番システムと開発/テスト システムでの問題の非常に一般的な原因です。これは、本番環境では無料で入手できる十分な数のテスト ケースを生成できないという単純な理由からです。

ロギングは見過ごされがちですが、デバッグを容易にするために、多くのデバッグ値をコードに追加することも好きです。環境変数、パス、壊れたシンボリック リンクが原因で 1 日が台無しになった回数を数えることさえできません。ただ、静的コードだけを見るのではなく、実行中に変数の値を見れば、簡単な修正で済みます。

他のすべてが失敗した場合は、ltrace内部straceで何が起こっているかを実際に確認するための最良の方法です. 読むのは簡単ではありませんが、一部のシステムコールの戻り値を見つけて解釈する方法に慣れると、非常に強力なデバッグ ツールが手に入ります。