Business continuity e Disaster recovery si rivelano strumenti imprescindibili per preservare la performance aziendale in casi di eventi che minacciano le funzionalità a qualunque livello: tecnologico, ma non solo. Si tratta però di processi caratterizzati da un alto grado di complessità: sia nelle valutazioni necessarie degli investimenti da effettuare, sia nell’articolazione degli step da adottare successivamente. Ecco una fotografia dei contesti in cui BC e DR si trovano ad agire.
Cos’è la business continuity
La Business Continuity (BC) è la capacità dell’azienda di mantenere la funzionalità operativa a seguito di eventi che ne minaccino le funzionalità a qualunque livello, non solo tecnologico: per esempio un’azione legale, un problema di compliance alle normative, un cambio di sede. Il Business Continuity Plan è lo strumento che stabilisce le strategie da adottare per mantenere la produttività.
Cos’è il disaster recovery
Nel caso di eventi che compromettano l’infrastruttura tecnologica interviene il Disaster Recovery che, secondo la definizione che ne dà Wikipedia, è: “… l’insieme delle misure tecnologiche e logistico/organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all’erogazione di servizi di business per imprese, associazioni o enti, a fronte di gravi emergenze che ne intacchino la regolare attività”.
Le differenze fra gli standard in campo
BC e DR sono essenziali per qualsiasi organizzazione e le aziende rispondono a questa necessità adottando standard di gestione come ISO 27001 e ISO 22301.
Tuttavia, questi standard indicano solo cosa fare (per esempio identificare i rischi, pianificare il recupero, ecc.), non come farlo. Ed è qui che interviene ISO 27031 che fornisce le indicazioni e il know-how in modo sintetico.
Lo standard ISO 27031 afferma: “Le strategie dovrebbero definire gli approcci per implementare la necessaria resilienza in modo da mettere in atto i principi di prevenzione, rilevamento, risposta, recupero e ripristino dagli incidenti”, e descrive i concetti e i principi relativi alle tattiche di Business Continuity.
Lo standard ISO 27031 raccomanda sei categorie da prendere in considerazione quando si definiscono le pratiche IT relative alla BC.
- Competenze e conoscenze chiave:
- Informazioni necessarie per gestire servizi ICT critici.
- Titolari di queste informazioni.
- Integrazione delle informazioni nelle conoscenze organizzative.
- Disponibilità di queste informazioni in caso di disastro.
- Strutture:
- Definizione dello stato ottimale delle infrastrutture per ridurre al minimo i rischi di interruzione e i tempi di recupero.
- Identificazione dei siti adatti ad ospitare le infrastrutture.
- Tecnologie:
- Identificazione delle tecnologie più importanti per il business aziendale.
- Determinazione dei requisiti di RTO e RPO delle tecnologie.
- Identificazione delle interdipendenze tra le tecnologie critiche.
- Dati:
- Identificazione dei dati necessari per ripristinare le attività, e in quale RTO considerando che RPO e RTO dei dati sono diversi da quelli dei servizi.
- Definizione dei controlli di sicurezza da osservare per la protezione dei dati.
- Processi:
- Identificazione dei processi da mettere in atto per affrontare un incidente o un disastro.
- Definizione dell’integrazione dei punti dall’1 al 4 in modo da ottenere un workflow teso a fornire i servizi aziendali necessari.
- Fornitori:
- Identificazione dei fornitori e delle forniture fondamentali per la continuità.
- Determinazione delle modalità in cui i fornitori possono garantire il supporto ai requisiti di continuità aziendale.
La differenza tra strategie e piani è che le strategie definiscono cosa si intende fare quando si risponde a un incidente, mentre i piani descrivono come lo si farà.
Lo strumento che si usa per definire queste misure è il Disaster Recovery Plan.
Il DR e il DR Plan fanno parte rispettivamente della Business Continuity (BC) e del BC Plan.
Le parti critiche del Disaster recovery
L’importanza, il costo, la complessità, la necessità di prestazioni e l’affidabilità rendono lo sviluppo e la definizione del Disaster Recovery un aspetto critico del piano di Business Continuity. Le parti più critiche della pianificazione del Disaster Recovery sono la strategia di Disaster Recovery e il DR Plan.
È nel DRP che vengono elencati i passi concreti da compiere per ripristinare i sistemi e ristabilire le funzionalità aziendali dopo un’interruzione non pianificata.
Un principio importante da tenere presente nella stesura del DRP è il concetto di “Don’t think, do”. L’elenco dei passi e delle procedure deve essere strutturato in modo da richiedere il minimo possibile delle decisioni in favore di una serie di istruzioni operative al giusto dettaglio che permettano di agire anche sotto pressione, in stato di ansia, e anche senza competenze specifiche sull’infrastruttura oggetto del recupero. Lo scopo è cercare di eliminare per quanto possibile l’errore umano e valutazioni soggettive.
La strategia di DR e il DRP si basano su una valutazione del rischio (Risk Assessment), su una BIA (Business Impact Analisys), sulla comprensione dei sistemi più critici per il business, e di ciò che è necessario fare per farli funzionare nuovamente in un arco di tempo accettabile; e il punto chiave è la definizione di “accettabile”, di cui parliamo più avanti.
Il parametro che influenza la definizione di un DR è uno SLO (Service Level Objective) che comprende un RPO (Recovery Point Objective) e un RTO (Recovery Time Objective).
Schematizzando i componenti principali:
La determinazione dei tempi di RPO e RTO è il punto di partenza per la creazione del Disaster Recovery e per la definizione del DR Plan.
I tempi di RPO e RTO sono controllabili tramite le tecnologie e possono essere piccoli a piacere fino a tendere allo zero, ma il costo di implementazione cresce esponenzialmente al diminuire del loro valore.
In casi particolari si arriva ad avere una infrastruttura identica a quella di produzione che viene replicata in modalità sincrona e rimane quiescente in attesa di essere eventualmente attivata in caso di necessità. È evidente che in questo caso il costo di esercizio totale (produzione + DR) sarà più del doppio di quello della sola produzione (ci sono i costi di replica).
Questo diagramma evidenzia la relazione tra RPO, RTO, la valutazione dei rischi e i costi:
La classificazione della protezione dei dati è importante per determinare come archiviare, accedere, proteggere, recuperare e aggiornare dati e informazioni più efficacemente in base alle loro peculiarità.
È necessario analizzare le applicazioni e determinare quali di esse sono essenziali per l’attività, producono utili, e sono indispensabili per rimanere operativi. Questo processo è essenziale per la creazione di un BCP ed è chiamato Business Impact Analisys (BIA) e stabilisce protocolli e azioni per affrontare una crisi, dopo aver valutato l’impatto e i costi di un eventuale downtime al livello più alto possibile, non solo quello tecnologico.
Come ottimizzare i costi
Uno dei modelli più diffusi usato per classificare ambiti e applicazioni secondo i criteri appena esposti è quello a tiering. Si possono definire diversi livelli di criticità, popolarli con le applicazioni pertinenti e assegnare a ciascuno livelli di RPO e RTO distinti.
Uno degli aspetti che emergono a seguito di una BIA è che i valori di RPO e RTO non sono assoluti e variano a seconda delle aree, dei processi e dei sistemi coinvolti.
Per gli ambiti più critici potrei decidere di avere un RTO molto basso anche se con funzionalità degradate, per altri potrei avere valori più rilassati ma con necessità di piena ripresa delle funzionalità; oppure i dati che hanno un basso turnover potrebbero sottostare a RPO più alti (per esempio parte della gestione documentale o gli archivi storicizzati). Questa stratificazione consente di ottimizzare i costi e proteggere l’operatività aziendale investendo di più sulla protezione degli ambiti critici e risparmiando negli ambiti collaterali.
È importante considerare che il momento definito dall’RTO non necessariamente identifica la piena ripresa delle attività aziendali, ma solo lo stato “accettabile” dopo la recovery da un disastro. In tempi successivi, con basso o nullo impatto, la produttività potrà essere ripristinata.
Questo perché non è scontato che al “momento RTO” i processi e le tecnologie siano gli stessi del pre-evento: il caso più comune è che i servizi e le applicazioni di produzione siano erogati da un sito secondario. Il rollback per riportare tutti i workload allo stato “pre incidente” deve essere incluso nel BCP e spesso anche nel DRP.
Il timing della governance del “disastro”
Un altro aspetto da considerare che deve essere inserito nel BCP è come e quando decidere di dichiarare un disastro.
Nella fase iniziale dell’incidente si registra una situazione fuori dalla norma, per esempio ricevendo avvisi da allarmi dal monitoraggio dei sistemi. In seguito alle prime valutazioni diagnostiche si cerca di stabilire prima possibile la gravità tramite una serie di processi di qualificazione dell’incidente.
Mentre si compiono le azioni necessarie a tentare di contenere l’incidente, vengono attivati i processi di governance che scalano la gravità fino al management e agli stakeholder. Una sezione del BCP definisce i criteri per l’avvio del DRP, quali dati sono necessari e chi prende la decisione.
Una volta stabilito che l’incidente non può essere fermato, e ottenuto il via libera dalle figure chiave identificate dal BCP, si procede all’attivazione del DRP, coinvolgendo i membri del team di ripristino.
Le figure aziendali da coinvolgere
Quindi, tornando al concetto di “accettabile”, è evidente che dopo una valutazione del rischio e una Business Impact Analisys, le decisioni che riguardano RTO e RPO non possono essere esclusiva responsabilità del CIO, ma devono essere prese dal Management aziendale con il contributo di tutte le figure del C-Level, perché l’interruzione o il degrado delle attività comportano conseguenze che impattano su tutta l’azienda a livello societario, finanziario, legale e di immagine, e non riguardano solo la mera disponibilità delle infrastrutture.
Uno degli aspetti che accomuna il backup e il Disaster Recovery è il fatto che non si saprà mai se funzionano veramente finché non se ne ha bisogno. Proprio per questo una strategia di DR deve prevedere almeno un test annuale di recovery, con procedure e KPI definiti per verificare che il DRP sia aggiornato e funzionante. La simulazione di disastro consente di verificare che il personale sia preparato a reagire, tutte le figure indicate nel piano siano a conoscenza delle attività di loro competenza, e i processi siano adeguati a raggiungere il risultato desiderato.
La Business Continuity è una pratica imprescindibile per un’azienda (e per alcune è obbligatoria); è evidente che l’investimento che richiede deve essere fatto in modo oculato, strutturato e ben integrato con i processi aziendali. In un mercato che si muove sempre più velocemente, nessuno si può permettere di interrompere le proprie operazioni senza subire conseguenze fatali per la sopravvivenza del proprio business.
P.S. Se vuoi parlare di BC, comincia con la pronuncia corretta (gli italiani la sbagliano)
