Personalmente non l'ho mai fatto. Non capisco perché così tanti siti facciano, se sviluppi il tuo sviluppo su un server di sviluppo, perché dovresti mai chiudere il tuo sito di produzione?
Mi sono sempre chiesto questo.
Che cosa stanno facendo in questo momento, cosa è necessario fare?
Un grande kicker per qualsiasi cosa con una grande scala è che se uno sta cambiando gli schemi di database in qualche modo, uno in genere ha degli script di manutenzione grandi e cattivi da eseguire.
Ora, potrebbero essere necessari circa un secondo per eseguire il set di dati di sviluppo. Ma quando inizi a misurare i dati in terabyte e petabyte, anche l'aggiunta di una singola colonna a un tavolo può richiedere ore.
Quindi, indipendentemente dalla rapidità e automazione della distribuzione, hai ancora problemi di manutenzione dei dati da superare. Se stai pianificando bene, puoi creare un mirror di sola lettura del sito mentre stai subendo il processo, ma per molti siti la sola lettura è inutile e quindi non vale la pena.
Esistono diversi motivi per cui potresti voler ritirare un sito per la manutenzione. Per citarne alcuni:
In sostanza, se il tuo sito non è statico, quando esegui un aggiornamento logico lo vuoi rimuovere altrimenti le persone che colpiscono il tuo sito potrebbero ricevere errori o comportamenti imprevisti.
Inoltre, se toccherai il web.config (in ASP.NET) per il tuo sito, dovresti eliminarlo prima per manutenzione, in quanto spegnerà la sessione per gli utenti. Quindi, se fossero nel mezzo di qualcosa, sarebbe perso.
Beh, questa è una domanda in qualche modo astratta - ho persino visto siti che utilizzavano "Down for Maintenance" invece di HTTP 500.
Per i siti Web a volte è necessario eseguire un aggiornamento. Ad esempio, se si modifica il database, non si desidera che nessun altro utente tocchi il database durante tale periodo. Se il database non è in linea, il sito deve essere disattivato correttamente anche perché mostrare SqlException non è molto bello. Un altro motivo è un errore hardware o un errore di sistema (come perdite di risorse) che richiede l'applicazione o il riavvio del sistema.
Una volta ho partecipato all'aggiornamento del sistema di internet banking in una delle più grandi banche del mio paese. L'intero processo di aggiornamento di siti Web, middle tier e database ha richiesto tre giorni in cui il sistema era offline per i clienti. Include anche il backup completo di tutto, quindi in caso di errore il sistema potrebbe tornare alla versione precedente.
I server richiedono l'esecuzione di patch e su molti sistemi operativi queste patch richiedono il riavvio. Quindi questa è una categoria di tempi morti. Molte aziende programmano il riavvio da patch per i periodi di utilizzo ridotti, ad esempio domenica mattina. Se non ci sono patch, riavviano comunque i server ai tempi di manutenzione programmati regolarmente (si tratta di una sbornia dai giorni NT4 in cui alcuni contatori hanno superato ogni settimana e mezzo, quindi il riavvio settimanale ha impedito altri bug).
Una società per cui lavoravo aveva un sito di e-commerce alla fine degli anni '90 che ha portato oltre $ 1.000.000 di vendite al mese. Qualcuno ha promosso la tabella delle tasse sbagliata al server del database di produzione. La cura era di ripristinare il server db dal backup e applicare le transazioni dall'ultimo backup. Ciò ha richiesto diverse ore, durante le quali il sito Web non era disponibile per prendere ordini. Dal momento che la parte relativa agli ordini e le brochure di vendita statiche erano in esecuzione sullo stesso sito ed erano inseparabili, entrambi dovevano venire giù.
Una società per la quale ho lavorato ha inserito del testo sbagliato nel posto sbagliato e l'amministratore delegato ha fatto fuori servizio il sito Web "per manutenzione" mentre il layout e il testo sono stati "riparati" e la vittima appropriata ha incolpato e licenziato.
Mentre altre risposte sono corrette, puoi quasi sempre evitare tempi di inattività usando le architetture giuste. Ma questo ha un costo, e questo costo potrebbe non valerne la pena: un'ora di costi di downtime amazon o l'infrastruttura dietro NASDAQ molto. Stackoverflow? Molto probabilmente non così tanto.
Come evitare i tempi di inattività:
Generalmente, in un'architettura a più livelli, più vicino al "top" sei, più difficile diventa per evitare tempi di inattività, lo stesso per stateful (server web vs database).
Un sito può pianificare tempi di fermo regolari anche se non c'è nulla da fare ogni volta che si verificano i tempi di inattività programmati. In questo modo, gli utenti si abituano all'idea che il sito sarà interrotto per un certo periodo di tempo ogni tanto in modo che quando il lavoro fa deve essere fatto, gli utenti non si lamenteranno così tanto .
C'è anche un lato psicologico e di marketing in questo. In alcuni casi (oso dire la maggior parte dei casi ma non sono così audace * g *) la lettura di "Down for maintenance" può anche significare "Il server è andato in crash o è andato fuori servizio per qualsiasi altro motivo".
L'ho visto abbastanza spesso. Normalmente come sviluppatore vorrai un messaggio di errore "reale" che dice qualcosa come "Whoops, stiamo sperimentando un carico elevato in questo momento e non tutte le richieste possono essere gestite", ma alcune persone del marketing ti diranno "amico, non puoi dì al cliente che stiamo avendo un problema, digli che siamo in manutenzione programmata - questo sarà molto meglio ".
Quindi "Down for maintenance" spesso è solo un altro termine per "out of service".
Nessun server ha BISOGNO di andare giù per la manutenzione. Puoi evitare di farlo per qualsiasi cosa, su qualsiasi scala, modifica del DB, aggiornamenti del server, ecc.
Il problema è che un sistema di 0-downtime, in una certa scala, è molto costoso da creare e mantenere. Hai bisogno di ridondanza ovunque, bilanciamento del carico ovunque, replica dei dati, sincronizzazione. Questi sono problemi difficili.
Fondamentalmente è necessario arrivare al livello di poter rilasciare Netflix Chaos Monkey in prod per assicurarsi che funzioni anche se parte del tuo sistema è impegnata con l'aggiornamento, o semplicemente non sincronizzata. Questo è certamente fattibile. È anche molto costoso, richiede molto tempo e molti esperti per risolvere il problema.
Mettere un sito in modalità di manutenzione può essere una via di mezzo che si sceglie, perché non si vuole investire così tanto solo per evitare di buttar giù il sito per un po 'di tempo una volta ogni tanto.
Economia.
Ovviamente, se scegli la strada del tempo di 0down, il tuo sito guadagnerà più della semplice disponibilità, guadagnerà anche l'affidabilità, dal momento che queste best practice servono a entrambi gli scopi.
I don't understand why so many sites do, if you do your development on a development server why would you ever need to shut down your production site?
Succede la merda. A meno che tu non stia facendo una verifica matematica dei tuoi risultati finali ( e le tue specifiche sono valide ), indipendentemente da quanto sei attento, succede la merda.
Inoltre, ci sono momenti in cui potresti dover apportare una modifica a un pezzo chiave della tua infrastruttura (ad esempio, una modifica alle strutture del database) che richiedono tempi di inattività.
A meno che tu non stia sviluppando un sistema critico (ad esempio un sistema cinque-nove o sei-nove ), il La cosa responsabile ed economica è costruire un sistema con l'accettazione dei tempi morti come parte della realtà.
Inoltre, si prende ulteriormente questo principio rendendo i tempi di fermo gestibilità e adattabilità alla pianificazione (o almeno rilevabile) con una chiara comprensione e procedura per un recupero efficace.
Una volta che il nostro sito Web è stato violato (vecchio server IIS6 e Windows 2003 pochi anni fa). mentre stavamo lavorando al restauro abbiamo inserito la pagina "in manutenzione" per alcune ore ....
Leggi altre domande sui tag web-development maintenance