Google Cloud Well-Architected Framework: affidabilità

Last reviewed 2025-02-14 UTC

Il pilastro dell'affidabilità nel Google Cloud Framework Well-Architected fornisce principi e consigli per aiutarti a progettare, implementare e gestire carichi di lavoro affidabili in Google Cloud.

Questo documento è rivolto a cloud architect, sviluppatori, ingegneri di piattaforma, amministratori e SRE.

L'affidabilità è la capacità di un sistema di eseguire in modo coerente le funzioni previste all'interno delle condizioni definite e di mantenere un servizio ininterrotto. Le best practice per l'affidabilità includono ridondanza, progettazione fault-tolerant, monitoraggio e procedure di recupero automatico.

La resilienza è parte dell'affidabilità ed è la capacità del sistema di resistere e recuperare da guasti o interruzioni impreviste, mantenendo le prestazioni. Le funzionalitàGoogle Cloud , come i deployment multi-regionali, i backup automatici e le soluzioni di disaster recovery, possono aiutarti a migliorare la resilienza del tuo sistema.

L'affidabilità è importante per la tua strategia cloud per molti motivi, tra cui:

  • Tempi di inattività minimi: i tempi di inattività possono comportare perdita di entrate, produttività ridotta e danni alla reputazione. Le architetture resilienti possono contribuire a garantire che i sistemi possano continuare a funzionare durante gli errori o a riprendersi in modo efficiente dagli errori.
  • Esperienza utente migliorata: gli utenti si aspettano interazioni fluide con la tecnologia. I sistemi resilienti possono contribuire a mantenere prestazioni e disponibilità coerenti e a fornire un servizio affidabile anche in caso di domanda elevata o problemi imprevisti.
  • Integrità dei dati: gli errori possono causare la perdita o il danneggiamento dei dati. I sistemi resilienti implementano meccanismi come backup, ridondanza e replica per proteggere i dati e garantire che rimangano accurati e accessibili.
  • Continuità aziendale: la tua attività si basa sulla tecnologia per le operazioni critiche. Le architetture resilienti possono contribuire a garantire la continuità dopo un guasto catastrofico, consentendo alle funzioni aziendali di continuare senza interruzioni significative e supportando un rapido recupero.
  • Conformità: molti settori hanno requisiti normativi per la disponibilità del sistema e la protezione dei dati. Le architetture resilienti possono aiutarti a soddisfare questi standard garantendo che i sistemi rimangano operativi e sicuri.
  • Costi inferiori a lungo termine: le architetture resilienti richiedono un investimento iniziale, ma la resilienza può contribuire a ridurre i costi nel tempo impedendo i tempi di riposo costosi, evitando le correzioni reattive e consentendo un utilizzo più efficiente delle risorse.

Mentalità organizzativa

Per rendere affidabili i tuoi sistemi, hai bisogno di un piano e di una strategia consolidata. Questa strategia deve includere l'istruzione e l'autorità per dare la priorità all'affidabilità insieme ad altre iniziative.

Indica chiaramente che l'intera organizzazione è responsabile della affidabilità, inclusi sviluppo, gestione del prodotto, operazioni, ingegneria della piattaforma e ingegneria di affidabilità del sito (SRE). Anche i gruppi incentrati sulle attività, come marketing e vendite, possono influire sull'affidabilità.

Ogni team deve comprendere gli obiettivi di affidabilità e i rischi delle proprie applicazioni. I team devono essere responsabili del rispetto di questi requisiti. I conflitti tra affidabilità e sviluppo regolare delle funzionalità del prodotto devono essere assegnati la priorità e riassegnati di conseguenza.

Pianifica e gestisci l'affidabilità in modo olistico, in tutte le funzioni e in tutti i team. Valuta la possibilità di creare un Cloud Center of Excellence (CCoE) che includa un pilastro di affidabilità. Per ulteriori informazioni, consulta Ottimizzare il percorso cloud della tua organizzazione con un Cloud Center of Excellence.

Aree di intervento per l'affidabilità

Le attività che esegui per progettare, implementare e gestire un sistema affidabile possono essere classificate nelle seguenti aree di interesse. Ciascuno dei principi e dei consigli di affidabilità di questo pilastro è pertinente a una di queste aree di attenzione.

  • Definizione dell'ambito: per comprendere il sistema, esegui un'analisi dettagliata della sua architettura. Devi comprendere i componenti, il loro funzionamento e la loro interazione, il flusso di dati e azioni all'interno del sistema e cosa potrebbe andare storto. Identifica potenziali errori, colli di bottiglia e rischi, il che ti aiuta a intraprendere azioni per mitigare questi problemi.
  • Osservazione: per contribuire a evitare guasti del sistema, implementa un'osservazione e un monitoraggio completi e continui. Grazie a questa osservazione, puoi comprendere le tendenze e identificare in modo proattivo i potenziali problemi.
  • Risposta: per ridurre l'impatto degli errori, rispondi in modo appropriato e recupera in modo efficiente. Le risposte automatiche possono anche contribuire a ridurre l'impatto degli errori. Anche con la pianificazione e i controlli, possono verificarsi errori.
  • Apprendimento: per contribuire a evitare che gli errori si ripetano, impara da ogni esperienza e intraprendi le azioni appropriate.

