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 tue applicazioni, i tuoi 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 gradualmente nuove versioni degli eseguibili e modifiche alla configurazione. Inizia con un ambito ristretto, ad esempio alcune istanze VM in una zona, e amplialo gradualmente. Esegui il rollback rapidamente se la modifica non funziona come previsto o influisce negativamente sugli utenti in qualsiasi fase dell'implementazione. Il tuo scopo è 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 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 funziona come previsto, il sistema di test canary dovrebbe interrompere automaticamente i deployment. I problemi possono essere evidenti, come errori utente, o sottili, come l'aumento dell'utilizzo della CPU o l'aumento della memoria.
È meglio interrompere e eseguire il rollback al primo accenno di problemi e diagnosticare i problemi senza la pressione del 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 vendite che iniziano a un'ora precisa e incoraggiano molti utenti a connettersi contemporaneamente al servizio. In questo caso, progetta il codice client in modo da distribuire il traffico in alcuni secondi. Utilizza ritardi casuali prima di avviare le richieste.
Puoi anche preriscaldare l'impianto. Quando preriscaldi il sistema, invii in anticipo il traffico utente che prevedi per assicurarti che funzioni come previsto. Questo approccio impedisce picchi di traffico istantaneo che potrebbero causare un arresto anomalo dei server all'ora di inizio pianificata.
Automatizza la creazione, i test e il deployment
Elimina le operazioni manuali dal processo di rilascio con l'utilizzo di pipeline di integrazione e distribuzione continua (CI/CD). Esegui test di integrazione e deployment automatici. 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.
Progettazione per la sicurezza
Progetta gli strumenti operativi in modo che rifiutino le 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 le versioni di configurazione che differiscono troppo dalla versione precedente.
Non consentire modifiche o comandi con un ambito troppo ampio e potenzialmente dannosi. 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, ad esempio il numero di VM interessate dalla modifica, e richiedere il riconoscimento esplicito dell'operatore prima che lo strumento proceda. 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.
Testa il ripristino dagli errori
Testa regolarmente le procedure operative per recuperare dagli errori nel servizio. Senza test regolari, le procedure potrebbero non funzionare quando ne hai bisogno se si verifica un vero e proprio errore. 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 si verifichi un disastro. Testa e verifica periodicamente le procedure di ripristino di emergenza.
Potresti creare un'architettura di sistema per fornire alta disponibilità (HA). Questa architettura non si sovrappone completamente al ripristino di emergenza (RE), ma spesso è necessario prendere in considerazione l'HA quando si pensa ai valori di RTO (Recovery Time Objective) e RPO (Recovery Point Objective).
L'HA ti 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 di standby passiva o attiva 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, consulta Architettare ripristino di emergenza per le interruzioni del cloud.
Esercitarsi con l'ingegneria del caos
Valuta la possibilità di utilizzare l'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 contribuisce a garantire che non ci sia alcun impatto complessivo sul sistema perché il servizio gestisce gli errori correttamente a ogni livello.
Gli errori che inietti nel sistema possono includere arresti anomali delle attività, errori e timeout nelle RPC o riduzioni della disponibilità delle risorse. Utilizza l'iniezione di errori random per testare i guasti intermittenti (flapping) nelle dipendenze dei servizi. 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.