Well-Architected Framework: pilastro affidabilità

Last reviewed 2025-02-14 UTC

Il pilastro dell'affidabilità nel Google Cloud framework Well-Architected fornisce principi e suggerimenti per aiutarti a progettare, eseguire il deployment e gestire carichi di lavoro affidabili in Google Cloud.

Questo documento è rivolto ad architetti cloud, sviluppatori, ingegneri di piattaforma, amministratori e SRE.

L'affidabilità è la capacità di un sistema di svolgere costantemente le sue funzioni previste nelle 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 automatici.

Nell'ambito dell'affidabilità, la resilienza è la capacità del sistema di resistere e riprendersi da guasti o interruzioni impreviste, mantenendo le prestazioni. Le funzionalitàGoogle Cloud , come implementazioni multiregionali, backup automatici e soluzioni di ripristino di emergenza, possono aiutarti a migliorare la resilienza del sistema.

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

  • Tempi di inattività minimi: i tempi di inattività possono comportare perdite di entrate, 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 contribuire 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 basa sulla tecnologia per le operazioni critiche. Le architetture resilienti possono contribuire a garantire la continuità dopo un guasto catastrofico, il che consente alle funzioni aziendali di continuare senza interruzioni significative e supporta 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 rispettare 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 affidabili i tuoi sistemi, hai bisogno di un piano e di una strategia consolidata. Questa strategia deve includere l'istruzione e l'autorità di dare la priorità all'affidabilità insieme ad altre iniziative.

Definisci 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 marketing e vendite, possono influenzare l'affidabilità.

Ogni team deve comprendere i target 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 prioritari 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 configurare un Cloud Center of Excellence (CCoE) che includa un pilastro di affidabilità. Per ulteriori informazioni, vedi 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 interesse.

  • 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 nel sistema e cosa potrebbe andare storto. Identifica potenziali guasti, colli di bottiglia e rischi, il che ti aiuta ad adottare misure per mitigare questi problemi.
  • Osservazione: per evitare guasti al 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 dei guasti, rispondi in modo appropriato e ripristina in modo efficiente. Le risposte automatizzate possono anche contribuire a ridurre l'impatto dei guasti. Anche con la pianificazione e i controlli, possono comunque verificarsi errori.
  • Apprendimento: per evitare che gli errori si ripetano, impara da ogni esperienza e intraprendi le azioni appropriate.

Principi fondamentali

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

Google Cloud

Collaboratori

Autori:

Altri collaboratori:

Definisci 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 dei tuoi utenti e poi a mappare i risultati in base a obiettivi e metriche di affidabilità.

Questo principio è pertinente all'ambito dell'area di interesse 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 notare un elevato utilizzo 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.

Per misurare l'esperienza utente, devi distinguere tra il comportamento del sistema interno e i problemi riscontrati dagli utenti. Concentrati su metriche come il tasso 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 in modo coerente ed efficace la tua applicazione o il tuo servizio.

Consigli

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

Misurare l'esperienza utente

Per comprendere veramente l'affidabilità del tuo servizio, dai la priorità alle metriche che riflettono l'esperienza effettiva dei tuoi utenti. Ad esempio, misura il rapporto di successo delle query 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 influire in modo significativo sugli utenti.

Analizzare 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 dettagliati sulle prestazioni per ogni hop nell'architettura del servizio. Questi dati ti aiutano a identificare e risolvere i problemi di rendimento in modo più efficiente, il che può portare a un'esperienza utente più affidabile e soddisfacente.

Imposta target realistici per l'affidabilità

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

Questo principio è pertinente all'ambito dell'area di interesse 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. In questo modo, puoi utilizzare le risorse in modo più efficace 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 target di affidabilità realistici, tieni conto dei consigli riportati nelle sottosezioni seguenti.

Accettare alcuni errori e dare la priorità ai componenti

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

Il divario tra il 100% di uptime 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 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 maggiore tolleranza agli errori.

Trovare un equilibrio tra 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 ripristino di emergenza, 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 disponibilità tramite la ridondanza delle risorse

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

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

Panoramica del principio

Dopo aver deciso il livello di affidabilità di cui hai bisogno, devi progettare i tuoi sistemi per 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 sottoposto a deployment 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 presenti i consigli riportati nelle seguenti sottosezioni.

Identificare i domini di errore e replicare i servizi

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

Per garantire l'alta disponibilità, 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 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 i problemi tempestivamente.

Puoi monitorare lo stato attuale dei servizi in tutte le regioni utilizzando la Google Cloud dashboard di Service Health. Google Cloud 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 indirizzare automaticamente il traffico ai backend integri. Per saperne di più, consulta la panoramica dei controlli di integrità.

Testa gli scenari di failover

Come una prova di evacuazione in caso di incendio, simula regolarmente gli errori per convalidare l'efficacia delle strategie di replica e failover.

Per saperne di più, consulta Simula un'interruzione del servizio in una zona per un MIG regionale e Simula un errore di zona nei cluster regionali GKE.

Sfruttare la scalabilità orizzontale

Questo principio del pilastro dell'affidabilità del Google Cloud framework Well-Architected fornisce consigli per aiutarti a utilizzare la scalabilità orizzontale. Utilizzando la scalabilità orizzontale, puoi contribuire a garantire 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 l'architettura del sistema in modo che sia orizzontale. Per far fronte all'aumento 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 i limiti 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 necessari 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 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 Crea sistemi a disponibilità elevata tramite la ridondanza delle risorse.

Oltre a questi limiti di scalabilità, lo scaling verticale tende a essere più costoso. Il costo può aumentare in modo esponenziale man mano che vengono acquisite 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 a una singola VM a un'architettura orizzontale a più macchine, devi pianificare con attenzione e utilizzare gli strumenti giusti. Per aiutarti a ottenere uno scaling orizzontale, prendi in considerazione i suggerimenti nelle seguenti sottosezioni.

Utilizzare i servizi gestiti

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

Promuovere la progettazione modulare

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

Implementare 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 guasti.

Questo principio è pertinente all'area di interesse 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 cometasso di richiestee e il tasso di errore, che possono essere utilizzate come indicatori del livello del servizio (SLI). Potresti anche dover monitorare metriche aziendali specifiche dell'applicazione, come ordini effettuati e 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 problema o una modifica dello stato. I log possono includere metriche e puoi anche utilizzarli per gli indicatori di livello del servizio.
  • 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 i componenti utilizzati nei viaggi, i punti critici e la durata dei viaggi.

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

Consigli

Per rilevare in modo efficiente potenziali guasti, considera i consigli riportati nelle sottosezioni seguenti.

Ottenere informazioni complete

Per monitorare le 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 carico di lavoro.

Per prendere decisioni basate sui dati, analizza le metriche del servizio predefinito per comprendere le dipendenze dei componenti e il loro impatto sulle prestazioni complessive del carico di lavoro.

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

Eseguire la risoluzione dei problemi proattiva

Implementa una gestione degli errori efficace e abilita la registrazione in tutti i componenti dei tuoi carichi di lavoro in Google Cloud. Attiva i log come Log di accesso di Cloud Storage e Log di flusso VPC.

Quando configuri la registrazione, considera i costi associati. Per controllare i costi di logging, puoi configurare i filtri di esclusione sui sink di log per escludere l'archiviazione di determinati log.

Ottimizzare l'utilizzo delle risorse

Monitora il consumo di CPU, le metriche di I/O di rete e le metriche di I/O del disco per rilevare risorse con provisioning insufficiente e con provisioning eccessivo in servizi come GKE, Compute Engine e Dataproc. Per un elenco completo dei servizi supportati, consulta la panoramica di Cloud Monitoring.

Dare la priorità agli avvisi

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

Progettazione per la riduzione controllata

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

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

Panoramica del principio

Il degrado controllato è un approccio di progettazione in cui un sistema che subisce un carico elevato continua a funzionare, possibilmente con prestazioni o precisione ridotte. Il degrado controllato garantisce la disponibilità continua del sistema e ne impedisce il guasto completo, anche se il funzionamento non è ottimale. Quando il carico torna 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 delle pagine web con un ranking più elevato, sacrificando potenzialmente un po' di precisione. Quando il carico diminuisce, la Ricerca Google ricalcola i risultati di ricerca.

Consigli

Per progettare i tuoi sistemi per la riduzione controllata, tieni presenti i consigli nelle seguenti sottosezioni.

Implementare la limitazione

Assicurati che le repliche possano gestire in modo indipendente i sovraccarichi e limitare le richieste in entrata durante gli 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 dei criteri in modo che riflettano il modo in cui vuoi ridurre le richieste.

Eliminare le richieste in eccesso in anticipo

Configura i tuoi sistemi in modo da eliminare le richieste in eccesso nel livello frontend per proteggere i componenti di backend. L'eliminazione di alcune richieste impedisce errori globali e consente al sistema di ripristinarsi in modo più controllato.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.

Gestire errori parziali e tentativi

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

Testare 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 contribuiscono a garantire che il tuo 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 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 per il ripristino in caso di errori.

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

Panoramica del principio

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

Questi test ti aiutano a esercitarti a rispondere a eventi che comportano rischi maggiori per l'affidabilità, come l'interruzione di un'intera regione. Questi test ti aiutano anche a verificare che il tuo 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 primaria 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 anche essere in grado di spostare il traffico nella 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 a volte viene chiamata svuotamento di una regione, il che significa che interrompi il traffico in entrata verso la regione e sposti tutto il traffico altrove.

Consigli

Quando progetti ed esegui test per il ripristino in caso di errore, considera i consigli riportati nelle seguenti sottosezioni.

Definisci gli obiettivi e l'ambito del 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, vedi Nozioni di base della pianificazione del DR.
  • Valuta 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 come istanze Cloud SQL o cluster GKE. Google Cloud 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. Scatta snapshot o esegui backup di servizi e database 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 IAM, i criteri e le configurazioni di failover siano impostati correttamente. Verifica che siano presenti le autorizzazioni necessarie per gli strumenti e gli script di test.