Principi fondamentali

I consigli nel pilastro dell'affidabilità del framework Well-Architected sono mappati ai seguenti principi fondamentali:

Collaboratori

Autori:

Altri collaboratori:

Definire l'affidabilità in base agli obiettivi dell'esperienza utente

Questo principio del pilastro dell'affidabilità del Google Cloud Framework Well-Architected ti aiuta a valutare l'esperienza degli utenti e poi a mappare i risultati agli scopi e alle metriche di affidabilità.

Questo principio è pertinente all'ambito dell'area di attenzione dell'affidabilità.

Panoramica del principio

Gli strumenti di osservabilità forniscono grandi quantità di dati, ma non tutti si riferiscono direttamente all'impatto sugli utenti. Ad esempio, potresti notare un utilizzo elevato della CPU, operazioni del server lente o persino arresti anomali delle attività. Tuttavia, se questi problemi non influiscono sull'esperienza utente, non costituiscono un'interruzione del servizio.

Per misurare l'esperienza utente, devi distinguere tra il comportamento interno del sistema e i problemi che riguardano gli utenti. Concentrati su metriche come il rapporto di successo delle richieste degli utenti. Non fare affidamento solo su metriche incentrate sul server, come l'utilizzo della CPU, che possono portare a conclusioni fuorvianti sull'affidabilità del servizio. L'affidabilità vera e propria significa che gli utenti possono utilizzare la tua applicazione o il tuo servizio in modo coerente ed efficace.

Consigli

Per aiutarti a misurare l'esperienza utente in modo efficace, prendi in considerazione i consigli riportati nelle sezioni seguenti.

Misurare l'esperienza utente

Per comprendere appieno l'affidabilità del tuo servizio, dai la priorità alle metriche che riflettono l'esperienza effettiva dei tuoi utenti. Ad esempio, misura la percentuale di query riuscite degli utenti, la latenza dell'applicazione e i tassi di errore.

Idealmente, raccogli questi dati direttamente dal dispositivo o dal browser dell'utente. Se questa raccolta diretta dei dati non è fattibile, sposta il punto di misurazione progressivamente più lontano dall'utente nel sistema. Ad esempio, puoi utilizzare il bilanciatore del carico o il servizio frontend come punto di misurazione. Questo approccio ti aiuta a identificare e risolvere i problemi prima che possano avere un impatto significativo sui tuoi utenti.

Analizzare i percorsi degli utenti

Per capire in che modo gli utenti interagiscono con il tuo sistema, puoi utilizzare strumenti di monitoraggio come Cloud Trace. Se segui il percorso di un utente nella tua applicazione, puoi trovare colli di bottiglia e problemi di latenza che potrebbero peggiorare la sua esperienza. Cloud Trace acquisisce dati dettagliati sulle prestazioni per ogni hop nell'architettura del servizio. Questi dati ti aiutano a identificare e risolvere i problemi di prestazioni in modo più efficiente, in modo da offrire un'esperienza utente più affidabile e soddisfacente.

Imposta target realistici per l'affidabilità

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework ti aiuta a definire obiettivi di affidabilità tecnicamente possibili per i tuoi carichi di lavoro in Google Cloud.

Questo principio è pertinente all'ambito dell'area di attenzione dell'affidabilità.

Panoramica del principio

Progetta i tuoi sistemi in modo che siano sufficientemente affidabili per la soddisfazione degli utenti. Potrebbe sembrare controintuitivo, ma un obiettivo di affidabilità al 100% spesso non è la strategia più efficace. Una maggiore affidabilità potrebbe comportare un costo notevolmente superiore, sia in termini di investimento finanziario sia di potenziali limitazioni all'innovazione. Se gli utenti sono già soddisfatti del livello di servizio attuale, gli sforzi per aumentare ulteriormente la soddisfazione potrebbero generare un basso ritorno sull'investimento. In questo modo, puoi utilizzare meglio le risorse altrove.

Devi determinare il livello di affidabilità che soddisfa i tuoi utenti e il punto in cui il costo dei miglioramenti incrementali inizia a superare i vantaggi. Una volta stabilito questo livello di affidabilità sufficiente, puoi allocare le risorse in modo strategico e concentrarti su funzionalità e miglioramenti che offrono un valore maggiore ai tuoi utenti.

Consigli

