Avere un piano

Affrontare qualsiasi crisi è stressante e le catastrofi non sono da meno. Durante un disastro, è probabile che stiate cercando di riavviare i servizi critici per l'azienda e che siate sotto pressione per farlo rapidamente, con il rischio di commettere errori. Nell'improbabile caso di un disastro, avere un piano chiaramente definito aiuta l'azienda a riprendersi in modo prevedibile, alleviando lo stress e riducendo gli errori. Per ulteriori informazioni sulla creazione di un piano di ripristino d'emergenza, vedere Pianificazione del ripristino d'emergenza.

Determinare le priorità

Quando create un piano di ripristino d'emergenza, assicuratevi che la vostra organizzazione lo approvi, lo comprenda e sia in grado di finanziarlo. Quando si ottiene il consenso di tutti gli stakeholder, è possibile individuare le priorità dell'azienda in caso di disastro. In questo modo, il piano è completo e proporzionato alle aspettative aziendali. Rivedete regolarmente il piano con la vostra organizzazione per cogliere i cambiamenti nelle priorità e aggiornatelo se necessario.

Bilanciare la capacità tra le zone

La distribuzione dei carichi di lavoro su più zone di disponibilità all’interno di una regione aumenta la disponibilità, ma occorre prestare attenzione agli squilibri tra le zone, in particolare quando si utilizzano le VSI ( IBM Cloud® Virtual Servers for Virtual Private Cloud ). Assicurati che i tuoi carichi di lavoro siano distribuiti tra le diverse zone, in modo che, in caso di guasto di una zona, continuino a funzionare. Assicurati inoltre che le zone rimanenti dispongano di una capacità sufficiente per gestire l'intero carico di lavoro. Quando si effettua l'implementazione su tre zone, è necessario prevedere una capacità VSI aggiuntiva pari a circa il 17% per ciascuna zona, al fine di compensare la perdita di capacità del 33% che si verifica in caso di interruzione di una zona.

Capire cosa si intende per disastro

Per mettere in atto il piano di ripristino d'emergenza, è necessario essere certi che quello che si sta verificando sia un disastro. Esprimete chiaramente nel piano ciò che si qualifica come disastro, altrimenti rischiate falsi allarmi o l'inattività quando si verifica un disastro. Definire diversi scenari che costituiscono un disastro, come l'azienda può reagire ad essi e con quale rapidità. Considerate anche la portata dell'impatto. Se un componente di un carico di lavoro subisce un disastro, la risposta è diversa rispetto a una situazione in cui tutto si guasta?

La comunicazione è fondamentale

In una situazione di disastro, è importante una comunicazione efficace tra le squadre. Nel vostro piano, indicate chiaramente quali persone possono chiamare in caso di catastrofe. Definire le modalità di comunicazione con l'organizzazione e con le persone che devono attuare il piano di disaster recovery. Indicare chiaramente i canali di comunicazione, come il telefono o l'e-mail, per garantire che i messaggi importanti non vadano persi. Pensate a canali di comunicazione di riserva nel caso in cui i canali primari siano interessati. Il piano potrebbe anche prescrivere alcune riunioni che devono svolgersi per acquisire gli aggiornamenti della situazione.

Testate il vostro piano

La reazione a un vero disastro non è il momento ideale per testare il vostro piano per la prima volta. Testate regolarmente il vostro piano per assicurarvi che funzioni e per capire quanto tempo potrebbe essere necessario per attuarlo. Nel caso in cui sia coinvolto altro personale, testare il piano consente di comprendere meglio il proprio ruolo. Dopo il test, assicuratevi di incorporare nel piano le lezioni apprese. Per ulteriori informazioni sulla verifica del piano di ripristino d'emergenza, vedere Verifica del ripristino d'emergenza.

Comprendere le proprie responsabilità

Ogni servizio IBM Cloud ha una matrice di ruoli e responsabilità che definisce le responsabilità di IBM®, le responsabilità del cliente e le responsabilità condivise, comprese quelle relative a backup, ripristino e disastri. Assicuratevi di comprendere appieno la proprietà delle responsabilità per ciascuno dei servizi che utilizzate, in quanto determinano le azioni per ripristinare con successo le istanze del servizio e vi aiutano a pianificare.

Considerare i requisiti di resilienza e residenza dei dati

La resilienza dei dati si riferisce alla capacità di accedere, mantenere o recuperare rapidamente i dati in caso di guasti o disastri. È legato ai concetti di alta disponibilità, disaster recovery e resilienza informatica. Per ulteriori informazioni sulla resilienza dei dati, vedere il IBM Well-Architected Framework.

Un altro aspetto importante da considerare è la residenza dei dati ed eventuali restrizioni o requisiti sulla loro ubicazione fisica, non solo per gli ambienti di produzione ma anche per il backup e il ripristino.

Progettate HA e DR nei vostri carichi di lavoro

Quando progettate carichi di lavoro distribuiti nel cloud, pensate all'alta disponibilità e al disaster recovery come parte della fase di raccolta dei requisiti. Capendo fin dalle prime fasi del processo di progettazione quali sono le qualità di resilienza del carico di lavoro, è possibile prendere decisioni che influenzano l'architettura e facilitano il ripristino. Ad esempio, se si conosce l'obiettivo del tempo di ripristino per un carico di lavoro, si può decidere come distribuire un carico di lavoro per raggiungere tale obiettivo utilizzando le caratteristiche dei servizi disponibili. Allo stesso modo, se si comprende l'obiettivo del punto di ripristino si possono prendere decisioni migliori sui dati, su come eseguirne il backup o su come replicarli. Progettare questo aspetto in una fase iniziale consente inoltre all'azienda di comprendere meglio i costi di gestione del carico di lavoro.

Considerate come sviluppare il codice dell'applicazione per facilitare il passaggio a un sito di disaster recovery. Ad esempio, evitare di codificare in modo rigido le stringhe di connessione o altre configurazioni che potrebbero cambiare in seguito alla connessione a risorse alternative.

Scegliere gli strumenti adeguati

Pensate a IBM Cloud come a una cassetta degli attrezzi con una serie di strumenti o servizi che potete usare per distribuire ed eseguire carichi di lavoro. Per utilizzare correttamente qualsiasi strumento, è necessario capire cosa può o non può fare e scegliere quello giusto. Se si cerca di utilizzare uno strumento per un lavoro per il quale non è stato progettato, qualcosa può andare storto. Quando si progetta il piano di resilienza, è necessario conoscere il più dettagliatamente possibile i servizi utilizzati dal carico di lavoro, le loro capacità e i loro limiti. Se un servizio non è in grado di soddisfare i vostri obiettivi RTO o RPO, prendete in considerazione altri servizi o strumenti che possano aiutarvi a colmare il divario. Considerate anche se gli obiettivi fissati sono realistici o se state introducendo una complessità e un costo eccessivi nella vostra soluzione per un guadagno minimo.

Eseguite dei backup prima di apportare modifiche

La gestione dei sistemi IT non è mai esente da rischi e l'introduzione di cambiamenti nell'ambiente di lavoro è un punto in cui il rischio aumenta. Disponete di un piano di rilascio delle modifiche e di un piano di backout per gestire le modifiche apportate al vostro ambiente. Uno dei primi passi di qualsiasi piano di rilascio delle modifiche è l'esecuzione di backup dei dati e delle configurazioni. Se qualcosa va storto durante o subito dopo il rilascio, è possibile recuperare dai backup.

Creare immagini personalizzate

Creare un' immagine personalizzata da un volume di avvio e usarla come immagine d'oro, con applicazioni e configurazioni preinstallate, per ridurre il tempo di provisioning delle istanze IBM Cloud® Virtual Servers for Virtual Private Cloud nel sito DR. Il volume di avvio deve essere collegato a un'istanza di server virtuale (VSI) ferma per creare l'immagine personalizzata.

Utilizzare i nomi di host per le sottoreti

Utilizzate i nomi di host e i DNS invece degli indirizzi IP per ridurre al minimo le modifiche necessarie per la ridistribuzione di un'applicazione nel sito DR, in particolare con le istanze VPC, comprese le VSI. Le sottoreti sono specifiche della zona e non si estendono tra le zone. I nuovi indirizzi IP vengono assegnati alle nuove istanze di servizio, il che può interrompere le configurazioni esistenti, come le regole di sicurezza e i file di configurazione delle applicazioni.

Configurare i servizi di gestione delle chiavi per il ripristino di emergenza

Per Key Protect, configurare il servizio nel sito primario con failover nella regione DR per consentire il reindirizzamento automatico delle richieste di Key Protect in caso di interruzione del servizio regionale. Creare script per aggiornare le impostazioni del Virtual Private Endpoint (VPE) per accedere al servizio Key Protect, in particolare l'indirizzo IP ( Internet Protocol ), come parte delle procedure di disaster recovery.

Per HPCS, configurare un'unità crypto di failover nella regione DR. Inizializzare e configurare le unità crittografiche di failover come le unità crittografiche operative prima che si verifichi il disastro, in modo che siano disponibili se si verifica un'interruzione regionale

Investire nell'osservabilità

L'osservabilità include strumenti come IBM Cloud Logs e IBM Cloud Monitoring che consentono di conoscere ciò che accade nel sistema e, in caso di interruzione o degrado dei servizi, aiutano a identificare, mitigare e rimediare rapidamente alla causa principale. Questo è particolarmente necessario per i sistemi distribuiti complessi, dove i guasti sono inevitabili ed è molto difficile tracciare o correlare le dipendenze tra i componenti. Inoltre, il servizio Activity Tracker Event Routing consente di verificare gli eventi e di registrare e monitorare le modifiche al sistema mentre Flow Logs for VPC fornisce visibilità sul traffico IP che va e viene dalle interfacce di rete all'interno della VPC e consente di risolvere i problemi di rete e connettività, altrimenti difficili da osservare.

Le applicazioni resilienti costruite per il cloud e i processi che le supportano dovrebbero sfruttare efficacemente queste capacità. Ad esempio, le applicazioni dovrebbero esporre le metriche relative allo stato di salute dei propri componenti e dei loro sottosistemi. Tutti i servizi di IBM Cloud supportano la raccolta di metriche della piattaforma ed espongono metriche dettagliate che sono documentate individualmente, come questa per il loadbalancer. Le applicazioni e i cruscotti costruiti a loro supporto dovrebbero sfruttare queste metriche per migliorare l'efficienza operativa.

IBM Cloud Logs offre funzioni avanzate per arricchire, interrogare e avvisare sui log generati dalle applicazioni, gestendo al contempo il volume dei log e il loro costo. Diversi tipi di allerta consentono funzionalità più sofisticate per monitorare efficacemente i sistemi.

Rimanere aggiornati con le notifiche di IBM Cloud

Se si verifica un disastro che colpisce un servizio o una regione IBM Cloud, si ricevono notifiche da IBM Cloud nel proprio account o via e-mail. Per ricevere le notifiche sul vostro account, consultate la sezione Visualizza notifiche. È inoltre possibile visualizzare la pagina IBM Cloud Pagina Panoramica dello stato.