回答:
フェニックスサーバーという用語は、マーティンファウラーの仲間によって作られました。3つの用語はすべて、マーティンのブリキに関する短い記事で説明されています。
このような各サーバーの長所と短所は、記事で説明されています。主な違いは、サーバーの管理方法にあります。
サーバーは、一部のアプリケーションのコンテナの役割を果たすために存在します。アプリケーションは頻繁に変更されるため、多くの場合、パッケージ、構成など、コンテナの一部の属性を変更する必要があります。また、セキュリティ上の脆弱性など、インストールされます。
既存のサーバーを変更するには、いくつかの方法があります。
前者はSnowflakeと呼ばれ、後者はPhoenixおよびImmutableサーバータイプを許可するプラクティスです。Immutableは、既存のサーバーが作成された後は変更が行われないことを示し、Phoenixは、サーバーが完全に破壊され、変更プロセス中に新しいサーバーが使用されることを意味します。
各タイプの長所と短所のリストをもっと考えていたので、ここに私の見解があります（網羅的ではなく、私の意見では重要な運用上のものです）：
スノーフレークサーバー
それらが何であるか：特定の構成を持つシステム、データセンター内の他のサーバーにはまったく同じパラメーターがありません。通常、手動で管理されます。
利点：
欠点：
フェニックスサーバー
利点：
欠点：
不変サーバー
利点：
欠点：
これらのパターンはいずれも排他的ではなく、実際のニーズに応じて最適なパターンを選択する必要があります。雪片は、災害後の復旧の際に多くの懸念をもたらします。そのため、通常、選択はフェニックスとイミュータブルの間で行われます。
3つすべてが種類のパターンです。特定の状況でどちらを使用するかを選択するのではなく、あなたを助けたり傷つけたりする可能性のあるパターンをいつ認識するかを知っている場合です。
A スノーフレークサーバーは非常に制御されないようにケースを表すアンチパターン場合、サーバ進化が容易に再現することができない点にあります。
実稼働中にこの種のサーバーで多数の実行を行ってきましたが、通常、「開発/テスト/ UAT /ステージングで機能した」というような失敗した変更やコメントが多数あるため、それらを見つけるのはかなり簡単です。 「。
A フェニックスServerは、より多くの元本のMartin Fowler氏がそれを置くようなパターンよりも次のとおりです。
サーバーは不死鳥のように、灰から定期的に上昇する必要があります。[a]
ITサービス管理（ITSM）またはITIL言語を同じ状況に適用する場合、ITサービス継続性計画または回復計画と呼ぶことになります。
復旧チームがサービスを復元し、それによって合意されたプロセスとコンポーネントRTOを満たすことができるように、各サービスの個別の計画は、インシデントの各段階の詳細な手順とステップバイステップのガイドラインを提供する必要があります。
アン不変サーバーまたは不変インフラストラクチャは、我々はすなわち不変、全く不変としてデプロイされたすべてのインフラストラクチャ、構成、およびコードを治療するプロセスです。新しいものを展開するときは、新しいインフラストラクチャをスピンアップし、これにコードを展開します。興味深いことに、これはエバーグリーンによって伝統的に満たされたニーズをほとんど満たします。