Per impostare target di affidabilità realistici, tieni conto dei consigli riportati nelle seguenti sezioni.

Accettare alcuni errori e dare la priorità ai componenti

Mira a un'alta disponibilità, ad esempio un tempo di attività del 99,99%, ma non imposta un target di tempo di attività del 100%. Riconoscere che alcuni errori sono inevitabili.

Il divario tra il tempo di attività del 100% e un obiettivo del 99,99% è la tolleranza per i guasti. Questo divario viene spesso chiamato budget di errore. Il budget di errore può aiutarti a correre rischi e a innovare, il che è fondamentale per qualsiasi attività per rimanere competitiva.

Dai la priorità all'affidabilità dei componenti più critici del sistema. Accetta che i componenti meno critici possano avere una tolleranza agli errori più elevata.

Trova il giusto equilibrio tra affidabilità e costi

Per determinare il livello di affidabilità ottimale per il tuo sistema, esegui analisi approfondite costi-benefici.

Prendi in considerazione fattori quali i requisiti di sistema, le conseguenze degli errori e la tolleranza al rischio della tua organizzazione per l'applicazione specifica. Ricorda di considerare le metriche di ripristino di emergenza, come il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). Decidi quale livello di affidabilità è accettabile in base al budget e ad altri vincoli.

Cerca modi per migliorare l'efficienza e ridurre i costi senza compromettere le funzionalità di affidabilità essenziali.

Crea sistemi ad alta disponibilità tramite la ridondanza delle risorse

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per pianificare, creare e gestire la ridondanza delle risorse, che puoi aiutarti a evitare errori.

Questo principio è pertinente all'ambito dell'area di attenzione dell'affidabilità.

Panoramica del principio

Dopo aver deciso il livello di affidabilità di cui hai bisogno, devi progettare i tuoi sistemi per evitare qualsiasi singolo punto di errore. Ogni componente critico del sistema deve essere replicato su più macchine, zone e regioni. Ad esempio, un database critico non può trovarsi in una sola regione e un server di metadati non può essere dipiegato in una sola zona o regione. In questi esempi, se si verifica un'interruzione nella sola zona o regione, il sistema presenta un'interruzione globale.

Consigli

Per creare sistemi ridondanti, tieni presenti i consigli riportati nelle seguenti sezioni.

Identifica i domini di errore e replica i servizi

Mappa i domini di errore del sistema, dalle singole VM alle regioni, e progetta la ridondanza tra i domini di errore.

Per garantire l'alta disponibilità, distribuisci e replica i servizi e le applicazioni in più zone e regioni. Configura il sistema per il failover automatico per assicurarti che i servizi e le applicazioni continuino a essere disponibili in caso di interruzioni a livello di zona o regione.

Per esempi di architetture multizona e multiregione, consulta Progettare un'infrastruttura affidabile per i carichi di lavoro in Google Cloud.

Rileva e risolvi i problemi tempestivamente

Monitora continuamente lo stato dei tuoi domini di errore per rilevare e risolvere rapidamente i problemi.

Puoi monitorare lo stato corrente dei Google Cloud servizi in tutte le regioni utilizzando la Google Cloud dashboard di Service Health. Puoi anche visualizzare gli incidenti pertinenti al tuo progetto utilizzando Personalized Service Health. Puoi utilizzare i bilanciatori del carico per rilevare lo stato delle risorse e instradare automaticamente il traffico ai backend integri. Per ulteriori informazioni, consulta la panoramica dei controlli di integrità.

Testare gli scenari di failover

Come per un'esercitazione antincendio, simula regolarmente gli errori per convalidare l'efficacia delle tue strategie di replica e failover.

Per ulteriori informazioni, consulta Simulare un'interruzione di servizio in una zona per un gruppo di istanze gestite a livello di regione e Simulare un errore di zona nei cluster regionali GKE.

Sfrutta la scalabilità orizzontale

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per aiutarti a utilizzare la scalabilità orizzontale. Utilizzando la scalabilità orizzontale, puoi contribuire ad assicurare che i tuoi carichi di lavoro inGoogle Cloud possano essere scalati in modo efficiente e mantenere le prestazioni.

Questo principio è pertinente all'ambito dell'area di interesse dell'affidabilità.

Panoramica del principio

Riprogetta il sistema in un'architettura orizzontale. Per far fronte alla crescita del traffico o dei dati, puoi aggiungere altre risorse. Puoi anche rimuovere le risorse quando non sono in uso.

Per comprendere il valore della scalabilità orizzontale, prendi in considerazione le limitazioni della scalabilità verticale.

