Piano di continuità aziendale - Ripristino di emergenza dei carichi di lavoro in AWS: ripristino nel cloud

Piano di continuità aziendale

Il piano di ripristino di emergenza deve essere un sottoinsieme del piano di continuità aziendale dell'organizzazione e non un documento autonomo. Non ha senso mantenere obiettivi di ripristino di emergenza aggressivi per il ripristino di un carico di lavoro se gli obiettivi aziendali del carico di lavoro non possono essere realizzati a causa dell'impatto dell'emergenza su elementi dell'azienda diversi dal carico di lavoro stesso. Ad esempio, un terremoto potrebbe impedire il trasporto di prodotti acquistati sull'applicazione di e-commerce: anche se una strategia di ripristino di emergenza efficace mantiene in funzione il carico di lavoro, il piano di continuità aziendale deve soddisfare le esigenze in fatto di trasporti. La strategia di ripristino di emergenza deve essere basata su priorità, contesto e requisiti aziendali.

Analisi dell'impatto aziendale e valutazione del rischio

Un'analisi dell'impatto aziendale deve quantificare l'impatto aziendale di un'interruzione subita dai carichi di lavoro. Deve identificare l'impatto su clienti interni ed esterni dell'impossibilità di usare i carichi di lavoro e l'effetto che ha sulla tua azienda. L'analisi deve aiutare a determinare quanto rapidamente deve essere reso disponibile il carico di lavoro e l'entità della perdita di dati tollerata. Tuttavia, è importante notare che gli obiettivi di ripristino non devono essere definiti in modo isolato. La probabilità di un'interruzione e il costo del ripristino sono fattori chiave per definire il valore aziendale dell'implementazione di una strategia di ripristino di emergenza per un carico di lavoro.

L'impatto aziendale può dipendere dal momento in cui si verifica l'emergenza. Può essere utile prendere in considerazione questo aspetto nella pianificazione del ripristino di emergenza. Ad esempio, è probabile che un'interruzione al sistema di gestione delle retribuzioni abbia un impatto molto elevato sull'azienda se si verifica appena prima di pagare tutti i dipendenti, ma può avere un impatto ridotto se avviene subito dopo il pagamento.

Una valutazione del rischio del tipo di emergenza e dell'impatto geografico insieme a una panoramica dell'implementazione tecnica del carico di lavoro determinerà la probabilità di interruzione causata da ogni tipo di emergenza.

Per carichi di lavoro altamente critici, puoi prendere in considerazione la disponibilità elevata tra più regioni con backup continui per ridurre al minimo l'impatto aziendale. Per i carichi di lavoro meno critici, una strategia valida può essere quella di non definire alcun ripristino di emergenza. E per alcuni scenari di emergenza, è anche ragionevole non prevedere alcuna strategia di ripristino di emergenza come decisione informata basata su una ridotta probabilità del verificarsi dell'emergenza. Ricorda che le zone di disponibilità all'interno di una regione AWS sono già progettate con una distanza significativa le une dalle altre e un'attenta pianificazione della posizione, in modo che le emergenze più comuni abbiano impatto solo su una zona e non sulle altre. Di conseguenza, un'architettura Multi-AZ all'interno di una regione AWS potrebbe già soddisfare le tue esigenze di attenuazione dei rischi.

È bene valutare il costo delle opzioni di ripristino di emergenza per garantire che la strategia di ripristino di emergenza fornisca il livello corretto di valore aziendale considerando l'impatto e il rischio per l'azienda.

Con tutte queste informazioni, potrai documentare la minaccia, il rischio, l'impatto e il costo di diversi scenari di emergenza e le opzioni di ripristino associate. Queste informazioni devono essere usate per determinare gli obiettivi di ripristino per ognuno dei carichi di lavoro.

Obiettivi di ripristino (RTO e RPO)

Nel creare una strategia di ripristino di emergenza, le organizzazioni basano in genere la propria pianificazione sull'obiettivo del tempo di ripristino (RTO) e sull'obiettivo del punto di ripristino (RPO).

Immagine che mostra la relazione degli obiettivi di ripristino.

Figura 3 – Obiettivi di ripristino

L'obiettivo del tempo di ripristino (RTO) è il ritardo massimo accettabile tra l'interruzione del servizio e il suo ripristino. Questo obiettivo determina una finestra temporale accettabile per la non disponibilità del servizio, definita dall'organizzazione.

In questo documento vengono presentate quattro strategie di ripristino di emergenza: backup e ripristino, Pilot Light, standby a freddo e attivo/attivo multisito (consulta Opzioni di ripristino di emergenza nel cloud). Nel diagramma seguente l'azienda ha determinato il proprio RTO massimo accettabile e il limite di spesa per la propria strategia di ripristino del servizio. In base agli obiettivi aziendali, le strategie di ripristino di emergenza Pilot Light e standby a freddo soddisfano entrambe i criteri di RTO e costo.

Grafico che mostra l'obiettivo del tempo di ripristino come relazione tra costi e complessità e la durata dell'interruzione del servizio.

Figura 4 – Obiettivo del tempo di ripristino

L'obiettivo del punto di ripristino (RPO) è il periodo di tempo massimo accettabile dall'ultimo punto di ripristino dei dati. Questo obiettivo determina una perdita di dati accettabile tra l'ultimo punto di ripristino e l'interruzione del servizio, definita dall'organizzazione.

Nel diagramma seguente l'azienda ha determinato il proprio RPO massimo consentito e il limite di spesa per la propria strategia di ripristino dei dati. Delle quattro strategie di ripristino di emergenza, le strategie Pilot Light e standby a freddo soddisfano entrambe i criteri di RPO e costo.

Grafico che mostra l'obiettivo del punto di ripristino come relazione tra costi e complessità e la perdita di dati prima dell'interruzione del servizio.

Figura 5 – Obiettivo del punto di ripristino

Nota

Se il costo del ripristino è superiore al costo dell'errore o della perdita, l'opzione di ripristino non deve essere implementata a meno che non sia necessario tenere conto di un fattore secondario, ad esempio i requisiti normativi.