Questa settimana, nella nostra infrastruttura interna, un cuscinetto a sfera da 0,02 € guasto ha innescato una reazione a catena che ha coinvolto uno dei tre ipervisori di un cluster interno. Nessun cliente e nessun dipendente è stato maltrattato, perché gli altri due ipervisori del cluster hanno assorbito il carico grazie alla ridondanza. I sistemi di monitoraggio hanno segnalato l'anomalia al team tecnico, consentendo di intervenire per tempo senza che utenti o clienti subissero disservizi. È la dimostrazione pratica di cosa significhi davvero fare business continuity e disaster recovery: non un costo da tagliare, ma un piano da costruire prima che serva.
L'effetto domino: dal cuscinetto al cluster
La catena dei fatti, ricostruita insieme al nostro team tecnico, parte da un componente talmente piccolo da sembrare irrilevante. Ed è proprio questo il punto: in un sistema complesso, non è la grandezza del guasto iniziale a contare, ma la lunghezza della catena di dipendenze che lo separa dal danno finale.
Va precisato un dettaglio tecnico importante: cuscinetto, ventola e scheda non sono tre componenti esterni e separati. Sono tutti fisicamente interni allo stesso ipervisore. È il guasto interno di quella singola macchina a propagarsi verso l'alto, fino a farla uscire completamente dal cluster di cui faceva parte, un cluster da 24.000,00 € composto da tre nodi.
| Componente coinvolto | Valore indicativo | Ruolo nella catena |
|---|---|---|
| Cuscinetto a sfera | 0,02 € | Innesco del guasto |
| Ventola di raffreddamento | 8,00 € | Si blocca per il cuscinetto guasto |
| Scheda interna all'ipervisore | 60,00 € | Si inchioda per il surriscaldamento |
| Ipervisore | 8.000,00 € | Va completamente fuori servizio |
| Cluster di 3 ipervisori | 24.000,00 € | Regge grazie alla ridondanza degli altri due nodi |
0,02 €
8,00 €
60,00 €
8.000,00 €
su 3 nodi · cluster da 24.000,00 €
gli altri 2 ipervisori assorbono il carico, nessun disagio
Clicca su "Avvia il guasto" per vedere la cascata, dal cuscinetto al cluster.
Perché la ridondanza del cluster ha salvato tutto
Il punto centrale della storia non è il guasto, che può capitare, ma quello che non è successo dopo. Il cluster coinvolto era progettato in ridondanza: quando l'ipervisore guasto è uscito di scena, gli altri due nodi del cluster hanno assorbito il carico che gestiva. Questo ha impedito qualunque interruzione ai servizi condivisi, e ha permesso a tutti i dipendenti di continuare a lavorare senza percepire alcun disagio.
È l'esempio più concreto possibile di un principio che ripetiamo spesso durante le verifiche che effettuiamo per i clienti: separare i sistemi critici, non tenerli tutti sullo stesso piano di rischio, è una delle misure di disaster recovery più efficaci e meno costose da implementare, perché non richiede nuovo hardware, ma progettazione.
Ti piace Alchimie Digitali? Aggiungilo alle tue fonti preferite su Google
Se vuoi trovare più facilmente i nostri approfondimenti su cybersecurity, infrastruttura IT e compliance, puoi scegliere Alchimie Digitali tra le tue fonti preferite su Google.
★ Aggiungi Alchimie Digitali come fonte preferita → La disponibilità della funzione e la visualizzazione delle fonti possono dipendere dall'account e dall'esperienza Google utilizzata.Cosa è successo davvero, giorno per giorno
I sistemi di monitoraggio dell'infrastruttura hanno rilevato l'anomalia e avvertito il team tecnico, permettendo di intervenire per tempo e avviare subito le attività di diagnosi e ripristino. Nel frattempo, la ridondanza del cluster ha continuato a garantire l'operatività senza disservizi percepibili per utenti e clienti.
Una volta individuato, il ripristino completo ha richiesto circa due giorni pieni di lavoro da parte di due tecnici senior. Non un intervento banale: prima è stato necessario diagnosticare con precisione dove si trovasse il problema all'interno della catena hardware, risalendo fino al cuscinetto. Poi, grazie a una risorsa interna specializzata in elettrotecnica, è stato possibile smontare minuziosamente la ventola, pulirla, ingrassare il cuscinetto e rimontare tutto, riportando il componente perfettamente funzionante invece di doverlo sostituire. È un dettaglio che spesso viene sottovalutato quando si parla di disaster recovery: anche un piano ben progettato richiede tempo e competenza specialistica per essere eseguito, non è un pulsante da premere.
La lezione di disaster recovery: la business continuity non si improvvisa
Il costo dei componenti coinvolti in questa vicenda, dai due centesimi del cuscinetto ai 24.000,00 € del cluster, non è il punto. Il punto è che nessuna di queste cifre racconta davvero il rischio reale, che è sempre lo stesso: cosa succede quando un guasto, piccolo o grande, arriva davvero. Risparmiare su ridondanza, backup e monitoraggio funziona benissimo finché tutto va bene. Il problema è che prima o poi qualcosa si guasta, ed è proprio in quel momento che si scopre se l'azienda ha un piano oppure no.
Le infrastrutture migliori non sono quelle che non subiscono mai un danno, ma quelle che non crollano quando il danno arriva. È questa la differenza tra chi ha un piano di disaster recovery e chi si limita a sperare che non succeda nulla.
Costruire una strategia di business continuity seria richiede tempo, investimento e programmazione, non improvvisazione dell'ultimo momento. Non a caso lo standard internazionale ISO 22301 è quello specificamente dedicato ai sistemi di gestione della continuità operativa e definisce la continuità come la capacità di un'organizzazione di continuare a erogare prodotti e servizi entro tempi accettabili durante un'interruzione, attraverso un processo continuo di pianificazione, verifica e miglioramento, non attraverso interventi una tantum. La ISO/IEC 27001, pur essendo dedicata alla gestione della sicurezza delle informazioni, è strettamente collegata al tema perché comprende controlli relativi alla sicurezza delle informazioni durante le interruzioni e alla prontezza ICT per la business continuity. La ISO 9001, invece, non è uno standard specifico di business continuity, ma contribuisce sul piano della gestione del rischio e del controllo dei processi. È anche per questo che il nostro percorso verso le certificazioni ISO 9001 e ISO/IEC 27001 si inserisce in una visione più ampia di resilienza e continuità aziendale, senza sostituire il ruolo specifico della ISO 22301.
Lo stesso principio è oggi anche un obbligo normativo per molte imprese italiane: la direttiva NIS2 richiede esplicitamente alle entità coinvolte di dotarsi di piani documentati di continuità operativa e disaster recovery, con backup adeguati e livelli di ridondanza sufficienti a garantire la ripresa dei servizi in caso di incidente. Un cluster ridondante che continua a garantire l'operatività mentre i sistemi di monitoraggio segnalano l'anomalia al team tecnico è, in piccolo, esattamente il tipo di resilienza che queste normative chiedono di costruire.
I nostri servizi per una vera continuità operativa
Su questi principi lavoriamo ogni giorno con i nostri clienti. Ecco i servizi di Alchimie Digitali più legati a quanto raccontato in questo articolo.
Quattro pezzi dello stesso puzzle: nessuno basta da solo, insieme costruiscono la continuità operativa.
Domande frequenti sul caso
Perché un componente da pochi centesimi ha potuto mettere a rischio un cluster da 24.000,00 €?
Perché in un sistema informatico i componenti sono collegati da relazioni di dipendenza fisica e funzionale. Un cuscinetto guasto ha bloccato la ventola, la ventola bloccata ha fatto surriscaldare una scheda interna all'ipervisore, e il blocco della scheda ha fatto cadere prima l'ipervisore e poi l'intero cluster a cui apparteneva.
Perché utenti e dipendenti non hanno percepito il guasto?
Perché gli altri due ipervisori del cluster hanno assorbito il carico di quello guasto grazie alla ridondanza, evitando interruzioni del servizio. Questo non significa che il problema sia passato inosservato: i sistemi di monitoraggio hanno segnalato l'anomalia al team tecnico, consentendo di intervenire per tempo.
Quanto tempo serve per risolvere un guasto hardware di questo tipo?
In questo caso circa due giorni pieni di lavoro da parte di due tecnici senior, tra diagnosi e intervento, a causa della complessità nel risalire alla causa reale del blocco.
Che ruolo ha avuto il sistema di monitoraggio?
Il monitoraggio dell'infrastruttura ha funzionato come previsto: ha segnalato l'anomalia al team tecnico e ha permesso di intervenire per tempo, prima che il problema potesse trasformarsi in un disservizio percepibile da utenti o clienti.
Altre domande correlate
Cos'è un piano di business continuity?
È l'insieme di procedure e strategie che permettono a un'azienda di continuare a operare, o di riprendere rapidamente a farlo, durante e dopo un evento che interrompe i sistemi o i processi critici.
Cosa si intende per ridondanza di un'infrastruttura IT?
Significa progettare più risorse del minimo necessario, ad esempio un server in più in un cluster, così che se una di esse si guasta le altre possano assorbirne il carico senza interrompere il servizio.
La NIS2 obbliga le aziende ad avere un piano di disaster recovery?
Sì, per le entità che rientrano nel suo perimetro. La direttiva NIS2 richiede piani documentati di continuità operativa e ripristino, oltre a backup adeguati e livelli di ridondanza sufficienti a garantire la ripresa dei servizi.
Il tuo piano di business continuity regge davvero un guasto imprevisto, o funziona solo finché non succede niente?
Parliamone insieme