Uno scenario comune per l'escaling verticale è l'utilizzo di un database MySQL come database principale con dati critici. Con l'aumento dell'utilizzo del database, sono necessarie più RAM e CPU. Alla fine, il database raggiunge il limite di memoria sulla macchina host e deve essere eseguito l'upgrade. Questa procedura potrebbe dover essere ripetuta più volte. Il problema è che esistono limiti rigidi alla crescita di un database. Le dimensioni delle VM non sono illimitate. Il database può raggiungere un punto in cui non è più possibile aggiungere altre risorse.

Anche se le risorse fossero illimitate, una VM di grandi dimensioni può diventare un singolo punto di errore. Qualsiasi problema con la VM del database principale può causare risposte di errore o un'interruzione a livello di sistema che interessa tutti gli utenti. Evita i single point of failure, come descritto in Creare sistemi altamente disponibili tramite la ridondanza delle risorse.

Oltre a questi limiti di scalabilità, la scalabilità verticale tende ad essere più costosa. Il costo può aumentare in modo esponenziale man mano che vengono acquisite macchine con maggiore potenza di calcolo e memoria.

La scalabilità orizzontale, invece, può costare meno. Il potenziale di scalabilità orizzontale è praticamente illimitato in un sistema progettato per essere scalabile.

Consigli

Per passare da un'architettura a una singola VM a un'architettura orizzontale con più macchine, devi pianificare attentamente e utilizzare gli strumenti giusti. Per aiutarti a eseguire il scaling orizzontale, tieni presenti i consigli riportati nelle seguenti sezioni.

Utilizzare i servizi gestiti

I servizi gestiti eliminano la necessità di gestire manualmente la scalabilità orizzontale. Ad esempio, con i gruppi di istanze gestite (MIG) di Compute Engine, puoi aggiungere o rimuovere VM per scalare l'applicazione in orizzontale. Per le applicazioni containerizzate, Cloud Run è una piattaforma serverless che può scalare automaticamente i container stateless in base al traffico in entrata.

Promuovi il design modulare

Componenti modulari e interfacce chiare ti aiutano a scalare i singoli componenti in base alle esigenze, anziché l'intera applicazione. Per ulteriori informazioni, consulta Promuovere il design modulare nel pilastro sull'ottimizzazione del rendimento.

Implementare un design stateless

Progetta le applicazioni in modo che siano stateless, ovvero senza dati archiviati localmente. In questo modo, puoi aggiungere o rimuovere istanze senza preoccuparti della coerenza dei dati.

Rileva potenziali errori utilizzando l'osservabilità

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per aiutarti a identificare in modo proattivo le aree in cui potrebbero verificarsi errori e malfunzionamenti.

Questo principio è pertinente all'area di attenzione dell'osservazione dell'affidabilità.

Panoramica del principio

Per mantenere e migliorare l'affidabilità dei tuoi workload in Google Cloud, devi implementare un'osservabilità efficace utilizzando metriche, log e tracce.

  • Le metriche sono misurazioni numeriche delle attività che vuoi monitorare per la tua applicazione a intervalli di tempo specifici. Ad esempio, potresti voler monitorare metriche tecniche come la frequenza delle richieste e la percentuale di errori, che possono essere utilizzate come indicatori del livello del servizio (SLI). Potresti anche dover monitorare le metriche aziendali specifiche dell'applicazione, come gli ordini effettuati e i pagamenti ricevuti.
  • I log sono record con timestamp di eventi distinti che si verificano all'interno di un'applicazione o di un sistema. L'evento potrebbe essere un fallimento, un errore o una variazione di stato. I log potrebbero includere metriche e puoi anche utilizzarli per gli SLI.
  • Una traccia rappresenta il percorso di un singolo utente o transazione attraverso un numero di applicazioni separate o i componenti di un'applicazione. Ad esempio, questi componenti potrebbero essere microservizi. Le tracce ti aiutano a monitorare i componenti utilizzati nei percorsi, i colli di bottiglia esistenti e la durata dei percorsi.

Metriche, log e tracce ti aiutano a monitorare il sistema in modo continuo. Il monitoraggio completo ti aiuta a scoprire dove e perché si sono verificati errori. Puoi anche rilevare potenziali errori prima che si verifichino.

Consigli

Per rilevare in modo efficiente i potenziali errori, prendi in considerazione i consigli riportati nelle seguenti sezioni.

Ottenere informazioni complete

Per monitorare metriche chiave come tempi di risposta e percentuali di errore, utilizza Cloud Monitoring e Cloud Logging. Questi strumenti ti aiutano anche ad assicurarti che le metriche soddisfino in modo coerente le esigenze del tuo carico di lavoro.

Per prendere decisioni basate sui dati, analizza le metriche dei servizi predefiniti per comprendere le dipendenze dei componenti e il loro impatto sul rendimento complessivo del carico di lavoro.

Per personalizzare la tua strategia di monitoraggio, crea e pubblica le tue metriche utilizzando il Google Cloud SDK.

