Well-Architected Framework: pilastro affidabilità

Last reviewed 2025-02-14 UTC

Il pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce principi e consigli per aiutarti a progettare, eseguire il deployment e gestire workload affidabili in Google Cloud.

Questo documento è rivolto ad architetti cloud, sviluppatori, ingegneri di piattaforma, amministratori e ingegneri dell'affidabilità del sito.

L'affidabilità è la capacità di un sistema di svolgere 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 a tolleranza di errore, monitoraggio e processi di ripristino automatico.

Nell'ambito dell'affidabilità, la resilienza è la capacità del sistema di resistere e riprendersi da errori o interruzioni impreviste, mantenendo al contempo le prestazioni. Le funzionalità diGoogle Cloud , come i deployment multiregionali, i backup automatici e le soluzioni di ripristino di emergenza, 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 una perdita di entrate, una riduzione della produttività e danni alla reputazione. Le architetture resilienti possono contribuire a garantire che i sistemi possano continuare a funzionare durante i guasti o ripristinarsi in modo efficiente.
  • Esperienza utente migliorata: gli utenti si aspettano interazioni fluide con la tecnologia. I sistemi resilienti possono aiutare a mantenere prestazioni e disponibilità costanti e forniscono 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à operativa: la tua attività si affida alla tecnologia per le operazioni critiche. Le architetture resilienti possono contribuire a garantire la continuità dopo un errore catastrofico, consentendo alle funzioni aziendali di continuare senza interruzioni significative e supportando un rapido ripristino.
  • 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 a lungo termine inferiori: le architetture resilienti richiedono un investimento iniziale, ma la resilienza può contribuire a ridurre i costi nel tempo evitando costosi tempi di inattività, correzioni reattive e consentendo un utilizzo più efficiente delle risorse.

Mentalità organizzativa

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

Stabilisci un'aspettativa chiara che l'intera organizzazione sia responsabile dell'affidabilità, inclusi sviluppo, gestione del prodotto, operazioni, ingegneria della piattaforma e Site Reliability Engineering (SRE). Anche i gruppi incentrati sul business, come il marketing e le vendite, possono influenzare l'affidabilità.

Ogni team deve comprendere i target di affidabilità e i rischi delle proprie applicazioni. I team devono essere responsabili di questi requisiti. I conflitti tra l'affidabilità e lo sviluppo regolare delle funzionalità del prodotto devono essere classificati in ordine di priorità e riassegnati di conseguenza.

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

Aree di interesse per l'affidabilità

Le attività che svolgi per progettare, eseguire il deployment 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 interesse.

  • Definizione dell'ambito: per comprendere il tuo 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 attraverso il sistema e cosa potrebbe andare storto. Identificare potenziali errori, colli di bottiglia e rischi, il che ti aiuta a passare all'azione per mitigare questi problemi.
  • Osservazione: per contribuire a prevenire gli errori di sistema, implementa un'osservazione e un monitoraggio completi e continui. Attraverso questa osservazione, puoi comprendere le tendenze e identificare i potenziali problemi in modo proattivo.
  • Risposta: per ridurre l'impatto degli errori, rispondi in modo appropriato ed esegui il recupero in modo efficiente. Le risposte automatiche possono anche contribuire a ridurre l'impatto degli errori. Anche con la pianificazione e i controlli, possono comunque verificarsi guasti.
  • Apprendimento: per evitare che gli errori si ripetano, impara da ogni esperienza e intraprendi le azioni appropriate.

Valuta i workload utilizzando una skill dell'agente

Per consentire agli agenti AI di valutare i tuoi workload cloud in base ai principi e ai suggerimenti di questo pilastro, utilizza la skill google-cloud-waf-reliability, disponibile nel repository Google Agent Skills su GitHub.

Per installare la skill, esegui il seguente comando nel client o nel terminale dell'agente:

npx skills add google/skills --skill google-cloud-waf-reliability

Quando richiesto, specifica gli agenti AI per i quali vuoi installare la skill e imposta l'ambito di installazione (progetto o globale).

Principi fondamentali

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

Collaboratori

Autori:

Altri collaboratori:

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

Questo principio del pilastro dell'affidabilità del Well-Architected FrameworkGoogle Cloud ti aiuta a valutare l'esperienza degli utenti e a mappare i risultati in base agli obiettivi e alle metriche di affidabilità.

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

Panoramica del principio

Gli strumenti di osservabilità forniscono grandi quantità di dati, ma non tutti i dati sono direttamente correlati agli impatti sugli utenti. Ad esempio, potresti osservare un utilizzo elevato della CPU, operazioni del server lente o persino l'arresto anomalo delle attività. Tuttavia, se questi problemi non influiscono sull'esperienza utente, non costituiscono un'interruzione.

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

