3

高可用性とディザスタリカバリに関してJavaアプリケーションの最悪の慣行を監査する必要がある場合は、ハードコードされたIPアドレスとバインドハンドルの最適ではないキャッシングを探すことになるでしょう。他に何を考慮する必要がありますか？

4

6 に答える 6

5

アクション/状態のログ記録の欠如。

Java アプリケーションは、クラッシュしたときの場所から再開できる必要があります。
つまり、すでに実行したことを記録できるメカニズムが必要です (次の実行時にすべてをやり直さないようにするため)。

これはまた、そのような Java プログラムは、同じ一連のアクションの後、常に同じ状態に到達する必要があることも意味します。(何かを 2 回実行しても同じ結果になるため、既に実行されたアクションは再度実行されるべきではなく、単純にスキップされます)

そのレコードはさまざまな形式 (ファイル、データベース、ある種のリポジトリ内のメタデータなど) をとることができますが、ポイントは、可能な限り迅速に回復しようとする Java アプリケーションは、それが既に行ったことを認識している必要があるということです。

于 2009-05-01T23:15:47.463 に答える
3

監視施設の欠如。遅かれ早かれ、すべてのアプリケーションが失敗します。それが起こったとき、あなたは他の誰よりも先にそれについて知りたいでしょう。

于 2009-05-01T22:30:46.433 に答える
3

ロギングの欠如。アプリを殺した原因が見つからない場合、それを修正するのは非常に困難です。これは、再現が難しいケースが発生する非常に断続的な障害がある場合に特に厄介です。

于 2009-05-01T22:33:07.597 に答える
3

適切な監視については既に述べたので、緊急時対応計画を立てることを付け加えておきます。それは、次のような単純なことです。これが発生した場合はこれを実行し、別のことが発生した場合はこれを実行します。その後、問題が発生したときに、全員をパニックに陥らせて迅速な決定を下すのではなく、(以前にテストした) 計画に従うだけです。

于 2009-05-01T23:38:33.213 に答える
1

ご覧のとおり、お問い合わせの内容にはいくつかの重要な側面があります。言語固有のものではないと思います。例として Java アプリを使用したので、特に Java について話さなくてもかまいません。

Failover/HA : ここで、SPoF (単一障害点) を識別します。例には、あなたが言及したようにハードコードされたアドレスが含まれますが、ローカルディスクなどの複製不可能な方法でデータを保存するアプリケーションも含まれます。その他の項目は、「長すぎる」ための DNS ルックアップのキャッシュ、切断された接続の再確立ではなく、特定のハードウェア情報 (MAC アドレス、CPUID、ドングル、パーティション ラベル、MB またはドライブのシリアル番号など) の検索である可能性があります。これらはすべて、BCP/DR を機能させるための不要な回避策につながる問題であると認識しています。

データの整合性: データはどのように保存されますか? カスタム形式/構造を使用していますか? もしそうなら、「ダンプと復元」メカニズムはありますか? サービスはクライアントへのサービスを停止する必要がありますか、それともバックアップを行うためにサービスを低下させますか? デバイスに非同期でデータを書き込みますか?また、そうであれば、どのくらいの頻度でディスクに「フラッシュ」されますか (これはアプリ次第である場合もあれば、そうでない場合もあります) ファイルのロック、メモリから永続的なストレージへの時間枠、および機能もこれに含まれます。

基本的に、回避しなければならない原因を調べてください。次に、それがどのように発生したかを見てください。おそらく、BCP/DR を改善するために使用するパターンと、問題を引き起こすアンチパターンという 2 つの重要な知識を身につけ始めるでしょう。この種の質問を可能な限り早く開発プロセスに投入することで、開発者は探しているパターンとアンチパターンを導き出すことができます。多くの場合、質問をするだけで問題を回避できます。

于 2010-07-12T19:09:39.397 に答える
0

最善の方法は、ダウンタイムをスケジュールしてテストすることです。これを行うと、さらに多くの問題が見つかります。すべてを文書化したら、あなたの助けなしに他の人にそれをやってもらいます。;)

于 2009-05-02T08:19:13.087 に答える