Questa è la seconda parte di una serie di cinque articoli dedicati alle ResOps (operazioni di resilienza). Per la prima parte, consulta l’articolo “Cosa sono le ResOps e perché sono necessarie per la resilienza informatica””. Non perderti il prossimo articolo, che tratterà la fase di controllo delle ResOps. Puoi anche scaricare la guida completa:“ResOps: una guida per i dirigenti””.
Punti di forza
- La visibilità è alla base delle ResOps (operazioni di resilienza): sapere cosa conta di più, sapere come è protetto e sapere in che misura è possibile ripristinarlo.
- Il concetto di “Minimum Viable Company” (MVC) definisce i servizi essenziali di cui un’organizzazione ha bisogno per continuare a operare.
- I servizi critici devono avere responsabili designati e soglie di tolleranza all’impatto definite dall’azienda.
- La mappatura delle dipendenze aiuta a individuare gli elementi da cui i servizi critici dovranno dipendere per funzionare e riprendersi.
- Un servizio critico è ripristinabile solo nella misura in cui lo sono le sue dipendenze.
La sfida delle dipendenze
Prima di poter pianificare Recovery, è necessario capire cosa conta di più. E la risposta non è sempre così ovvia come sembra.
Ecco perché la visibilità è fondamentale per il ResOps. Prima che i team elaborino strategie di Recovery o ne verifichino l’efficacia, devono avere una visione condivisa di ciò che l’organizzazione deve mantenere in funzione o ripristinare per primo – e di tutto ciò da cui dipendono quei servizi critici.
Sembra semplice, ma nella pratica spesso mette in luce alcune lacune scomode:
- Un servizio che l’azienda considera fondamentale potrebbe dipendere da un’applicazione a cui viene prestata molta meno attenzione.
- Un’applicazione cloud potrebbe affidarsi a un unico fornitore di identità.
- Un servizio apparentemente autonomo potrebbe condividere l’infrastruttura con decine di altri.
ResOps aiuta a mettere in evidenza queste connessioni prima che si verifichi un’interruzione.
Che cos’è la Minimum Viable Company (MVC)?
La maggior parte delle organizzazioni è in grado di indicare i propri sistemi importanti. La questione si complica quando si chiede quali siano quelli senza i quali l’azienda semplicemente non può funzionare.
Rifletti su questa domanda:Se stasera perdessimo tutto, cosa dovrebbe tornare operativo per primo?
Rispondere a questa domanda aiuta a definire la vostra MVC: la versione più snella dell’organizzazione in grado di servire i clienti, generare ricavi e adempiere ai propri obblighi più urgenti in materia legale, normativa, di sicurezza o relativi alla missione aziendale.
Il punto non è classificare ogni applicazione importante come critica. Si tratta piuttosto di stabilire le priorità in base ai risultati aziendali.
I responsabili tecnologici non possono prendere questa decisione da soli. I titolari dell’azienda, i responsabili tecnologici e i team legali e di conformità devono concordare su quali servizi siano realmente critici e quali sarebbero le conseguenze qualora tali servizi non fossero disponibili o funzionassero in modo compromesso.
Ogni servizio critico dovrebbe inoltre avere un responsabile aziendale designato. Tale responsabilità contribuisce a collegare le decisioni tecniche di Recovery alle persone che comprendono cosa comporti un’interruzione per i clienti, i ricavi, le operazioni e gli obblighi.
Quando un’interruzione è eccessiva?
Una volta individuati i servizi più importanti, la domanda successiva è:Quale livello di interruzione è in grado di sopportare l’azienda?
In ResOps, ogni servizio critico è associato a una tolleranza all’impatto definita dall’azienda. Tale tolleranza descrive la quantità di tempi di inattività, corruzione dei dati, prestazioni ridotte, output errati o ricorso a soluzioni manuali che l’azienda è in grado di assorbire prima che il danno diventi inaccettabile.
Si consideri una piattaforma di pagamento che è online, ma elabora solo il 20% del suo normale volume di transazioni. Tecnicamente, è operativa. Ma dal punto di vista aziendale, potrebbe essere considerata un fallimento.
Ecco perché le tolleranze relative all’impatto dovrebbero riflettere i risultati aziendali, e non limitarsi a indicare se un sistema è attivo o inattivo. A seconda del servizio, ciò potrebbe includere l’impatto sui ricavi orari, le soglie delle transazioni, i livelli di servizio ai clienti o gli obblighi normativi.
Le soglie esatte varieranno a seconda dell’organizzazione. Ciò che conta è definire chiaramente le priorità e rivederle man mano che l’attività evolve.
In che modo la mappatura delle dipendenze può mettere in luce gli ostacoli al Recovery
La definizione di un servizio critico indica ciò che dovrà essere ripristinato. La mappatura delle dipendenze indica – in modo dettagliato – da cosa dipende quel servizio critico per funzionare e consentire la Recovery.
I servizi critici raramente operano in modo isolato. Possono dipendere da sistemi di identità e accesso, database, reti, infrastrutture cloud, applicazioni SaaS, API di terze parti, infrastrutture condivise, persone e altri servizi interni.
Alcune di queste dipendenze sono evidenti. Altre no. È proprio qui che i piani di Recovery possono fallire. Un servizio di livello 0 può dipendere da un sistema di livello inferiore che nessuno considera critico. Diverse applicazioni possono fare affidamento sullo stesso provider di identità. Un servizio ritenuto autonomo può condividere l’infrastruttura con altri carichi di lavoro. Un servizio di terze parti può trovarsi direttamente nel percorso di Recovery anche se la vostra organizzazione ha scarso controllo su di esso.
Concentrarsi esclusivamente sui servizi critici può nascondere questi punti deboli. Mappare la catena delle dipendenze li rende visibili. Una designazione di livello 0 ha scarso significato se il servizio dipende da un sistema di priorità inferiore che non può essere ripristinato in tempo.
Comprendere l’intera catena di dipendenze è un prerequisito affinché i team possano individuare dove potrebbero verificarsi delle interruzioni prima che un’interruzione metta in luce la lacuna.
Perché è necessaria la visibilità prima di Recovery
La visibilità non consiste nel creare una mappa tecnologica il più dettagliata possibile. Si tratta piuttosto di capire cosa conta di più, cosa l’azienda può tollerare e dove le dipendenze potrebbero mettere a rischio la Recovery.
Con questa consapevolezza, i team possono concentrare gli sforzi di Recovery dove sono più importanti. Tuttavia, prima di poter rafforzare o testare la Recovery, è necessario avere un quadro chiaro di ciò che si sta cercando di ripristinare e di ciò che servirà per raggiungere tale obiettivo.
Scopri di più su ResOps
Commvault ha pubblicato“ResOps: una guida per i dirigenti”per fornire ai CISO, ai CIO e ai responsabili dei settori IT, sicurezza, resilienza e Risk un quadro di riferimento pratico per l’implementazione delle ResOps nelle loro organizzazioni.
I responsabili impareranno a identificare i servizi più importanti, a verificare la Readiness al ripristino attraverso prove concrete e a testare continuamente la resilienza. Di conseguenza, le organizzazioni potranno definire un unico modello operativo che riunisca i responsabili della sicurezza, dell’infrastruttura, delle operazioni IT e del business attorno a una recuperabilità basata su prove concrete.
Domande frequenti
D: Cosa significa “visibilità” nel contesto del ResOps?
R:Per “visibilità” si intende la capacità di comprendere quali servizi siano fondamentali per l’azienda, quale livello di interruzione ciascuno di essi possa sopportare e quali dipendenze siano necessarie affinché ogni servizio possa funzionare e riprendersi.
D: Che cos’è la “minimum viable company” (MVC)?
R:L’MVC è la versione più ridotta di un’organizzazione in grado di servire i clienti, generare ricavi e adempiere ai propri obblighi legali, normativi, di sicurezza o relativi alla missione più urgenti. È una componente fondamentale per comprendere e mettere in pratica il ResOps, poiché aiuta a stabilire le priorità su ciò che deve essere protetto e ripristinato, e in quale ordine.
D: In che modo la tolleranza all’impatto differisce dall’obiettivo relativo al tempo di ripristino (RTO)?
R: La tolleranza all’impatto descrive il livello di interruzione che l’azienda è in grado di assorbire prima che il danno diventi inaccettabile. Può includere il danneggiamento dei dati, il calo delle prestazioni, output errati, la capacità di elaborazione delle transazioni e soluzioni alternative manuali. L’RTO è un obiettivo di pianificazione del ripristino incentrato sul tempo, piuttosto che sull’impatto alla produttività o alla missione.
D: Cosa dovrebbe essere incluso nella mappatura delle dipendenze?
R: La mappatura delle dipendenze identifica ciò di cui un servizio critico ha bisogno per funzionare e ripristinarsi, inclusi applicazioni, dati, infrastruttura, sistemi di identità, servizi cloud e SaaS, terze parti, persone e altri servizi interni.D: Con quale frequenza dovrebbero essere rivisti i servizi critici e le dipendenze? R:È necessario rivederli regolarmente e ogni volta che si verificano cambiamenti significativi a livello aziendale o tecnologico. Nuove priorità, applicazioni, fornitori, integrazioni o sistemi di intelligenza artificiale possono modificare il percorso di Recovery. Michael Thelanderè direttore senior del marketing di prodotto presso Commvault.