Come si aggiorna un sito Web attivo e affollato nel modo più educato possibile?

StackOverflow https://stackoverflow.com/questions/67368

Domanda

Quando implementi le modifiche a un sito web attivo, come fai a verificare che il file vivere il sistema funziona correttamente?Quali strumenti usi?Chi lo fa?Blocchi l'accesso al sito per il periodo di prova?Quale periodo di inattività è accettabile?

È stato utile?

Soluzione

Tendo a fare tutti i miei test in un altro ambiente (non quello live!).Ciò mi consente di inviare gli aggiornamenti al sito live sapendo che il codice dovrebbe funzionare correttamente, e faccio solo test di integrità sui dati live: assicurati di non aver dimenticato un file da qualche parte o che qualcosa di strano sia andato storto.

Quindi test adeguati in un ambiente di test o di prova, quindi solo banali controlli di integrità.Non c'è bisogno di tempi di inattività.

Altri suggerimenti

Già tanti buoni consigli.

Come è stato già detto, se non è coinvolto un singolo punto, è semplice introdurre gradualmente le modifiche aggiornando un server app alla volta.Ma questo accade raramente, quindi ignoriamolo e concentriamoci sulle parti difficili.

Di solito c'è un db che è comune a tutto il resto.Ciò significa tempi di inattività per l'intero sistema. Come puoi minimizzarlo?

Automazione.Script dell'intera procedura di distribuzione.Ciò (in particolare) include eventuali modifiche allo schema del database.Ciò (in particolare) include qualsiasi migrazione dei dati necessaria tra le versioni dello schema.

Controllo di qualità.Assicurati che ci siano dei test.Test di accettazione automatizzati (ciò che l'utente vede e si aspetta dal punto di vista della logica aziendale/esperienza).Prendi in considerazione la possibilità di avere account di prova nel sistema di produzione su cui puoi creare script per testare le attività di sola lettura.Se non interagisci con altri sistemi esterni, considera di svolgere anche attività di scrittura.Potrebbe essere necessario filtrare l'attività dell'account di prova in alcune parti del sistema, soprattutto se riguardano denaro e contabilità.I contatori dei fagioli si arrabbiano, per buone ragioni, quando i fagioli non corrispondono.

Provare.Distribuisci in un ambiente di staging il più identico possibile a quello di produzione.Fallo con i volumi dei dati di produzione e i dati di produzione.Devi sentire quanto tempo impiega un tavolo d'alterazione.Ed è necessario verificare che una tabella di modifica funzioni sia strutturalmente che con tutte le chiavi esterne nei dati effettivi.

Se disponi di enormi volumi di dati, le modifiche allo schema richiederanno tempo.Forse più tempo di quanto puoi permetterti di stare giù.Una soluzione è usare migrazioni graduali dei dati, in modo che la modifica dello schema venga popolata con dati "recenti" o "correnti" (diciamo vecchi di uno o tre mesi) durante il periodo di inattività e che i dati per i restanti cinque anni possano essere inseriti dopo che sei di nuovo online.Per l'utente finale le cose sembrano a posto, ma non è possibile accedere ad alcune funzionalità per un altro paio d'ore/giorni/qualunque cosa.

Al lavoro trascorriamo un periodo di tempo con il codice congelato nell'ambiente di test.Quindi, dopo alcune settimane di preavviso, disattiviamo il sito a mezzanotte di venerdì sera, lavoriamo tutta la notte per l'implementazione e la convalida e lo installiamo sabato mattina tardi.Le statistiche sul traffico ci hanno mostrato che questo era il periodo migliore per farlo.

Se disponi di un set di server con carico bilanciato, sarai in grado di portarli offline uno per uno separatamente e aggiornarli.Nessun tempo di inattività per gli utenti!

Avere un'immagine carina e disarmante e/o una pagina di backup.Alcuni siti implementano semplici giochi javascript per tenerti occupato mentre aspetti l'aggiornamento.

Ad esempio, fallisci la balena.

-Adamo

Nell'ultimo posto in cui ho lavorato, il QA eseguiva test nell'ambiente QA.Eventuali problemi importanti verrebbero risolti, testati e verificati prima del lancio.

Dopo che la build è stata certificata dal QA, il team di supporto alla produzione ha inviato il codice all'ambiente di staging dove il cliente esamina il sito e verifica che tutto sia come desiderato.

L'effettivo lancio della produzione avviene durante gli orari non lavorativi (dopo le 21:00).se si tratta di una spinta notturna di emergenza, oppure dalle 5 del mattino- 8 del mattino.se si tratta di un'implementazione normalmente pianificata).