Consigli

Per 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 degli utenti. Ad esempio, misura la percentuale di successo delle query degli utenti, la latenza delle applicazioni 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.

Analizza i percorsi degli utenti

Per capire in che modo gli utenti interagiscono con il tuo sistema, puoi utilizzare strumenti di tracciamento come Cloud Trace. Seguendo il percorso di un utente nella tua applicazione, puoi trovare colli di bottiglia e problemi di latenza che potrebbero peggiorare l'esperienza dell'utente. Cloud Trace acquisisce dati sul rendimento dettagliati per ogni hop nell'architettura del servizio. Questi dati ti aiutano a identificare e risolvere i problemi di prestazioni in modo più efficiente, il che può portare a 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 fattibili per i tuoi workload in Google Cloud.

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

Panoramica del principio

Progetta i tuoi sistemi in modo che siano affidabili al punto che gli utenti siano soddisfatti. Potrebbe sembrare controintuitivo, ma un obiettivo di affidabilità del 100% spesso non è la strategia più efficace. Una maggiore affidabilità potrebbe comportare un costo significativamente più elevato, 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 produrre un basso ritorno sull'investimento. Invece, 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. Quando determini 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 obiettivi di affidabilità realistici, prendi in considerazione i suggerimenti nelle seguenti sottosezioni.

Accettare alcuni errori e dare la priorità ai componenti

Punta a un'alta affidabilità, ad esempio un uptime del 99,99%, ma non impostare un target di uptime del 100%. Riconosci che alcuni errori sono inevitabili.

Il divario tra il 100% di uptime e un target del 99,99% è la tolleranza per i guasti. Questo divario viene spesso chiamato budget di errore. Il budget di errore può aiutarti ad assumerti 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 maggiore agli errori.

Bilancia affidabilità e costi

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

Considera fattori come i requisiti di sistema, le conseguenze dei guasti e la tolleranza al rischio della tua organizzazione per l'applicazione specifica. Ricorda di considerare le metriche di disaster recovery, come il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). Decidi quale livello di affidabilità è accettabile entro il budget e altri vincoli.

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

Crea sistemi ad alta affidabilità 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, il che può aiutarti a evitare errori.

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

Panoramica del principio

Dopo aver deciso il livello di affidabilità di cui hai bisogno, devi progettare i tuoi sistemi in modo da evitare qualsiasi single point of failure. 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 distribuito in una sola zona o regione. In questi esempi, se l'unica zona o regione ha un'interruzione, il sistema ha un'interruzione globale.

Consigli

Per creare sistemi ridondanti, tieni presente i consigli riportati nelle seguenti sottosezioni.

Identifica i domini in errore e replica i servizi

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

Per garantire l'alta affidabilità, distribuisci e replica i tuoi servizi e le tue 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 multiregionali, consulta Progetta un'infrastruttura affidabile per i tuoi workload in Google Cloud.

Rilevare e risolvere i problemi tempestivamente

Monitora continuamente lo stato dei domini in errore per rilevare e risolvere i problemi tempestivamente.

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

Testa 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 Simula un'interruzione del servizio in una zona per un MIG a livello di regione e Simula un errore della zona nei cluster GKE a livello di regione.

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 a garantire che i tuoi workload inGoogle Cloud possano scalare in modo efficiente e mantenere le prestazioni.

Questo principio è pertinente all'area di interesse di definizione dell'ambito 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, considera le limitazioni della scalabilità verticale.

Uno scenario comune per lo scale up verticale è l'utilizzo di un database MySQL come database principale con dati critici. Man mano che l'utilizzo del database aumenta, sono necessarie più RAM e CPU. Alla fine, il database raggiunge il limite di memoria sulla macchina host e deve essere aggiornato. Questo processo potrebbe dover essere ripetuto 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 single point of failure. 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 Crea sistemi ad alta affidabilità tramite la ridondanza delle risorse.

Oltre a questi limiti di scalabilità, la scalabilità verticale tende a essere più costosa. Il costo può aumentare in modo esponenziale con l'acquisto di macchine con maggiore potenza di calcolo e memoria.

La scalabilità orizzontale, al contrario, può costare meno. Il potenziale di scalabilità orizzontale è praticamente illimitato in un sistema progettato per la scalabilità.

Consigli

Per passare da un'architettura con una singola VM a un'architettura con più macchine orizzontali, devi pianificare attentamente e utilizzare gli strumenti giusti. Per aiutarti a ottenere la scalabilità orizzontale, tieni presente i suggerimenti riportati nelle sottosezioni seguenti.

Utilizza i servizi gestiti

I servizi gestiti eliminano la necessità di gestire manualmente lo scaling orizzontale. Ad esempio, con i gruppi di istanze gestite di Compute Engine, puoi aggiungere o rimuovere VM per scalare la tua 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.

Promuovere la progettazione modulare

I componenti modulari e le interfacce chiare ti aiutano a scalare i singoli componenti in base alle esigenze, anziché l'intera applicazione. Per saperne di più, consulta Promuovere la progettazione modulare nel pilastro dell'ottimizzazione del rendimento.

Implementa un design stateless

Progetta applicazioni 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 anomalie.

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

Panoramica del principio

Per mantenere e migliorare l'affidabilità dei workload inGoogle 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 il tasso di richieste e la percentuale di errori, che possono essere utilizzate come indicatori del livello di servizio (SLI). Potresti anche dover monitorare metriche aziendali specifiche dell'applicazione, come gli ordini effettuati e i pagamenti ricevuti.
  • I log sono record con timestamp di eventi discreti che si verificano all'interno di un'applicazione o di un sistema. L'evento potrebbe essere un errore, un'anomalia o una modifica dello stato. I log potrebbero includere metriche e puoi utilizzarli anche per gli SLI.
  • Una traccia rappresenta il percorso di un singolo utente o transazione attraverso una serie di applicazioni separate o i componenti di un'applicazione. Ad esempio, questi componenti potrebbero essere microservizi. Le tracce ti aiutano a monitorare quali componenti sono stati utilizzati nei percorsi, dove si trovano i colli di bottiglia e quanto tempo hanno richiesto i 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 suggerimenti nelle sottosezioni seguenti.

Ottieni insight completi

Per monitorare metriche chiave come i tempi di risposta e le percentuali di errore, utilizza Cloud Monitoring e Cloud Logging. Questi strumenti ti aiutano anche a garantire che le metriche soddisfino costantemente le esigenze del tuo workload.

Per prendere decisioni basate sui dati, analizza le metriche dei servizi predefiniti per comprendere le dipendenze dei componenti e il loro impatto sulle prestazioni complessive del workload.

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

Eseguire la risoluzione proattiva dei problemi

Implementa una gestione degli errori efficace e attiva il logging in tutti i componenti dei tuoi workload in Google Cloud. Attiva i log come Log di accesso di Cloud Storage e Log di flusso VPC.

Quando configuri il logging, tieni conto dei costi associati. Per controllare i costi di logging, puoi configurare filtri di esclusione nei sink di log per escludere l'archiviazione di determinati log.

Ottimizza 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 risorse con provisioning insufficiente ed eccessivo in servizi come GKE, Compute Engine e Managed Service for Apache Spark. Per un elenco completo dei servizi supportati, consulta la panoramica di Cloud Monitoring.

Assegnazione di priorità agli avvisi

Per gli avvisi, concentrati sulle metriche principali, imposta soglie appropriate per ridurre al minimo l'eccesso di avvisi e assicurati rispondere in modo tempestivo ai problemi significativi. Questo approccio mirato ti consente di mantenere in modo proattivo l'affidabilità del workload. Per ulteriori informazioni, consulta la Panoramica degli avvisi.

Progetta per la riduzione controllata

Questo principio del pilastro dell'affidabilità del Google Cloud Well-Architected Framework fornisce consigli per aiutarti a progettare i tuoi workload Google Cloud in modo che non si verifichino errori.

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

Panoramica del principio

La riduzione controllata è un approccio di progettazione in cui un sistema che subisce un carico elevato continua a funzionare, possibilmente con prestazioni o accuratezza ridotte. La riduzione controllata garantisce la disponibilità continua del sistema e previene un errore completo, anche se il lavoro del sistema non è ottimale. Quando il carico torna a un livello gestibile, il sistema ripristina la piena funzionalità.

Ad esempio, durante i periodi di carico elevato, la Ricerca Google dà la priorità ai risultati delle pagine web con un 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 tuoi sistemi in modo che la riduzione controllata sia efficace, tieni presenti i suggerimenti nelle seguenti sottosezioni.

Implementa la limitazione

Assicurati che le repliche possano gestire in modo indipendente i sovraccarichi e limitare le richieste in entrata in scenari di traffico elevato. Questo approccio ti aiuta a prevenire errori a cascata causati da spostamenti del traffico in eccesso tra zone.

Utilizza strumenti come Apigee per controllare la frequenza delle richieste API durante i periodi di traffico elevato. Puoi configurare le regole della policy in modo che riflettano il modo in cui vuoi ridurre le richieste.

