Google PCA: Affidabilità, disaster recovery e continuità operativa — Guida allo studio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fa parte della Google Professional Cloud Architect — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Affidabilità, Disaster Recovery (DR) e continuità operativa garantiscono che i servizi continuino a soddisfare gli obiettivi concordati nonostante guasti a livello di componente, zona o region. Su Google Cloud, l’affidabilità viene progettata comprendendo i domini di errore (zonali, regionali e globali), definendo gli obiettivi di ripristino (RTO/RPO), selezionando architetture di servizio resilienti (ad es. attivo-attivo) e testando rigorosamente i piani di ripristino. La tua progettazione deve mappare la criticità del servizio a obiettivi di disponibilità espliciti, garanzie di durabilità e percorsi di ripristino convalidati, bilanciando disponibilità, coerenza, costi e complessità operativa. I temi chiave includono l’isolamento dei singoli punti di guasto (single point of failure), l’uso della replica gestita dove possibile, l’automazione delle decisioni di failover e la convalida continua che le ipotesi rimangano valide in condizioni simili a quelle di produzione.

Domini di errore, località e servizi multi-regionali

Zone di disponibilità e region:
- Le zone sono domini di errore indipendenti all’interno di una region. I guasti a livello di zona sono gli eventi su larga scala più comuni per cui si progetta.
- Le region sono insiemi di zone con collegamenti a bassa latenza. I guasti a livello di region sono più rari ma devono essere considerati per i sistemi ad alta criticità.
- Pattern di progettazione:
  - Intra-regionale: distribuire il carico di calcolo stateless su almeno due zone tramite gruppi di istanze gestite (MIG) regionali.
  - Inter-regionale: replicare lo stato ed eseguire il failover del traffico per i servizi critici che non possono tollerare la perdita di una region.
Servizi multi-regionali e globali:
- Piani di controllo globali: reti VPC, Cloud DNS, bilanciamento del carico HTTP(S) esterno globale e Cloud IAM sono servizi con ambito globale utilizzati per ridurre l’accoppiamento regionale.
- Il posizionamento del piano dati è importante:
  - Cloud Storage: scegliere bucket regionali, dual-region o multi-regionali in base ai pattern di accesso e alle esigenze di DR.
  - BigQuery: i set di dati risiedono in una region o in una multi-region; la multi-region migliora la disponibilità della superficie di analisi, ma bisogna considerare la residenza dei dati e l’egress per le join esterne.
  - Spanner: la configurazione dell’istanza (regionale o multi-regionale) definisce la topologia delle repliche e il comportamento di coerenza.
Analisi dei domini di errore:
- Mappare ogni componente al suo raggio d’impatto (blast radius). Esempi:
  - Zonale: singola VM, pool di nodi GKE zonale, PD SSD zonale.
  - Regionale: il primario e lo standby di Cloud SQL HA sono regionali; alcuni eventi di manutenzione possono avere un impatto su una region.
  - Globale: una configurazione errata di IAM o Cloud DNS influisce su tutte le region.
- Identificare i guasti correlati come le dipendenze condivise (ad es. un unico gateway NAT, un’unica istanza di Memorystore) o il rischio indotto dall’uomo (account di servizio condiviso, un unico stato di Terraform).
- Considerare le quote come domini di errore; un autoscaler che raggiunge il limite di una quota regionale è funzionalmente non operativo.

Compromessi:

La replica tra zone riduce i tempi di inattività ma aggiunge traffico e costi tra le zone.
Le architetture cross-region riducono l’RTO ma aumentano la latenza, la complessità e la spesa.
Il bilanciamento del carico anycast globale semplifica il failover ma maschera i backend non integri solo se i controlli di integrità (health check) sono precisi.

Obiettivi, mappatura delle dipendenze e convalida del DR