Il sito è ospitato su più server, il cui carico viene bilanciato utilizzando un bilanciatore di carico F5:

  • Un paio di server vengono rimossi dalla produzione,
  • il codice è installato e
  • viene eseguito un controllo superficiale sui server prima di reinserirli nel pool.

Ciò viene ripetuto finché tutti i server non vengono aggiornati al codice più recente e consente al sito di rimanere attivo per tutto il tempo.

Questo processo è ideale, ma ci sono casi in cui è necessario aggiornare anche il database.Se questo è il caso, ci sono due opzioni, a seconda se il nuovo database danneggerà o meno il sito.

Se il nuovo database è incompatibile con il front-end esistente, non hai altra scelta se non quella di avere una finestra di tempo in cui il sito è inattivo.

Ma se il nuovo database è compatibile con il front-end esistente, è comunque possibile inviare il codice senza tempi di inattività effettivi, ma ciò richiede la presenza di due server di database di produzione.

  • Tutto il traffico viene instradato al secondo DB e viene estratto il primo server DB.
  • Il primo DB viene aggiornato e, una volta completata la verifica, rimesso in produzione.
  • Tutto il traffico viene instradato al primo DB e viene estratto il secondo DB.
  • Il secondo DB viene aggiornato e, una volta completata la verifica, rimesso in produzione.
  • Il passaggio successivo consiste nell'eseguire gli aggiornamenti parziali come descritto sopra.

Quindi riassumendo:

  • Quando implementi le modifiche a un sito web live, come fai a verificare che il sistema live funzioni correttamente? Nel migliore dei casi, questo viene fatto in modo incrementale.

  • Quali strumenti usi? Controlli manuali per verificare che il codice sia installato correttamente insieme ad alcuni test automatizzati di base, utilizzando qualsiasi strumento di automazione.Abbiamo usato l'IDE di selenio.

  • Chi lo fa? Il DBA esegue gli aggiornamenti del DB, il supporto tecnico/gli amministratori di sistema eseguono il push/pull dei server e installa il codice, mentre il supporto QA o di produzione esegue i test manuali e/o esegue i test automatizzati.

  • Blocchi l'accesso al sito per il periodo di prova? Se possibile, questo dovrebbe essere evitato a tutti i costi, soprattutto, come menzionato prima da Gilles, se si tratta di un sito a pagamento.

  • Quale periodo di inattività è accettabile? I tempi di inattività dovrebbero essere limitati ai momenti in cui gli utenti avrebbero meno probabilità di utilizzare il sito e dovrebbero essere completati in meno di 3 ore.
    Nota: 3 ore sono molto generose.Dopo l'allenamento e le prove, come menzionato da jplindstrom, la squadra avrà terminato l'intero processo e potrà entrare e uscire a volte in meno di un'ora.

Spero che questo ti aiuti!

Parte di ciò dipende anche dal fatto che tu stia aggiornando un database.In passato, se il DB veniva aggiornato, chiudevamo il sito per un periodo di manutenzione pianificato (e pubblicato), di solito qualcosa di veramente fuori orario in cui l'impatto era minimo.Se l'aggiornamento non coinvolge il DB, in un ambiente con bilanciamento del carico, prenderemo 1 scatola dal mix, la distribuiremo e testeremo.Se l'operazione ha avuto successo, è stata inserita nel mix e l'altra scatola (presumendo 2 scatole) è stata estratta e aggiornata/testata.

Nota:NON stiamo testando il codice, solo che la distribuzione è avvenuta senza intoppi, quindi i tempi di inattività sono stati comunque minimi.Come è stato accennato, il codice dovrebbe aver già superato i test in un altro ambiente.

IMHO lunghi tempi di inattività (ore) sono accettabili per un sito gratuito.Se istruisci sufficientemente i tuoi utenti, capiranno che è una necessità.Magari dai loro qualcosa con cui giocare finché il sito web non verrà ripristinato (ad es.gioco flash, feed live dalla webcam che mostra il team di sviluppo al lavoro, ecc.).Per un sito web a cui le persone pagano per accedere, molte persone ti faranno perdere tempo con reclami se fornisci loro tempi di inattività regolari.Eviterei i tempi di inattività come la peste e implementerei gli aggiornamenti molto lentamente e con attenzione se gestissi un servizio che addebita costi agli utenti.

