Webサイト（これでも）が「メンテナンスのためにダウン」することがあるのはなぜですか？

私は個人的にこれをやったことがありません。開発サーバーで開発を行う場合、なぜ実稼働サイトをシャットダウンする必要があるのでしょうか？

私はいつもこれについて疑問に思っていました。

この間に彼らは何をしていて、何をする必要がありますか？

大規模なものに対する大きなキッカーは、何らかの方法でデータベーススキーマを変更している場合、通常は実行するための大きくて厄介なメンテナンススクリプトがいくつかあるということです。

現在、これらは開発データセットで実行するのに数秒かかります。ただし、テラバイトおよびペタバイト単位でデータの測定を開始すると、テーブルに単一の列を追加するだけでも数時間かかる場合があります。

そのため、展開がどれほど迅速かつ自動化されても、データメンテナンスの問題を解決する必要があります。本当にうまく計画していれば、処理中にサイトの読み取り専用ミラーを設置できますが、多くのサイトでは読み取り専用は無意味であり、努力する価値はありません。

メンテナンスのためにサイトを停止する理由はいくつかあります。いくつか例を挙げると：

• データベースの変更
• DALの変更
• サービスの更新

基本的に、サイトが静的でない場合は、ロジックの更新を行うときにそれを削除する必要があります。そうしないと、サイトにアクセスしたユーザーがエラーや予期しない動作を受け取る可能性があります。

また、サイトのweb.config（ASP.NET）に触れる場合は、ユーザーのセッションを吹き飛ばすため、メンテナンスのために最初にそれを削除する必要があります。したがって、彼らが何かの真ん中にいた場合、それは失われます。

まあ、これは何らかの形で抽象的な質問です-HTTP 500の代わりに「Down for Maintenance」を使用したサイトを見たことがあります。

Webサイトの場合、アップグレードを行う必要がある場合があります。たとえば、データベースを変更する場合、その間は他のユーザーがデータベースにアクセスしないようにします。データベースがオフラインの場合、SqlExceptionを表示するのはあまり適切ではないため、サイトも適切にオフにする必要があります。別の理由は、アプリケーションまたはシステムの再起動が必要なハードウェア障害またはシステム障害（リソースのリークなど）です。

かつて、私の国で最大の銀行の1つでインターネットバンキングシステムのアップグレードに参加しました。Webサイト、中間層、およびデータベースのアップグレードプロセス全体は、システムが顧客のためにオフラインであった場合、3日間かかりました。また、すべての完全バックアップが含まれているため、障害が発生した場合にシステムを古いバージョンに戻すことができます。

サーバーを実行するにはパッチが必要です。多くのオペレーティングシステムでは、これらのパッチを再起動する必要があります。これがダウンタイムの1つのカテゴリです。多くの企業は、日曜日の朝など、使用時間が短いパッチからの再起動をスケジュールしています。パッチがない場合、定期的にスケジュールされたメンテナンス時間にサーバーをリブートします（これは、特定のカウンターが毎週1.5オーバーフローしたNT4日からの二日酔いなので、毎週リブートすると他のバグが防止されます）。

私が働いていた会社の1つは、90年代後半に1か月あたり100万ドル以上の売上をもたらしたeコマースサイトを持っていました。誰かが本番データベースサーバーに間違った税率表を昇格させました。解決策は、バックアップからdbサーバーを復元し、最後のバックアップ以降のトランザクションを適用することでした。これには数時間かかり、その間、ウェブサイトは注文を受け付けられませんでした。注文部分と静的な販売パンフレットは同じサイトで実行されており、切り離せないため、両方ともダウンする必要がありました。

私が働いていたある会社では、間違ったテキストが間違った場所に挿入され、CEOがひっくり返して、レイアウトとテキストを「修正」し、適切な被害者を非難し、解雇する間、ウェブサイトを「メンテナンスのため」に切断しました。