Esegui la risoluzione dei problemi in modo proattivo

Implementa una gestione degli errori efficace e abilita il logging in tutti i componenti del tuo carico di lavoro in Google Cloud. Attiva i log come log di accesso a Cloud Storage e log di flusso VPC.

Quando configuri la registrazione, tieni conto dei costi associati. Per controllare i costi di registrazione, puoi configurare i filtri di esclusione sui sink di log per escludere la memorizzazione di determinati log.

Ottimizzare l'utilizzo delle risorse

Monitora il consumo della CPU, le metriche di I/O di rete e le metriche di I/O del disco per rilevare le risorse sottodimensionate e sovradimensionate in servizi come GKE, Compute Engine e Dataproc. Per un elenco completo dei servizi supportati, consulta Panoramica di Cloud Monitoring.

Assegnare priorità agli avvisi

Per gli avvisi, concentrati sulle metriche critiche, imposta soglie appropriate per ridurre al minimo la fatica da avvisi e assicurarti risposte tempestive a problemi significativi. Questo approccio mirato consente di mantenere in modo proattivo l'affidabilità del carico di lavoro. Per ulteriori informazioni, consulta la panoramica degli avvisi.

Progettare per la riduzione controllata

Questo principio del pilastro dell'affidabilità del Google Cloud Framework Well-Architected fornisce suggerimenti per aiutarti a progettare i tuoi Google Cloud carichi di lavoro in modo che falliscano in modo corretto.

Questo principio è pertinente all'area di attenzione della risposta dell'affidabilità.

Panoramica del principio

Il degradamento graduale è un approccio di progettazione in cui un sistema con un carico elevato continua a funzionare, eventualmente con prestazioni o precisione ridotte. Il degradamento graduale garantisce la disponibilità continua del sistema e impedisce un guasto completo, anche se il funzionamento del sistema non è ottimale. Quando il carico ritorna a un livello gestibile, il sistema riprende la piena funzionalità.

Ad esempio, durante i periodi di carico elevato, la Ricerca Google dà la priorità ai risultati provenienti da pagine web con ranking più elevato, sacrificando potenzialmente un po' di accuratezza. Quando il carico diminuisce, la Ricerca Google ricalcola i risultati di ricerca.

Consigli

Per progettare i sistemi per la riduzione controllata, tieni presenti i consigli riportati nelle sezioni seguenti.

Implementare la limitazione

Assicurati che le repliche possano gestire in modo indipendente i sovraccarichi e possano limitare le richieste in arrivo durante gli scenari di traffico elevato. Questo approccio ti aiuta a evitare i guasti a cascata causati da trasferimenti di traffico in eccesso tra le zone.

Utilizza strumenti come Apigee per controllare la frequenza delle richieste API durante i periodi di traffico elevato. Puoi configurare le regole di criteri in base a come vuoi ridurre le richieste.

Eliminare in anticipo le richieste in eccesso

Configura i sistemi in modo che eliminino le richieste in eccesso a livello di livello frontend per proteggere i componenti di backend. L'eliminazione di alcune richieste impedisce i guasti globali e consente al sistema di riprendersi in modo più graduale.Con questo approccio, alcuni utenti potrebbero riscontrare errori. Tuttavia, puoi ridurre al minimo l'impatto delle interruzioni, diversamente da un approccio come l'interruzione del circuito, in cui tutto il traffico viene interrotto durante un sovraccarico.

Gestire errori parziali e tentativi di nuovo caricamento

Crea le tue applicazioni in modo che gestiscano gli errori parziali e le riavviate senza problemi. Questo design contribuisce a garantire che venga servito il maggior volume di traffico possibile durante gli scenari di carico elevato.

Testare gli scenari di sovraccarico

Per verificare che i meccanismi di throttling e di riduzione delle richieste funzionino in modo efficace, simula regolarmente condizioni di sovraccarico nel sistema. I test contribuiscono a garantire che il sistema sia preparato per i picchi di traffico reali.

Monitorare i picchi di traffico

Utilizza gli strumenti di analisi e monitoraggio per prevedere e rispondere ai picchi di traffico prima che si trasformino in sovraccarichi. Il rilevamento e la risposta tempestivi possono contribuire a mantenere la disponibilità del servizio durante i periodi di alta domanda.

Esegui test per il ripristino dagli errori

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per aiutarti a progettare ed eseguire test per il recupero in caso di errori.

Questo principio è pertinente all'area di interesse dell'apprendimento dell'affidabilità.

Panoramica del principio

Per assicurarti che il sistema possa riprendersi dagli errori, devi eseguire periodicamente test che includono failover regionali, rollback delle release e ripristino dei dati dai backup.

Questi test ti aiutano a fare pratica con le risposte a eventi che rappresentano rischi significativi per l'affidabilità, come l'interruzione di un'intera regione. Questi test ti aiutano anche a verificare che il sistema si comporti come previsto durante un'interruzione.

