release-management - ライブで忙しい Web サイトをできるだけ丁寧に更新するにはどうすればよいでしょうか?

Question

ライブ Web サイトに変更を加える場合、ライブシステムが正しく機能していることをどのように確認しますか? どのツールを使用しますか? 誰がそれをしますか？テスト期間中、サイトへのアクセスをブロックしますか? どのくらいのダウンタイムが許容されますか?

score 13 · Accepted Answer

私はすべてのテストを別の環境で行う傾向があります (ライブ環境ではありません!)。これにより、コードが正常に動作することを確認して、更新をライブサイトにプッシュできます。また、ライブデータのサニティテストを行うだけです。どこかにファイルを忘れていないか、何か奇妙な問題が発生していないかを確認します。

したがって、テスト環境またはステージング環境で適切にテストしてから、簡単な健全性チェックを行います。ダウンタイムは必要ありません。

score 7 · Accepted Answer

すでにたくさんの良いアドバイス。

人々が言及したように、単一のポイントが関与していない場合は、一度にアプリサーバーをアップグレードすることで段階的に変更を加えるだけで簡単です。しかし、それはめったにないので、それを無視して難しい部分に焦点を当てましょう.

通常、そこには他のすべてに共通するデータベースがあります。つまり、システム全体のダウンタイムを意味します。それをどのように最小化しますか？

オートメーション。展開手順全体をスクリプト化します。これには (特に) データベーススキーマの変更が含まれます。これには (特に) スキーマのバージョン間で必要なデータ移行が含まれます。

品質管理。テストがあることを確認してください。自動化された受け入れテスト (ビジネスロジック / エクスペリエンスの観点から、ユーザーが見たり期待したりするもの)。読み取り専用アクティビティをテストするスクリプトを作成できる、運用システムにテストアカウントを用意することを検討してください。他の外部システムとやり取りしない場合は、書き込みアクティビティも検討してください。システムの特定の部分で、特にお金や会計を扱う場合は、テストアカウントのアクティビティを除外する必要がある場合があります。Bean が一致しない場合、正当な理由で Bean カウンターが動揺します。

リハーサル。本番環境と可能な限り同一のステージング環境にデプロイします。本番データボリュームと本番データでこれを行います。テーブルの変更にかかる時間を感じる必要があります。また、alter table が構造的に機能することと、実際のデータのすべての外部キーで機能することを確認する必要があります。

大量のデータがある場合、スキーマの変更には時間がかかります。たぶん、あなたがダウンしている余裕がないほどの時間です。1 つの解決策は、段階的なデータ移行を使用することです。これにより、ダウンタイム中にスキーマの変更に「最近」または「現在」(たとえば 1 か月前または 3 か月前) のデータが取り込まれ、残りの 5 年間のデータがその後少しずつ取り込まれます。あなたは再びオンラインです。エンドユーザーにとっては問題ないように見えますが、一部の機能にはさらに数時間/数日/何でもアクセスできません。

score 4 · Accepted Answer

職場では、コードをテスト環境で凍結した状態で一定期間過ごします。その後、数週間の通知の後、金曜日の深夜にサイトを停止し、夜通し展開と検証に取り組み、土曜日の深夜にサイトを立ち上げました。トラフィックの統計から、これが最適な時間枠であることがわかりました。

score 3 · Accepted Answer

私が働いた最後の場所で、QAはQA環境でテストを実行しました。主要な問題は、ロールアウトする前に修正、テスト、および検証されます。

ビルドがQAによって認定された後、本番サポートチームは、クライアントがサイトを確認し、すべてが希望どおりであることを確認するステージング環境にコードをプッシュしました。

実際の本番ロールアウトは、営業時間外（緊急の夜間プッシュの場合は午後9時以降、通常のスケジュールのロールアウトの場合は午前5時から午前8時まで）に発生します。

サイトは複数のサーバーでホストされており、F5ロードバランサーを使用して負荷分散されています。

いくつかのサーバーが本番環境から削除されました。
コードがインストールされ、
サーバーをプールに戻す前に、サーバーに対して大まかなチェックが実行されます。

これは、すべてのサーバーが最新のコードにアップグレードされ、サイトが常に稼働し続けることができるようになるまで繰り返されます。

このプロセスは理想的ですが、データベースもアップグレードする必要がある場合があります。この場合、新しいデータベースがサイトを破壊するかどうかに応じて、2つのオプションがあります。

新しいデータベースが既存のフロントエンドと互換性がない場合は、サイトがダウンしている時間枠を設ける以外に選択肢はありません。

ただし、新しいデータベースが既存のフロントエンドと互換性がある場合でも、実際のダウンタイムなしでコードをプッシュできますが、これには2つの本番データベースサーバーが必要です。

すべてのトラフィックは2番目のDBにルーティングされ、最初のDBサーバーがプルされます。
最初のDBがアップグレードされ、検証が完了したら、本番環境に戻します。
すべてのトラフィックは最初のDBにルーティングされ、2番目のDBがプルされます。
2番目のDBがアップグレードされ、検証が完了したら、本番環境に戻します。
次のステップは、上記のように部分的なアップグレードを実行することです。

要約すると：

ライブWebサイトに変更をロールアウトする場合、ライブシステムが正しく機能していることをどのように確認しますか？ 最良の場合、これは段階的に行われます。
どのツールを使用していますか？自動化ツールを使用して、コードがいくつかの基本的な自動化テストとともに正しくインストールされていることを確認するための手動チェック。SeleniumIDEを使用しました。
誰ですか？ DBAはDBアップグレードを実行し、テクニカルサポート/システム管理者はサーバーをプッシュ/プルしてコードをインストールし、QAまたは本番サポートは手動テストを実行したり自動テストを実行したりします。
テスト期間中、サイトへのアクセスをブロックしますか？可能であれば、特に有料サイトの場合は、Gillesが前述したように、これは絶対に避けてください。
どのくらいのダウンタイムが許容されますか？ダウンタイムは、ユーザーがサイトを使用する可能性が最も低い時間に制限する必要があり、3時間以内に実行する必要があります。
注： 3時間は非常に寛大です。jplindstromが述べたように、練習とリハーサルの後、チームはプロセス全体を停止し、1時間以内に出入りできるようになります。

お役に立てれば！

score 3 · Accepted Answer

負荷分散されたサーバーのセットがある場合は、1 つずつ個別にオフラインにして更新することができます。ユーザーのダウンタイムなし！

score 2 · Accepted Answer

かわいい、武装解除の画像および/またはバックアップページを用意してください。一部のサイトでは、更新を待っている間に忙しくするために、単純な JavaScript ゲームを実装しています。

たとえば、クジラに失敗します。

-アダム

score 1 · Accepted Answer

答えは「場合による」です。まず第一に、リリースする環境の種類について。どこかの共有ホストにある「こんにちは、世界」タイプのウェブサイトですか、それとも 0.5 ミルのサーバーを備えた google.com ですか? 通常、ユーザーは 1 日に 1 人ですか、それとも数百万人ですか? HTML/CSS/JPG をパブリッシュしていますか、それとも SQL サーバー、中間層サーバー、分散キャッシュなどを備えた大規模なバックエンドがありますか?

一般に、開発、QA、ステージング、および本番用に別々の環境を用意する余裕がある場合は、それらを用意してください。リソースがある場合は、エコシステムを作成して、1 回のクリックで完全なインストール可能なパッケージを構築できるようにします。そして、もう一度クリックするだけで、同じバイナリインストールを DEV/QA/STAGE/PROD に正常にインストールできることを確認してください。答え

score 1 · Accepted Answer

その一部は、データベースも更新しているかどうかによって異なります。以前は、DB が更新されている場合、計画された (および公開された) メンテナンス期間のためにサイトをダウンさせていました。通常は、影響が最小限に抑えられる時間外に行われていました。更新に DB が関係しない場合は、負荷分散された環境で、ミックスから 1 つのボックスを取り出し、展開してテストします。それが成功した場合、それはミックスに入り、他のボックス (2 つのボックスを想定) が持ち出され、更新/テストされました。

注: コードのテストは行っていません。デプロイがスムーズに行われたため、ダウンタイムが最小限に抑えられただけです。前述のとおり、コードは別の環境でのテストに既に合格している必要があります。

score 1 · Accepted Answer

IMHO の長いダウンタイム (数時間) は、無料のサイトでは許容されます。ユーザーを十分に教育すれば、ユーザーはそれが必要であることを理解するでしょう。ウェブサイトが復旧するまで何か遊べるものを提供するかもしれません (例: フラッシュゲーム、開発チームの作業を示すウェブカメラライブフィードなど)。人々がお金を払ってアクセスする Web サイトの場合、定期的なダウンタイムを与えると、多くの人が苦情で時間を無駄にすることになります。ユーザーに料金を請求するサービスを実行している場合は、疫病のようなダウンタイムを回避し、更新を非常にゆっくりと慎重に展開します。

現在のセットアップでは、変更をテストするためにライブコピーと同じデータベースとキャッシュに接続されたセカンダリ Web サイトがあります。

また、いくつかの「ページウォッチャー」スクリプトを cron ジョブで実行しています。このスクリプトは、正規表現を使用して、Web サイトが主要なページを適切にレンダリングしているかどうかをチェックします。

score 0 · Accepted Answer

ユーザーに対して透過的にする唯一の方法は、負荷分散されたプロキシの背後に配置することです。別のサーバーを更新するときに、1つのサーバーを停止します。次に、更新が完了したら、更新したものをオンラインに置き、もう1つを削除します。それが僕たちのやり方です。

何らかの「ベータ」ビルドがある場合は、ライブサーバーにロールアウトしないでください。「ライブで忙しいサイト」がある場合は、人々がそれを叩いて何かを壊そうとしている可能性があります。

これは典型的な高可用性セットアップであり、高可用性を維持するには、最低3台のサーバーが必要です。2つのライブサーバーと1つのテストサーバー。さらに、専用のDBなどが必要な場合は、その他の追加サーバーが必要です。

score 0 · Accepted Answer

ライブに移行する前に別の開発サイトで可能な限りすべてをテストするために、Selenium (Web ページテスター) を使用して、サイトのすべてのナビゲーション可能な部分を実行し、ダミーの値をフォームに入力し、それらの値が右側に表示されることを確認します。結果としての場所など

多くのJavaScriptや動的なものもチェックするのに十分強力です.

次に、ライブサイトをアップグレードした後、Selenium をもう一度簡単に実行して、更新が機能し、ミッシングリンクやデータベースエラーがないことを確認します。

手動でフリックするだけでは見逃していた微妙なエラーをキャッチすることで、何度か救われました。

また、ライブサイトをある種の「リバースプロキシ」またはロードバランサー (大規模な場合) の背後に配置すると、問題が発生した場合に以前のバージョンに簡単に切り替えることができます。

score 0 · Accepted Answer

ホストクラスを作成し、そのホストクラスにライブサイトをデプロイします。ホストクラスとは、負荷分散が設定され、クラスからホストを簡単に追加および削除できる一連のホストを意味します。

ベータテストが完了し、運用の準備が整ったら、サイトを停止する必要はありません。運用ホストクラスからいくつかのホストを削除し、それらを新しいホストクラスに追加して、そこに最新のコードをデプロイし、適切にテストするだけです。すべてが正常に機能していることを確認したら、すべてのホストを徐々に新しいものに移動し、新しいホストクラスを運用ホストクラスとしてポイントします。または、最初に使用していたものと同じものを使用することもできます。このアクティビティの背後にある全体的な考え方は、展開の問題は恐ろしく、デバッグが難しいため、展開後にサイトが実行される運用ボックスで展開をテストしていることを確認することです。

score 0 · Accepted Answer

メインサーバーを 80 以外のポートで実行します。軽量サーバー (nginx など) をポート 80 の前に配置します。サイトを更新するときは、新しいポートで別のインスタンスを開始します。テスト。正しくデプロイされたことを確認したら、プロキシ構成ファイルを編集して再起動します。nginx の場合、これによりダウンタイムがゼロになるか、リクエストが失敗し、より一般的な Apache のみのホスティングオプションよりもパフォーマンスが向上します。

もちろん、これは適切なステージングサーバーの代わりになるものではなく、限られたリソースでハンドオーバーを実行するための「丁寧な」方法にすぎません。

release-management - ライブで忙しい Web サイトをできるだけ丁寧に更新するにはどうすればよいでしょうか?

13 に答える 13

Related

Reference