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 del RE: ciò che devi sapere per progettare e implementare un piano di RE. Le parti successive illustrano casi d'uso specifici di RE con esempi di implementazioni su Google Cloud.

La serie è composta dai seguenti componenti:

Gli eventi che interrompono il servizio possono verificarsi in qualsiasi momento. La tua rete potrebbe subire un'interruzione, l'ultimo push dell'applicazione potrebbe introdurre un bug critico o potresti dover affrontare una calamità naturale. Quando le cose non vanno come previsto, è importante avere un piano di RE solido, mirato e ben testato.

Con un piano di RE ben progettato e testato, puoi assicurarti che, in caso di catastrofe, l'impatto sui profitti della tua attività sarà minimo. Indipendentemente dalle tue esigenze di RE, Google Cloud offre una selezione solida, flessibile e economicamente vantaggiosa di prodotti e funzionalità che puoi utilizzare per creare o migliorare la soluzione più adatta alle tue esigenze.

Nozioni di base sulla pianificazione del ripristino RE

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

  • Un RTO (Recovery Time Objective), ovvero il periodo di tempo massimo accettabile per cui la tua applicazione può essere offline. Questo valore viene solitamente definito nell'ambito 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 perduti dall'applicazione a causa di un incidente grave. Questa metrica varia in base ai modi in cui vengono utilizzati i dati. Ad esempio, i dati utente modificati frequentemente potrebbero avere un RPO di pochi minuti. Al contrario, i dati meno critici e modificati di rado potrebbero avere un RPO di diverse ore. Questa metrica descrive solo la durata, ma non la quantità o la qualità dei dati persi.

In genere, più i valori RTO e RPO sono ridotti (ovvero più velocemente l'applicazione deve riprendersi da un'interruzione), più elevato sarà il costo di esecuzione dell'applicazione. Il seguente grafico mostra il rapporto tra il costo e RTO/RPO.

Grafico che mostra che RTO/RPO ridotti corrispondono a costi elevati.

Poiché valori RTO e RPO più bassi spesso indicano una maggiore complessità, il carico 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.

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

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

Potresti anche pianificare un'architettura per la disponibilità elevata (HA). L'HA non si sovrappone completamente al RE, ma spesso è necessario prendere in considerazione l'HA quando si pensa ai valori RTO e RPO. L'HA contribuisce a garantire un livello concordato di prestazioni operative, in genere tempo di attività, 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 accade un problema in una regione, l'applicazione continui a fornire il servizio anche se è meno disponibile a livello generale. In sostanza, l'applicazione richiama il proprio piano di RE.

Perché Google Cloud?

Google Cloud può ridurre notevolmente i costi associati sia a RTO che a 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à:assicurati risorse sufficienti per eseguire la scalabilità in base alle esigenze.
  • Sicurezza: fornisce sicurezza fisica per proteggere le risorse.
  • Infrastruttura di rete:inclusi componenti software come firewall e bilanciatori del carico.
  • Assistenza: mettere a disposizione tecnici qualificati per eseguire la manutenzione e risolvere i problemi.
  • Larghezza di banda:pianifica la larghezza di banda adatta per i picchi di carico.
  • Strutture: garantire l'infrastruttura fisica, comprese attrezzature e energia.

Fornendo una soluzione altamente gestita su una piattaforma di produzione di livello mondiale, Google Cloud ti aiuta a bypassare la maggior parte o tutti questi fattori complicanti, rimuovendo molti costi aziendali. Inoltre,l'attenzione di Google Cloudalla semplicità amministrativa significa che anche i costi di gestione di un'applicazione complessa sono ridotti.

Google Cloud offre diverse funzionalità pertinenti alla pianificazione della RE, tra cui:

  • Una rete globale. Google dispone di una delle reti informatiche più grandi e avanzate al mondo. La rete backbone di Google utilizza avanzati servizi di networking software-defined e di memorizzazione nella cache perimetrale per offrire prestazioni elevate, coerenti e scalabili.
  • Ridondanza. La presenza di più punti di presenza (POP) in tutto il mondo garantisce una forte ridondanza. I dati vengono sottoposti a mirroring automatico su dispositivi di archiviazione in più località.
  • Scalabilità. Google Cloud è progettato per scalare come altri prodotti Google (ad esempio Ricerca e Gmail), anche in caso di picchi di traffico elevati. I servizi gestiti come Cloud Run, Compute Engine e Firestore ti offrono la scalabilità automatica che consente alla tua applicazione di crescere e ridursi in base alle esigenze.
  • Sicurezza. Il modello di sicurezza di Google si basa su decenni di esperienza nel garantire la sicurezza degli utenti su applicazioni Google come Gmail e Google Workspace. Inoltre, i team SRE (Site Reliability Engineer) di Google contribuiscono a garantire un'elevata disponibilità e a impedire utilizzi illeciti delle risorse della piattaforma.
  • Conformità. Google si sottopone regolarmente a audit 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 come ISO 27001, SOC 2/3 e PCI DSS 3.0.

