Questo documento del framework dell'architettura di Google Cloud fornisce principi operativi per eseguire il servizio in modo affidabile, ad esempio come eseguire il deployment degli aggiornamenti, eseguire i servizi in ambienti di produzione e verificare la presenza di 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 essere confusi, in particolare per i dipendenti più recenti, aumentando potenzialmente il tempo di mitigazione (TTM) per le interruzioni. Per quanto possibile, scegli nomi appropriati per tutte le applicazioni, i servizi e le risorse di sistema critiche, come VM, cluster e istanze di database, rispettando i rispettivi limiti di lunghezza del nome. Un buon nome descrive lo scopo dell'entità, è preciso, specifico e distintivo e ha un significato per chiunque lo veda. Un buon nome evita acronimi, nomi in codice, abbreviature e terminologia potenzialmente offensiva e non crea una risposta pubblica negativa anche se pubblicato esternamente.
Esegui implementazioni progressive con i test canary
Le modifiche globali istantanee ai binari o alla configurazione dei servizi sono intrinsecamente rischiose. 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 di test canary che sia consapevole delle modifiche al servizio ed esegui il confronto A/B delle metriche dei server modificati con quelle dei server rimanenti. Il sistema 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 discreti, 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 i test canary, propagala gradualmente a ambiti più ampi, ad esempio a una zona completa, quindi a una seconda zona. Attendi che il sistema modificato gestisca volumi progressivamente maggiori di traffico utente per rilevare eventuali bug latenti.
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. In questo caso, progetta il codice client in modo da distribuire il traffico in alcuni 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 impedisce picchi di traffico istantaneo che potrebbero causare un arresto anomalo dei 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 il deployment e i test di integrazione. Ad esempio: crea un processo CI/CD moderno con GKE.
Per ulteriori informazioni, consulta integrazione continua, distribuzione continua, automazione dei test, e automazione del deployment.
Progettazione per la sicurezza
Progetta gli strumenti operativi in modo da rifiutare configurazioni potenzialmente non valide. Rileva e avvisa quando una versione della configurazione è vuota, parziale o troncata, danneggiata, logicamente errata o inaspettata oppure non viene ricevuta entro il tempo previsto. 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 le autorizzazioni per tutti gli 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 i flag o le impostazioni di opzione della riga di comando per l'override di emergenza durante 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 che lo strumento continua. 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 il failover regionale, come eseguire il rollback 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 un'alta disponibilità (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 verifica un'emergenza nella regione principale. Per ulteriori informazioni, vedi Architettura del ripristino di emergenza per interruzioni del cloud.
Esercitati con l'ingegneria del caos
Prendi in considerazione l'uso dell'ingegneria del caos nelle tue pratiche di test. Introducere guasti effettivi in diversi componenti dei sistemi di produzione sotto carico in un ambiente sicuro. 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 conseguenze di questi esperimenti siano minime e contenute. Tratta questi test come esercitazioni per le interruzioni effettive e utilizza tutte le informazioni raccolte per migliorare la risposta alle interruzioni.
Passaggi successivi
- Creare avvisi efficienti (documento successivo di questa serie)
- Esplora i consigli negli altri pilastri del Framework dell'architettura.