Guida alla pianificazione del ripristino di emergenza

Last reviewed 2023-11-22 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 devi 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:

Introduzione

Gli eventi che interrompono il servizio possono verificarsi in qualsiasi momento. La rete potrebbe presentare un'interruzione, il push più recente dell'applicazione potrebbe introdurre un bug critico o è possibile che tu debba fare i conti con una calamità naturale. Quando si verificano problemi, è importante avere un piano di RE efficace, mirato e ben collaudato.

Con un piano di RE ben progettato e collaudato, puoi avere la certezza che, in caso di catastrofe, l'impatto sui profitti della tua attività sarà minimo. Indipendentemente dalle esigenze di RE, Google Cloud offre una selezione di prodotti e funzionalità solida, flessibile ed economica che puoi utilizzare per creare o potenziare la soluzione adatta a te.

Nozioni di base sulla pianificazione di RE

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

  • Un Recovery Time Objective (RTO), che corrisponde al periodo di tempo massimo accettabile in cui la tua applicazione può essere offline. Questo valore è solitamente definito nell'ambito di un accordo sul livello del servizio (SLA) più ampio.
  • Un RPO (Recovery Point Objective), che corrisponde al periodo di tempo massimo accettabile durante il quale i dati potrebbero essere persi dalla tua 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 la durata e non la quantità o la qualità dei dati persi.

In genere, minori sono i valori RTO e RPO (ovvero, maggiore è la velocità di ripristino dell'applicazione da un'interruzione), maggiore sarà il costo dell'esecuzione dell'applicazione. Il seguente grafico mostra il rapporto tra costo e RTO/RPO.

Grafico che mostra che un RTO/RPO di piccole dimensioni corrisponde a costi elevati.

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

I valori RTO e RPO in genere vengono raggruppati in un'altra metrica: l'obiettivo del livello del servizio (SLO), che è 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 è supportato, orari, località, costi, prestazioni, sanzioni 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 dovrebbero essere considerati SLO.

Puoi scoprire di più su SLO e SLA nel libro Google Site Reliability Engineering.

Potresti anche pianificare un'architettura per l'alta disponibilità. L'alta disponibilità non si sovrappone completamente al RE, ma spesso è necessario tenerne conto quando si pensano 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 piano di RE.

Perché Google Cloud?

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

  • Capacità: garantire la sicurezza di risorse sufficienti per la scalabilità necessaria.
  • Sicurezza: fornire sicurezza fisica per proteggere le risorse.
  • Infrastruttura di rete:inclusi 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 una larghezza di banda adeguata per i picchi di carico.
  • Strutture: garanzia dell'infrastruttura fisica, incluse apparecchiature e alimentazione.

Fornendo una soluzione altamente gestita su una piattaforma di produzione di altissimo livello, Google Cloud ti aiuta ad aggirare la maggior parte o tutti questi fattori complicanti, rimuovendo molti costi aziendali nel processo. Inoltre, l'attenzione di Google Cloud alla semplicità amministrativa consente di ridurre 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 possiede una delle reti informatiche 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ù punti di presenza (POP) in tutto il mondo consente una forte ridondanza. Il mirroring dei dati viene eseguito automaticamente su più dispositivi di archiviazione in diverse 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 App Engine, i gestori della scalabilità automatica di Compute Engine e Datastore offrono una scalabilità automatica che consente all'applicazione di crescere e ridursi a seconda delle esigenze.
  • Sicurezza. Il modello di sicurezza di Google si basa su oltre 15 anni di esperienza nell'aiutare a proteggere i clienti nelle applicazioni Google come Gmail e Google Workspace. Inoltre, i team tecnici di Google per l'affidabilità del sito aiutano a garantire un'alta disponibilità e a prevenire l'uso illecito delle risorse della piattaforma.
  • Conformità. Google si sottopone a regolari audit di terze parti indipendenti 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 caldi, freddi o caldi. Questi pattern indicano la prontezza con cui il sistema può recuperare quando qualcosa va storto. Un'analogia potrebbe essere quella che faresti se stessi guidando e forando una gomma di un'auto.