Nell'improbabile caso di interruzione di un'intera regione, devi eseguire il failover di tutto il traffico in un'altra regione. Durante il normale funzionamento del carico di lavoro, quando i dati vengono modificati, devono essere sincronizzati dalla regione principale alla regione di failover. Devi verificare che i dati replicati siano sempre molto recenti, in modo che gli utenti non perdano dati o non interrompano la sessione. Il sistema di bilanciamento del carico deve anche essere in grado di trasferire il traffico alla regione di failover in qualsiasi momento senza interruzioni del servizio. Per ridurre al minimo i tempi di inattività dopo un'interruzione a livello di regione, gli ingegneri operativi devono anche essere in grado di spostare manualmente e in modo efficiente il traffico dell'utente da una regione, nel minor tempo possibile. Questa operazione è talvolta chiamata svuotamento di una regione, il che significa che interrompi il traffico in entrata nella regione e sposti tutto il traffico altrove.

Consigli

Quando progetti ed esegui test per il recupero in caso di errore, tieni conto dei consigli riportati nelle sezioni seguenti.

Definisci gli scopi e l'ambito dei test

Definisci chiaramente cosa vuoi ottenere dai test. Ad esempio, i tuoi scopi possono includere:

Decidi quali componenti, servizi o regioni rientrano nell'ambito dei test. L'ambito può includere livelli di applicazione specifici come frontend, backend e database oppure risorse Google Cloud specifiche come istanze Cloud SQL o cluster GKE. L'ambito deve specificare anche eventuali dipendenze esterne, come API di terze parti o interconnessioni cloud.

Preparare l'ambiente per i test

Scegli un ambiente appropriato, preferibilmente un ambiente di staging o sandbox che replichi la configurazione di produzione. Se esegui il test in produzione, assicurati di avere a disposizione misure di sicurezza, come il monitoraggio automatico e le procedure di rollback manuale.

Crea un piano di backup. Acquisisci snapshot o backup di database e servizi critici per evitare la perdita di dati durante il test. Assicurati che il tuo team sia preparato a eseguire interventi manuali in caso di guasto dei meccanismi di failover automatico.

Per evitare interruzioni dei test, assicurati che i ruoli IAM, i criteri e le configurazioni di failover siano impostati correttamente. Verifica che siano presenti le autorizzazioni necessarie per gli script e gli strumenti di test.

Informa gli stakeholder, tra cui operazioni, DevOps e proprietari di applicazioni, sulla pianificazione, sull'ambito e sul potenziale impatto del test. Fornisci agli stakeholder una sequenza temporale stimata e i comportamenti previsti durante il test.

Simulare scenari di errore

Pianifica ed esegui errori utilizzando strumenti come Chaos Monkey. Puoi utilizzare script personalizzati per simulare guasti di servizi critici, ad esempio l'arresto di un nodo principale in un cluster GKE multizona o di un'istanza Cloud SQL disattivata. Puoi anche utilizzare script per simulare un'interruzione della rete su larga scala utilizzando regole firewall o restrizioni API in base all'ambito del test. Esegui la riassegnazione graduale degli scenari di errore per osservare il comportamento del sistema in varie condizioni.

Introduci i test di carico insieme agli scenari di errore per replicare l'utilizzo reale durante le interruzioni. Testa gli impatti degli errori a cascata, ad esempio il comportamento dei sistemi frontend quando i servizi di backend non sono disponibili.

Per convalidare le modifiche alla configurazione e valutare la resilienza del sistema agli errori umani, testa scenari che prevedono configurazioni errate. Ad esempio, esegui test con impostazioni di failover DNS o autorizzazioni IAM errate.

Monitorare il comportamento del sistema

Monitora il modo in cui i bilanciatori del carico, i controlli di integrità e altri meccanismi reindirizzano il traffico. Utilizza Google Cloud strumenti come Cloud Monitoring e Cloud Logging per acquisire metriche ed eventi durante il test.

Osserva le variazioni di latenza, percentuale di errori e throughput durante e dopo la simulazione di errore e monitora l'impatto complessivo sul rendimento. Identifica eventuali sviluppi o incoerenze nell'esperienza utente.

Assicurati che i log vengano generati e che gli avvisi vengano attivati per eventi chiave, come interruzioni del servizio o failover. Utilizza questi dati per verificare l'efficacia dei tuoi sistemi di avviso e risposta agli incidenti.

Verificare il recupero in base a RTO e RPO

Misura il tempo necessario al sistema per riprendere le normali operazioni dopo un guasto, poi confronta questi dati con il RTO definito e documenta eventuali lacune.

