常に使用されているサイトでメンテナンスを実行する方法についてのアイデアはありますか？

オーストラリアの大規模なゲームサイトを手伝います。現地時間の午前7時から翌日の午前1時まで、毎日毎日コンテストを開催しています。サイトがリリースされてから1日もスキップしていません。当然、これによりメンテナンスの実行が非常に難しくなり、ステージングサーバーが本番ブランチよりも最大50コミット先になることがわかります。通常、メインの開発者は、ブランチをマージしてすべてが正常に機能することを確認するために、非常に早く起動する必要があります。

ステージングサイトはできる限り本番サイトと同じようにしようとしてきましたが、できるだけ同じようにすることができます。

私たちのサイトは、リアルタイムのNode.JSサーバーを備えたLaravelに基づいています。Laravel Forgeを使用しています。

更新をより頻繁にプッシュする方法について提案はありますか？私たちは何に対してもオープンです。

展開プロセスを改善するためにできることはたくさんあります。それらのいくつかは次のとおりです。

• コードが十分にテストされていることを確認してください。

  理想的には、100％の単体テストの範囲と、考えられるすべてのシナリオの統合テストが必要です。

  これを持っていない場合は、おそらくすべてをドロップし、これを処理する必要があります。

  行動駆動型開発を調べてください。

  完全なテストスイートがあると、次のことが可能になります。

• 継続的インテグレーションを実行します。

  誰かが変更をコミットするたびに、CIはそのテストスイートを自動的に実行できます。テストスイートに合格すると、すぐに展開できます（または展開をスケジュールできます）。データベースの大幅な変更を必要としない変更については、これだけで多くの時間と頭痛の種を節約できます。

  問題が発生した場合、CIを使用してワンクリックでロールバックすることもできます。

  テストスイートが完全で正しくない場合、CIはあまり役に立ちません。前提は、自動化された方法でコードを検証できることにあるからです。

• アトミック更新を行います。

  理想的には、運用サーバー上の古いファイルに新しいファイルをコピーするだけではいけません。代わりに、capistranoなどのツールを使用します。このツールは、すべてのファイルを新しい場所にコピーし、シンボリックリンクを使用して目的の展開をポイントします。ロールバックは、前の展開を指すようにシンボリックリンクを変更するだけなので、瞬時に行われます。（これは必ずしもデータベースの移行をカバーするわけではありません。）

  また、Dockerなどのコンテナーが役立つかどうかも調べてください。

• より小さく、より頻繁に変更を加えます。

  テストがある場合でも、CIがある場合でも、何もない場合でも、これだけでも非常に役立ちます。すべての変更には独自のgitブランチが必要であり、デプロイメントにはできるだけ少ない変更が必要です。変更が小さいため、展開中に問題が発生する可能性が低くなります。

  そのメモで、可能な限り変更をより隔離してください。オマハゲームに変更を加えたが、それがテキサスホールデム、5カードスタッドなどに影響しない場合、メンテナンスのために停止する必要があるゲームはそれだけです。

• 長時間実行されているものを分析します。

  デプロイメントの一部に時間がかかると述べました。これはおそらくデータベーススキーマの変更です。DBAが各スキーマの変更とともにデータベースを調べて、パフォーマンスが向上するものを確認する価値があります。

  主題の専門家に、大規模な時間を要する展開の他の部分を見てもらいます。

• 奇数時間働きます。

  すでにこれを行っているかもしれませんが、言及する必要があります。開発者（およびシステム管理者！）は、「24時間365日の操作」の場合は特に、「9〜5」で動作することを期待されるべきではありません。誰かが展開をベビーシッターで過ごし、問題を修正してから、昼間のスケジュールを守ると予想される場合、あなたの期待は現実的ではなく、あなたはその人を燃え尽きようとしています。

あなたが言っていることから、毎日午前1時から午前7時までのメンテナンス時間帯があり、問題は時間ではなく利便性です。これは正常な動作であり、多くの人がビジネスの一部としてそれを扱っています。

現在稼働している方にトラフィックを転送するフロントエンドを持つ2つ（またはそれ以上のバックエンド）システムを使用できます。リリースが機能することに満足したら、フロントエンドに新しいシステムに切り替えるように指示します。これは簡単にスクリプトを作成するのに時間がかかります。

これで、古いシステムをそのままにして、バックアウトできるようにするか、次のアップデートをビルド/テストするまでライブシステムのスペアとして使用できるように最新の状態にするかを選択できます。