3 foto di pneumatici a terra: non di scorta; una gomma di scorta con attrezzi; una gomma a terra.

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

  • Freddo: non hai una gomma di scorta, quindi devi chiamare qualcuno che venga da te con una gomma nuova e sostituirla. Il percorso si ferma fino all'arrivo dei soccorsi per effettuare la riparazione.
  • Caldo: hai una gomma di scorta e un kit di ricambio, così puoi tornare in auto con il mezzo che hai in auto. Tuttavia, devi interrompere il tuo percorso per risolvere il problema.
  • Caldo: hai pneumatici fuori terra. Potresti dover rallentare un po', ma l'impatto immediato sul tuo percorso non è immediato. Le gomme funzionano abbastanza bene da poter continuare (anche se alla fine devi risolvere il problema).

Creazione di un piano di RE dettagliato

Questa sezione fornisce consigli su come creare un piano di RE.

Progetta in base ai tuoi obiettivi di recupero

Quando progetti il tuo piano di RE, devi combinare le tecniche di recupero di applicazioni e dati e analizzare il quadro più ampio. Il modo tipico per farlo è esaminare i valori RTO e RPO e il pattern di RE che puoi adottare per soddisfare tali valori. Ad esempio, nel caso dei dati storici orientati alla conformità, probabilmente non hai bisogno di un accesso rapido ai dati, per cui sono appropriati un valore RTO elevato e un pattern di RE a freddo. Tuttavia, se il tuo servizio online subisce un'interruzione, ti consigliamo di recuperare sia i dati sia la parte dell'applicazione rivolta ai clienti il più rapidamente possibile. In questo caso, uno schema più attivo sarebbe più appropriato. Il tuo sistema di notifica via email, che in genere non è business critical, è probabilmente un candidato per un modello caldo.

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

Progetta per il ripristino end-to-end

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

Rendi specifiche le tue attività

Quando è il momento di eseguire il piano di RE, non perdere tempo a tirare a indovinare il significato di ogni passaggio. Fai in modo che ogni attività del piano di RE sia costituita da uno o più comandi o azioni concreti e non ambigui. Ad esempio, l'opzione "Esegui lo script di ripristino" è troppo generica. Al contrario, "Open Bash and run /home/example/restore.sh" è preciso e concreto.

Implementazione di misure di controllo

Aggiungi controlli per prevenire le emergenze e rilevare i problemi prima che si verifichino. Ad esempio, aggiungi un monitoraggio che invii un avviso quando un flusso distruttivo dei dati, come una pipeline di eliminazione, presenta picchi imprevisti o altre attività insolite. Questo monitoraggio potrebbe anche terminare i processi della pipeline se viene raggiunta una determinata soglia di eliminazione, evitando una situazione catastrofica.

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 dall'origine o da un'immagine preconfigurata. Assicurati di disporre della licenza appropriata per qualsiasi software che eseguirai il deployment su Google Cloud; verifica con il fornitore del software per istruzioni.

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

Progetta un deployment continuo per il ripristino

Il set di strumenti per il deployment continuo (CD) è parte integrante del deployment delle tue applicazioni. Nell'ambito del tuo piano di ripristino, devi considerare la posizione nell'ambiente recuperato in cui eseguire 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à

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

Configura la stessa sicurezza per gli ambienti di RE e produzione

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

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

  • Se il tuo ambiente di produzione è Google Cloud, la replica dei criteri IAM nell'ambiente di ripristino di emergenza è semplice. Puoi utilizzare strumenti di Infrastructure as Code (IaC) come Terraform per eseguire il deployment dei 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 ripristino dell'ambiente di RE.

  • Se il tuo ambiente di produzione è on-premise, puoi mappare i ruoli funzionali, come i ruoli di amministratore di rete e di revisore, ai criteri IAM con i ruoli IAM appropriati. La documentazione di IAM contiene alcuni esempi di configurazioni 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 Google Cloud IAM.

