4

良いが少し複雑な製品があるとしましょう。製品はワイルドになりました。顧客は中規模および比較的大規模な企業です。顧客の官僚主義のレベルは非常に高いです。

  • 多くの異なる役割と責任
  • 保護された環境
  • 数十のルールとポリシー
  • 高度に専門化されたエンジニア (DB-guy はある部署に所属し、tomcat-guy は別の部署に所属するなど)

このようなアプローチでは、些細な操作 (再起動とアプリ、ログの取得など) でさえ、数時間または数日かかる場合があります。ログへのアクセスを制限するか、完全に禁止することができます。前に述べたように、製品は複雑であるため、展開および初期構成段階で問題が発生する可能性があります。これは、顧客がサポート チームからの支援と支援を必要とすることを意味します。

ここに画像の説明を入力

問題は、エンド ユーザーが通常 R&D 部門に属しており、アプリケーション、アプリケーション ログ、データベースなどにアクセスできないことです。つまり、エンド ユーザーは貴重な情報をまったく提供できません。利用可能なフィードバックはスクリーンショットのみです。

この問題の良い解決策を知っている人はいますか?

アイデアは、顧客を満足させ、サポートチームをオフロードし、あらゆる要求に迅速に対応することです. また、センシティブ情報などに関してはいくつかのルールがありますのでご注意ください。

アプリケーションがエラーを処理する方法がいくつか考えられます。

  • サニタイズされた例外またはエラー コードを提供する「詳細」オプションを使用して、高レベルの問題情報を提示します。
  • 同じことを行いますが、いくつかの追加情報を収集し、ログに記録し、暗号化し、ユーザーがファイルをダウンロードできるようにします
  • ログと追加のシステム情報にアクセスできる非表示の「サービス」画面を提供する
  • 初期段階で使用されるデバッグモードのようなものを導入する
  • 最後に、ログへの永続的なアクセスを要求できます (個人的には、これは安全でない解決策だと思います)。

これらのオプションはすべて、使いやすさとセキュリティの観点からあまり良くありません。

そのような状況であなたはどうしますか？

4

3 に答える 3

3

あなたが考えていることのいくつかを読むことによって、具体的には：

  • 「詳細」オプションを使用して高レベルの問題情報を提示し、
  • サニタイズされた例外またはエラーコードを提供することは同じことを行いますが、
  • いくつかの追加情報を収集し、ログに記録し、それを暗号化し、ユーザーがファイルをダウンロードできるようにする ログと追加のシステム情報にアクセスできる非表示の「サービス」画面を提供する

それを組み合わせて「より安全」にするのはどうですか？

エラー/例外が一種の「フォルト チケット」も作成するようにコードを変更し (できるだけ多くの余分な情報を保存します)、ユーザーには表示されないようにします。ユーザーは「チケット番号」を取得します (サポートに送信されるメールに手動でコピーする必要があります。または、可能であれば、エラー メッセージによって Web ページまたはパネルが自動的に作成され、ユーザーがチケットから何が起こったかの説明を追加できるようになります)。視点、スクリーンショットなど）。

このようにして、サポートはコンテキスト化されたより豊富な詳細にアクセスできるようになります (これらをユーザーに公開することなく、分析したり、メンテナンス グループに転送したりできます)。私は内部構造とグローバル アーキテクチャについて十分に知らないので、これを実装するのがどれほど複雑になるかは判断できません。理想的には、ログが正しい参照を持つように、すべての操作に「障害チケット」が自動的に割り当てられる必要がありますが、チケット番号は例外の場合にのみ「公開」されます。

于 2013-01-07T08:16:50.667 に答える
1

要約して詳細を提供するだけです。

エラーが発生した場合、間違いなくユーザーに通知する必要があります。通知は、問題に関する高レベルの情報を提供する必要があります。問題を説明するだけでなく、何らかの解決策または回避策 (利用可能な場合) を提供することをお勧めします。

