Questo documento nel framework dell'architettura Google Cloud fornisce i principi operativi per eseguire il tuo servizio in modo affidabile, ad esempio come eseguire il deployment degli aggiornamenti, eseguire servizi in ambienti di produzione e testare gli errori. Un'architettura per l'affidabilità dovrebbe coprire l'intero ciclo di vita del tuo servizio, non solo la progettazione del software.
Scegli 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 appropriati per tutte le tue applicazioni, i tuoi servizi e le tue risorse di sistema critiche, come VM, cluster e istanze di database, rispettando i rispettivi limiti di lunghezza dei nomi. Un nome appropriato descrive lo scopo dell'entità, è preciso, specifico e distintivo ed è significativo per chiunque lo vede. Un nome corretto 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 nuove versioni degli eseguibili e apporta modifiche alla configurazione in modo incrementale. Inizia con un ambito piccolo, 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 sia consapevole delle 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 genera il rendimento previsto, il sistema di test canary dovrebbe interrompere automaticamente le implementazioni. I problemi possono essere chiari, ad esempio errori utente, o poco visibili, come l'aumento dell'utilizzo della CPU o il sovraccarico della memoria.
È meglio interrompere ed eseguire il rollback al primo suggerimento e diagnosticare i problemi senza il carico di lavoro di un'interruzione. Dopo che la modifica ha superato i test canary, propagala gradualmente ad ambiti più grandi, ad esempio a una zona completa e poi a una seconda zona. Lascia al sistema cambiato il tempo di gestire volumi sempre più elevati di traffico degli utenti in modo da esporre eventuali bug latenti.
Per maggiori informazioni, consulta Strategie di test e deployment delle applicazioni.
Diffondi il traffico per promozioni e lanci a tempo
Potresti avere eventi promozionali, ad esempio saldi che iniziano a un orario specifico e incoraggiano molti utenti a connettersi contemporaneamente al servizio. Se sì, progetta il codice client in modo da distribuire il traffico in pochi secondi. Utilizza ritardi casuali prima che avviino le richieste.
Puoi anche preriscaldare l'impianto. Quando preriscalda il sistema, invii in anticipo il traffico utente previsto per assicurarti che funzioni come previsto. Questo approccio impedisce picchi di traffico istantanei che potrebbero causare l'arresto anomalo dei tuoi server all'ora di inizio pianificata.
Automatizza build, test e deployment
Elimina lo sforzo manuale dal processo di rilascio con l'uso di pipeline di integrazione continua e distribuzione continua (CI/CD). Esegui test di integrazione e deployment automatizzati. Ad esempio, crea un processo CI/CD moderno con GKE.
Per maggiori informazioni, consulta integrazione continua, distribuzione continua, automazione dei test e 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 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 che differiscono troppo rispetto alla versione precedente.
Non consentire le modifiche o i comandi con un ambito troppo ampio che sono potenzialmente 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 flag della riga di comando di override di emergenza o impostazioni delle opzioni durante il deployment della configurazione.
Gli strumenti devono mostrare l'impatto dei comandi rischiosi, ad esempio il numero di VM che incidono sulle modifiche, e devono richiedere un consenso esplicito dell'operatore prima che lo strumento prosegua. Puoi anche utilizzare 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.
Test del ripristino da errori
Testa regolarmente le tue procedure operative per il ripristino in caso di errori del tuo servizio. Senza test regolari, le procedure potrebbero non funzionare quando ne hai bisogno se si verifica un 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 l'evento di emergenza. Testa e verifica periodicamente le procedure e i processi di ripristino di emergenza.
Potresti creare un'architettura di sistema per fornire disponibilità elevata (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 dell'RTO (Recovery Time Objective) e del Recovery Point Objective (RPO).
L'alta disponibilità consente di 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 in standby passivo o attivo in una seconda regione. Con questa architettura, l'applicazione continua a fornire servizio dalla regione non interessata in caso di emergenza nella regione principale. Per maggiori informazioni, consulta 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. Introduci 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 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'inserimento di errori 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 ricadute 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à.