Anche se la complessità che hanno raggiunto gli attuali sistemi IT è la causa dell’80% dei downtime, nella grande maggioranza dei casi le società non hanno modificato il modo in cui progettano i loro sistemi di disaster recovery (DR). E ciò rappresenta uno dei più grandi errori che oggi si commettono nella pianificazione del disaster recovery.
Questo è quanto sostengono diversi esperti di DR, i quali affermano che il segreto per un’efficace pianificazione a lungo termine è nascosto all’interno degli errori più diffusi fra le aziende.
Secondo Forrester Research, per rendere più effficaci i sistemi di disaster recovery, le imprese impiegano un numero sempre maggiore di tecnologie, dal server di virtualizzazione alla replicazione host-based per arrivare alle wide area network ottimizzate (tra siti remoti, in co-locazione o in outsourcing).
Gli errori da evitare
Può così nascere il problema di far lavorare assieme (e in modo efficace) tutti questi pezzi quando se ne ha bisogno. Di seguito gli errori più comuni da evitare.
Mancanza di flessibilità. “L’approccio standard alla pianificazione del disaster recovery spesso parte dall’elenco dei più frequenti eventi che possono minare i sistemi informativi e dalle soluzioni per riattivare i sistemi IT nel caso tali eventi si verificassero” spiega Paul Clifford, fondatore del Davenport Group, società di consulenza di storage e data recovery. Ma questa modalità operativa lascia fuori l’elemento più critico all’interno di un buon piano di DR: la flessibilità. “Probabilmente il più grande errore che vediamo fare dai CIO è di non costruire un piano in grado di essere adattato”, ha detto Clifford.
Il rimedio? “Semplificare l’architettura It e centralizzare il controllo, in modo da avere un approccio veramente data-centric. La semplificazione e la centralizzazione permettono di ottenere la flessibilità”, ha dichiarato Clifford (che per inciso sostiene che l’80% del downtime dei sistemi è causato dalla complessità.) La virtualizzazione è una via per costruire la flessibilità, lo stesso vale per le storage area network dual-mirrored che forniscono la possibilità di avere la scelta tra più location.
Clifford ha precisato che “una volta che avete i dati in mano, e le immagini reali di tutti gli altri siti, potete fare qualsiasi cosa vi serva, sia che si tratti di portare tali dati in un colocation center o di reinviarli alla sede principale, oppure di definire un’altra location primaria”.
Sottovalutare il tempo necessario per la piena attuazione di un piano di disaster recovery. Questo è un aspetto che riguarda principalmente le aziende con sedi remote.
“Sinora, non mi è mai capitato di vedere team IT sovradimensionati o con extra budget – ha sottolineato Clifford -. Ci vuole molto tempo per implementare tali soluzioni in uffici remoti. Non è possibile realizzare nulla in un arco temporale di 30 giorni”.
In realtà, in molti casi, non si ottiene una “piena” implementazione, considerando le difficoltà di una piano di DR su più location. I CIO hanno bisogno di capire le sfumature di ogni sito, dalle risorse tecniche e operative al personale.
“In alcune location si vedono i tecnici impegnati a fare il backup su nastri e fare affidamento che lo staff amministrativo gestisca tali nastri e si preoccupi di conservarli in un luogo esterno al sito. Questa è una strada che presenta solo pericoli”, ha dichiarato Clifford.
Affidarsi a un provider che non risponde alle vostre esigenze. Stephanie Balaouras, analista di Forrester, ha evidenziato il fatto che molte aziende stanno riportando il disaster recovery in-house per diversi motivi. Questi possono andare “dai problemi avuti col service provider di DR” a più impegnativi obiettivi di recovery, ma spesso dipendono semplicemente dal fatto che i progressi tecnologici permettono oggi ai CIO di portare le capacità in-house.
Attualmente, la tecnologia è molto più accessibile di quanto non lo fosse qualche tempo fa e un’azienda può utilizzarla per impieghi che vanno oltre il semplice DR. “La replicazione host-based è meno costosa è più efficiente in termini di larghezza di banda rispetto alla replicazione storage-based e aiuta a raggiungere obiettivi di recovery che si possono misurare in ore”, ha sostenuto Balaouras. L’IT, per esempio, può utilizzare un sito di recovery per lo sviluppo di applicazioni e per il loro test.
“Ciò detto, vi sono comunque buoni motivi per continuare il rapporto con il medesimo fornitore di DR”, ha suggerito Balaouras. Per esempio non va sottovalutato il fatto che con l’avvento delle soluzioni più commodity e offerte “alla carta”, i provider stanno diminuendo sensibilmente i loro costi.
Partecipa alla community