Informa le parti interessate, inclusi i proprietari di operazioni, DevOps e applicazioni, in merito alla pianificazione, all'ambito e al potenziale impatto del test. Fornisci agli stakeholder una cronologia 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 errori di servizi critici, ad esempio l'arresto di un nodo primario 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 test di carico insieme a 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 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, percentuali di errore e velocità effettiva durante e dopo la simulazione di errore e monitora l'impatto complessivo sulle prestazioni. Identifica eventuali degradazioni o incongruenze nell'esperienza utente.

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

Verificare il ripristino in base a RTO e RPO

Misura il tempo necessario al sistema per riprendere il normale funzionamento 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 del servizio e verifica che tutti i servizi siano ripristinati in uno stato funzionale con interruzioni minime 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.

Metti in evidenza 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.

Suggerisci miglioramenti all'architettura del sistema, ai meccanismi di failover o alle configurazioni di monitoraggio. In base ai risultati del test, aggiorna le norme di failover e i playbook pertinenti. Presenta un report post mortem alle parti interessate. Il report deve riassumere i risultati, le lezioni apprese e i passaggi successivi. Per saperne di più, vedi Eseguire analisi post mortem approfondite.

Iterare e migliorare

Per convalidare l'affidabilità e la resilienza continue, 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 la procedura di test e la resilienza del sistema.

Esegui test per il ripristino 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 ripristino dalla perdita di dati.

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

Panoramica del principio

Per assicurarti che il sistema possa ripristinare le 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 software o da un 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, tempo di ripristino del servizio (RTO) e perdita dati tollerata (RPO). Per informazioni dettagliate sulle metriche RTO e RPO, consulta Nozioni di RE emergenza.

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 suggerimenti riportati nelle seguenti sezioni.

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 ripristinare immediatamente il servizio delle 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 dei dati. Documenta i passaggi per il ripristino dei dati e forma i tuoi team per eseguirli in modo efficace in caso di errore.

Pianificare backup regolari e frequenti

Per ridurre al minimo la perdita di dati durante il ripristino e soddisfare gli obiettivi RPO, è essenziale disporre di 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 Google Cloud strumenti come Cloud Storage, backup automatici di Cloud SQL o backup di Spanner per pianificare e gestire i backup. Per le applicazioni critiche, utilizza soluzioni di backup quasi continue 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 esigenze aziendali e monitora il rispetto dell'RPO. Se gli intervalli di backup superano l'RPO definito, utilizza Cloud Monitoring per configurare gli avvisi.

Monitorare l'integrità del backup

Utilizza Google Cloud il RE e DR 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.

Pianificare scenari oltre il backup

Combina i backup con strategie di ripristino di emergenza come configurazioni di failover active-active o replica tra regioni per migliorare il tempo di ripristino in casi estremi. Per ulteriori informazioni, vedi la Guida alla pianificazione del disaster recovery.

Eseguire analisi post mortem approfondite

Questo principio del pilastro dell'affidabilità del Google Cloud framework Well-Architected fornisce consigli per aiutarti a condurre postmortem efficaci dopo guasti e incidenti.

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

Panoramica del principio

Un 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 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 postmortem.

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

  • Crea un postmortem
  • Acquisire 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:

  • Tempi di inattività o peggioramenti visibili agli utenti oltre una determinata soglia.
  • Perdite di dati di qualsiasi tipo.
  • Interventi di ingegneri di turno, ad esempio un rollback della 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 post mortem prima che si verifichi un incidente, in modo che tutti sappiano quando è necessario un post mortem.

Per condurre postmortem efficaci, tieni presente i consigli nelle seguenti sottosezioni.

Eseguire analisi post mortem senza attribuzione delle colpe

Le analisi post mortem efficaci si concentrano su processi, strumenti e tecnologie e non attribuiscono la colpa a individui o team. Lo scopo di un'analisi post-mortem è quello di migliorare la tua tecnologia e il tuo futuro, non di trovare il colpevole. Tutti commettono errori. L'obiettivo dovrebbe essere analizzare gli errori e imparare da questi.

Gli esempi seguenti mostrano la differenza tra un feedback che attribuisce la colpa e un feedback che non attribuisce la colpa:

  • 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'azione per riscrivere l'intero sistema di backend potrebbe effettivamente impedire che queste pagine continuino a essere visualizzate. Il manuale di manutenzione per questa versione è piuttosto lungo e molto difficile da imparare completamente. Sono sicuro che i nostri futuri ingegneri di turno ci ringrazieranno."

Rendere 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 necessitano di maggiori informazioni possono richiederle.

Evita soluzioni complesse o eccessivamente elaborate

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

Condividi l'analisi post-mortem il più ampiamente possibile

Per assicurarti che i problemi non rimangano irrisolti, pubblica i risultati dell'analisi post mortem per un vasto pubblico e ricevi il supporto della gestione. Il valore di un'analisi post mortem è proporzionale all'apprendimento che si verifica dopo l'analisi. Quando più persone imparano dagli incidenti, la probabilità che si verifichino nuovamente guasti 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.