Pattern di RE

I pattern di RE sono considerati freddi, tiepidi o caldi. Questi pattern indicano quanto facilmente il sistema può recuperare quando si verifica un problema. Un'analogia potrebbe essere cosa faresti se guidassi e foravi uno pneumatico dell'auto.

La modalità di gestione di una gomma a terra dipende da quanto sei preparato:

  • Freddo: non hai una ruota di scorta, quindi devi chiamare qualcuno che venga da te con una nuova ruota e la sostituisca. Il viaggio si interrompe finché non arriva l'assistenza per eseguire la riparazione.
  • Buono: hai una ruota di scorta e un kit di sostituzione, quindi puoi riprendere la strada utilizzando ciò che hai nell'auto. Tuttavia, devi interrompere il tuo percorso per risolvere il problema.
  • Hot: hai pneumatici run-flat. Potresti dover rallentare un po', ma non ci sarà alcun impatto immediato sul tuo viaggio. I pneumatici funzionano abbastanza bene da consentirti di continuare (anche se alla fine dovrai risolvere il problema).

Creazione di un piano di RE dettagliato

Questa sezione fornisce consigli su come creare il 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 guardare al quadro generale. Il modo più comune 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 incentrati sulla conformità, probabilmente non hai bisogno di un accesso rapido ai dati, quindi è appropriato un valore RTO elevato e un pattern di RE a freddo. Tuttavia, se il tuo servizio online subisce un'interruzione, è importante che tu possa recuperare il prima possibile sia i dati sia la parte dell'applicazione rivolta agli utenti. In questo caso, un pattern caldo sarebbe più appropriato. Il sistema di notifiche via email, che solitamente non è fondamentale per l'attività, è probabilmente un candidato per un pattern di attesa.

Per indicazioni sull'utilizzo di Google Cloud per gestire scenari di RE comuni, consulta gli scenari di recupero delle applicazioni. Questi scenari forniscono strategie di RE mirate per una serie di casi d'uso e offrono implementazioni di esempio suGoogle Cloud per ciascuno.

Progettare per il recupero end-to-end

Non basta avere un piano per il backup o l'archiviazione dei dati. Assicurati che il piano di RE tenga conto dell'intera procedura di recupero, dal backup al ripristino fino alla pulizia. Questo argomento è trattato nei documenti correlati relativi al recupero e ai dati di RE.

Specifica le attività

Quando è il momento di eseguire il piano di RE, non vuoi dover 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, "Esegui lo script di ripristino" è troppo generico. Al contrario, "Apri una shell ed esegui /home/example/restore.sh" è preciso e concreto.

Implementazione di misure di controllo

Aggiungi controlli per evitare che si verifichino incidenti e per rilevare i problemi prima che si verifichino. Ad esempio, aggiungi un monitoraggio che invii un avviso quando un flusso che comporta la distruzione dei dati, ad esempio 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

La pianificazione del piano di RE prevede di assicurarsi che il software di cui ti servi sia pronto per un evento di recupero.

Verificare 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 delle licenze appropriate per qualsiasi software che implementerai su Google Cloud. Rivolgiti al fornitore del software per ricevere indicazioni.

Assicurati che le risorse Compute Engine necessarie siano disponibili nell'ambiente di recupero. Potrebbe essere necessario preallocare le istanze o prenotarle.

Progetta il deployment continuo per il recupero

Il set di strumenti di deployment continuo (CD) è un componente fondamentale per il deployment delle applicazioni. Nell'ambito del piano di recupero, devi considerare dove eseguire il deployment degli elementi nell'ambiente recuperato. Pianifica dove vuoi ospitare l'ambiente e gli elementi del CD: devono essere disponibili e operativi in caso di emergenza.

Implementazione di controlli di sicurezza e conformità

