Guida alla pianificazione del ripristino di emergenza

Last reviewed 2024-07-05 UTC

Questo documento è la prima parte di una serie che illustra il ripristino di emergenza (RE) in Google Cloud. Questa parte fornisce una panoramica del processo di pianificazione di RE: ciò che è necessario sapere per progettare e implementare un piano di RE. Le parti successive discutono di casi d'uso specifici di RE con implementazioni di esempio su Google Cloud.

La serie è costituita dai seguenti componenti:

Gli eventi che interrompono il servizio possono verificarsi in qualsiasi momento. La tua rete potrebbe avere un'interruzione, l'ultimo push dell'applicazione potrebbe introdurre un bug critico o potresti dover fare i conti con una calamità naturale. Quando le cose non vanno per il verso giusto, è importante avere un piano di RE efficace, mirato e collaudato.

Con un piano di RE ben progettato e collaudato, puoi assicurarti che, in caso di catastrofi, l'impatto sui profitti della tua azienda sarà minimo. A prescindere dalle esigenze di RE, Google Cloud offre una selezione solida, flessibile e conveniente di prodotti e funzionalità che puoi utilizzare per creare o potenziare la soluzione che fa al caso tuo.

Nozioni di base sulla pianificazione di RE

RE è un sottoinsieme della pianificazione della continuità aziendale. La pianificazione RE inizia con un'analisi dell'impatto aziendale che definisce due metriche chiave:

  • Un Recovery Time Objective (RTO), ovvero il periodo di tempo massimo accettabile durante il quale la tua applicazione può rimanere offline. Questo valore è in genere definito come parte di un accordo sul livello del servizio (SLA) più ampio.
  • Un Recovery Point Objective (RPO), ovvero il periodo di tempo massimo accettabile durante il quale i dati potrebbero essere persi dall'applicazione a causa di un incidente grave. Questa metrica varia in base alle modalità di utilizzo dei dati. Ad esempio, i dati utente modificati di frequente potrebbero avere un RPO di pochi minuti. Al contrario, i dati meno critici e modificati raramente potrebbero avere un RPO di diverse ore. Questa metrica descrive solo il periodo di tempo, non tiene conto della quantità o della qualità dei dati persi.

In genere, minori sono i valori RTO e RPO (ovvero, più rapidamente è necessario recuperare l'applicazione a seguito di un'interruzione), maggiore sarà il costo dell'esecuzione dell'applicazione. Il seguente grafico mostra il rapporto tra i costi e l'RTO/RPO.

Il grafico mostra che RTO/RPO di dimensioni ridotte è associato a costi elevati.

Poiché valori di RTO e RPO più piccoli spesso corrispondono a una maggiore complessità, l'overhead amministrativo associato segue una curva simile. Un'applicazione ad alta disponibilità potrebbe richiedere la gestione della distribuzione tra due data center fisicamente separati, la gestione della replica e altro ancora.

I valori RTO e RPO in genere vengono raggruppati in un'altra metrica: l'obiettivo del livello di servizio (SLO), un elemento chiave misurabile di uno SLA. SLA e SLO sono spesso confusi. Uno SLA è l'intero contratto che specifica quale servizio deve essere fornito, come viene supportato, orari, località, costi, prestazioni, penalità e responsabilità delle parti coinvolte. Gli SLO sono caratteristiche specifiche e misurabili dello SLA (accordo sul livello del servizio), come disponibilità, velocità effettiva, frequenza, tempo di risposta o qualità. Uno SLA può contenere molti SLO. RTO e RPO sono misurabili e devono essere considerati SLO.

Per ulteriori informazioni su SLO e SLA, consulta il libro Google Site Reliability Engineering.

Potresti anche pianificare un'architettura per l'alta disponibilità (HA). L'alta disponibilità non si sovrappone completamente alla RE, ma spesso è necessario prendere in considerazione l'alta disponibilità quando si pensa ai valori RTO e RPO. L'alta disponibilità aiuta a garantire un livello concordato di prestazioni operative, in genere di uptime, per un periodo superiore al normale. Quando esegui carichi di lavoro di produzione su Google Cloud, potresti utilizzare un sistema distribuito a livello globale, in modo che, se si verifica un problema in una regione, l'applicazione continui a fornire il servizio anche se è meno disponibile. In sostanza, l'applicazione richiama il suo piano di RE.

Perché Google Cloud?

Google Cloud può ridurre notevolmente i costi associati sia all'RTO che all'RPO, rispetto al soddisfacimento dei requisiti RTO e RPO on-premise. Ad esempio, la pianificazione RE richiede di tenere conto di una serie di requisiti, tra cui:

  • Capacità: proteggi risorse sufficienti per scalare in base alle esigenze.
  • Sicurezza: fornire sicurezza fisica per proteggere le risorse.
  • Infrastruttura di rete: componenti software come firewall e bilanciatori del carico.
  • Assistenza:mette a disposizione tecnici qualificati per eseguire la manutenzione e risolvere i problemi.
  • Larghezza di banda: pianifica la larghezza di banda adeguata per i picchi di carico.
  • Strutture: garantire l'infrastruttura fisica, comprese attrezzature e alimentazione.