エラー ダイアログは、問題に関する詳細情報を取得する方法も提供する必要があります。

ここに画像の説明を入力

最も簡単な方法は、サニタイズされたスタック トレース、関連するログ メッセージなどを提供することです。ユーザーの一般的なシナリオは、利用可能な詳細を取得し、サポートまたは開発者に通知することです。明らかに、このようなソリューションを使用して必要なすべてのデータを提供することはできません。これは、サイズや機密情報などの理由によるものです。

ここに画像の説明を入力

オプションとして、システムはその情報をサポート/エラー収集ツールに直接送信できます。安全なチャネルを使用してデータを保護できます。必要に応じて、収集ツールが顧客のネットワーク内に存在する可能性があるため、機密情報が外部に流出することはありません。

そのようなオプションが利用できない場合、システムはユーザーが必要なすべての情報を含むアーカイブをダウンロードできるようにします。アーカイブを暗号化して、(問題に直面している) 通常のユーザーが潜在的に機密性の高いデータを調べられないようにすることができます。

ここに画像の説明を入力

当然、ハードコードされたパスワードを使用しない方がよいため、より高度なアプローチを使用できます。シナリオは次のとおりです。

  1. システムがエラー メッセージを表示する
  2. システムはエラー ID を生成し、それを使用して一意の値 (ハッシュ) を生成します。
  3. ユーザーがサポートに連絡し、独自の価値を伝える
  4. サポートはその値を使用してコードを生成します
  5. ユーザーはサポートからコードを受け取ります
  6. ユーザーはすべての詳細を含むアーカイブをダウンロードします (暗号化)
  7. ユーザーはダウンロードした情報をサポートに渡します

ここに画像の説明を入力

偏執的なソリューションのように見えますが、潜在的に機密性の高い情報へのアクセスを制御できます。

最終的な結論

ロギング戦略は十分に開発されている必要があります。機密情報はログに記録しないでください。

便利なリンク

于 2013-01-11T17:10:14.280 に答える
1

柔軟なオンライン「サービスカタログ」で作業中に同様の問題を解決したことがあります。ソリューションは非常に単純でしたが、異種システムでの技術的な実装は複雑でした。

そのような種類のエラー検出と追跡は、主なビジネス ドメインにとって別の分野横断的な関心事であることを指摘しなければなりません。したがって、既存のソース コードを変更せずにこれを適用することができれば、はるかに優れています。

  1. システムでのすべての要求/トランザクション/操作に論理参照または相関ID を導入します。
    • GUIDは完璧です
    • エンド ユーザーはこの ID を参照します
    • スクリーンショットでこの ID をキャプチャするのは簡単なはずです
    • すべての画面のページ タイトルにこの ID が表示されるようにします。
  2. AOP フレームワークを使用して (SO プロファイルによると、AspectJ または Spring AOP を開始するのに適しています)、トレース/ロギングの側面を定義します。アスペクトは、Web アプリケーション/ビジネス ロジック/データ アクセス レイヤーへのすべての呼び出しに関する情報を、関連する参照 ID とともに記録します。
    • 再利用されたログシステムは情報を保持しますが、呼び出しを傍受するには側面を使用します
    • AOP フレームワークを使用している限り、トレース/ロギングが行われる場所、1 か所で収集される詳細を構成できます
    • すべてのトレース/ロギングが 1 か所にカプセル化されているため、構成を使用して簡単に制御できます
    • アスペクトは、電子メールなどを介してすぐにいくつかの問題をエスカレーションするために使用できます。
  3. 最後に、最も複雑な部分に直面します。開発者と運用が情報を無視しないようにする方法は? このような組織の問題は、stackoverflow の範囲外です。最悪の場合、エラーに対応するのに何日もかかる場合、本番環境のコンテキストとログ システムから多くの詳細を取得できます。
于 2013-01-09T12:17:13.750 に答える