14

私はこのトピックについて無知なので、この質問に客観的な答えがあるかどうかさえわかりません。「ない」という結果になった場合は、投稿を削除するか、投稿を閉じるために投票します。

シナリオは次のとおりです。ちょっとした Web サービスを書きました。それは私のマシンで動作します。私のチームリーダーのマシンで動作します。私の知る限り、運用サーバーを除くすべてのマシンで動作します。運用サーバーが障害時に吐き出す例外は、サードパーティの JAR ファイルに由来し、情報が不足しています。Web を何時間も検索しますが、役立つ情報が見つかりません。

では、本番マシンでのみ発生する問題を追跡する手順は何ですか? このための標準的な方法論、またはおそらくツールのカテゴリ/ファミリーはありますか?

この質問に影響を与えたエラーは既に修正されていますが、それはデバッグへの堅実なアプローチよりもむしろ幸運によるものでした。今後の参考のためにこの質問をしています。

編集:これまでのところ、これに対する答えは、 logging
という 1 つの単語に要約されているようです。ロギングに関する 1 つの問題は、事前の考慮が必要なことです。ロギングが不十分な既存のシステムで状況が発生した場合、またはクライアントが機密データについて心配していて、そもそもシステムに広範なロギングシステムを望んでいない場合はどうなりますか?

関連する質問:
本番システムでアカウントと製品を
テストする 本番コード/サーバーでテストを実行する

4

7 に答える 7

10

非常に貴重なロギングに加えて、私自身と同僚が何年にもわたって使用してきた他のテクニックをいくつか紹介します...アクセスできなかったクライアントマシンの16ビットウィンドウに戻ります. （私は自分自身とデートしましたか？） 確かに、すべてがうまくいくわけではありません。

  • 目にするすべての行動を分析します。
  • 再現、可能であれば、それを再現します。
  • 机上でチェックし、疑わしいコードを確認してください。
  • チームメンバーと、コードにほとんどまたはまったく精通していない人々との間で、ラバーダックを行います。誰かに何かを説明しなければならないほど、何かを明らかにする可能性が高くなります。
  • イライラしないでください。5～10分の休憩を取ります。建物/通り/何でも横切って素早く歩いてください。その時はその問題について考えないでください。
  • あなたの本能に耳を傾けてください。
于 2010-06-10T15:54:54.873 に答える
7

これは、最も困難なデバッグ シナリオの 1 つです。答えは、生産システムの詳細に依存します。それはあなたが完全に制御できるシステムですか？それとも、クライアントのマシンにインストールされていて、ログ ファイルにアクセスしたり、構成パラメーターを変更したりするためだけに、何度も電話をかけなければならないのでしょうか?

これをデバッグする最も効果的な方法はロギングを使用することであることにほとんどの人が同意すると思います。積極的に行動し、できるだけ多くのログ情報を追加する必要があります。ただし、必要に応じてロギングを有効または無効にできる必要があります。実稼働システムの広範なデバッグ ログにより、パフォーマンスが低下する可能性があります。同じ理由で、ログの特定の部分のみを有効にする必要があります。ログ出力の論理グループを作成し、最も関連性の高い情報が得られると思われるものだけを有効にします。

于 2010-06-10T14:47:28.480 に答える
2

まず、本番環境とテスト環境の小さな、簡単に確認できる違いから始めます。実際のテストを通じて、権限、ファイアウォール、異なるバージョンなどの明らかなものを排除します。手を抜いて、ああ、それはあり得ないと言ったことは一度だけです。

次に、可能性とコストによって、より高価なテストに優先順位を付けます。クリエイティブに。あなたが見ている行動を引き起こすかもしれない本当に奇妙なことを考えてください。

于 2010-06-10T15:56:21.560 に答える
1

通常、「デバッグ」[つまり、プロセスにアタッチして実行を検査する] は実行できません。多くの理由から、データの機密性が重要です [たとえば、開発者は、操作するデータを検査する資格を\持っていることはめったにありません]。

したがって、これは通常、二次的なソースとアーティファクトから実行を推測することになります。これは、要約すると...

  • ロギング、
  • ロギング、
  • ロギング、

最近作成されたソフトウェアの大部分は、Java または .Net キャンプのいずれかに該当するため、log4j と log4net をそれぞれ活用します。

また、防弾の Ops 中心の構成ガイドと検証プロセスも役立ちます。ハードウェアと環境の責任者は、ホストしているアプリケーションの構成要件をほとんど理解していないことに注意してください。

于 2010-06-10T14:54:15.640 に答える
0

私は、Log4J などの構成可能なログ システムを使用して、運用環境で何が起こっているかを確認しました。これは、開発者が有用なデバッグ情報をログに記録したことを前提としています。

ただし、ロギングによって機密性の高いプライベート データが公開される可能性があることに注意してください。これらのデータは、可能な場合はエンコードおよび/またはスキップする必要があります。

于 2010-06-10T14:49:53.420 に答える
0

ロギングに加えて、他の手法には、後で独自の「同一の」システムにフィードできる要求データの保存が含まれます。これは、後で分析するために、受信したすべての HTTP 要求をファイルに保存するのと同じくらい簡単です。現在、この情報 (特に GET の URL) の多くをログに記録している可能性があります。必要なのは、ヘッダーと要求本文をミックスに追加することだけです。

エラーメッセージに詳細を追加することも便利です。たとえば、ルーチンから例外を受け取った場合、その呼び出しで使用されたパラメーターを Exception エラーに追加できます。または、少なくともグローバルな状態情報 (誰がログインしているか、どの高レベル モジュールにいるか、どの高レベル関数を呼び出しているかなど)。

于 2010-06-10T14:54:33.830 に答える