In estate diminuiscono tradizionalmente sia l'attività di acquisto che l'intensità dei cambiamenti nell'infrastruttura dei progetti web, ci dice Captain Obvious. Semplicemente perché anche gli specialisti IT a volte vanno in vacanza. E anche il CTO. È ancora più difficile per chi resta in carica, ma ora non è questo il punto: forse è per questo che l’estate è il periodo migliore per riflettere con calma sullo schema di prenotazioni esistente ed elaborare un piano per migliorarlo. E l'esperienza di Yegor Andreev da , di cui ha parlato alla conferenza .
Esistono diverse trappole in cui puoi cadere quando crei siti di backup. Ed è assolutamente impossibile rimanervi intrappolati. E ciò che ci rovina in tutto questo, come in tante altre cose, è il perfezionismo e... la pigrizia. Stiamo cercando di fare tutto, tutto, tutto perfettamente, ma non abbiamo bisogno di farlo perfettamente! Devi solo fare certe cose, ma farle correttamente, completarle in modo che funzionino correttamente.
Il failover non è una cosa divertente e divertente; questa è una cosa che dovrebbe fare esattamente una cosa: ridurre i tempi di inattività in modo che il servizio, l'azienda, perda meno denaro. E in tutti i metodi di prenotazione, suggerisco di pensare nel seguente contesto: dove sono i soldi?
Prima trappola: quando costruiamo sistemi grandi e affidabili e ci impegniamo nella ridondanza, riduciamo il numero di incidenti. Questo è un terribile malinteso. Quando ci impegniamo in licenziamenti, è probabile che aumentiamo il numero di incidenti. E se facciamo tutto bene, insieme ridurremo i tempi di inattività. Ci saranno più incidenti, ma avverranno a costi inferiori. Cos'è una prenotazione? - questa è una complicazione del sistema. Qualsiasi complicazione è negativa: abbiamo più ingranaggi, più ingranaggi, in una parola, più elementi e, quindi, maggiori possibilità di guasto. E si romperanno davvero. E si romperanno più spesso. Un semplice esempio: supponiamo di avere un sito web con PHP e MySQL. E ha urgente bisogno di essere prenotato.
Shtosh (c) Prendiamo il secondo sito, costruiamo un sistema identico... La complessità diventa due volte più grande: abbiamo due entità. Implementiamo inoltre una determinata logica per il trasferimento dei dati da un sito a un altro, ovvero replica dei dati, copia di dati statici e così via. Quindi, la logica di replica è solitamente molto complessa e quindi la complessità totale del sistema può essere non 2, ma 3, 5, 10 volte maggiore.
Seconda trappola: quando costruiamo sistemi complessi davvero grandi, fantasticamo su cosa vogliamo ottenere alla fine. Voila: vogliamo ottenere un sistema super affidabile che funzioni senza tempi di inattività, si accenda in mezzo secondo (o meglio ancora, istantaneamente) e iniziamo a realizzare i sogni. Ma qui c'è anche una sfumatura: quanto più breve è il tempo di commutazione desiderato, tanto più complessa diventa la logica del sistema. Quanto più complessa sarà la nostra logica, tanto più spesso il sistema crollerà. E puoi ritrovarti in una situazione molto spiacevole: stiamo cercando con tutte le nostre forze di ridurre i tempi di fermo, ma in realtà stiamo rendendo tutto più complicato, e quando qualcosa va storto, i tempi di fermo finiscono per essere più lunghi. Qui spesso ti sorprendi a pensare: beh... sarebbe meglio non prenotare. Sarebbe meglio se funzionasse da solo e con tempi di inattività comprensibili.
Come puoi combatterlo? Dobbiamo smettere di mentire a noi stessi, smettere di illuderci che costruiremo un'astronave qui adesso, ma capire adeguatamente quanto durerà il progetto. E per questo tempo massimo sceglieremo quali metodi utilizzeremo effettivamente per aumentare l'affidabilità del nostro sistema.
È tempo di “storie da w”... dalla vita, ovviamente.
Esempio numero uno
Immagina un sito web con biglietti da visita per l'impianto di laminazione tubi n. 1 nella città di N. Dice a grandi lettere: IMPIANTO DI LAMINAZIONE TUBI n. 1. Appena sotto c'è lo slogan: "I nostri tubi sono i tubi più rotondi di N." E sotto c'è il numero di telefono dell'amministratore delegato e il suo nome. Comprendiamo che è necessario effettuare una prenotazione: questa è una cosa molto importante! Cominciamo a capire in cosa consiste. Html-statics - cioè un paio di immagini in cui il direttore generale, infatti, sta discutendo una sorta di prossimo accordo al tavolo dello stabilimento balneare con il suo partner. Iniziamo a pensare ai tempi di inattività. Mi viene in mente: devi sdraiarti lì per cinque minuti, non di più. E allora sorge spontanea la domanda: quante vendite ci sono state in generale da questo nostro sito? Quanto...quanto? Cosa significa "zero"? E questo significa: perché il generale l'anno scorso ha fatto tutte e quattro le transazioni allo stesso tavolo, con le stesse persone con cui vanno allo stabilimento balneare e si siedono al tavolo. E capiamo che anche se il sito resta fermo per un giorno, non accadrà nulla di terribile.
Sulla base delle informazioni introduttive, c'è un giorno per sollevare questa storia. Cominciamo a pensare a un piano di licenziamento. E scegliamo lo schema di ridondanza più ideale per questo esempio: non utilizziamo la ridondanza. Tutta questa faccenda può essere sollevata da qualsiasi amministratore in mezz'ora con pause fumo. Installa un server web, aggiungi file: il gioco è fatto. Funzionerà. Non è necessario tenere d'occhio nulla, non è necessario prestare particolare attenzione a nulla. La conclusione dell'esempio numero uno è quindi abbastanza ovvia: i servizi che non necessitano di essere prenotati non hanno bisogno di essere prenotati.
Esempio numero due
Blog aziendale: lì persone appositamente formate scrivono notizie, abbiamo preso parte a questa o quella mostra, ma abbiamo rilasciato un altro nuovo prodotto e così via. Diciamo che questo è PHP standard con WordPress, un piccolo database e un po' di statico. Naturalmente, mi viene in mente ancora una volta che non dovresti in nessun caso sdraiarti - "non più di cinque minuti!" Questo è tutto. Ma ragioniamo oltre. Cosa fa questo blog? Le persone vengono lì da Yandex, da Google in base ad alcune query, in modo organico. Grande. Le vendite c'entrano qualcosa? Epifania: non proprio. Il traffico pubblicitario va al sito principale, che si trova su un computer diverso. Cominciamo a pensare a uno schema di prenotazione. In senso buono, deve essere sollevato in un paio d'ore e sarebbe bello prepararsi per questo. Sarebbe ragionevole prendere una macchina da un altro data center, installarvi l'ambiente, ovvero un server web, PHP, WordPress, MySQL e lasciarla lì. Nel momento in cui capiamo che tutto è rotto, dobbiamo fare due cose: srotolare il dump mysql di 50 metri, volerà lì in un minuto e srotolare lì un certo numero di immagini dal backup. Anche questo non è lì da Dio sa quanto tempo. Quindi, in mezz'ora tutto si alza. Nessuna replica, o Dio mi perdoni, failover automatico. Conclusione: ciò che possiamo implementare rapidamente da un backup non ha bisogno di essere sottoposto a backup.
Esempio numero tre, più complicato
Negozio online. PhP con cuore aperto è un po' ottimizzato, MySQL con una base solida. Un bel po' di statico (dopotutto, il negozio online ha bellissime immagini HD e tutta quella roba), Redis per la sessione ed Elasticsearch per la ricerca. Iniziamo a pensare ai tempi di inattività. E qui, ovviamente, è ovvio che un negozio online non può restare indolore per un giorno. Dopotutto, più a lungo si trova, più soldi perdiamo. Vale la pena accelerare. Quanto? Penso che se ci rilassiamo per un'ora, nessuno impazzirà. Sì, perderemo qualcosa, ma se iniziamo a lavorare duro, le cose non potranno che peggiorare. Definiamo uno schema di tempi di inattività consentiti ogni ora.
Come si può riservare tutto questo? L'auto è comunque necessaria: un'ora di tempo è davvero poco. Mysql: qui abbiamo già bisogno della replica, della replica live, perché tra un'ora molto probabilmente non verranno aggiunti 100 GB al dump. Statiche, immagini: ancora una volta, in un'ora potrebbero non avere il tempo di essere aggiunti 500 GB. Pertanto, è meglio copiare subito le immagini. Redis: è qui che le cose si fanno interessanti. In Redis, le sessioni vengono archiviate: non possiamo semplicemente prenderle e seppellirle. Perché questo non andrà molto bene: tutti gli utenti verranno disconnessi, i loro cestini verranno svuotati e così via. Le persone saranno costrette a reinserire nome utente e password e molte persone potrebbero allontanarsi e non completare l'acquisto. Ancora una volta, le conversioni diminuiranno. D'altro canto Redis è direttamente aggiornato e probabilmente non sono nemmeno necessari gli ultimi utenti registrati. E un buon compromesso è prendere Redis e ripristinarlo da un backup di ieri o, se lo fai ogni ora, di un'ora fa. Fortunatamente, ripristinarlo da un backup significa copiare un file. E la storia più interessante è Elasticsearch. Chi ha mai utilizzato la replica di MySQL? Chi ha mai utilizzato la replica Elasticsearch? E per chi ha funzionato normalmente dopo? Ciò che intendo è che vediamo una certa entità nel nostro sistema. Sembra essere utile, ma è complesso.
Complesso nel senso che i nostri colleghi ingegneri non hanno esperienza nel lavorarci. Oppure c'è un'esperienza negativa. Oppure capiamo che questa è ancora una tecnologia abbastanza nuova con sfumature o crudezza. Pensiamo... Cavolo, anche l'elastico è salutare, inoltre ci vuole molto tempo per ripristinarlo da un backup, cosa devo fare? Comprendiamo che l'elastico nel nostro caso viene utilizzato per la ricerca. Come vende il nostro negozio online? Andiamo dagli esperti di marketing e chiediamo da dove vengono le persone in generale. Rispondono: "Il 90% del mercato Yandex arriva direttamente alla scheda prodotto". E o lo comprano oppure no. Pertanto, la ricerca è necessaria al 10% degli utenti. E mantenere una replica elastica, soprattutto tra data center diversi in zone diverse, presenta davvero molte sfumature. Quale uscita? Prendiamo l'elastico da un sito riservato e non ne facciamo nulla. Se la questione si trascina, probabilmente un giorno la solleveremo, ma questo non è certo. In realtà, la conclusione è la stessa, più o meno: noi, ancora una volta, non riserviamo servizi che non incidono sul denaro. Per mantenere il diagramma più semplice.
Esempio numero quattro, ancora più difficile
Integratore: vendere fiori, chiamare un taxi, vendere merci, in generale, qualsiasi cosa. Una cosa seria che funziona 24 ore su 7, 5 giorni su XNUMX per un gran numero di utenti. Con uno stack interessante a tutti gli effetti, dove ci sono basi interessanti, soluzioni, carico elevato e, soprattutto, fa male sdraiarsi per più di XNUMX minuti. Non solo e non tanto perché le persone non compreranno, ma perché le persone vedranno che questa cosa non funziona, si arrabbieranno e potrebbero non tornare affatto.
OK. Cinque minuti. Cosa faremo a riguardo? In questo caso, noi, come gli adulti, utilizziamo tutti i soldi per costruire un vero sito di backup, con la replica di tutto, e forse anche automatizzare il più possibile il passaggio a questo sito. E oltre a questo bisogna ricordarsi di fare una cosa importante: scrivere, infatti, le norme sul cambio. La regolamentazione, anche se è tutto automatizzato, può essere molto semplice. Dalla serie "esegui questo o quell'altro script ansible", "fai clic su questa o quella casella di controllo nel percorso 53" e così via, ma questo deve essere una sorta di elenco esatto di azioni.
E tutto sembra chiaro. Cambiare la replica è un compito banale, altrimenti cambierà da solo. La riscrittura di un nome di dominio in DNS appartiene alla stessa serie. Il problema è che quando un progetto del genere fallisce, scoppia il panico e anche gli amministratori barbuti più forti possono esserne soggetti. Senza istruzioni chiare “apri il terminale, vieni qui, l’indirizzo del nostro server è ancora così”, è difficile rispettare il limite di tempo di 5 minuti assegnato per la rianimazione. Ebbene, in più, quando utilizziamo queste normative, è facile registrare alcuni cambiamenti nell’infrastruttura, ad esempio, e modificare le normative di conseguenza.
Bene, se il sistema di prenotazione è molto complesso e ad un certo punto abbiamo commesso un errore, allora possiamo distruggere il nostro sito di backup e inoltre trasformare i dati in una zucca su entrambi i siti: questo sarà completamente triste.
Esempio numero cinque, hardcore completo
Un servizio internazionale con centinaia di milioni di utenti in tutto il mondo. Ci sono tutti i fusi orari, carico elevato alla massima velocità, non puoi sdraiarti affatto. Un minuto - e sarà triste. Cosa fare? Prenotate, ancora una volta, secondo il programma completo. Abbiamo fatto tutto quello di cui ho parlato nell'esempio precedente, e anche un po' di più. Un mondo ideale e la nostra infrastruttura è conforme a tutti i concetti di IaaC devops. Cioè, tutto è in Git e basta premere il pulsante.
Che cosa manca? Uno: esercizi. È impossibile senza di loro. Sembra che con noi tutto sia perfetto, generalmente abbiamo tutto sotto controllo. Premiamo il pulsante, succede tutto. Anche se è così - e comprendiamo che non accade in questo modo - il nostro sistema interagisce con altri sistemi. Ad esempio, questo è DNS dal percorso 53, archiviazione s3, integrazione con alcune API. Non saremo in grado di prevedere tutto in questo esperimento speculativo. E finché non premeremo effettivamente l’interruttore, non sapremo se funzionerà o meno.
Probabilmente è tutto. Non essere pigro e non esagerare. E che il tempo di attività sia con te!
Fonte: habr.com