他の回答の修正：青緑展開モデルに従う必要があります。新しいバージョンをリリースする場合は、内部ステージングWebサイトに展開します。その後、次のバージョンの本番サイトで自動テストを実行できます。テストが完了すると、新しいWebサイトを使用するようにロードバランサーを指定します。

これは次の方法で役立ちます。

1. 深刻な問題は、常にダウンタイムなしで見つかります。
2. 新しいバージョンはすでに開始されてウォームアップされているため、新しいバージョンに切り替えるとダウンタイムはまったくゼロになります。
3. 古いバージョンはまだ物理的に実行されているため、いつでも古いバージョンに切り替えることができます。

あなたや他の人が言及した他の問題はすべて、ストレスのない方法でいつでも展開できる場合、それほど深刻ではなくなります。青緑の展開モデルは、展開の問題に対する非常に完全なソリューションです。

すべてのデータセンターで時々発生するメインのデータセンターが停止した場合はどうしますか？ダウンタイムを受け入れるか、別のデータセンターにフェールオーバーするか、常に複数のデータセンターでアクティブ/アクティブモードで実行している、または他の計画がある可能性があります。どちらの場合でも、リリース時に実行してください。そうすれば、リリース中にメインのデータセンターを停止できます。データセンターが停止したときにダウンタイムが発生する準備ができている場合は、ダウンタイムが発生する準備ができているので、リリース中に問題になることはありません。

前の回答に追加するには：

• ロールバックとインスタントスイッチングを可能にする展開戦略を使用してください。Capistranoまたは他のほとんどの展開システムがこれに役立ちます。データベーススナップショットやコードシンボリックリンクなどを使用して、以前の状態にすばやく戻すことができます。

• 完全な構成管理を使用し、手動で管理されるものを残さないでください。SaltStack、Ansible、Puppetなどのシステムがその例です。これらは、Dockerコンテナー構成とvagrantボックスにも適用できます。

• HAを使用して、ノードをアップグレードするときに要求をハンドオフできるようにします。アップグレードが失敗した場合は、単にノードを停止し、ロールバックされたら、それを元に戻すと、HAソリューションはそのノードにリクエストを通知してプッシュします。HAProxyは例ですが、nginxも同様に機能します。

• アプリケーションが、キャッシュなどのディスクに保存する必要がある非コードデータの中央バージョン管理されたデータリポジトリを使用して、同時インスタンスを処理できることを確認します。このように、アップグレードされたアプリケーションを実行して、異なるバージョンのファイルをキャッシュすることはありません。これは、キャッシュのパージとキャッシュウォームアップの実行に加えて行われます。（キャッシングは単なる例です）

通常、チームマネージャーが通常のすべてのCIを行う特別なブランチへのマージリクエストを承認できるワークフローを設定しますが、追加の最後のステップとして実稼働ノードへのプッシュを開始します。基本的に行うことは、実稼働インスタンスへの手動CIデプロイの実行です。そのインスタンスが無効な応答を生成したり、中断したり、データに対して奇妙なことをしたりしない場合は、選択したCIソリューションを使用してすべてのノードを一括アップグレードします。このように、1つの展開が機能する場合、すべての展開が特定のタグ/コミットに対して機能することがわかります。

現時点では、1つの展開プロセス、1つのソース、1つのターゲットで、1つのノードで本番アプリケーションを実行しているように聞こえます。これは実際には、そのワークフローのすべてのステップが、それ自体でWebサイトを破壊する可能性のある障害点であることを意味します。そのようなことが起こらないようにすることが、すべてのCI、HA、およびフェールオーバープロセスの基本です。1つのノードだけを実行しないでください。1つのHAプロセスを実行しないでください。1つのIPアドレスで実行しないでください。1つのCDNだけを実行しないでください。独自の接続を備えたサーバー上のラックでは、通常、ビジネスサイトでのダウンタイムは1時間未満です。

私は、マイケルのすべてのポイント（/server//a/739449/309477）について、マイケルにグローバルに同意します。

私の意見では、最初にすべき改善点は、展開ツール（Capistrano）の使用です。

これにより、平和的に展開し、すぐに新しいバージョンに切り替えることができます。何か問題が発生した場合、現在のシンボリックリンクを作業バージョンに変更するだけで、すぐに作業バージョンに切り替えることができます。

また、Capistranoは最初の処理が非常に高速です（テストとCIの使用を開始するのに比べると、時間の投資が大きくなります）。

第二に、お金が主な問題ではない場合、本番環境にデプロイする前にアプリをテストするiso-prod開発サーバーが必要です。VPSインスタンスを管理するには、産業用ソリューション（Ansible、Chef、Puppet）を使用します。