Nella mia configurazione attuale ho un sito Web secondario collegato allo stesso database e memorizzato nella cache della Live Copy per testare le mie modifiche.

Ho anche diversi script "page watcher" in esecuzione su processi cron che utilizzano espressioni regolari per verificare che il sito Web stia visualizzando correttamente le pagine chiave.

La risposta è che "dipende".Innanzitutto dal tipo di ambiente in cui ti stai liberando.È un sito Web del tipo "ciao mondo" su un host condiviso da qualche parte o un google.com con mezzo milione di server?In genere c'è un utente al giorno o più, come un paio di milioni?Stai pubblicando HTML/CSS/JPG o esiste un grosso backend peloso con server SQL, server di livello intermedio, cache distribuite, ecc.?

In generale, se puoi permetterti di avere ambienti separati per lo sviluppo, il controllo qualità, la gestione temporanea e la produzione, disponi di quelli.Se disponi delle risorse, crea l'ecosistema in modo da poter creare il pacchetto installabile completo con 1 (un) clic.E assicurati di questo lo stesso l'installazione binaria può essere installata con successo in DEV/QA/STAGE/PROD con un altro solo clic...Sono state scritte tantissime cose su questo argomento e devi essere più specifico con la tua domanda per ottenere una risposta ragionevole

Esegui il tuo server principale su una porta diversa da 80.Attacca un server leggero (ad es.nginx) di fronte sulla porta 80.Quando aggiorni il tuo sito, avvia un'altra istanza su una nuova porta.Test.Quando sei soddisfatto che sia stato distribuito correttamente, modifica il file di configurazione del proxy e riavvialo.Nel caso di nginx, ciò si traduce in zero tempi di inattività o richieste non riuscite e può anche fornire miglioramenti delle prestazioni rispetto alla più tipica opzione di hosting solo Apache.

Naturalmente, questo non sostituisce un server di staging adeguato, è semplicemente un modo "educato" di eseguire il passaggio con risorse limitate.

Per testare tutto il più possibile su un sito di sviluppo separato prima di andare in diretta, uso Selenium (un tester di pagina Web) per eseguire tutte le parti navigabili del sito, riempire i valori fittizi in moduli, verificare che tali valori appaiano a destra Luoghi di conseguenza, ecc.

È abbastanza potente da controllare anche molte cose JavaScript o dinamiche.

Quindi una rapida run-through con selenio dopo aver aggiornato il sito live verifica che l'aggiornamento abbia funzionato e che non ci sono collegamenti mancanti o errori di database.

Mi ha salvato alcune volte catturando errori sottili che mi sarei perso solo sfuggendo manualmente.

Inoltre, se metti il ​​sito live dietro una sorta di "proxy inverso" o bilanciamento del carico (se è grande), ciò rende facile tornare alla versione precedente in caso di problemi.

L'unico modo per renderlo trasparente ai tuoi utenti è metterlo dietro un proxy con bilanciamento del carico.Disattivi un server mentre aggiorni un altro server.Quindi, una volta terminato l'aggiornamento, metti quello che hai aggiornato online e rimuovi l'altro.Ecco come lo facciamo.

Se disponi di qualsiasi tipo di build "beta", non implementarla sul server live.Se hai un "sito attivo e attivo", è probabile che le persone lo colpiscano e rompano qualcosa.

Questa è una tipica configurazione ad alta disponibilità, per mantenere l'alta disponibilità avrai bisogno di almeno 3 server.2 live e 1 server di test.Inoltre eventuali altri server extra se desideri avere un DB dedicato o qualcosa del genere.

Crea una classe host e distribuisci il tuo sito live su quella classe host.Per classe host intendo un insieme di host in cui è configurato il bilanciamento del carico ed è facile aggiungere e rimuovere host dalla classe.

Quando hai finito con il beta testing e sei pronto per la produzione, non è necessario disattivare il tuo sito, basta rimuovere alcuni host dalla classe host di produzione, aggiungerli nella nuova classe host e distribuire lì il tuo codice più recente e testare correttamente.Una volta che sei sicuro che tutto funzioni correttamente, sposta gradualmente tutti i tuoi host su quello nuovo e indica la nuova classe host come classe host di produzione.Oppure puoi utilizzare lo stesso che stavi utilizzando inizialmente, l'idea alla base di questa attività è assicurarti di testare la tua distribuzione sulle scatole di produzione, dove il tuo sito verrà eseguito dopo la distribuzione, perché i problemi di distribuzione sono spaventosi e difficili da eseguire il debug.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top