Una nuova ricerca di Commvault ed ESG rivela spese impressionanti, dovute soprattutto alle rebuild manuali
A cura di Mauro Palmigiani, Corporate Vice President Europe South di Commvault
La promessa su cui le applicazioni cloud-native hanno prosperato e si sono diffuse è quella che avrebbero dovuto semplificare la vita. Invece, molte aziende stanno scoprendo una dolorosa realtà: quando queste moderne app smettono di operare, il costo per ripristinarne il funzionamento è molto più elevato di quanto chiunque potesse immaginare.
La nostra ricerca, condotta in collaborazione con Enterprise Strategy Group (ESG), “Il costo nascosto della complessità del cloud: come le rebuild automatiche consentono di risparmiare tempo, denaro e salute mentale”, rivela dati sorprendenti su ciò che accade realmente quando le applicazioni cloud vanno in crash – e perché l’approccio tradizionale al ripristino stia fallendo nell’era cloud-native.
Una realtà sconcertante: 40,6 giorni-persona per ogni rebuild
Ecco il numero che non dovrebbe far dormire ogni CTO la notte: 40,6 giorni-persona. Questo è il tempo medio impiegato da un’azienda per ripristinare le principali funzionalità durante una rebuild completa di un’applicazione cloud.
Ma c’è di peggio. La ricerca ESG ha rilevato che il 42% delle interruzioni delle moderne applicazioni cloud non può essere risolto con un semplice ripristino da backup – ma richiede invece una ricostruzione completa da zero. Se consideriamo che le organizzazioni devono affrontare circa nove rebuild complete all’anno, è chiaro che stiamo parlando di una grave interruzione operativa.
Analizziamo con la giusta prospettiva:
- Il 66% delle aziende necessita di almeno una settimana per ripristinare le funzionalità principali.
- Il 78% richiede più di un mese per il ripristino completo dell’ambiente.
- Con un costo medio giornaliero di $577 per specialista, queste rebuild costano circa $210.836 all’anno solo in termini di manodopera.
Si tratta di oltre $200.000 all’anno solo in costi di staff per il ripristino – importo che potrebbe essere investito nell’innovazione invece che nella gestione delle emergenze.
L’imposta sulle iniziative strategiche: quando il recovery azzera l’innovazione
Non si tratta solo di denaro, non dimentichiamo la “tassa sull’innovazione” – ogni ora spesa a ricostruire applicazioni è un’ora non investita in trasformazione digitale, nuove funzionalità o vantaggi competitivi. Il 41% delle organizzazioni afferma che gli incidenti di rebuild interrompono lo sviluppo di iniziative strategiche.
La ricerca rivela ulteriori impatti di business che si estendono ben oltre l’IT:
- Il 49% segnala un aumento dello stress del personale durante i periodi di rebuild.
- Il 36% subisce una perdita diretta di entrate.
- Il 35% affronta l’abbandono da parte dei clienti.
- Il 34% indica una diminuzione della soddisfazione del cliente.
Quando, per settimane, si dedicano 4-5 risorse specializzate, con una capacità del 50%-75%, si verificano effetti a catena in ogni parte dell’azienda.
Perché le applicazioni cloud-native stanno rivoluzionando il ripristino tradizionale
I dati mostrano una cruda realtà: il 49% delle organizzazioni trova backup e ripristino più semplici per le applicazioni legacy, rispetto a solo il 26% per quelle cloud-native. Questo non sorprende se si capisce cosa sta accadendo.
Le applicazioni cloud-native sono costruite su architetture a microservizi – componenti vagamente connessi che possono essere di proprietà di vari team, utilizzare stack tecnologici differenti e seguire cicli di rilascio diversi. Sebbene ciò abiliti l’agilità che rende attraente il cloud-native, crea un incubo quando si parla di ripristino:
- L’82% delle organizzazioni segnala livelli problematici derivanti della configurazione.
- Il 69% riconosce che la deriva della configurazione mina attivamente la propria resilienza digitale.
- Il 47% di tutto il nuovo sviluppo di applicazioni è ora cloud-native, creando un ambiente ibrido sempre più complesso da proteggere.
L’effetto moltiplicatore del multi-cloud
La complessità si aggrava se si considera che il 90% delle aziende intervistate utilizza due o più fornitori di cloud. Sebbene l’87% desideri strumenti di resilienza coerenti tra le piattaforme cloud, la realtà è sconfortante: quasi il 90% si trova ad affrontare una sostanziale variabilità nei propri attuali tool di protezione.
Questa frammentazione crea:
- Inefficienze operative tra i team.
- Necessità di competenze specialistiche per ogni piattaforma.
- Potenziali lacune di resilienza tra gli ambienti.
L’imperativo della rebuild automatica
I dati rendono un risultato cristallino: l’approccio manuale alle rebuild di applicazioni cloud è insostenibile. Le aziende devono ripensare radicalmente il loro approccio, passando dal ripristino reattivo alla resilienza proattiva.
È qui che le rebuild automatiche diventano non solo utili, ma essenziali:
- Velocità che fa risparmiare denaro: comprimere processi di ricostruzione che durano settimane in ore o minuti non solo riduce i tempi di inattività, ma preserva le iniziative strategiche che guidano la crescita del business.
- Coerenza su larga scala: i processi automatizzati eliminano sia la deriva della configurazione che l’errore umano, che affliggono quelle manuali, consentendo un ripristino ogni volta affidabile.
- Liberazione delle risorse: se i team IT non gestiscono costantemente crisi di ricostruzione, possono concentrarsi sulle attività di innovazione che fanno effettivamente progredire l’azienda.
I processi di ricostruzione manuale sono un freno all’innovazione, un drenaggio di risorse e un rischio per la continuità aziendale. Con l’accelerazione dell’adozione del cloud-native – con il 47% delle nuove applicazioni ora costruite su questi principi – le aziende che sopravvivranno e prospereranno saranno quelle che abbracceranno l’automazione come requisito fondamentale, non come un “nice-to-have”.