Fornendo una soluzione altamente gestita su una piattaforma di produzione di altissimo livello, Google Cloud ti aiuta ad aggirare gran parte o tutti questi fattori di complicanza, eliminando molti costi aziendali nel processo. Inoltre, l'attenzione di Google Cloud alla semplicità amministrativa riduce anche i costi di gestione di un'applicazione complessa.

Google Cloud offre diverse funzionalità pertinenti per la pianificazione di RE, tra cui:

  • Una rete globale. Google ha una delle reti di computer più grandi e avanzate del mondo. La rete backbone di Google utilizza avanzati servizi di networking software-defined e di memorizzazione in una cache perimetrale per offrire prestazioni rapide, coerenti e scalabili.
  • Ridondanza. La presenza di più POP (POP) in tutto il mondo si traduce in una forte ridondanza. Il mirroring dei dati viene eseguito automaticamente su dispositivi di archiviazione in più località.
  • Scalabilità. Google Cloud è progettato per scalare come altri prodotti Google (ad esempio, Ricerca e Gmail), anche quando si verifica un enorme picco di traffico. I servizi gestiti come Cloud Run, Compute Engine e Firestore offrono scalabilità automatica che consente alla tua applicazione di crescere e ridursi secondo necessità.
  • Sicurezza. Il modello di sicurezza di Google si basa su decenni di esperienza nella protezione dei clienti su applicazioni Google come Gmail e Google Workspace. Inoltre, i team di Site Reliability Engineering di Google contribuiscono a garantire un'alta disponibilità e a prevenire l'abuso delle risorse della piattaforma.
  • Conformità. Google si sottopone a regolari controlli indipendenti di terze parti per verificare che Google Cloud sia in linea con le best practice e le normative di sicurezza, privacy e conformità. Google Cloud è conforme a certificazioni quali ISO 27001, SOC 2/3 e PCI DSS 3.0.

Pattern RE

I pattern di RE sono considerati freddi, caldi o caldi. Questi pattern indicano la prontezza con cui il sistema può recuperare quando qualcosa va storto. Un'analogia potrebbe essere quello che faresti se stessi guidando e forando una gomma.

Il modo in cui devi gestire una gomma a terra dipende dal tuo livello di preparazione:

  • A freddo: non hai una gomma di scorta, quindi devi chiamare qualcuno che venga da te con una gomma nuova e la sostituisca. La corsa si ferma finché non arriva i soccorsi per effettuare la riparazione.
  • Caldo: hai una ruota di scorta e un kit di sostituzione, così puoi rimetterti sulla strada con ciò che hai in auto. Tuttavia, devi fermarti per risolvere il problema.
  • Caldo: hai pneumatici run-flat. Potresti dover rallentare un po', ma non c'è un impatto immediato sul tuo percorso. Gli pneumatici funzionano abbastanza bene da poter continuare (ma alla fine devi risolvere il problema).

Creare un piano di RE dettagliato

Questa sezione fornisce consigli su come creare il tuo piano di RE.

Progettati in base ai tuoi obiettivi di recupero

Quando progetti il tuo piano di RE, devi combinare le tue tecniche di recupero delle applicazioni e dei dati e di avere un quadro più ampio. Il modo tipico per farlo è esaminare i valori RTO e RPO e il pattern di RE che puoi adottare per soddisfare questi valori. Ad esempio, nel caso di dati storici orientati alla conformità, probabilmente non hai bisogno di un accesso rapido ai dati, quindi un valore RTO elevato e un pattern di RE a freddo sono appropriati. Tuttavia, se si verifica un'interruzione del servizio online, vorrai poter recuperare sia i dati sia la parte dell'applicazione rivolta agli utenti il più rapidamente possibile. In tal caso, un pattern a caldo sarebbe più appropriato. Il tuo sistema di notifica via email, che in genere non è essenziale per l'attività, è probabilmente un candidato per un modello caldo.

Per indicazioni sull'utilizzo di Google Cloud per risolvere scenari di RE comuni, esamina gli scenari di ripristino delle applicazioni. Questi scenari forniscono strategie di RE destinate per una varietà di casi d'uso e offrono implementazioni di esempio su Google Cloud per ciascuno.

Progetta per il recupero end-to-end

Non basta avere un piano per il backup o l'archiviazione dei dati. Assicurati che il tuo piano di RE risolva l'intero processo di ripristino, dal backup al ripristino fino alla pulizia. Ne discuteremo nei documenti correlati sui dati di RE e sul ripristino.

Rendi specifiche le tue attività

Quando è il momento di eseguire il tuo piano di RE, non devi essere bloccato a indovinare il significato di ogni passaggio. Fai in modo che ogni attività nel tuo piano di RE sia composta da uno o più comandi o azioni concreti e non ambigui. Ad esempio, "Esegui lo script di ripristino" è troppo generico. Al contrario, l'opzione "Apri una shell ed esegui /home/example/restore.sh" è precisa e concreta.

Implementazione di misure di controllo

Aggiungi controlli per prevenire i disastri e rilevare i problemi prima che si verifichino. Ad esempio, aggiungi un monitor che invii un avviso quando un flusso distruttivo dei dati, come una pipeline di eliminazione, mostra picchi imprevisti o altre attività insolite. Questo monitoraggio potrebbe anche interrompere i processi della pipeline al raggiungimento di una determinata soglia di eliminazione, evitando situazioni catastrofiche.

Preparazione del software

Parte della pianificazione di RE consiste nell'assicurarti che il software su cui fai affidamento sia pronto per un evento di ripristino.

Verifica di poter installare il software

Assicurati che il software dell'applicazione possa essere installato dal codice sorgente o da un'immagine preconfigurata. Assicurati di disporre della licenza adeguata per qualsiasi software di cui eseguirai il deployment su Google Cloud. Per indicazioni, rivolgiti al fornitore del software.

Assicurati che nell'ambiente di ripristino siano disponibili le risorse Compute Engine necessarie. Ciò potrebbe richiedere la preallocazione delle istanze o la loro prenotazione.

Progettare il deployment continuo per il ripristino

Il set di strumenti per il deployment continuo (CD) è un componente integrante quando esegui il deployment delle tue applicazioni. Nell'ambito del piano di ripristino, devi considerare in quale punto dell'ambiente recuperato eseguirai il deployment degli artefatti. Pianifica dove vuoi ospitare l'ambiente CD e gli artefatti, che devono essere disponibili e operativi in caso di emergenza.

Implementazione dei controlli di sicurezza e conformità

Quando si progetta un piano di RE, la sicurezza è importante. All'ambiente recuperato devono essere applicati gli stessi controlli utilizzati nell'ambiente di produzione. Le normative di conformità verranno applicate anche all'ambiente recuperato.

Configurare la sicurezza allo stesso modo per gli ambienti di RE e di produzione

Assicurati che i controlli di rete forniscano la stessa separazione e blocco utilizzati dall'ambiente di produzione di origine. Scopri come configurare un VPC condiviso e i firewall per stabilire un controllo centralizzato di sicurezza e networking del deployment, configurare subnet e controllare il traffico in entrata e in uscita. Capire come utilizzare gli account di servizio per implementare privilegio minimo per le applicazioni che accedono alle API Google Cloud. Usa gli account di servizio come parte delle regole firewall.

Assicurati di concedere agli utenti lo stesso accesso all'ambiente di RE di cui dispongono nell'ambiente di produzione di origine. Il seguente elenco illustra i modi per sincronizzare le autorizzazioni tra gli ambienti:

  • Se il tuo ambiente di produzione è Google Cloud, replicare i criteri IAM nell'ambiente di RE è semplice. Puoi utilizzare strumenti di Infrastructure as Code (IaC) come Terraform per eseguire il deployment dei tuoi criteri IAM in produzione. Potrai quindi utilizzare gli stessi strumenti per associare i criteri alle risorse corrispondenti nell'ambiente di RE nell'ambito del processo di preparazione dell'ambiente di RE.

  • Se il tuo ambiente di produzione è on-premise, devi mappare i ruoli funzionali, ad esempio i ruoli di amministratore di rete e revisore, ai criteri IAM che dispongono dei ruoli IAM appropriati. La documentazione IAM contiene alcune configurazioni di esempio dei ruoli funzionali. Ad esempio, consulta la documentazione per la creazione di ruoli funzionali di networking e audit logging.

  • Devi configurare i criteri IAM per concedere le autorizzazioni appropriate ai prodotti. Ad esempio, potresti voler limitare l'accesso a bucket Cloud Storage specifici.

  • Se il tuo ambiente di produzione è un altro cloud provider, mappa le autorizzazioni nei criteri IAM dell'altro provider ai criteri IAM di Google Cloud.

Verifica la sicurezza di RE

Dopo aver configurato le autorizzazioni per l'ambiente RE, assicurati di testare tutto. Crea un ambiente di test. Verifica che le autorizzazioni concesse agli utenti corrispondano a quelle di cui gli utenti dispongono on-premise.

Assicurati che gli utenti possano accedere all'ambiente di RE

