Guida alla pianificazione del ripristino di emergenza

Last reviewed 2024-07-05 UTC

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

La serie è composta dalle seguenti parti:

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 vanno male, è 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à sia minimo. Indipendentemente dalle tue esigenze di RE, Google Cloud offre una selezione solida, flessibile ed economica di prodotti e funzionalità che puoi utilizzare per creare o migliorare la soluzione più adatta a te.

Nozioni di base della pianificazione del RE

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

  • Un recovery time objective (RTO), 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 andare persi dalla tua 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 di frequente 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 del periodo di tempo; non indica la quantità o la qualità dei dati persi.

In genere, più bassi sono i valori di RTO e RPO (ovvero più rapidamente deve essere ripristinata l'applicazione in seguito a un'interruzione), più costerà l'esecuzione dell'applicazione. Il seguente grafico mostra il rapporto tra costo e RTO/RPO.

Grafico che mostra che un RTO/RPO ridotto corrisponde a un costo elevato.

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

I valori RTO e RPO in genere vengono aggregati in un'altra metrica: l'obiettivo del livello di servizio (SLO), che è un elemento chiave misurabile di un SLA. SLA e SLO vengono spesso confusi. Un SLA è l'intero accordo che specifica quale servizio deve essere fornito, come viene supportato, tempi, località, costi, prestazioni, sanzioni e responsabilità delle parti coinvolte. Gli SLO sono caratteristiche specifiche e misurabili dell'SLA, come disponibilità, velocità effettiva, frequenza, tempo di risposta o qualità. Un contratto di servizio può contenere molti SLO. RTO e RPO 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 l'alta disponibilità (HA). L'alta disponibilità non si sovrappone completamente al RE, ma spesso è necessario tenerla in considerazione quando si pensa ai valori RTO e RPO. L'alta disponibilità 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 si verifica un problema in una regione, l'applicazione continui a fornire il servizio anche se è meno disponibile. 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à:assicurarsi risorse sufficienti per scalare in base alle esigenze.
  • Sicurezza:fornire sicurezza fisica per proteggere gli asset.
  • Infrastruttura di rete:inclusi componenti software come firewall e bilanciatori del carico.
  • Assistenza:mettiamo a disposizione tecnici esperti per eseguire la manutenzione e risolvere i problemi.
  • Larghezza di banda:pianificazione di una larghezza di banda adatta al carico di picco.
  • Strutture:garantire l'infrastruttura fisica, comprese attrezzature ed energia elettrica.

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

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

  • 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. Più punti di presenza (POP) in tutto il mondo significano una forte ridondanza. I tuoi 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, la ricerca e Gmail), anche in caso di picchi di traffico elevatissimi. I servizi gestiti come Cloud Run, Compute Engine e Firestore offrono una 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 nell'aiutare a mantenere i clienti al sicuro 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 a regolari controlli indipendenti di terze parti per verificare che Google Cloud sia in linea con le normative e le best practice in materia 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 vengono considerati freddi, tiepidi o caldi. Questi pattern indicano la facilità con cui il sistema può ripristinarsi in caso di problemi. Un'analogia potrebbe essere cosa faresti se stessi guidando e forassi uno pneumatico.

Il modo in cui gestisci una foratura dipende dalla tua preparazione:

  • Freddo: non hai una ruota di scorta, quindi devi chiamare qualcuno che ti porti una ruota nuova e la sostituisca. Il tuo viaggio si interrompe finché non arriva l'assistenza per effettuare la riparazione.
  • Caldo: hai una ruota di scorta e un kit di sostituzione, quindi puoi riprendere la strada utilizzando ciò che hai in auto. Tuttavia, devi interrompere il tuo viaggio per risolvere il problema.
  • Caldo: hai pneumatici runflat. Potresti dover rallentare un po', ma non ci sono conseguenze immediate sul tuo viaggio. I tuoi pneumatici funzionano abbastanza bene da poter continuare (anche se alla fine dovrai risolvere il problema).

Creare un piano di RE dettagliato

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

Progettare in base agli obiettivi di recupero

Quando progetti il piano di RE, devi combinare le tecniche di recupero di applicazioni e dati e considerare il quadro generale. Il modo tipico per farlo è esaminare i valori RTO e RPO e quale pattern di RE 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 RE freddo sono appropriati. Tuttavia, se il tuo servizio online subisce un'interruzione, vorrai essere in grado di recuperare sia i dati sia la parte dell'applicazione rivolta agli utenti il più rapidamente possibile. In questo caso, un pattern caldo sarebbe più appropriato. Il tuo sistema di notifiche via email, che in genere non è fondamentale per l'attività, è probabilmente un candidato per un pattern caldo.

Per indicazioni sull'utilizzo di Google Cloud per risolvere 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 è sufficiente avere un piano per il backup o l'archiviazione dei dati. Assicurati che il piano diRER copra l'intera procedura di ripristino, dal backup al ripristino alla pulizia. Ne parliamo nei documenti correlati sui dati di RE e sul ripristino.

Rendi specifiche le tue attività

Quando è il momento di eseguire il piano di ripristino di emergenza, non vuoi rimanere bloccato a indovinare il significato di ogni passaggio. Fai in modo che ogni attività del piano di RE consista in uno o più comandi o azioni concreti e inequivocabili. 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 prevenire disastri e rilevare problemi prima che si verifichino. Ad esempio, aggiungi un monitor che invia un avviso quando un flusso distruttivo dei dati, come una pipeline di eliminazione, mostra picchi imprevisti o altre attività insolite. Questo monitor 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 RE consiste nell'assicurarsi che il software su cui fai affidamento sia pronto per un evento di recupero.

Verifica di poter installare il software

Assicurati che il software applicativo possa essere installato dall'origine o da un'immagine preconfigurata. Assicurati di disporre delle licenze appropriate per qualsiasi software che verrà implementato su Google Cloud. Rivolgiti al fornitore del software per ricevere indicazioni.

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

Progettare il deployment continuo per il recupero

Il tuo set di strumenti di distribuzione continua (CD) è un componente integrante quando esegui il deployment delle tue applicazioni. Nell'ambito del piano di ripristino, devi considerare in quale parte dell'ambiente recuperato verranno implementati gli artefatti. Pianifica dove ospitare l'ambiente e gli artefatti di 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. I regolamenti di conformità si applicheranno anche all'ambiente recuperato.

Configurare la sicurezza allo 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 VPC condiviso e firewall per stabilire il controllo centralizzato di rete e sicurezza del tuo deployment, configurare le subnet e controllare il traffico in entrata e in uscita. Scopri come utilizzare i service account per implementare il principio del 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. Il seguente elenco descrive i modi per sincronizzare le autorizzazioni tra gli ambienti:

  • Se il tuo ambiente di produzione è Google Cloud, la replica delle norme IAM nell'ambiente di ripristino di emergenza è semplice. Puoi utilizzare strumenti di Infrastructure as Code (IaC) come Terraform per eseguire il deployment dei tuoi criteri IAM in produzione. Quindi, utilizza gli stessi strumenti per associare i criteri alle risorse corrispondenti nell'ambiente di RE nell'ambito della procedura di configurazione dell'ambiente di RE.

  • Se il tuo ambiente di produzione è on-premise, mappa i ruoli funzionali, come i ruoli di amministratore di rete e revisore, con i 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 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 nelle norme IAM dell'altro provider con le norme IAM. Google Cloud

Verifica la sicurezza del tuo RE

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

Assicurarsi che gli utenti possano accedere all'ambiente di ripristino di emergenza

Non aspettare che si verifichi un disastro prima di verificare che gli utenti possano accedere all'ambienteREa. 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 REa sarà il tuo ambiente di produzione per un po' di tempo, chiedi agli utenti che dovranno accedere all'ambiente di ripristino dREza di accedere e risolvi eventuali problemi di autenticazione. Incorpora gli utenti che accedono all'ambiente RE nell'ambito dei test RE regolari che implementi.

Per gestire centralmente chi ha accesso amministrativo alle macchine virtuali (VM) avviate, attiva la funzionalità OS Login sui 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 l'accesso e l'accesso alle VM. Utilizza l'ambiente di test per addestrare gli utenti a eseguire queste attività in modo da salvaguardare la sicurezza del sistema.

Assicurati che l'ambiente di ripristino di emergenza soddisfi i requisiti di conformità

Verifica che l'accesso all'ambiente di RE sia limitato solo agli utenti che ne hanno bisogno. Assicurati che i dati PII siano oscurati e criptati. Se esegui test di penetrazione regolari sul tuo ambiente di produzione, devi includere il tuo ambiente di RE nell'ambito e svolgere test regolari configurando un ambiente di RE.

Assicurati che, mentre l'ambiente di RE è in servizio, tutti i log che raccogli vengano inseriti nell'archivio log dell'ambiente di produzione. Allo stesso modo, assicurati che, nell'ambito del tuo ambiente di RE, tu possa esportare gli audit log raccolti tramite Cloud Logging nel tuo archivio principale del sink di log. Utilizza le funzionalità del sink di esportazione. Per i log delle applicazioni, crea un mirror del tuo ambiente di logging e monitoraggio on-premise. Se il tuo ambiente di produzione è un altro provider cloud, mappa i servizi di logging e monitoraggio di questo provider con i servizi Google Cloud equivalenti. Avere una procedura per formattare l'input nell'ambiente di produzione.

Trattare i dati recuperati come dati di produzione

Assicurati che i controlli di sicurezza che applichi ai dati di produzione vengano applicati anche ai dati recuperati: devono essere applicate le stesse autorizzazioni, crittografia e requisiti di controllo.

Sapere dove si trovano i backup e chi è autorizzato a ripristinare i dati. Assicurati che la procedura di recupero sia verificabile. Dopo unripristino di emergenzay, assicurati di poter mostrare chi ha avuto accesso ai dati di backup e chi ha eseguito il recupero.

Assicurarsi che il piano di RE funzioni

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

Mantenere più di un percorso di recupero dei dati

In caso di emergenza, il metodo di connessione a Google Cloud potrebbe non essere più 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, annotando eventuali problemi che si presentano e modificando il piano di conseguenza. Utilizzando Google Cloud, puoi testare scenari di ripristino a costi minimi. Per facilitare i test, ti consigliamo di implementare quanto segue:

  • Automatizza il provisioning dell'infrastruttura. Puoi utilizzare strumenti IaC come Terraform per automatizzare il provisioning della tua Google Cloud infrastruttura. Se esegui l'ambiente di produzione on-premise, assicurati di disporre di una procedura di monitoraggio che possa avviare la proceduraRER 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, consentendoti di automatizzare l'implementazione di scenari di ripristino reagendo alle metriche. Quando progetti i test, assicurati di aver implementato un 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 sul tuo ambiente di RE.
    • Esegui un test in cui il tuo percorso di accesso abituale a Google Cloud non funziona.

Passaggi successivi

Collaboratori

Autori: