C’è stato un tempo, poco dopo aver capito che Linux e l’open-source sarebbero stati la mia vita (professionale, si intende) in cui è sbocciato dentro di me il primo vero amore, che si riassumeva in un concetto che nel corso degli anni ha più volte cambiato senso. Sto parlando dell’Alta Affidabilità, in inglese High Availability o HA.

Lo so, in realtà la traduzione letterale del termine inglese sarebbe Alta Disponibilità, ma ho sempre preferito la parola Affidabilità poiché in esse ci trovavo tutto il suo obiettivo: garantire continuità nei servizi erogati a fronte di problematiche più o meno importanti.

Ai tempi, stiamo parlando della metà degli anni 2000, questa categoria di servizi era tutta raggruppata sotto la parola “cluster”. E non si parlava di cluster Kubernetes con 3 nodi a fare da control plane e mille altri nodi a fungere da worker. No, il classico cluster era quello a due nodi. Tipicamente Active/Passive. Se moriva uno, l’altro saliva a prenderne il posto.

In questo che appare un semplice principio, in realtà erano racchiuse decine di migliaia di implicazioni tecniche. La concorrenza dei dati, il locking dei file, la gestione degli stati delle macchine, e via dicendo. Tutti questi comportamenti andavano programmati e gestiti attraverso strumenti e tool di una complessità disarmante.

In principio c’era Heartbeat (parte del progetto Linux HA), tempo dopo è arrivato Pacemaker, che modernizzava (aumentando ulteriormente però la complessità di gestione) l’approccio e consentiva una gestione più organica dei nodi e delle risorse.

Con Pacemaker è stato subito amore: ne ho curato la traduzione italiana e sono finito a lavorare per un certo periodo anche con il suo creatore, Andrew Beekhof quando entrambi lavoravamo al progetto OpenStack. Inizialmente infatti, la parte HA di OpenStack era gestita mediante Pacemaker. Tutti i servizi che permettevano a OpenStack di funzionare erano singoli processi gestiti all’interno di un cluster Pacemaker che, in maniera autonoma (frutto di una configurazione molto, molto complessa) gestiva il ciclo di vita e la sopravvivenza dei servizi.

Tutta questa lezione di storia, probabilmente inutile ai più, torna però comoda per parlare di un concetto che tutte le tecnologie sopra descritte lavoravano per eliminare: lo SPOF.

Il Single Point Of Failure è da sempre il nemico giurato di quanti lavoravano ai cluster e rappresenta una o più componenti che, se interrotte, impattano sul funzionamento generale di un servizio.

Quel Pacemaker di cui scrivevo poco fa era nato esattamente con l’idea di eliminare gli SPOF, poiché autonomamente era in grado di riavviare e spostare risorse e, nel caso, uccidere nodi dei quali non si riusciva a decifrare lo stato, attraverso la tecnologia descritta da un altro acronimo a cui sono molto affezionato, ossia STONITH, cioè Shoot The Other Node In The Head.

Solo che, ad un certo punto, con l’avvento del cloud tutto è cambiato. Perché mai qualcuno avrebbe dovuto preoccuparsi di gestire questioni come la sopravvivenza (o meno) dei nodi in un contesto cloud, venduto come sempre attivo? Le stesse tecnologie cloud native, in primis Kubernetes, non si devono più porre il problema degli SPOF, poiché sono resilienti by design, per così dire.

E questo è un bene per un uomo del passato come me.

Solo che poi ci sono le notizie. C’è il fatto che nell’ottobre 2025, migliaia di utenti del cloud provider AWS hanno subito un disservizio globale, ed a quanto pare il motivo di tale disservizio è riassunto proprio da quell’acronimo: SPOF.

Nell’articolo di ARS Technica viene indicato come Amazon ha attribuito la causa del disservizio a un bug nel software che gestisce il sistema DNS interno su cui si basa DynamoDB..

Ora, uno potrebbe pensare: shit happens, i problemi capitano. Eppure questo problema, avvenuto sul più importante cloud provider del mondo, evidenzia che quel Nirvana senza SPOF che i sysadmin stanno cercando di raggiungere da sempre è ben lontano dall’essere realtà.

Tutto il resto è solamente un’illusione. Il fatto che usare il cloud sollevi chi crea e gestisce i servizi dal doversi preoccupare di “cosa succede se” è, scusate il francesismo, una cazzata. Leggete ad esempio la storia apparsa su DevOps.com, dove viene descritto l’effetto a cascata del disservizio su un ambiente che utilizzava l’auto scaling per ovviare a questi problemi.

È impressionante e ricorda tantissimo uno di quei momenti in cui guardavi il tuo cluster Pacemaker, che pensavi fosse costruito a regola d’arte, iniziare a fare fencing (ossia l’uccisione, parte dello STONITH descritto prima) a rotazione su tutti i sistemi, trovandoti nella condizione in cui la tecnologia che doveva salvarti, in realtà ti stava affondando.

Perché sì, succedeva molto spesso, ed evidentemente succede molto anche oggi.

Convinciamoci che il cloud non è la panacea di tutti i mali.

Convinciamoci che pensare a qualcun altro a cui demandare la resilienza dei nostri sistemi, vedi ad esempio l’IA, non è mai la scelta più indicata.

E non lo dico io, è una questione di fatti.