Verifica la sicurezza del RE

Dopo aver configurato le autorizzazioni per l'ambiente di RE, assicurati di eseguire tutti i test. Crea un ambiente di test. Utilizza strumenti IaC come Terraform per eseguire il deployment dei criteri Google Cloud nell'ambiente di test. Verifica che le autorizzazioni che concedi agli utenti corrispondano a quelle concesse agli utenti 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 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 accedere e risolvere eventuali problemi di autenticazione. Incorpora gli utenti che accedono all'ambiente di ripristino di RE;ambito dei normali test di RE che implementi.

Per gestire centralmente chi ha accesso SSH alle macchine virtuali (VM) lanciate, abilita la funzionalità OS Login sui progetti Google Cloud che costituiscono l'ambiente di RE.

Addestrare gli utenti

Gli utenti devono capire come eseguire in Google Cloud le azioni che sono abituati a svolgere nell'ambiente di produzione, ad esempio l'accesso, l'accesso alle VM e così via. Utilizzando l'ambiente di test, addestra gli utenti a 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 di RE sia limitato solo a chi ne ha bisogno. Assicurati che i dati PII siano oscurati e criptati. Se esegui regolari test di penetrazione nell'ambiente di produzione, ti consigliamo di includere l'ambiente di RE nell'ambito di questo ambito ed eseguire test regolari stabilendo un ambiente di RE.

Assicurati che, mentre l'ambiente di RE è in servizio, tutti i log che raccogli vengono sottoposti a backfill nell'archivio log dell'ambiente di produzione. Allo stesso modo, assicurati di poter esportare gli audit log raccolti tramite Cloud Logging nell'ambito del tuo ambiente di ripristino di RE nell'archivio sink di log principale. Utilizza le funzionalità per il 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 di quel provider ai servizi Google Cloud equivalenti. Disporre di un processo per formattare l'input nel tuo ambiente di produzione.

Usa Cloud Storage come parte delle tue routine di backup giornaliere

Utilizza Cloud Storage per archiviare i backup. Assicurati che ai bucket che contengono i tuoi backup siano applicate le autorizzazioni appropriate.

Gestisci i secret correttamente

Gestisci chiavi e secret a livello di applicazione utilizzando Google Cloud per ospitare il servizio di gestione delle chiavi/segreti (KMS). Puoi utilizzare Cloud KMS o una soluzione di terze parti come HashiCorp Vault con un backend di Google Cloud come Spanner o Cloud Storage.

Tratta i dati recuperati come i dati di produzione

Assicurati che i controlli di sicurezza che applichi ai dati di produzione vengano applicati anche ai dati recuperati: devono essere applicati gli stessi requisiti in termini di autorizzazioni, crittografia e audit.

Sapere dove si trovano i 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 aveva accesso ai dati di backup e chi ha eseguito il ripristino.

Assicurarsi che il piano di RE funzioni

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

Mantieni più di un percorso di recupero dati

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

Testa il tuo piano regolarmente

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

  • Automatizzazione del provisioning dell'infrastruttura. Puoi utilizzare strumenti IaC come Terraform per automatizzare il provisioning delle istanze VM e di altre infrastrutture di Google Cloud. Se esegui l'ambiente di produzione on-premise, assicurati di disporre di un processo di monitoraggio che possa avviare il processo di RE quando viene rilevato un errore e può attivare le azioni di ripristino appropriate.
  • Monitora ed esegui il debug dei test con Cloud Logging e Cloud Monitoring. 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 appropriati che possano attivare azioni di recupero appropriate.

  • Esegui i test indicati in precedenza:

    • Verifica che le autorizzazioni e l'accesso utente funzionino nell'ambiente di RE come nell'ambiente di produzione.
    • Esegui test di penetrazione nel tuo ambiente di RE.
    • Esegui un test in cui il tuo solito percorso di accesso a Google Cloud non funziona.

Che cosa succede dopo?