RTO e RPO:
- Recovery Time Objective (RTO): tempo target per ripristinare il servizio. Determina il livello di automazione, la postura dello standby e il dettaglio dei runbook.
- Recovery Point Objective (RPO): finestra di perdita di dati accettabile. Determina la scelta della replica e la cadenza dei backup.
Criticità e classificazione (tiering) dei servizi:
- Definire i livelli (tier) (ad es. Tier 0: impatto sulla sicurezza/finanziario; Tier 1: fatturato; Tier 2: strumenti interni) con SLO, RTO/RPO target e frequenza dei test.
- Legare la spesa e la complessità al livello (tier); non tutti i servizi necessitano di una configurazione cross-region.
Mappatura delle dipendenze:
- Inventariare le dipendenze a monte (upstream) e a valle (downstream): identità (Cloud IAM, SAML IdP), segreti (Secret Manager, KMS), networking (DNS, Cloud Interconnect/VPN), storage e DB, osservabilità, CI/CD e API di terze parti.
- Documentare la region, la zona e lo SLA per ogni dipendenza; definire controlli di compensazione per gli anelli più deboli.
Piani di ripristino:
- Creare runbook e automazione per failover/failback, ripristino dei dati e promozione della configurazione (DNS, backend del bilanciatore di carico, firewall).
- Pre-provisionare permessi e account di servizio; preparare (stage) le definizioni dell’infrastruttura per eliminare i blocchi manuali.
- Mantenere un accesso di emergenza (break-glass) con elevazione dei privilegi tracciabile.
Test di ripristino:
- Pianificare failover di routine per i sistemi stateful (ad es. Cloud SQL HA) per convalidare la promozione e la rinegoziazione della connessione.
- Eseguire dei ‘game day’ che simulino un’interruzione a livello di zona o di region; includere i provider a monte e i guasti di IAM/KMS.
- Utilizzare l’iniezione di errori (fault injection) per convalidare i circuit breaker, i timeout e i tentativi (retry); verificare che l’autoscaling e il backpressure funzionino come previsto.
- Misurare continuamente RTO/RPO durante i test; modificare l’architettura quando gli obiettivi non vengono raggiunti.

Pattern resilienti per Compute, Database e Storage

Compute auto-riparante con MIG regionali e bilanciamento del carico:
- Utilizzare i MIG regionali per distribuire le istanze tra le zone con scalabilità e riparazione automatiche (autoscaling e autohealing).
- Utilizzare come front-end un bilanciatore del carico HTTP(S) esterno globale e un health check del servizio di backend allineato alla reale prontezza (ad es., /healthz che controlla le dipendenze).
- Consentire gli health check attraverso i firewall per evitare il riciclo costante delle VM:

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - Evitare lo stato locale; esternalizzare le sessioni su Memorystore o database; utilizzare il connection draining sui backend per preservare le richieste in transito (in-flight) durante lo scale-in.
  - Modalità di guasto comuni: health check non allineati (che controllano troppo o troppo poco), regole firewall mancanti e bootstrapping che dipende da servizi a valle (downstream) non integri.
- Resilienza di Cloud SQL:
  - Alta disponibilità (High availability): istanza primaria e di standby in zone separate con replica sincrona del disco e failover automatico; selezionare una finestra di manutenzione e testare i failover.
  - Repliche di lettura (Read replicas): aggiungere repliche di lettura nella stessa regione o cross-region per scaricare le letture e ridurre l'RTO in caso di eventi regionali; promuovere le repliche durante il DR (Disaster Recovery).
  - Backup e PITR:
    - Abilitare i backup giornalieri automatici e il point-in-time recovery (PITR) tramite log binari/di transazione con una conservazione (retention) sufficiente per la conformità e l'RPO.
    - Convalidare i ripristini in ambienti non di produzione ed esercitarsi con le procedure di promozione e gli aggiornamenti delle stringhe di connessione dell'applicazione.
  - Rete: preferire l'IP privato per la produzione; assicurarsi che i test di failover convalidino il comportamento del DNS e del connection pooling.
  - Suggerimento operativo: eseguire periodicamente un failover controllato per verificare che i pool di connessioni dell'applicazione si ricolleghino correttamente.

gcloud sql instances failover prod-sql
```

Configurazione e resilienza di Spanner:
- Le istanze regionali forniscono letture/scritture a bassa latenza e a consistenza forte (strongly consistent) all’interno di una regione, utilizzando Paxos tra le zone.
- Le istanze multiregionali replicano tra le regioni con scritture sincrone a quorum (consistenza forte globale) e repliche di sola lettura opzionali; scegliere una regione leader vicina a chi effettua le scritture (writer).
- Compromessi: la configurazione multiregionale migliora RTO/RPO e la disponibilità in lettura, ma aumenta la latenza di scrittura e i costi. Utilizzarla per carichi di lavoro distribuiti a livello globale, con scritture intensive che necessitano di consistenza forte; altrimenti, considerare Spanner regionale o Cloud SQL con repliche.
Pattern di durabilità e ripristino per Cloud Storage:
- Strategia di localizzazione: regionale per la vicinanza al compute (compute-locality), dual-region per un’architettura attivo-attivo su due regioni, multiregione per un’ampia disponibilità per gli utenti globali.
- Controllo delle versioni (Versioning): abilitare il versioning degli oggetti per il ripristino da cancellazioni o corruzioni; combinarlo con le regole del ciclo di vita (lifecycle rules) per gestire i costi.
- Conservazione (Retention): applicare policy di conservazione a livello di bucket e, se necessario, blocchi di conservazione (retention lock) per la conformità; utilizzare blocchi basati su eventi (event-based hold) per la gestione dei record.
- Pattern di backup: bucket cross-project con amministratori separati mitigano la cancellazione accidentale e l’escalation dei privilegi. Per i database, esportare i backup logici su Cloud Storage in un progetto distinto.
- Esempio di regola del ciclo di vita (lifecycle rule) per eliminare le versioni più vecchie di 90 giorni:

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    Applicare con:

gsutil lifecycle set lifecycle.json gs://prod-backups
```

