ウェブサーバーファームでのローリングアップデート？
大きなWebサイト（Amazon、Facebook、Yahooなど）は、アップグレードのダウンタイムをスケジュールしません。通常、それらは「ライブ」で行われ、サーバーファーム全体で段階的にロールされます。また、大きなインフラストラクチャとこれを管理するチームもあります。
通常、小規模なWebサイトでは、サイト全体をオフラインにしてデータベース構造を更新し、Webサーバーで実行されているコードをアップグレードします。ダウンタイムはごくわずかですが、それでもお客様の中断につながります。
ダウンタイムなしのローリング更新にどのようにジャンプしましたか？これを実現するための最小要件は何ですか？これを最初から可能にするアプリケーションを構築するにはどうすればよいですか？
これを実現するための最小要件は何ですか？
ロードバランサーの背後に少なくとも2つのサーバーを配置したら、クラスターからサーバーを順番に削除し、更新し、クラスターに追加して更新を完了できます（訪問者が関係している場合を除く）。
これを最初から可能にするアプリケーションを構築するにはどうすればよいですか？
負荷分散要件 を念頭に置いてアプリケーションを設計します。
0ダウンタイムは、「設計はすべてのブラウザでまったく同じに見える必要がある」と同等のWebサーバーです。スケジュールされたダウンタイムは問題ありません。スケジュールを設定して静的な通知を出すだけです。それが実際にあなたにたくさんのヒットやお金をかけない限り、それは小さなウェブサイトとしては定義ではないでしょう。あなたのウェブサイトが「花火火傷治療」または「フランシス・スコット・キーの歌詞」のGoogle検索結果の第1位でない限り、7月4日（または感謝祭などの機会）に誰にも見られたくない場合結構です.
通常、最初からこれを行うと、オーバーエンジニアリングのリスクがはるかに大きくなります。
計画的なダウンタイムには常に何らかの理由がありますが、最小限に抑えることができます。
インフラストラクチャに応じて、さまざまな戦略によりダウンタイムを最小限に抑えることができます。通常の古い更新では、ダウンタイムは必要ありません。
私が管理している多くのPHP駆動型サイトでは、コードベースのサイドバイサイドコピー、バージョン1.0、1.1、および1.2を維持しています。
/sites/site-1-0-0
/sites/site-1-1-0
/sites/site-1-2-0
次に、Webサーバーが使用できるシンボリックリンクを作成します。
/sites/production --> /sites/site-1-1-0
/sites/staging --> /sites/site-1-2-0
このようにして、土壇場での健全性チェックのために本番サーバーでコードをステージングできます。ライブに行きたいときは、次のようにします。
$ rm /sites/production; ln -s /sites/site-1-2-0 /sites/production
WebサーバーはDocumentRoot仕様のシンボリックリンクを使用するため、カットオーバーは実質的に瞬時に行われます。
もちろん、ここには落とし穴があります。外部データが外部のどこかに保存されるようにする必要があります。あなたは一時ファイルを書いたり、site-x-y-zディレクトリの下のファイルシステムにユーザー生成コンテンツを保存したくありません。
別の方法として、複数のサーバーがある場合は、ルーティングを介してカットオーバーを行うことです。一部のVPSベンダー（Linodeが思い浮かぶ）は、2台の仮想マシンを簡単に取り、IPアドレスを交換できるようにします。したがって、新しいサーバーに新しいバージョンをセットアップし、必要なテストを実行してから、IPを交換して更新を展開します。非コード資産を最新の状態に保つことに関する同じ問題が当てはまりますが、いくつかの注意深い思考と計画がそれを非問題にする可能性があります。
より堅牢で負荷分散されたセットアップでは、danlefreeの回答で提案されているような戦略も機能します。