Questo documento nel Framework dell'architettura Google Cloud fornisce i principi operativi per eseguire il tuo servizio in modo affidabile, come eseguire il deployment degli aggiornamenti, eseguire i servizi in ambienti di produzione e testare gli errori. L'architettura per l'affidabilità deve coprire l'intero ciclo di vita del servizio, non solo la progettazione del software.
Scegli nomi appropriati per applicazioni e servizi
Evita di utilizzare nomi di codice interni nei file di configurazione di produzione, perché possono creare confusione, in particolare per i nuovi assunti, aumentando potenzialmente il tempo per mitigare (TTM) le interruzioni. Per quanto possibile, scegli nomi appropriati per tutti i tuoi applicazioni, servizi e risorse di sistema fondamentali come VM, cluster di database, soggetti ai rispettivi limiti di lunghezza. Un buon nome descriva lo scopo della persona giuridica; siano accurati, specifici e distintivi; ed è significativo per chiunque le veda. Un nome efficace evita acronimi, nomi in codice, abbreviazioni e terminologia potenzialmente offensiva e non creerebbe un anche se pubblicata esternamente.
Esegui implementazioni progressive con i test canary
Vengono apportate modifiche globali istantanee ai file binari dei servizi o alla configurazione di per sé rischioso. Implementa nuove versioni degli eseguibili e modifiche alla configurazione in modo incrementale. Inizia con un ambito ridotto, ad esempio alcune istanze VM in una zona, ed espandere gradualmente l'ambito. Esegui rapidamente il rollback se la modifica non funziona come previsto o influisce negativamente sugli utenti in qualsiasi fase dell'implementazione. Il tuo l'obiettivo è identificare e risolvere i bug che interessano solo una piccola parte di utenti, prima di implementare la modifica a livello globale.
Configura un sistema canary test che sia a conoscenza delle modifiche al servizio e che esegua A/B un confronto delle metriche dei server modificati con quelle dei server rimanenti. La deve segnalare comportamenti imprevisti o anomali. Se la modifica non viene applicata funzionino come previsto, il sistema di test canary dovrebbe arrestarsi automaticamente i prodotti. I problemi possono essere chiari, ad esempio errori dell'utente, o impercettibili, come l'utilizzo della CPU. o aumento della memoria.
È meglio fermarsi e rollback al primo suggerimento di problemi senza la pressione di tempo di un'interruzione. Dopo che la modifica ha superato la versione canary test, propagalo gradualmente ad ambiti più grandi, ad esempio a una zona completa, in una seconda zona. Concedi al sistema modificato il tempo di gestire progressivamente di volumi di traffico utente più elevati per esporre eventuali bug latenti.
Per ulteriori informazioni, vedi Strategie di deployment e test delle applicazioni.
Diffondi il traffico per promozioni e lanci a tempo
Potresti avere eventi promozionali, ad esempio saldi che iniziano a un'ora precisa e incoraggiare molti utenti a connettersi contemporaneamente al servizio. Se sì, progettare un codice client in modo da distribuire il traffico nell'arco di pochi secondi. Usa ritardi casuali prima che avviino le richieste.
Puoi anche preriscaldare il sistema. Quando preriscalda il sistema, invii il traffico di utenti che prevedi di ricevere in anticipo per assicurarti che funzioni mentre in base alle previsioni. Questo approccio previene picchi di traffico istantanei che potrebbero arrestarsi in modo anomalo dai server all'ora di inizio pianificata.
Automatizza build, test e deployment
Elimina il lavoro manuale dal processo di rilascio grazie all'uso di di integrazione e distribuzione continua (CI/CD). Esegui i test automatici di integrazione e deployment. Ad esempio: crea un processo CI/CD moderno con GKE.
Per ulteriori informazioni, consulta la sezione sull'integrazione continua. distribuzione continua, l'automazione dei test, e l'automazione del deployment.
Progetta tenendo a mente la sicurezza
Progetta gli strumenti operativi in modo da rifiutare configurazioni potenzialmente non valide. Rileva e invia un avviso quando una versione di configurazione è vuota, parziale o troncata corrotti, errati o imprevisti, o non ricevuti nei tempi previsti nel tempo. Gli strumenti devono anche rifiutare versioni di configurazione troppo diverse da la versione precedente.
Non consentire modifiche o comandi con un ambito troppo ampio che potrebbero essere distruttivi. Questi comandi generici potrebbero essere "Revoca autorizzazioni per tutti utenti", "Riavvia tutte le VM in questa regione" o "Riformatta tutti i dischi in questa zona". Queste modifiche devono essere applicate solo se l'operatore aggiunge il override di emergenza tramite flag della riga di comando o impostazioni delle opzioni quando eseguono il deployment della configurazione.
Gli strumenti devono mostrare l'ampiezza dell'impatto dei comandi rischiosi, come il numero VM interessate dalla modifica e richiedono l'accettazione esplicita da parte dell'operatore prima dello strumento. Puoi anche utilizzare le funzionalità per bloccare risorse critiche e prevenire l'eliminazione accidentale o non autorizzata, ad esempio Blocchi dei criteri di conservazione di Cloud Storage.
Testa il ripristino da errori
Testa regolarmente le tue procedure operative per risolvere gli errori nel tuo completamente gestito di Google Cloud. Senza test regolari, le procedure potrebbero non funzionare quando ne hai bisogno in caso di errore reale. Gli elementi da testare periodicamente includono informazioni regionali il failover di una release e come ripristinare i dati dai backup.
Esegui test di ripristino di emergenza
Come per i test di ripristino da errori, non aspettare che si verifichi un'emergenza. Testa e verifica periodicamente le tue procedure e i tuoi processi di ripristino di emergenza.
Potresti creare un'architettura di sistema per fornire disponibilità elevata (HA). Questo Transformer non si sovrappone completamente al ripristino di emergenza (RE), ma spesso necessario considerare l'alta disponibilità quando si pensa al tempo di ripristino RTO (Recovery Point Objective) e un RPO (Recovery Point Objective).
L'alta disponibilità ti aiuta a raggiungere o superare un livello concordato di prestazioni operative, come uptime. Quando esegui carichi di lavoro di produzione su Google Cloud, potresti eseguire il deployment un'istanza passiva o attiva in standby in una seconda regione. Con questa architettura, l'applicazione continua a fornire il servizio dalla regione non interessata se si è verificata un'emergenza nella regione principale. Per ulteriori informazioni, vedi Architettura del ripristino di emergenza per le interruzioni del servizio cloud.
Esercitati con l'ingegneria del caos
Considera l'uso dell'ingegneria del caos nelle tue pratiche di test. Presenta gli effettivi in diversi componenti dei sistemi di produzione sotto carico e in completamente gestito di Google Cloud. Questo approccio aiuta a garantire che non ci sia alcun impatto complessivo sul sistema. perché il tuo servizio gestisce correttamente gli errori a ogni livello.
Gli errori che inserisci nel sistema possono includere attività di arresto anomalo, errori e i timeout sulle RPC o le riduzioni della disponibilità delle risorse. Utilizza errore casuale l'iniezione di dati per testare errori intermittenti (flapping) nelle dipendenze del servizio. Questi comportamenti sono difficili da rilevare e mitigare in produzione.
L'ingegneria del caos garantisce che le ricadute di questi esperimenti siano ridotte al minimo. contenuti. Tratta questi test come pratica per interruzioni effettive e utilizza tutte le le informazioni raccolte per migliorare la risposta alle interruzioni.
Passaggi successivi
- Crea avvisi efficienti (prossimo documento di questa serie)
Esplora altre categorie nella Framework dell'architettura come progettazione dei sistemi, eccellenza operativa, sicurezza, privacy e conformità.