Indice dei contenuti dell'articolo:
Ci sono disservizi che si ricordano per qualche ora. Poi ci sono quelli che diventano un caso interno, un promemoria operativo, una lezione da non dimenticare. E poi ci sono gli episodi che meritano di essere raccontati pubblicamente, perché smettono di essere un semplice incidente tecnico e diventano la dimostrazione plastica di un problema molto più ampio: la fragilità di certi servizi cloud quando la teoria commerciale si scontra con la pratica, e quando il supporto smette di essere supporto per trasformarsi in un centralino del rinvio.
Il Downtime della VPS in Cloud.it
Questa storia comincia sabato 4 aprile 2026 alle 14:49. In quel momento l’istanza Cloud afferente al servizio Cloud.it di Aruba e dal nome nodo “MANAGEDSERVER.IT”, diventa completamente irraggiungibile. Non parliamo di un servizio degradato, di una latenza anomala o di qualche pacchetto perso. Parliamo di un blackout totale. Nessuna raggiungibilità, nessuna operatività, nessun controllo reale dal pannello. Il ticket viene aperto alle 15:01. Da lì inizia una sequenza di ore che si trasformano in giorni, fino al ripristino soltanto il 7 aprile 2026 alle 10:30. In totale, quasi 67 ore e 41 minuti di inattività.
Sessantasette ore. SESSANTASETTE ! Più di due giorni e mezzo. Nel 2026. Su un servizio cloud.
Già questo, da solo, dovrebbe bastare a far alzare più di un sopracciglio.
La gestione inesistente del problema
Ma il punto non è soltanto il guasto. I guasti capitano. Capitano a tutti, capitano a Google, a Microsoft, ad AWS. Capitano. Capita un problema di nodo fisico, capita un fault sullo storage, capita un evento che innesca un’indisponibilità grave. Nessuno che lavori davvero nell’infrastruttura si scandalizza per l’idea astratta che qualcosa possa rompersi. Il punto è un altro: cosa succede dopo.
Ed è qui che la vicenda smette di essere una banale interruzione di servizio e diventa una disavventura esemplare.
Perché nelle ore successive all’apertura del ticket, e poi nelle decine di ore seguenti, la sensazione dominante non è stata quella di essere di fronte a un fornitore alle prese con un problema serio ma gestito. La sensazione è stata quella di essere precipitati in una zona grigia fatta di formule automatiche, rassicurazioni vuote e assenza quasi totale di informazioni tecniche utili. “Stiamo verificando”. “Abbiamo sollecitato”. “La contatteremo”. Frasi che hanno la funzione di occupare uno spazio, non di colmarlo. Frasi che servono più a guadagnare tempo che a restituire visibilità al cliente. E intanto il tempo passava, il sistema restava fermo, e dall’altra parte non arrivava alcuna spiegazione concreta sulla causa del disservizio, sul reale stato delle attività, sulle criticità incontrate o anche solo su una stima minimamente seria dei tempi di ripristino.
È questo il punto che irrita più del down. Un’infrastruttura può guastarsi. Ma una gestione del disservizio non può permettersi di guastarsi a sua volta.
Dopo oltre 18 ore di blackout viene inviata mezzo PEC una diffida formale e messa in mora. Poi, superate le 33 ore, un ulteriore sollecito dettagliato. Poi ancora, oltre le 50 ore, un’altra PEC in cui si ribadisce l’ovvio: qui non manca solo la risoluzione, manca la comunicazione. Manca il minimo sindacale che ci si aspetta quando si ha davanti un fornitore che vende un servizio cloud destinato, almeno nella sua presentazione, a un uso professionale.
A un certo punto erano state chieste perfino due strade alternative, entrambe ragionevoli: o il ripristino del nodo, oppure la consegna dello snapshot della macchina in formato OpenStack, così da consentire una migrazione autonoma. Nulla. Né una né l’altra. Solo quel limbo tossico in cui il cliente non ha la macchina, non ha i dati, non ha un ETA, non ha un referente tecnico che gli dica cosa stia succedendo, ma continua a sentirsi ripetere che “verrà ricontattato”.
È in momenti come questi che il cloud mostra il suo lato peggiore. Quando funziona, tutto è comodo. Scalabilità, flessibilità, provisioning rapido, pannello, automazione, marketing. Quando invece qualcosa si rompe davvero, e si rompe sul serio, il cliente scopre improvvisamente la parte più scomoda del patto: l’infrastruttura non è sua, il controllo non è suo, l’accesso al livello fisico non è suo, e la velocità di reazione dipende completamente dalla competenza, dalla trasparenza e dalla serietà del provider. Se queste tre cose mancano, il cloud smette di essere una comodità e diventa una gabbia.
Nel nostro caso, la differenza tra un disservizio pesante e un danno molto più grave l’ha fatta un fattore esterno al provider. Dopo circa quaranta minuti iniziali di down, constatata l’assenza di qualunque riscontro utile e intuendo che non ci sarebbe stato un recupero rapido, abbiamo attivato la nostra replica ZFS su Hetzner. È stata quella a salvarci. Non la resilienza nativa del servizio. Non il supporto. Non il fantomatico ombrello protettivo evocato dal termine “cloud”. La salvezza è arrivata da una replica indipendente, geograficamente separata, fuori da quell’infrastruttura, già pronta a essere usata. Grazie a quella replica, il sito istituzionale è tornato online dopo i primi quaranta minuti di down, proprio mentre dal provider non arrivava alcun elemento che lasciasse sperare in una risoluzione in tempi civili.
Ed è qui che bisogna fermarsi un attimo, perché la lezione è importante.
Il cloud non è backup. Il cloud non è disaster recovery. Il cloud non è replica geografica. Il cloud, da solo, è semplicemente il computer di qualcun altro. E quando quel computer di qualcun altro sparisce per quasi tre giorni, improvvisamente tutto il linguaggio patinato sulla continuità operativa mostra le sue crepe.
Oltre il danno la beffa dello SLA
A questo punto entra in scena la questione delle SLA, perché è qui che molte aziende si illudono di essere protette. L’SLA pubblicato da Cloud.it è il documento “Service Level Agreement (SLA) del Servizio Aruba Cloud Computing”, versione pubblica 1.3, in vigore dal 31 luglio 2025. Il documento distingue tra più scenari. Per i servizi cloud in generale, Aruba dichiara un uptime del 99,95% su base annuale per l’accessibilità tramite rete internet all’infrastruttura Data Center e un ulteriore 99,95% su base annuale per la disponibilità dei nodi fisici che ospitano l’infrastruttura virtuale del cliente. Per alcune tipologie specifiche, come VPS Openstack Starter e VPS VMware, il livello si abbassa a 99,8% su base annuale sia per accessibilità sia per disponibilità dei nodi fisici. Inoltre la manutenzione programmata non viene conteggiata e dovrebbe essere comunicata con almeno 48 ore di preavviso.
Tradotto in termini concreti, il 99,95% di uptime annuo significa un disservizio teoricamente tollerato nell’ordine di circa 4 ore e 23 minuti all’anno. Il 99,8% significa invece circa 17 ore e 31 minuti all’anno. Ora, mettiamo questi numeri accanto a ciò che è successo davvero: quasi 67 ore e 41 minuti di down. Anche prendendo l’ipotesi più benevola per il provider, cioè quella della soglia più larga del 99,8%, qui non siamo davanti a uno sforamento marginale. Siamo davanti a un incidente che travolge completamente il limite promesso. Se invece il servizio ricadesse nello scenario ordinario del 99,95%, il superamento sarebbe ancora più clamoroso. In entrambi i casi, comunque, non si parla di un piccolo scostamento statistico: si parla di una voragine.
Ma allora, concretamente, cosa ci si sarebbe dovuti aspettare da una SLA del genere?
Anzitutto, ci si sarebbe aspettati che la promessa di uptime non fosse un numero decorativo messo lì per arredare il listino, ma l’espressione di un modello operativo coerente: monitoraggio efficace, presa in carico seria dell’incidente, comunicazioni chiare, canali di escalation reali, capacità di offrire workaround. Una SLA non è solo una percentuale. È l’implicazione pratica che, se un disservizio grave si verifica, il fornitore ha una macchina pronta a gestirlo. In altre parole: non ci si aspetta l’impossibile, ma ci si aspetta competenza, trasparenza e tempi commisurati alla gravità dell’evento. Dopo qualche ora, quantomeno, ci si aspetta una causa probabile. Dopo decine di ore, ci si aspetta un piano. Dopo oltre due giorni, ci si aspetta una soluzione o almeno un’alternativa concreta per consentire al cliente di uscire dal blocco. Qui, invece, ciò che è emerso è il contrario: una SLA che, davanti a un incidente reale, non ha impedito né il blackout prolungato né il buco comunicativo.
Il rimborso “inesistente” per il danno subito.
Poi c’è il tema del rimborso, che è forse la parte più beffarda dell’intera storia. Per l’infrastruttura virtuale creata e allocata dal cliente, l’articolo 6.2 prevede un credito pari al 5% della spesa complessiva generata nei 30 giorni precedenti al disservizio, oppure della mensilità precedente per i servizi a pagamento mensile, per ogni frazione completa di 15 minuti di disservizio oltre i limiti previsti dallo SLA, fino a un massimo di 300 minuti. Poiché 300 minuti equivalgono a 20 blocchi completi da 15 minuti, il credito massimo arriva di fatto al 100% della spesa della parte di infrastruttura virtuale interessata nel periodo di riferimento. La richiesta del credito deve essere presentata entro 10 giorni dalla fine del disservizio tramite ticket, e vengono considerati validi solo i disservizi confermati anche dal sistema di monitoraggio di Aruba. Per i servizi cloud a pagamento mensile, inoltre, il documento precisa che non è dovuto alcun rimborso ulteriore per il periodo di inattività, se non il credito previsto dall’articolo 6.2. Il testo aggiunge anche che, durante il periodo di inattività, il servizio cloud non genera spesa, e che eventuali importi erroneamente addebitati devono essere riaccreditati sul pannello di gestione.
Qui il paradosso è quasi offensivo nella sua nettezza.
Poiché il disservizio è durato enormemente più dei limiti tollerati dallo SLA, il meccanismo del credito raggiunge con ogni probabilità il suo massimo teorico, ovvero 20 euro, VENTI.
In altre parole, salvo eccezioni applicate dal provider o contestazioni sulla qualificazione del servizio, il ristoro economico a cui si avrebbe diritto arriverebbe verosimilmente al 100% della spesa dell’infrastruttura colpita nei 30 giorni precedenti, oppure al 100% dell’ultima mensilità se si tratta di un servizio mensile. Non di più. Non il 200%. Non il costo del danno. Non il mancato guadagno. Non il tempo uomo bruciato. Non il danno d’immagine. Non l’ansia operativa. Non il costo della migrazione d’emergenza. Non la perdita potenziale di posizionamento. Semplicemente, al massimo, l’equivalente di una mensilità o dell’ultimo consumo del blocco interessato.
Ed è qui che la SLA, da strumento di tutela, mostra tutta la sua insufficienza pratica.
Perché davanti a quasi tre giorni di indisponibilità, con ticket aperti, PEC, telefonate e totale assenza di un vero presidio tecnico percepibile dal cliente, il rimedio economico massimo previsto è sostanzialmente un credito che può arrivare a compensare il costo del servizio nel periodo di riferimento, venti euro, il costo di una pizza e coca cola in una pizzerie di periferia. Una specie di “ti restituiamo il canone” travestito da tutela contrattuale. Dal punto di vista strettamente contrattuale, il provider dirà di aver definito chiaramente il perimetro. Dal punto di vista operativo, il cliente si accorge che tra il valore del danno reale e il valore del credito SLA c’è un abisso.
Non solo. La stessa SLA contiene una serie di esclusioni: forza maggiore, interventi straordinari urgenti per la sicurezza o stabilità, problemi imputabili al cliente, malfunzionamenti di software di terze parti, guasti esterni alla rete Aruba e così via. Sono clausole abbastanza tipiche, e non c’è nulla di sorprendente in sé. Ma quando già il rimedio economico è modesto, la presenza di un elenco ampio di esclusioni rende ancora più evidente quanto questo tipo di documento tuteli soprattutto il fornitore e assai meno il cliente.
Conclusioni della brutta esperienza vissuta.
Alla fine, quindi, la vera domanda non è nemmeno se il disservizio sia stato grave. Lo è stato, senza dubbio. La domanda vera è un’altra: ha senso utilizzare un servizio del genere come pilastro unico di un’infrastruttura, se non è affiancato da backup indipendenti, replica geografica e una strategia autonoma di disaster recovery?
Per quanto ci riguarda, la risposta dopo questa esperienza è brutale nella sua semplicità: no. O meglio, non da solo. Non senza un piano B serio. Non senza la consapevolezza che, nel momento in cui il provider si pianta e il supporto si rifugia dietro formule prefabbricate, l’unica cosa che ti salva davvero è ciò che hai costruito fuori da lui.
Nel nostro caso è stata una replica ZFS su Hetzner a rimettere in piedi il sito istituzionale dopo i primi quaranta minuti di down, proprio mentre dall’altra parte non arrivava alcun riscontro degno di questo nome. Ed è difficile immaginare una sintesi più severa di questa. Per quasi tre giorni la promessa del cloud è evaporata. La continuità operativa è arrivata altrove.
Il che ci riporta alla conclusione più onesta, e anche più scomoda: una SLA può forse offrirti un credito. Ma non ti restituisce il tempo perso, la reputazione erosa, la fiducia bruciata e l’assurdità di dover inseguire per quasi sessantotto ore un servizio che avrebbe dovuto, semplicemente, restare acceso.
