Questo documento nel framework dell'architettura Google Cloud fornisce principi operativi per eseguire il tuo servizio in modo affidabile, ad esempio come eseguire il deployment degli aggiornamenti, eseguire i servizi in ambienti di produzione e testare gli errori. Un'architettura per l'affidabilità dovrebbe coprire l'intero ciclo di vita del servizio, non solo la progettazione del software.
Scegliere nomi appropriati per applicazioni e servizi
Evita di utilizzare nomi in codice interni nei file di configurazione di produzione, perché potrebbero generare confusione, in particolare per i dipendenti più recenti, e aumentare potenzialmente i tempi di mitigazione (TTM) in caso di interruzioni. Scegli il più possibile nomi ottimali 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 dei nomi. Un buon nome descrive lo scopo dell'entità, è preciso, specifico e distintivo ed è significativo per chiunque lo veda. Un buon nome evita acronimi, nomi in codice, abbreviazioni e terminologia potenzialmente offensiva e non creerebbe una risposta pubblica negativa anche se pubblicata esternamente.
Esegui implementazioni progressive con i test canary
Le modifiche globali istantanee ai programmi binari o alla configurazione dei servizi sono intrinsecamente rischiose. Implementa le nuove versioni degli eseguibili e le modifiche alla configurazione in modo incrementale. Inizia con un ambito ristretto, ad esempio alcune istanze VM in una zona, ed espandi gradualmente l'ambito. Esegui rapidamente il rollback se la modifica non funziona come previsto o ha un impatto negativo sugli utenti in qualsiasi fase dell'implementazione. Il tuo obiettivo è identificare e risolvere i bug quando interessano solo una piccola parte del traffico degli utenti, prima di implementare la modifica a livello globale.
Configura un sistema di test canary che rileva le modifiche al servizio ed esegua il confronto A/B delle metriche dei server modificati con quelli dei server rimanenti. Il sistema deve segnalare comportamenti imprevisti o anomali. Se la modifica non funziona come previsto, il sistema di test canary dovrebbe interrompere automaticamente le implementazioni. I problemi possono essere chiari, come errori utente, o poco visibili, come un aumento dell'utilizzo della CPU o un sovraccarico della memoria.
È meglio fermarsi ed eseguire il rollback al primo segnale che si è verificato un guasto e diagnosticare i problemi senza la pressione del tempo di un'interruzione. Dopo che la modifica ha superato i test canary, propagala gradualmente agli ambiti più grandi, ad esempio a una zona completa e poi a una seconda zona. Lascia al sistema modificato il tempo necessario per gestire volumi progressivamente maggiori di traffico degli utenti al fine di esporre eventuali bug latenti.
Per ulteriori informazioni, consulta Strategie di deployment e test delle applicazioni.
Diffondi il traffico per promozioni e lanci a tempo
Potresti avere eventi promozionali, come i saldi che iniziano a un'ora precisa e incoraggiano molti utenti a connettersi contemporaneamente al servizio. In tal caso, progetta un codice client in modo da distribuire il traffico nell'arco di pochi secondi. Usa ritardi casuali prima di avviare le richieste.
Puoi anche preparare il sistema. Quando preriscalda il sistema, invii in anticipo il traffico utente previsto per assicurarti che funzioni come previsto. Questo approccio evita picchi di traffico istantanei che potrebbero causare l'arresto anomalo dei server all'ora di inizio pianificata.
Automatizza creazione, test e deployment
Elimina lo sforzo manuale dal processo di rilascio con l'uso delle pipeline di integrazione continua e distribuzione continua (CI/CD). Esegui test e deployment dell'integrazione automatizzati. Ad esempio, crea un processo CI/CD moderno con GKE.
Per ulteriori informazioni, consulta le pagine relative a integrazione continua, distribuzione continua, automazione dei test e automazione del deployment.
Difenditi dall'errore dell'operatore
Progetta i tuoi 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 imprevista o non viene ricevuta nei tempi previsti. Gli strumenti dovrebbero inoltre rifiutare le versioni di configurazione troppo diverse dalla versione precedente.
Non consentire modifiche o comandi con un ambito troppo ampio che possono essere potenzialmente distruttivi. Questi comandi generici potrebbero essere "Revoca le autorizzazioni per tutti gli utenti", "Riavvia tutte le VM in questa regione" o "Riformattazione di tutti i dischi in questa zona". Queste modifiche devono essere applicate solo se l'operatore aggiunge flag della riga di comando di override di emergenza o impostazioni delle opzioni quando esegue il deployment della configurazione.
Gli strumenti devono visualizzare l'ampiezza dell'impatto dei comandi rischiosi, ad esempio il numero di VM interessate dalle modifiche, e devono richiedere l'esplicita conferma dell'operatore prima che lo strumento prosegua. Puoi anche utilizzare le funzionalità per bloccare le risorse critiche e impedirne l'eliminazione accidentale o non autorizzata, ad esempio i blocchi dei criteri di conservazione di Cloud Storage.
Testa il ripristino da errori
Testa regolarmente le tue procedure operative per il ripristino in caso di errori nel tuo servizio. 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, il rollback di una release e il ripristino dei dati dai backup.
Esegui test di ripristino di emergenza
Come per i test di ripristino da errori, non aspettare che venga colpito un disastro. Testa e verifica periodicamente le procedure e i processi di ripristino di emergenza.
Potresti creare un'architettura di sistema per fornire l'alta disponibilità (HA). Questa architettura non si sovrappone completamente al ripristino di emergenza (RE), ma è spesso necessario tenere conto dell'alta disponibilità quando si pensa ai valori RTO (Recovery Time Objective) e RPO (Recovery Point Objective).
L'alta disponibilità ti aiuta a raggiungere o superare un livello concordato di prestazioni operative, come l'uptime. Quando esegui carichi di lavoro di produzione su Google Cloud, potresti eseguire il deployment di un'istanza di standby passivo o attivo in una seconda regione. Con questa architettura, l'applicazione continua a fornire il servizio dalla regione non interessata in caso di emergenza nella regione principale. Per ulteriori informazioni, consulta Architettura del ripristino di emergenza in caso di interruzioni del cloud.
Esercitati con l'ingegneria del caos
Considera l'uso dell'ingegneria del caos nelle tue pratiche di test. Introduci i guasti effettivi in diversi componenti dei sistemi di produzione sotto carico in un ambiente sicuro. Questo approccio aiuta a garantire che non vi sia alcun impatto complessivo sul sistema, perché il servizio gestisce correttamente gli errori a ogni livello.
Gli errori inseriti nel sistema possono includere attività in cui si verificano arresti anomali, errori e timeout sulle RPC o riduzioni della disponibilità delle risorse. Utilizza l'iniezione di guasti casuali per testare gli errori intermittenti (flapping) nelle dipendenze del servizio. Questi comportamenti sono difficili da rilevare e mitigare in produzione.
L'ingegneria del caos assicura che le conseguenze di questi esperimenti siano ridotte al minimo e contenute. Tratta questi test come pratica per le interruzioni effettive e utilizza tutte le informazioni raccolte per migliorare la risposta alle interruzioni.
Passaggi successivi
- Crea avvisi efficienti (prossimo documento di questa serie)
Esplora altre categorie nel framework dell'architettura come progettazione del sistema, eccellenza operativa e sicurezza, privacy e conformità.