Quando progetti un piano di RE, la sicurezza è importante. Gli stessi controlli che hai nell'ambiente di produzione devono essere applicati all'ambiente recuperato. Le normative di conformità verranno applicate anche all'ambiente recuperato.

Configura la sicurezza nello stesso modo per gli ambienti di produzione e di RE

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

Assicurati di concedere agli utenti lo stesso accesso all'ambiente di RE di quello che hanno 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, la replica dei criteri IAM nell'ambiente di RE è semplice. Puoi utilizzare strumenti di Infrastructure as Code (IaC) come Terraform per eseguire il deployment delle tue norme IAM in produzione. Poi, utilizza gli stessi strumenti per associare i criteri alle risorse corrispondenti nell'ambiente di RE nell'ambito della procedura di creazione dell'ambiente di RE.

  • Se l'ambiente di produzione è on-premise, mappa i ruoli funzionali, ad esempio i ruoli di amministratore di rete e di revisore, ai criteri IAM che dispongono dei ruoli IAM appropriati. La documentazione IAM contiene alcuni esempi di configurazioni di ruoli funzionali. Ad esempio, consulta la documentazione per la creazione di ruoli funzionali per 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 è di un altro provider cloud, mappa le autorizzazioni nei criteri IAM dell'altro provider ai criteri IAM di Google Cloud .

Verifica la sicurezza del piano di RE

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

Assicurati che gli utenti possano accedere all'ambiente di ripristino dei dati

Non aspettare che si verifichi un disastro 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 della 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 di farlo e risolvi eventuali problemi di autenticazione. Incorpora gli utenti che accedono all'ambiente di RE nell'ambito dei normali test di RE che implementi.

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

Formare gli utenti

Gli utenti devono capire come eseguire le azioni in Google Cloud che sono abituati a svolgere nell'ambiente di produzione, ad esempio accedere e accedere alle VM. Utilizzando l'ambiente di test, addestrare gli utenti a svolgere 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 regolarmente test di penetrazione nell'ambiente di produzione, devi includere l'ambiente di RE in questo ambito ed eseguire test regolari creando un ambiente di RE.

Assicurati che, mentre l'ambiente di RE è in servizio, tutti i log raccolti vengano sottoposti a backfill nell'archivio dei log dell'ambiente di produzione. Analogamente, assicurati che nell'ambito del tuo ambiente di RE tu possa esportare gli audit log raccolti tramite Cloud Logging nell'archivio del tuo sink di log principale. Utilizza le funzionalità di sink di esportazione. Per i log delle applicazioni, crea un'immagine speculare del tuo ambiente di logging e monitoraggio on-premise. Se il tuo ambiente di produzione è di un altro provider cloud, mappa il logging e il monitoraggio di quel provider ai servizi equivalenti Google Cloud . Avere implementato una procedura per formattare l'input nell'ambiente di produzione.

Tratta i dati recuperati come dati di produzione

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

Scopri dove si trovano i backup e chi è autorizzato a ripristinare i dati. Assicurati che la procedura di recupero sia verificabile: dopo un ripristino di emergenza, assicurati di poter dimostrare chi aveva accesso ai dati di backup e chi ha eseguito il recupero.

Verificare il funzionamento del piano di RE

Assicurati che, in caso di emergenza, il piano di RE funzioni come previsto.

Gestire più di un percorso di recupero dei dati

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

Testare regolarmente il piano

Dopo aver creato un piano di RE, testalo regolarmente, annota eventuali problemi che si verificano e modifica il piano di conseguenza. Con Google Cloud, puoi eseguire test di scenari di recupero a un costo minimo. Ti consigliamo di implementare quanto segue per facilitare i test:

  • Automatizza il provisioning dell'infrastruttura. Puoi utilizzare strumenti IaC come Terraform per automatizzare il provisioning dell'infrastruttura Google Cloud. Se esegui l'ambiente di produzione on-premise, assicurati di disporre di una procedura di monitoraggio che possa avviare la procedura di RE quando rileva un errore e attivare le azioni di recupero appropriate.
  • Monitora i tuoi ambienti con Google Cloud Observability. Google Cloud offre eccellenti strumenti di monitoraggio e registrazione a cui puoi accedere tramite chiamate API, che ti consentono di automatizzare il deployment di scenari di recupero reagendo alle metriche. Quando progetti i test, assicurati di disporre di un monitoraggio e di 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 nell'ambiente di RE.
    • Esegui un test in cui il percorso di accesso abituale a Google Cloud non funziona.

Passaggi successivi

Collaboratori

Autori: