Perché i siti Web (anche questo) a volte "Down for Maintenance"?

36

Personalmente non l'ho mai fatto. Non capisco perché lo facciano così tanti siti, se fai il tuo sviluppo su un server di sviluppo perché dovresti mai chiudere il tuo sito di produzione?

Mi sono sempre chiesto di questo.

Cosa stanno facendo in questo periodo, cosa richiede farlo?

web-development maintenance

— JD Isaacks
fonte

56

Stanno sostituendo i tubi a vuoto nei server.

— mipadi,

11

Ho pensato che stessero impilando le schede perforate.

— Christopher Mahan,

5

Tenete a mente che il sito probabilmente non rimanere in su per la maggior parte degli aggiornamenti. Ovviamente, vedi solo quelli in cui deve effettivamente rimanere offline per un po '.

— Dean Harding,

4

Nessuno ha affrontato un motivo di sicurezza; potrebbe esserci un exploit noto (ovvero qualcuno ha pubblicato come sfruttare un determinato sito Web) e gli amministratori lo mettono offline per mitigare gli abusi di altre parti mentre lo risolvono.

— Francisco Presencia,

1

Mi viene in mente di chiedere "Quali strategie posso usare per ottenere zero tempi di inattività (pianificati) in un'app Web supportata dal database?" In particolare aggiornamenti che richiedono modifiche allo schema db: softwareengineering.stackexchange.com/questions/336945/…

— Stephen

59

Un grande kicker per qualsiasi cosa su larga scala è che se si stanno modificando gli schemi di database in qualche modo, in genere si hanno alcuni script di manutenzione grandi e cattivi da eseguire.

Ora, potrebbero essere necessari circa un secondo per l'esecuzione con 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 una tabella può richiedere ore.

Quindi, non importa quanto sia veloce e automatizzata la distribuzione, hai ancora problemi di manutenzione dei dati da superare. Se pianifichi davvero bene, puoi creare un mirror di sola lettura del sito mentre stai eseguendo il processo, ma per molti siti di sola lettura è inutile e quindi non vale la pena.

— Wyatt Barnett
fonte

3

+1: un overflow dello stack di sola lettura non sarebbe molto buono. Non ci sarà molto che non potresti trovare su Google :)

— corsiKa

10

@glowcoder: quando esegui una ricerca su Google, trovi le risposte SO.

— Donal Fellows,

@Donal quello era esattamente il mio punto.

— corsiKa

1

