Webサイト（これも含む）が「メンテナンスのためにダウン」していることがあるのはなぜですか？
私は個人的にこれをしたことがありません。なぜこれほど多くのサイトがそうするのか理解できません。開発サーバーで開発を行う場合、なぜ本番サイトをシャットダウンする必要があるのでしょうか。
私はいつもこれについて疑問に思っていました。
この間、彼らは何をしているのですか？
大規模なものの大きなキッカーは、何らかの方法でデータベーススキーマを変更している場合、通常、実行する大きくて厄介なメンテナンススクリプトがあることです。
これで、開発データセットで実行するのに1秒ほどかかる場合があります。ただし、テラバイトおよびペタバイト単位でデータの測定を開始すると、テーブルに単一の列を追加するだけでも数時間かかる場合があります。
そのため、導入がいかに迅速かつ自動化されていても、データ保守の問題を解決する必要があります。本当によく計画していれば、プロセスの実行中にサイトの読み取り専用ミラーを設置できますが、多くのサイトでは読み取り専用は無意味であり、努力する価値はありません。
メンテナンスのためにサイトを停止する理由はいくつかあります。いくつか例を挙げると：
- データベースの変更
- DALの変更
- サービスの更新
基本的に、サイトが静的でない場合は、ロジックの更新を行うときにそれを削除する必要があります。そうしないと、サイトにアクセスしたユーザーがエラーや予期しない動作を受け取る可能性があります。
また、サイトのweb.config（ASP.NET内）を操作する場合は、ユーザーのセッションを中断させるため、メンテナンスのために最初にそれを停止する必要があります。したがって、それらが何かの真ん中にあった場合、それは失われます。
まあ、これはどういうわけか抽象的な質問です-私は、HTTP 500の代わりに "Down for Maintenance"を使用したサイトを見たことさえあります。
Webサイトの場合、アップグレードを行う必要がある場合があります。たとえば、データベースを変更する場合、その間、他のユーザーがデータベースに触れないようにします。データベースがオフラインの場合、SqlExceptionを表示することはあまり適切ではないため、サイトも適切にオフにする必要があります。もう1つの理由は、アプリケーションまたはシステムの再起動が必要なハードウェア障害またはシステム障害（リソースのリークなど）です。
かつて、私の国で最大の銀行の1つでインターネットバンキングシステムのアップグレードに参加しました。 Webサイト、中間層、およびデータベースをアップグレードするプロセス全体で、システムが顧客にとってオフラインであった場合、3日かかりました。また、障害が発生した場合にシステムを古いバージョンに戻すことができるように、すべての完全バックアップも含まれています。
サーバーではパッチを実行する必要があり、多くのオペレーティングシステムではこれらのパッチを再起動する必要があります。したがって、これはダウンタイムの1つのカテゴリーです。多くの企業は、日曜日の朝など、使用時間が短いパッチからの再起動をスケジュールしています。パッチがない場合でも、定期的にスケジュールされたメンテナンス時にサーバーを再起動します（これは、特定のカウンターが毎週半オーバーフローしたNT4日からの二日酔いなので、毎週再起動すると他のバグが防止されました）。
私が働いていた会社の1つに90年代後半にeコマースサイトがあり、毎月$ 1,000,000以上の売り上げをもたらしました。誰かが間違った税率表を本番データベースサーバーに昇格させました。解決策は、dbサーバーをバックアップから復元し、最後のバックアップ以降のトランザクションを適用することでした。これには数時間かかり、その間、ウェブサイトは注文を受けることができませんでした。注文部分と静的販売パンフレットは同じサイトで実行されており、切り離すことができないため、両方ともダウンする必要がありました。
私が働いていたある会社では、間違ったテキストが間違った場所に挿入され、CEOが裏返し、レイアウトとテキストが「修正」され、適切な犠牲者が非難し、解雇されたときにWebサイトを「メンテナンスのため」オフラインにしました。
他の答えは正しいですが、正しいアーキテクチャを使用すれば、ほとんどの場合、ダウンタイムを回避できます。しかし、これにはコストがかかり、このコストは価値がない場合があります。1時間のダウンタイムにより、AmazonまたはNASDAQの背後にあるインフラストラクチャに多くのコストがかかります。スタックオーバーフロー ？ほとんどないでしょう。
ダウンタイムを回避する方法：
- ハードウェアサービスページのシャットダウン：Webサイトの前にプロキシがある場合は、ユーザーに影響を与えることなく、それらをオフラインにできます。
- サーバーの再構成：上記と同じ
- データベース内のデータの更新/変更：Webサイトを読み取り専用モードにするなど...
一般に、レイヤードアーキテクチャでは、「トップ」に近いほど、ダウンタイムを回避することが難しくなり、ステートフル（Webサーバーとデータベース）の場合と同じです。
これには心理面とマーケティング面もあります。いくつかのケースでは（ほとんどの場合は大胆ではありませんが、大胆な* g *ではありません）、「メンテナンスのため停止中」と表示されている場合は、「サーバーがクラッシュしたか、その他の理由でサービスが停止しています」という意味もあります。
私はこれをかなり頻繁に見ました。通常、開発者は「本当の」エラーメッセージを表示する必要があります。「おっと、現在高負荷がかかっており、すべてのリクエストを処理できるわけではありません」というメッセージが表示されます。問題があることをお客様に伝えてください。定期メンテナンス中であることを伝えてください-これでかなり見栄えが良くなります。」.
したがって、「メンテナンスのためのダウン」は「サービス停止」の別の用語にすぎないことがよくあります。
定期的なダウンタイムが発生するたびに何もする必要がない場合でも、サイトは定期的なダウンタイムをスケジュールすることがあります。そうすることで、ユーザーはサイトが時々一定の時間ダウンするので、作業が必要になるときにdoesを実行する必要があるときに、ユーザーがそれほど文句を言わないという考えにユーザーを慣れさせます。
メンテナンスのためにダウンする必要のあるサーバーはありません。規模を問わず、DBの変更、サーバーの更新など、何でもそうすることを回避できます。
問題は、特定の規模でのゼロダウンタイムシステムの作成と維持に非常にコストがかかることです。あらゆる場所での冗長性、あらゆる場所での負荷分散、データ複製、同期が必要です。それらは難しい問題です。
基本的に、システムでNetflix Chaos Monkeyをリリースできるレベルに到達する必要があります。これは、システムの一部が更新でビジー状態であるか、同期していない場合でも機能することを確認するためです。これは確かに実行可能です。それはまた非常に高価で、問題に取り組むために多くの時間と多くの専門家を必要とします。
サイトをたまにダウンさせないようにするためだけにそれほど多くの投資をしたくないので、サイトをメンテナンスモードにすることは、あなたが選択する中間の立場になる可能性があります。
経済。
もちろん、ダウンタイムの道を選択した場合、サイトは可用性だけでなく信頼性も得られます。これらのベストプラクティスは両方の目的を果たすためです。
なぜこれほど多くのサイトがそうするのか理解できません。開発サーバーで開発を行う場合、なぜ本番サイトをシャットダウンする必要があるのでしょうか。
たわごとが起こります。あなたが成果物の何らかの数学的検証を行っていない限り（そしてあなたの仕様は有効です）、どれほど注意深くても、たわごとは起こります。
また、ダウンタイムを必要とするインフラストラクチャの重要な部分（たとえば、データベース構造の変更）を変更する必要がある場合もあります。
重要なシステム（たとえば ファイブナインまたはシックスナイン システムなど）を開発しているのでない限り、責任のある費用対効果の高いことは、一部としてダウンタイムを受け入れるシステムを構築することです現実の。
さらに、効果的な回復のための明確な理解と手順を備えたダウンタイムを管理可能にして、スケジューリングを容易に（または少なくとも検出可能に）することで、この原則をさらに活用します。