Assicurati che l'integrità e la disponibilità dei dati siano in linea con il RPO. Per verificare la coerenza del database, confronta gli snapshot o i backup del database prima e dopo un errore.

Valuta il ripristino dei servizi e verifica che tutti i servizi siano stati ripristinati in uno stato operativo con un'interruzione minima per gli utenti.

Documentare e analizzare i risultati

Documenta ogni passaggio del test, ogni scenario di errore e il comportamento del sistema corrispondente. Includi timestamp, log e metriche per analisi dettagliate.

Evidenzia i colli di bottiglia, i single point of failure o i comportamenti imprevisti osservati durante il test. Per dare la priorità alle correzioni, classifica i problemi in base alla gravità e all'impatto.

Suggerire miglioramenti all'architettura del sistema, ai meccanismi di failover o alle configurazioni di monitoraggio. In base ai risultati del test, aggiorna eventuali criteri di failover e playbook pertinenti. Presenta un report post mortem agli stakeholder. Il report deve riepilogare i risultati, le lezioni apprese e i passaggi successivi. Per ulteriori informazioni, consulta Eseguire autopsie approfondite.

Esegui l'iterazione e migliora

Per convalidare l'affidabilità e la resilienza continua, pianifica test periodici (ad esempio trimestrali).

Esegui test in scenari diversi, tra cui modifiche all'infrastruttura, aggiornamenti software e aumento dei carichi di traffico.

Automatizza i test di failover utilizzando le pipeline CI/CD per integrare i test di affidabilità nel ciclo di vita dello sviluppo.

Durante il post mortem, utilizza il feedback degli stakeholder e degli utenti finali per migliorare il processo di test e la resilienza del sistema.

Esegui test per il recupero da perdita di dati

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per aiutarti a progettare ed eseguire test per il recupero dalla perdita di dati.

Questo principio è pertinente all'area di interesse dell'apprendimento dell'affidabilità.

Panoramica del principio

Per assicurarti che il sistema possa recuperare da situazioni in cui i dati vengono persi o danneggiati, devi eseguire test per questi scenari. Le istanze di perdita di dati potrebbero essere causate da un bug del software o da un qualche tipo di calamità naturale. Dopo questi eventi, devi ripristinare i dati dai backup e riavviare tutti i servizi utilizzando i dati appena ripristinati.

Ti consigliamo di utilizzare tre criteri per valutare il successo o l'errore di questo tipo di test di recupero: integrità dei dati, tempo di ripristino del servizio (RTO) e perdita dati tollerata (RPO). Per informazioni dettagliate sulle metriche RTO e RPO, consulta Nozioni di base sulla pianificazione del piano di ripristino dei dati.

Lo scopo dei test di ripristino dei dati è verificare periodicamente che la tua organizzazione possa continuare a soddisfare i requisiti di continuità aziendale. Oltre a misurare RTO e RPO, un test di ripristino dei dati deve includere il test dell'intero stack di applicazioni e di tutti i servizi di infrastruttura critici con i dati ripristinati. Questa operazione è necessaria per verificare che l'intera applicazione di cui è stato eseguito il deployment funzioni correttamente nell'ambiente di test.

Consigli

Quando progetti ed esegui test per il recupero dalla perdita di dati, tieni in considerazione i consigli riportati nelle sezioni seguenti.

Verifica la coerenza del backup e testa le procedure di ripristino

Devi verificare che i backup contengano snapshot coerenti e utilizzabili dei dati che puoi ripristinare per rimettere immediatamente in servizio le applicazioni. Per convalidare l'integrità dei dati, configura i controlli di coerenza automatici da eseguire dopo ogni backup.

Per testare i backup, ripristinali in un ambiente non di produzione. Per assicurarti che i backup possano essere ripristinati in modo efficiente e che i dati ripristinati soddisfino i requisiti dell'applicazione, simula regolarmente scenari di recupero dei dati. Documenta la procedura di recupero dei dati e addestra i tuoi team a eseguirla in modo efficace in caso di errore.

Pianifica backup regolari e frequenti

Per ridurre al minimo la perdita di dati durante il ripristino e per raggiungere gli obiettivi RPO, è essenziale eseguire backup pianificati regolarmente. Stabilisci una frequenza di backup in linea con il tuo RPO. Ad esempio, se il tuo RPO è di 15 minuti, pianifica i backup in modo che vengano eseguiti almeno ogni 15 minuti. Ottimizza gli intervalli di backup per ridurre il rischio di perdita di dati.

Utilizza Google Cloud strumenti come Cloud Storage, i backup automatici di Cloud SQL o i backup di Spanner per pianificare e gestire i backup. Per le applicazioni critiche, utilizza soluzioni di backup quasi continui come il recupero point-in-time (PITR) per Cloud SQL o i backup incrementali per set di dati di grandi dimensioni.

Definisci e monitora il RPO