Elimina tempestivamente le richieste in eccesso

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

Gestisci gli errori parziali e i nuovi tentativi

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

Testa scenari di sovraccarico

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

Monitora i picchi di traffico

Utilizza 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 forte 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 di ripristino in caso di errori.

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

Panoramica del principio

Per assicurarti che il tuo sistema possa ripristinarsi in caso di errori, devi eseguire periodicamente test che includano failover regionali, rollback delle release e ripristino dei dati dai backup.

Questo test ti aiuta a esercitarti a rispondere a eventi che comportano rischi significativi per l'affidabilità, come l'interruzione di un'intera regione. Questo test ti aiuta anche a verificare che il sistema si comporti come previsto durante un'interruzione.

Nell'improbabile caso in cui un'intera regione non sia disponibile, devi eseguire il failover di tutto il traffico verso un'altra regione. Durante il normale funzionamento del workload, 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 subiscano perdite di dati o interruzioni della sessione. Il sistema di bilanciamento del carico deve inoltre essere in grado di spostare il traffico verso la regione di failover in qualsiasi momento senza interruzioni del servizio. Per ridurre al minimo i tempi di inattività dopo un'interruzione regionale, gli ingegneri delle operazioni devono anche essere in grado di spostare manualmente ed efficientemente il traffico degli utenti da una regione, nel minor tempo possibile. Questa operazione è talvolta chiamata svuotamento di una regione, il che significa che interrompi il traffico in entrata verso la regione e lo sposti altrove.

Consigli

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

Definisci gli obiettivi e l'ambito dei test

Definisci chiaramente cosa vuoi ottenere dal test. Ad esempio, i tuoi obiettivi possono includere quanto segue:

  • Convalida il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). Per maggiori dettagli, consulta Nozioni di base sulla RE DR.
  • Valutare la resilienza e la tolleranza di errore del sistema in vari scenari di errore.
  • Testa l'efficacia dei meccanismi di failover automatico.

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

Prepara 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 pronte 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 pronto a eseguire interventi manuali in caso di errore dei meccanismi di failover automatico.

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

Informa le parti interessate, tra cui i proprietari di operazioni, DevOps e applicazioni, del programma di test, dell'ambito e del potenziale impatto. Fornisci agli stakeholder una tempistica stimata e i comportamenti previsti durante il test.

Simula scenari di errore

Pianifica ed esegui errori utilizzando strumenti come Chaos Monkey. Puoi utilizzare script personalizzati per simulare errori di servizi critici, come l'arresto di un nodo principale in un cluster GKE multizona o un'istanza Cloud SQL disabilitata. Puoi anche utilizzare script per simulare un'interruzione di rete a livello di regione utilizzando regole firewall o limitazioni API in base all'ambito del test. Aumenta gradualmente gli 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 comportano configurazioni errate. Ad esempio, esegui test con impostazioni di failover DNS errate 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 cambiano il percorso del traffico. Utilizza strumenti Google Cloud come Cloud Monitoring e Cloud Logging per acquisire metriche ed eventi durante il test.

Osserva le variazioni di latenza, frequenza degli errori e velocità effettiva durante e dopo la simulazione degli errori e monitora l'impatto complessivo sulle prestazioni. Identifica eventuali peggioramenti o incoerenze nell'esperienza utente.

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

Verifica il recupero in base a RTO e RPO

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

Assicurati che l'integrità e la disponibilità dei dati siano in linea con l'RPO. Per testare 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 funzionale con un'interruzione minima per gli utenti.

Documentare e analizzare i risultati

Documenta ogni passaggio del test, scenario di errore e 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 stabilire le priorità delle correzioni, classifica i problemi in base alla gravità e all'impatto.

Suggerisci miglioramenti all'architettura del sistema, ai meccanismi di failover o alle configurazioni di monitoraggio. In base ai risultati del test, aggiorna le eventuali policy di failover e i playbook pertinenti. Presentare un report post-mortem agli stakeholder. Il report deve riassumere i risultati, le lezioni apprese e i passaggi successivi. Per saperne di più, consulta Esegui post-mortem approfondite.

Itera e migliora

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

Esegui test in diversi scenari, 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 l'analisi 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 dalla 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 Apprendimento dell'affidabilità.

Panoramica del principio

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

Ti consigliamo di utilizzare tre criteri per valutare la riuscita o il fallimento di questo tipo di test di ripristino: integrità dei dati, Recovery Time Objective (RTO) e Recovery Point Objective (RPO). Per informazioni dettagliate sulle metriche RTO e RPO, consulta Nozioni di RE DR.

L'obiettivo 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 confermare 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 conto dei suggerimenti riportati nelle sottosezioni seguenti.

Verifica la coerenza del backup e testa le procedure di ripristino

Devi verificare che i backup contengano snapshot dei dati coerenti e utilizzabili che puoi ripristinare per rimettere immediatamente in servizio le applicazioni. Per convalidare l'integrità dei dati, configura 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 dati. Documenta i passaggi per il ripristino dei dati e addestra i tuoi team a eseguirli in modo efficace in caso di errore.

Pianifica backup regolari e frequenti

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

Utilizza strumenti Google Cloud 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 continuo come il recupero point-in-time (PITR) per Cloud SQL o i backup incrementali per set di dati di grandi dimensioni.

Definisci e monitora l'RPO

Imposta un RPO chiaro in base alle tue esigenze aziendali e monitora l'aderenza all'RPO. Se gli intervalli di backup superano l'RPO definito, utilizza Cloud Monitoring per configurare gli avvisi.

Monitora lo stato del backup

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

Pianifica scenari che vanno oltre il backup

Combina i backup con strategie di ripristino di emergenza come configurazioni di failover attivo-attivo o replica tra regioni per migliorare il tempo di ripristino in casi estremi. Per saperne di più, consulta la Guida alla pianificazione del disaster recovery.

Esegui post-mortem approfonditi

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

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

Panoramica del principio

Un'analisi post mortem è un resoconto scritto di un incidente, del suo impatto, delle azioni intraprese per mitigarlo o risolverlo, delle cause principali e delle azioni di follow-up per evitare che si ripeta. L'obiettivo di un post mortem è imparare dagli errori e non assegnare colpe.

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

Il flusso di lavoro di un post-mortem.

Il flusso di lavoro di un postmortem include i seguenti passaggi:

  • Crea postmortem
  • Acquisisci i fatti
  • Identificare e analizzare le cause principali
  • Pianificare il futuro
  • Esegui il piano

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

  • Interruzioni o peggioramenti visibili agli utenti oltre una determinata soglia.
  • Perdite di dati di qualsiasi tipo.
  • Interventi da parte degli ingegneri on-call, come il rollback di una release o il reindirizzamento del traffico.
  • Tempi di risoluzione superiori a una soglia definita.
  • Errori di monitoraggio, che di solito implicano il rilevamento manuale degli incidenti.

Consigli

Definisci i criteri per il postmortem prima che si verifichi un incidente, in modo che tutti sappiano quando è necessario un postmortem.

Per condurre postmortem efficaci, prendi in considerazione i consigli riportati nelle sottosezioni seguenti.

Esegui analisi post mortem senza attribuzione delle colpe

I postmortem efficaci si concentrano su processi, strumenti e tecnologie e non attribuiscono la colpa a singoli individui o team. Lo scopo di un'analisi post-mortem è migliorare la tecnologia e il futuro, non trovare i colpevoli. Tutti commettiamo errori. L'obiettivo deve essere analizzare gli errori e imparare da questi.

I seguenti esempi mostrano la differenza tra un feedback che attribuisce la colpa e un feedback senza colpe:

  • Feedback che attribuisce la colpa: "Dobbiamo riscrivere l'intero complicato sistema di backend! Si rompe ogni settimana da tre trimestri e sono sicuro che siamo tutti stanchi di aggiustare le cose pezzo per pezzo. Seriamente, se mi chiamano un'altra volta, lo riscrivo io…"
  • Feedback senza colpe: "Un'attività per riscrivere l'intero sistema di backend potrebbe effettivamente impedire che queste pagine continuino a verificarsi. Il manuale di manutenzione di questa versione è piuttosto lungo e molto difficile da imparare completamente. Sono sicuro che i nostri futuri on-call engineer ci ringrazieranno!"

Rendi il report postmortem 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 i dati e le spiegazioni supplementari in un'appendice del report. I revisori che hanno bisogno di maggiori informazioni possono richiederle.

Evita soluzioni complesse o eccessivamente elaborate

Prima di iniziare a esplorare le soluzioni per un problema, valuta l'importanza del problema e la probabilità che si ripresenti. Aggiungere complessità al sistema per risolvere problemi che difficilmente si verificheranno di nuovo può portare a una maggiore instabilità.

Condividi l'analisi post mortem il più ampiamente possibile

Per assicurarti che i problemi non rimangano irrisolti, pubblica il risultato del postmortem per un vasto pubblico e ottieni il supporto della dirigenza. Il valore di un postmortem è proporzionale all'apprendimento che avviene dopo il postmortem. Quando più persone imparano dagli incidenti, la probabilità che si verifichino errori simili si riduce.