Google è enorme e sicuro di avere un enorme database; come mai non vedo mai "down for maintenance" per google? (

— Home

7

@ alexy13 - google appartiene a una speciale categoria di scala in cui non possono avere un singolo database o persino un datacenter, parti del sistema sono sempre inattive e hanno scritto il front-end per gestirlo. Lo farei anche se mi avessi consegnato quel tipo di tempo e budget per ricerca e sviluppo.

— Wyatt Barnett,

7

Esistono diversi motivi per cui potresti voler chiudere un sito per manutenzione. Per dirne alcuni:

Modifiche al database
DAL cambia
Servizi di aggiornamento

Fondamentalmente, se il tuo sito non è statico, quando esegui un aggiornamento logico vuoi eliminarlo altrimenti le persone che colpiscono il tuo sito potrebbero ricevere errori o comportamenti imprevisti.

Inoltre, se toccherai web.config (in ASP.NET) per il tuo sito, dovresti prima rimuoverlo per manutenzione in quanto interromperà la sessione per gli utenti. Quindi, se fossero nel mezzo di qualcosa, andrebbero persi.

— Tyanna
fonte

2

la sessione andrebbe persa se si utilizza lo stato della sessione "In-Process". Se si utilizza lo stato sessione fuori processo, la sessione non andrà persa se si modifica web.config.

— Anthony,

2

L'ultimo punto è vero solo se stai facendo sessioni in-process, che spero non tu sia in un sito di produzione! C'è di più che toccare semplicemente il web.config che interromperà il processo di lavoro.

— Dean Harding,

7

Bene, questa è in qualche modo una domanda astratta: ho anche visto siti che utilizzavano "Down for Maintenance" anziché HTTP 500.

Per i siti Web a volte è necessario eseguire un aggiornamento. Ad esempio, se si sta modificando il database, non si desidera che nessun altro utente tocchi il database durante quel periodo. Se il database non è in linea, anche il sito deve essere disattivato correttamente perché mostrare SqlException non è molto bello. Un altro motivo è un errore HW o un errore di sistema (come perdite di risorse) che richiede il riavvio dell'applicazione o addirittura 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, livello intermedio e database ha richiesto tre giorni in cui il sistema era offline per i clienti. Comprendeva anche il backup completo di tutto, quindi in caso di guasto il sistema poteva essere ripristinato alla versione precedente.

— Ladislav Mrnka
fonte

2

HTTP 503 (anziché 500) non è il codice di stato corretto per "down for maintenance"?

— Nubok,

4

I server richiedono l'esecuzione di patch e, su molti sistemi operativi, tali patch richiedono il riavvio. Quindi questa è una categoria di downtime. Molte aziende pianificano i riavvii dalle patch per i tempi di utilizzo bassi, come la domenica mattina. Se non ci sono patch, riavvia comunque i server al tempo di manutenzione regolarmente programmato (si tratta di postumi di una sbornia dai giorni NT4 in cui alcuni contatori traboccavano ogni settimana e mezzo, quindi il riavvio settimanale impediva altri bug).

Una società per cui ho lavorato aveva un sito di e-commerce alla fine degli anni '90 che ha generato oltre 1.000.000 di dollari di vendite al mese. Qualcuno ha promosso la tabella delle imposte errata sul server del database di produzione. La cura era 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 ricevere gli ordini. Poiché la parte degli ordini e gli opuscoli statici di vendita erano in esecuzione nello stesso sito ed erano inseparabili, entrambi dovevano scendere.

Una società per cui ho lavorato aveva inserito del testo sbagliato nel posto sbagliato e il CEO è stato lanciato fuori e il sito Web è stato tolto dalla linea "per manutenzione" mentre il layout e il testo sono stati "riparati" e la vittima appropriata è stata incolpata e licenziata.

— Tangurena
fonte

Anche questo può essere mitigato con un adeguato bilanciamento del carico

— Voycey,

4

Mentre le altre risposte sono corrette, puoi quasi sempre evitare i tempi di fermo utilizzando le architetture giuste. Ma questo ha un costo e questo costo potrebbe non valerne la pena: un'ora di downtime costa molto amazon o l'infrastruttura dietro il NASDAQ. StackOverflow? Molto probabilmente non così tanto.

Come evitare i tempi di inattività:

chiusura delle pagine di pubblicazione dell'hardware: se hai proxy di fronte al tuo sito web, puoi invece metterli offline senza alcun impatto per l'utente
riconfigurazione dei server: come sopra
aggiornamento / modifica dei dati nei database: potresti mettere il tuo sito web in modalità di sola lettura, ecc ...

Generalmente, in un'architettura a strati, più ci si avvicina alla "cima", più diventa difficile evitare i tempi di inattività, lo stesso per stateful (server web vs database).

— David Cournapeau
fonte

4

Il NASDAQ non ha circa 14 ore al giorno di inattività programmata?

— Peter Taylor,

3

Un sito può programmare tempi di inattività regolari anche se non c'è nulla da fare ogni volta che si verifica il tempo di inattività pianificato. In questo modo, gli utenti ottengono utilizzati per l'idea che il sito sarà verso il basso per un certo periodo di tempo ogni tanto in modo che quando il lavoro fa bisogno di essere fatto, gli utenti non si lamentano così tanto.

— Barry Brown
fonte

c'è una cura per questo: abbattere il sistema dei reclami durante i tempi di inattività :) Ho visto le aziende farlo. Una società di MMO che sta pubblicando il sito Web che ospita l'annuncio dei tempi di inattività, nonché i forum di supporto insieme al gioco inattivo per manutenzione, ne è un buon esempio. Chi non avesse ricevuto l'annuncio durante le poche ore in cui era attivo prima della manutenzione non avrebbe mai saputo cosa stava succedendo.

— jwenting

3

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 "Giù per manutenzione" può anche significare "Il server si è bloccato o è andato fuori servizio per qualsiasi altro motivo".

L'ho visto abbastanza frequentemente. Normalmente come sviluppatore vorrai un messaggio di errore "reale" che dice qualcosa del tipo "Whoops, stiamo vivendo 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 riscontrando un problema. Digli che stiamo effettuando la manutenzione programmata - sarà molto meglio ".

Quindi "Down for maintenance" spesso è solo un altro termine per "fuori servizio".

— perdian
fonte

2

Nessun server DEVE ESSERE interrotto per manutenzione. Puoi evitare di farlo per qualsiasi cosa, a qualsiasi scala, modifica del DB, aggiornamenti del server, ecc.

Il problema è che un sistema 0-downtime, ad 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 devi arrivare al livello di essere in grado di rilasciare Netflix Chaos Monkey in prod per essere sicuro che funzioni anche se parte del tuo sistema è occupata con l'aggiornamento, o semplicemente non sincronizzata. Questo è certamente fattibile. È anche molto costoso, richiede molto tempo e molti esperti lavorano sul problema.

Mettere un sito in modalità di manutenzione può essere una via di mezzo che scegli, perché non vuoi investire così tanto solo per evitare di smantellare il tuo sito per un po 'di tanto in tanto.

Economia.

Naturalmente, se scegli la strada del tempo 0down, il tuo sito guadagnerà più della semplice disponibilità, guadagnerà anche affidabilità, dal momento che queste migliori pratiche servono entrambi gli scopi.

— e-satis
fonte

0

Non capisco perché lo facciano così tanti siti, se fai il tuo sviluppo su un server di sviluppo perché dovresti mai chiudere il tuo sito di produzione?

Merda succede. A meno che tu non stia facendo una qualche forma di verifica matematica dei tuoi risultati ( e le tue specifiche sono valide ), non importa quanto stai attento, la merda accade.

Inoltre, in alcuni casi potrebbe essere necessario apportare una modifica a un elemento chiave della propria infrastruttura (ad esempio, una modifica alle strutture del database) che richiede un tempo di inattività.

A meno che tu non stia sviluppando un sistema critico (diciamo un sistema cinque-nove o sei-nove ), la cosa responsabile ed economica da fare è costruire un sistema con l'accettazione dei tempi morti come parte della realtà.

Inoltre, si spinge oltre tale principio rendendo i tempi di inattività gestibili e suscettibili di programmazione (o almeno rilevabili) con una chiara comprensione e procedura per un recupero efficace.

— luis.espinal
fonte

1

La verifica matematica non è neanche una panacea; a volte scopri che ciò che hai verificato non è ciò che volevi verificare.

— Donal Fellows,

Vero. Ma poi direi che il problema non è con la verifica formale delle specifiche, ma con la convalida di tali specifiche. Se le tue specifiche non sono valide, ovviamente tutto andrà in pezzi da lì, ma la convalida delle specifiche ( "stiamo davvero costruendo la cosa giusta necessaria all'utente previsto per lo scopo previsto" ), non è questo l'obiettivo della verifica (* "dato queste specifiche, stiamo costruendo questa cosa giusta, o può essere costruita? "), informale o altro. Immagino che avrei dovuto fare un avvertimento (scritto sulla validità delle specifiche.)

— luis.espinal

Non sto sostenendo che ti sbagli a dirlo. Sottolineo solo che ci sono limiti a ciò che può fare. Lavoravo sulla verifica formale e il grosso problema all'epoca era come far evolvere correttamente le specifiche in modo da tenere conto della modifica della comprensione dei requisiti. Dato che si tratta principalmente di un problema umano, in secondo luogo un problema di ingegneria e solo terribilmente un problema matematico, non immagino che sia stato ancora risolto completamente.

— Donal Fellows,

Oh. Penso che allora siamo come pensare. I requisiti in evoluzione (e la convalida delle richieste) sono alla base dei metodi formali di Achille. Dal momento che è un compito creativo (a causa della sua natura umana), non credo che sia risolvibile, non nel modo in cui formalisti / puristi vorrebbero che fosse. Penso che sia stata una delle promesse mancate di FM; sono stati ipervenduti (intendo, ad esempio, metodi formali per lo sviluppo web ?) Le specifiche devono essere attentamente esaminate e non suscettibili di rapidi cambiamenti (e questo è tipico dei sistemi critici, non altamente malleabili). I successivi sono la norma piuttosto che l'eccezione.

— luis.espinal,

Il 99% delle interfacce utente non ha a che fare con metodi formali, ma piuttosto con la psicologia applicata. Le prove rimanenti sono ovvie ("non bloccare l'IU") anche se non sempre è ovvio da dimostrare. Ma se hai separato la webapp secondo le migliori pratiche, i metodi formali avranno molto senso nel livello dei metodi di business (anche nel livello di archiviazione dei dati, ma di solito è qui che i consigli standard di "non scrivere il tuo DB "si applica comunque. :-))

— Donal Fellows

-2

Una volta il nostro sito Web è stato violato (vecchio server IIS6 e Windows 2003 alcuni anni fa). mentre stavamo lavorando al restauro abbiamo messo la pagina "in manutenzione" per alcune ore ....

— serega
fonte