Imposta un RPO chiaro in base alle esigenze della tua attività e monitora la conformità all'RPO. Se gli intervalli di backup superano il RPO definito, utilizza Cloud Monitoring per configurare gli avvisi.

Monitorare lo stato di integrità del backup

Utilizza Google Cloud il servizio di backup e RE o strumenti simili per monitorare l'integrità dei backup e confermare che siano memorizzati in posizioni sicure e affidabili. Assicurati che i backup vengano replicati su più regioni per una maggiore resilienza.

Pianificare scenari oltre il backup

Combina i backup con strategie di ripristino di emergenza come le configurazioni di failover attivo-attivo o la replica tra regioni per migliorare i tempi di recupero in casi estremi. Per ulteriori informazioni, consulta la guida alla pianificazione del ripristino di emergenza.

Esegui analisi post mortem approfondite

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per aiutarti a eseguire autopsie efficaci dopo errori e incidenti.

Questo principio è pertinente all'area di interesse dell'apprendimento dell'affidabilità.

Panoramica del principio

Un'analisi post mortem è una registrazione scritta di un incidente, del suo impatto, delle azioni intraprese per mitigare o risolvere l'incidente, delle cause principali e delle azioni di follow-up per impedire che si ripresenti. Lo scopo di un'analisi post mortem è imparare dagli errori e non assegnare responsabilità.

Il seguente diagramma mostra il flusso di lavoro di un'analisi post mortem:

Il flusso di lavoro di un'analisi post mortem.

Il flusso di lavoro di un'analisi post mortem include i seguenti passaggi:

  • Creare un post mortem
  • Raccogli i fatti
  • Identifica e analizza le cause principali
  • Pianificare il futuro
  • Esegui il piano

Esegui analisi post mortem dopo eventi importanti e non importanti, come i seguenti:

  • Tempi di riposo o degradamenti visibili agli utenti oltre una determinata soglia.
  • Perdite di dati di qualsiasi tipo.
  • Interventi di tecnici disponibili, ad esempio un rollback della release o un nuovo routing del traffico.
  • Tempi di risoluzione superiori a una soglia definita.
  • Errori di monitoraggio, che in genere implicano la rilevazione manuale degli incidenti.

Consigli

Definisci i criteri di post mortem prima che si verifichi un incidente in modo che tutti sappiano quando è necessario eseguire un post mortem.

Per eseguire post mortem efficaci, tieni presenti i consigli riportati nelle seguenti sezioni.

Esegui analisi post mortem senza attribuzione delle colpe

I post mortem efficaci si concentrano su processi, strumenti e tecnologie e non fanno ricadere la colpa su persone o team. Lo scopo di un'analisi post mortem è migliorare la tecnologia e il futuro, non trovare il colpevole. Tutti commettono errori. L'obiettivo dovrebbe essere analizzare gli errori e imparare da essi.

Gli esempi riportati di seguito mostrano la differenza tra un feedback che attribuisce la colpa e un feedback senza colpa:

  • Feedback che attribuisce la colpa: "Dobbiamo riscrivere l'intero sistema di backend complicato. Si verificano guasti settimanali da tre quarti di anno a questa parte e sono sicuro che siamo tutti stanchi di sistemare le cose a poco a poco. Seriamente, se mi chiami un'altra volta lo riscriverò io…"
  • Feedback senza colpa: "Un'azione per riscrivere l'intero sistema di backend potrebbe effettivamente impedire la comparsa di queste pagine. Il manuale di manutenzione per questa versione è piuttosto lungo ed è molto difficile ricevere una formazione completa. Sono sicuro che i nostri futuri ingegneri di guardia ce lo ringrazieranno."

Rendi il report post mortem leggibile da tutti i segmenti di pubblico previsti

Per ogni informazione che prevedi di includere nel report, valuta se è importante e necessaria per aiutare il pubblico a capire cosa è successo. Puoi spostare spiegazioni e dati supplementari in un'appendice del report. I revisori che hanno bisogno di maggiori informazioni possono richiederle.

Evita soluzioni complesse o sovraingegnerizzate

Prima di iniziare a esplorare le soluzioni per un problema, valutane l'importanza e la probabilità di ricorrenza. L'aggiunta di complessità al sistema per risolvere problemi che difficilmente si verificheranno di nuovo può portare a un aumento dell'instabilità.

Condividi il post mortem con il maggior numero di persone possibile

Per assicurarti che i problemi non rimangano irrisolti, pubblica i risultati del post-mortem per un pubblico ampio e ricevi assistenza dal team di gestione. Il valore di un post-mortem è proporzionale all'apprendimento che si verifica dopo il post-mortem. Quando più persone imparano dagli incidenti, la probabilità che si ripetano errori simili si riduce.

Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.

Ultimo aggiornamento 2025-02-14 UTC.