他の答えは正しいですが、ほとんどの場合、適切なアーキテクチャを使用してダウンタイムを回避できます。しかし、これにはコストがかかり、このコストは価値がないかもしれません。1時間のダウンタイムは、AmazonまたはNASDAQの背後にあるインフラストラクチャに多大なコストをかけます。スタックオーバーフロー ？ほとんどないでしょう。

ダウンタイムを回避する方法：

• ハードウェア提供ページのシャットダウン：Webサイトの前にプロキシがある場合、代わりにユーザーに影響を与えずにプロキシをオフラインにできます。
• サーバーの再構成：上記と同じ
• データベース内のデータの更新/変更：ウェブサイトを読み取り専用モードなどにすることができます...

一般に、階層型アーキテクチャでは、「トップ」に近いほど、ダウンタイムを回避することが難しくなります。ステートフル（Webサーバーとデータベース）の場合も同じです。

スケジュールされたダウンタイムが発生するたびに何もすることがなくても、サイトは定期的なダウンタイムをスケジュールする場合があります。そうすることで、ユーザーはサイトが一定の時間の間頻繁にダウンするという考えに慣れることができるので、作業を行う必要があるときにユーザーはそれほど不満を言うことはありません。

これには心理的およびマーケティング的な側面もあります。場合によっては（ほとんどの場合はあえて言いますが、それほど大胆ではありませんが* g *）、「メンテナンスのためダウン」と表示される場合は、「サーバーがクラッシュしたか、他の理由でサービスを停止した」ことも意味します。

これはかなり頻繁に見ました。通常、開発者としては、「うわー、私たちは現在高負荷を経験しているため、すべてのリクエストを処理できない」というような「本当の」エラーメッセージが必要になりますが、マーケティングの一部の人は「おい、できません」と言うでしょう問題が発生していることをお客様に伝えてください。定期メンテナンスを行っていることを伝えてください。

そのため、「メンテナンスのためのダウン」は、しばしば「アウトオブサービス」の単なる別の用語です。

メンテナンスのためにサーバーを停止する必要はありません。あらゆる規模、DBの変更、サーバーの更新などに対して、そうすることを避けることができます。

問題は、特定の規模のダウンタイムゼロのシステムは、作成と保守に非常にコストがかかることです。どこでも冗長性、どこでも負荷分散、データ複製、同期が必要です。これらは難しい問題です。

基本的に、システムの一部がアップデートでビジーである場合や、単に同期が取れていない場合でも、Netflix Chaos Monkeyをprodでリリースできるレベルに到達する必要があります。これは確かに実行可能です。また、非常に高価であり、多くの時間と多くの専門家が問題に取り組む必要があります。

サイトをメンテナンスモードにすることは、あなたが選択する妥協点になる可能性があります。なぜなら、たまにサイトを少しの間ダウンさせることを避けるためだけに投資したくないからです。

経済。

もちろん、ダウンタイムのない道を選択すると、サイトは可用性だけでなく、信頼性も向上します。これらのベストプラクティスは両方の目的に役立つからです。

開発サーバーで開発を行う場合、なぜ実稼働サイトをシャットダウンする必要があるのでしょうか？

たわごとが起こる。成果物の数学的な検証（および仕様が有効である）を何らかの形で行っていない限り、どんなに慎重であっても、たわごとは起こります。

また、ダウンタイムを必要とするインフラストラクチャの重要な部分（データベース構造の変更など）を変更しなければならない場合があります。

重要なシステム（たとえば、ファイブナインシステムまたはシックスナインシステム）を開発している場合を除き、責任があり費用対効果の高いことは、現実の一部としてダウンタイムを受け入れてシステムを構築することです。

さらに、ダウンタイムを管理しやすくし、効果的な回復のための明確な理解と手順でスケジュールを立てることができます（または少なくとも検出可能）。

Webサイトがハッキングされた（数年前の古いIIS6およびWindows 2003サーバー）。修復作業中に、「メンテナンス中」ページを数時間表示しました。...