高可用性と災害時回復ソフトウェアのアンチパターン

Question

高可用性と惨事復旧に関して最悪の場合にJavaアプリケーションを監査する必要がある場合は、ハードコードされたIPアドレスとバインドハンドルの最適化キャッシュを探します。他に何を考慮する必要がありますか？

Answer 1

アクション/ステートロギングの不足。

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

つまり、このようなJavaプログラムは、と同じアクションの後も常に同じ状態を達成する必要があります。 （何かを2回行うと同じ結果が得られ、すでに実行されたアクションはもう一度やり直すべきではなく、単純にスキップします）

このレコードは、ソートのリポジトリ内のファイル、データベース、メタデータ。）しかし、要点は：できるだけ早く回復するJavaアプリケーションは、すでに行ったことを知っている必要があります。

Answer 2

モニタリング機能の不足。遅かれ早かれ、すべてのアプリケーションが失敗します。それが起こると、他の誰よりも前にそれについて知りたいでしょう。

Answer 3

ロギングの不足。あなたのアプリを殺したものが見つからなければ、それを修正するのは本当に難しいです。これは非常に断続的な障害が発生した場合に特に困っています。

Answer 4

適切な監視が既に述べられているので、私は不測の事態が発生した場合の計画を追加します。それは次のような単純なものになります。もしこのようなことが起きれば、私たちはこれを行います。それから、問題が発生したときに、誰もが慌てて迅速に意思決定をするのではなく、（以前にテストした）プランに従ってください。

Answer 5

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

Answer 6

私はそれを見ると、あなたが尋ねていることにいくつかの重要な側面があります。私はそれが言語特有ではないと思っています。あなたはJavaアプリケーションを例として使用しました。私はあなたがJavaについて特に話していないことを願っています。

フェイルオーバー/ HA： ここでは、SPoF（Single Points of Failure）を特定します。例としては、上記のハードコードされたアドレスだけでなく、ローカルディスクなどの複製不可能な手段でデータを格納するアプリケーションもあります。他の項目は、切断された接続を再確立せず、特定のハードウェア情報（MACアドレス、CPUID、ドングル、パーティションラベル、MBまたはドライブのシリアル番号など）を検索する、「長すぎる」ためのDNSルックアップをキャッシュしている可能性があります。私はこれらのすべてをBCP/DR機能を得るための不必要な回避策につながる問題として見てきました。

データ整合性： データはどのように格納されていますか？カスタムフォーマット/構造を使用していますか？もしそうなら、「ダンプと復元」の仕組みがありますか？サービスはクライアントのサービスを停止する必要がありますか、またはバックアップを行うサービスが低下しますか？それはデバイスにデータを非同期で書き込みますか？そうであれば、それはどれくらいの頻度でディスクに書き込まれますか（時にはこれはアプリケーションに依存するのでしょうか？ファイルロック、メモリから永続的なストレージのタイムフレームと機能もこれの一部です。

本質的には、何を回避する必要があるのか​​を見てください。それでは、どのようになっているのかを見てみましょう。おそらく、BCP/DRを改善するためのパターンと、言及したように、問題を引き起こすアンチパターンという2つの重要な知識を開発することになります。これらのタイプの質問を開発プロセスに注入することは、可能な限り速やかに、開発者があなたが探しているパターンや反パターンを導き出すのに役立ちます。多くの場合、質問するだけでその問題を防ぐことができます。