Non attendere che si verifichi un'emergenza prima di verificare che gli utenti possano accedere all'ambiente di RE. Assicurati di aver concesso i diritti di accesso appropriati a utenti, sviluppatori, operatori, data scientist, amministratori della sicurezza, amministratori di rete e a qualsiasi altro ruolo nella tua organizzazione. Se utilizzi un sistema di identità alternativo, assicurati che gli account siano stati sincronizzati con il tuo account Cloud Identity. Poiché l'ambiente di RE sarà il tuo ambiente di produzione per un po' di tempo, chiedi agli utenti che avranno bisogno di accedere all'ambiente di RE per eseguire l'accesso e risolvi eventuali problemi di autenticazione. Incorpora gli utenti che accedono all'ambiente di RE nell'ambito dei regolari test di RE implementati.

Per gestire centralmente chi ha accesso amministrativo alle macchine virtuali (VM) avviate, abilita la funzionalità di accesso al sistema operativo sui progetti Google Cloud che costituiscono il tuo ambiente di RE.

Formare gli utenti

Gli utenti devono capire come intraprendere in Google Cloud le azioni che sono abituati a svolgere nell'ambiente di produzione, come l'accesso e l'accesso alle VM. Utilizzando l'ambiente di test, forma gli utenti su come eseguire queste attività in modo da salvaguardare la sicurezza del sistema.

Assicurati che l'ambiente di RE soddisfi i requisiti di conformità

Verifica che l'accesso all'ambiente RE sia limitato solo a coloro che hanno bisogno dell'accesso. Assicurati che i dati PII siano oscurati e criptati. Se esegui regolarmente test di penetrazione nel tuo ambiente di produzione, devi includere il tuo ambiente di RE in questo ambito ed eseguire test regolari mettendo in pratica un ambiente di RE.

Assicurati che, mentre l'ambiente di RE è in servizio, venga eseguito il backfill di tutti i log raccolti nell'archivio dei log dell'ambiente di produzione. Allo stesso modo, assicurati che nell'ambiente di RE sia possibile esportare gli audit log raccolti tramite Cloud Logging nell'archivio principale del sink di log. Utilizza i servizi di sink di esportazione. Per i log delle applicazioni, crea un mirroring dell'ambiente di logging e monitoraggio on-premise. Se il tuo ambiente di produzione è un altro cloud provider, mappa il logging e il monitoraggio del provider ai servizi Google Cloud equivalenti. Prepara un processo per formattare l'input nel tuo ambiente di produzione.

Tratta i dati recuperati come dati di produzione

Assicurati che i controlli di sicurezza applicati ai dati di produzione si applichino anche ai dati recuperati: si applicano le stesse autorizzazioni, gli stessi requisiti di crittografia e di controllo.

Scopri dove si trovano i tuoi backup e chi è autorizzato a ripristinare i dati. Assicurati che il processo di ripristino sia controllabile: dopo un ripristino di emergenza, assicurati di poter mostrare chi ha avuto accesso ai dati di backup e chi ha eseguito il ripristino.

Verificare il funzionamento del piano di RE

In caso di disastro, assicurati che il tuo piano di RE funzioni come previsto.

Gestire più di un percorso di recupero dei dati

In caso di emergenza, il metodo di connessione a Google Cloud potrebbe non essere disponibile. Implementare un mezzo di accesso alternativo a Google Cloud per assicurarsi di poter trasferire i dati in Google Cloud. Verifica regolarmente che il percorso di backup sia operativo.

Verifica regolarmente il piano

Dopo aver creato un piano di RE, testalo regolarmente, annotando gli eventuali problemi che si presentano e modificando il piano di conseguenza. Con Google Cloud puoi testare scenari di ripristino con costi minimi. Ti consigliamo di implementare quanto segue per agevolare il test:

  • Automatizzare il provisioning dell'infrastruttura. Puoi utilizzare strumenti IaC come Terraform per automatizzare il provisioning della tua infrastruttura Google Cloud. Se esegui il tuo ambiente di produzione on-premise, assicurati di disporre di un processo di monitoraggio in grado di avviare il processo di RE quando rileva un errore e possa attivare le azioni di ripristino appropriate.
  • Monitora i tuoi ambienti con Google Cloud Observability}. Google Cloud dispone di eccellenti strumenti di logging e monitoraggio a cui puoi accedere tramite chiamate API, che ti consentono di automatizzare il deployment degli scenari di ripristino reagendo alle metriche. Quando progetti i test, assicurati di disporre di monitoraggio e avvisi adeguati che possano attivare azioni di ripristino appropriate.

  • Esegui i test indicati in precedenza:

    • Verifica che le autorizzazioni e l'accesso degli utenti funzionino nell'ambiente di RE come nell'ambiente di produzione.
    • Eseguire un test di penetrazione nel proprio ambiente di RE.
    • Esegui un test in cui il normale percorso di accesso a Google Cloud non funziona.

Che cosa succede dopo?

Collaboratori

Autori: