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 servizi in ambienti di produzione e testare gli errori. L'architettura per l'affidabilità dovrebbe 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 dipendenti più recenti, aumentando potenzialmente il tempo di mitigazione (TTM) in caso di interruzioni. Scegli il più possibile nomi appropriati per tutte le applicazioni, tutti i servizi e risorse di sistema critiche, come VM, cluster e istanze di database, rispettando i rispettivi limiti sulla lunghezza dei nomi. Un nome appropriato descrive lo scopo dell'entità, è accurato, specifico e distintivo e ha un senso per chiunque la veda. Un nome appropriato evita acronimi, nomi in codice, abbreviazioni e terminologia potenzialmente offensivo e non creerebbe una risposta pubblica negativa anche se pubblicata esternamente.
Esegui implementazioni progressive con i test canary
Le modifiche globali istantanee ai file binari dei servizi o alla configurazione 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 espandi gradualmente l'ambito. Esegui rapidamente il rollback se la modifica non ha il rendimento previsto o non influisce negativamente 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 a conoscenza delle modifiche al servizio ed esegue un confronto A/B delle metriche dei server modificati con quelle dei server rimanenti. Il sistema deve segnalare i 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 dell'utente, o lievi, come l'aumento dell'utilizzo della CPU o il sovraccarico della memoria.
È meglio fermarsi e rollback al primo accenno del problema e diagnosticare i problemi senza il tempo necessario per un'interruzione. Una volta 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. Lasciare al sistema modificato il tempo di gestire volumi progressivamente maggiori di traffico degli utenti per 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, ad esempio saldi che iniziano a un'ora esatta e che 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. Utilizza ritardi casuali prima di avviare le richieste.
Puoi anche preriscaldare il sistema. Durante il preriscaldamento del sistema, gli 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 build, test e deployment
Elimina gli sforzi manuali dal processo di rilascio con l'uso delle pipeline di integrazione e distribuzione continua (CI/CD). Esegui test di integrazione e deployment automatizzati. Ad esempio, crea un processo CI/CD moderno con GKE.
Per saperne di più, 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 avvisa quando una versione di configurazione è vuota, parziale o troncata, danneggiata, logicamente errata o imprevista o non viene ricevuta entro i tempi previsti. Gli strumenti dovrebbero anche rifiutare versioni di configurazione troppo diverse dalla versione precedente.
Non consentire modifiche o 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". Tali modifiche dovrebbero essere applicate solo se l'operatore aggiunge flag della riga di comando o impostazioni delle opzioni di override di emergenza durante il deployment della configurazione.
Gli strumenti devono mostrare l'ampiezza dell'impatto dei comandi rischiosi, ad esempio il numero di VM interessate dalla modifica, e richiedono l'accettazione esplicita dell'operatore prima di utilizzare lo strumento. Puoi inoltre 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 procedure operative per risolvere gli errori del 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 a livello di regione, 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 attendere 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). Questa architettura non si sovrappone completamente al ripristino di emergenza (RE), ma è spesso necessario prendere in considerazione l'alta disponibilità quando si pensa ai valori RTO (Recovery Time Objective) e RPO (Recovery Point Objective).
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 passiva o attiva 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 maggiori informazioni, consulta Architecting ripristino di emergenza per 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à di arresto anomalo, errori e timeout nelle RPC o riduzioni della disponibilità delle risorse. Usa l'iniezione 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 garantisce che le ripercussioni di questi esperimenti siano ridotte al minimo e contenute. Tratta questi test come pratica per 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 di sistemi, eccellenza operativa e sicurezza, privacy e conformità.