私は主にクライアントのバックアップと復旧計画を設計する必要がありますが、もう 1 つの義務は、システム アーキテクチャを変更することになるフェイルオーバーと負荷分散に関してシステムを信頼できるものにすることです。
私は主に、システムをリファクタリングした後にバックアップおよびリカバリ計画を適用するように設計する方がよいと考えています。つまり、リファクタリング後にバックアップおよびリカバリ計画をすぐに設計することです。
事前にそうすると、大きな頭痛の種になると思います。
DR 計画を適用する前に、クライアントにシステムのリファクタリングを提案するのは良い考えだと思いますか?
そうしますか？
ありがとう
あなたの説明によると、既存のアプリケーションのリファクタリングが必要な理由は、機能要件に基づいて構築され、負荷分散と可用性の側面が無視されたためです。これらは最初のアプリケーション設計では考慮されていなかったため、アプリケーションを再設計する必要があります。アプリケーション設計に対する HA と負荷分散のさまざまな影響は、クライアントが設計されていないアプリケーションに対してそれらを実装しようとし始めるまで、問題になりませんでした。
あなたが提案しているのは、災害復旧の側面を考慮せずに新しいアプリケーションの再設計を行うことです。これは、最初の実装時に犯した間違いとまったく同じですが、今回のみ無視された要件は DR の側面です。DR 設計に到達し、新たにリファクタリングされたアプリに、DR 設計と競合する予期しない機能のギャップや欠陥があることに気付いた場合、どうしますか?
この割り当てのコードに触れる前に、クライアントの回復要件を十分に理解し、これらを念頭に置いてアプリケーションを設計する必要があります。目標復旧時間、目標復旧時点、アプリケーションがアップストリームまたはダウンストリーム アプリケーションとその状態を調整する方法 (および調整が手動か自動か)、ホット/ウォーム/コールド DR サイトのライセンスの影響を把握する必要があります。など。そうしないと、不当なリスクが発生し、後で大幅なやり直しが発生する可能性があります。