Ripristino: mantenere cataloghi degli oggetti critici e testare i ripristini; per dataset di grandi dimensioni, effettuare i ripristini (stage) in bucket temporanei per evitare collisioni di nomi e convalidare l’integrità.

Gestione del traffico, strategie multi-sito e resilienza continua

Strategie multi-sito:
- Attivo-attivo: serve il traffico da più region contemporaneamente; richiede la replica simmetrica dei dati e scritture senza conflitti. Migliori RTO/RPO; costo e complessità più elevati.
- Attivo-passivo: un’istanza primaria attiva (hot) e una secondaria pronta; i dati vengono replicati continuamente, il traffico viene deviato in caso di guasto. Buon equilibrio tra costo e RTO.
- Warm standby: un’istanza secondaria ridimensionata con dati pre-sincronizzati; richiede uno scale-up al momento del failover; RTO e costo moderati.
- Pilot light: replica minima dei dati critici e definizioni dell’infrastruttura; la maggior parte dei componenti viene provisionata al momento del failover; RTO lungo, costo operativo basso.
- Cold standby: solo backup periodici; ripristino (rehydrate) in caso di guasto; RTO più lungo, costo più basso.
Failover tramite DNS e gestione del traffico:
- Preferire il routing basato sullo stato di integrità (health-based) a livello 7 (Layer 7) con il load balancer HTTP(S) esterno globale. Esegue health check per ogni backend e sposta il traffico lontano da zone o region non integre senza modifiche al DNS.
- Utilizzare record DNS con TTL basso solo come controllo di failover approssimativo o per passare da un VIP di load balancer a un altro disgiunto; comprendere che la cache DNS implica che il failover non è istantaneo.
- Per i servizi privati, utilizzare l’Internal HTTP(S) Load Balancing con pattern di failover regionali, più un DNS privato che è possibile aggiornare programmaticamente se necessario.
Pattern di degrado graduale (graceful degradation):
- Implementare feature flag per disabilitare le funzionalità non critiche in condizioni di stress.
- Utilizzare circuit breaker, timeout, tentativi di ripetizione (retry) con jitter e bulkhead per localizzare i guasti.
- Fornire una modalità di sola lettura (read-only) quando i percorsi di scrittura sono compromessi; accodare le scritture per una riconciliazione successiva.
- Applicare il rate-limiting ai client e la contropressione (backpressure) per prevenire guasti a cascata.
Chaos testing e miglioramento continuo:
- L’iniezione di guasti (fault injection) a livello di rete (latenza, perdita di pacchetti) e di applicazione convalida che i controlli di resilienza si attivino come previsto.
- I game day rendono operativo il ripristino tra i team; includono la notifica al personale (paging), l’esecuzione dei runbook e analisi post-mortem con azioni correttive concrete.
- Monitorare gli error budget e gli SLO; regolare la capacità, le strategie di retry e le configurazioni di replica in base a quanto giustificato dai dati.
Compromessi tra disponibilità, coerenza, costo e complessità:
- Disponibilità vs. coerenza: una coerenza forte globale (strong global consistency) (es. Spanner multi-regionale) può aggiungere latenza in scrittura; la coerenza finale (eventual consistency) (es. repliche asincrone) può migliorare la latenza ma rischia letture di dati non aggiornati (stale reads).
- Costo vs. RTO/RPO: lo storage dual-region e i database multi-regionali aumentano la spesa ma minimizzano la perdita di dati e i tempi di inattività.
- Complessità vs. affidabilità: ogni meccanismo di failover, flusso di replica e regola di routing deve essere gestito e testato; mantenere i progetti il più semplici possibile per raggiungere gli obiettivi.

Scenario pratico

Acme Tickets, un’azienda di biglietteria online in rapida crescita, deve garantire la continuità operativa durante le interruzioni regionali per la sua API di acquisto e il catalogo eventi, mantenendo al contempo RTO/RPO rigorosi (RTO ≤ 5 minuti, RPO ≤ 1 minuto). Lo stack include microservizi stateless, un database relazionale per gli ordini, una pipeline di analisi e asset multimediali statici.

Definire i livelli di servizio (tier), gli SLO e gli obiettivi di ripristino

Motivazione: Classificare l’API di acquisto e il DB degli ordini come Tier 0 (RTO 5m, RPO 1m), il catalogo come Tier 1 (RTO 15m, RPO 5m) e l’analisi come Tier 2 (best effort). Questo allinea costo e complessità all’impatto sul business.

Scegliere il posizionamento regionale e la strategia multi-sito

Motivazione: Implementare una configurazione attivo-attivo tra us-central1 e us-east1 per i servizi stateless al fine di minimizzare l’RTO; utilizzare una configurazione attivo-passivo per il database degli ordini per bilanciare la latenza di scrittura e i costi.

Implementare MIG regionali e load balancing HTTP(S) globale

Motivazione: Due MIG regionali (uno per region) distribuiti ciascuno su almeno due zone. Un singolo VIP anycast globale instrada il traffico tramite servizi di backend monitorati da health check, escludendo automaticamente le region non integre.

Esternalizzare lo stato e configurare l’autoriparazione (self-healing)

Motivazione: Archiviare le sessioni in Memorystore con repliche di lettura (read replica) cross-region per il catalogo e mantenere i servizi stateless in modo che l’autohealing dei MIG e gli aggiornamenti continui (rolling update) siano sicuri. Gli health check puntano a /healthz, che convalida i sistemi a valle critici.

Provisionare Cloud SQL for PostgreSQL con HA e read replica cross-region

Motivazione: Utilizzare l’HA nella region primaria per la resilienza a livello di zona e abilitare il PITR con una retention sufficiente. Creare una read replica cross-region nella region secondaria e un runbook testato per promuoverla in caso di guasto regionale, rispettando un RPO ≤ 1 minuto con una perdita minima di scritture.

Pianificare test di failover di routine per il database

Motivazione: Eseguire failover controllati mensilmente per convalidare il comportamento di riconnessione dell’applicazione e la promozione della replica. Questo affronta una modalità di guasto comune in cui le repliche non vengono mai promosse durante incidenti reali.

Posizionare gli asset multimediali statici in un bucket Cloud Storage dual-region con versioning e retention

Motivazione: La configurazione dual-region garantisce la disponibilità degli oggetti in due region; il versioning protegge da sovrascritture/cancellazioni accidentali. Applicare regole di ciclo di vita (lifecycle rule) per far scadere le versioni obsolete e controllare i costi.

Proteggere gli health check e il traffico in uscita (egress) con firewall e quote

Motivazione: Creare regole firewall esplicite per gli health check del load balancer e monitorare le quote delle istanze regionali per prevenire blocchi dell’autoscaler durante il failover.

Implementare il DNS come controllo approssimativo con TTL basso

Motivazione: Sebbene il load balancer globale gestisca il routing basato sullo stato di integrità, mantenere un record A con TTL basso che punta a un VIP di standby per un passaggio manuale di emergenza, tenendo conto dei limiti della cache DNS.

Automatizzare i runbook di DR e convalidarli tramite game day

Motivazione: Utilizzare Cloud Scheduler per attivare traffico sintetico e gli SLO di Cloud Monitoring per confermare il comportamento durante i game day trimestrali con iniezione di guasti (es. blocco del traffico inter-region, terminazione di nodi). Raccogliere le metriche di RTO/RPO e affinare le procedure.

Mettere in sicurezza e separare i backup

Motivazione: Esportare backup logici giornalieri del DB degli ordini in un bucket Cloud Storage in un progetto separato con blocchi di conservazione (retention lock); ripristinare periodicamente su un’istanza di staging per convalidare l’integrità e le tempistiche.

Implementare il degrado graduale (graceful degradation)

Motivazione: Se il DB degli ordini è degradato, passare il catalogo in modalità di sola lettura, accodare le scritture per una riconciliazione successiva ed escludere le funzionalità non critiche. Questo previene guasti a cascata e mantiene un servizio parziale.

Questa architettura fornisce un failover regionale automatizzato per i servizi stateless, un failover controllato e testato per i componenti stateful e processi di ripristino verificati che soddisfano gli obiettivi di continuità operativa di Acme Tickets.

← Sicurezza · Tutti i domini · Migrazione →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →