Un primo "code red" nazionale della storia. Per noi, un non-evento — perché eravamo pronti.

Una credenziale a cui non si può accedere è una credenziale che non si possiede. Per un vault, restare disponibile — ogni volta, da qualsiasi luogo — non è una funzionalità; è l'intero lavoro.

Questa settimana i Paesi Bassi hanno dichiarato il loro primo "code red" nazionale della storia per il caldo estremo — un evento da 40°C che il Paese non aveva più affrontato dall'inizio delle registrazioni meteorologiche nel 1901 [1][2]. Entro venerdì il caldo aveva raggiunto lo strato quasi nessuno prende in considerazione finché non va in avaria: il data center. Il nostro provider ad Amsterdam, Leaseweb, ha fatto esattamente la cosa giusta e ci ha avvisato per tempo — la struttura lavorava al limite, aveva iniziato a spegnere parti della propria infrastruttura per dissipare calore, e la macchina che ospitiamo lì poteva essere la successiva. L'abbiamo verificata: in salute, in servizio normalmente. Poi siamo tornati al lavoro. Non perché fossimo certi che Amsterdam avrebbe retto — perché non è necessario che lo faccia.

Un data center surriscaldato ad Amsterdam non può essere un nostro problema

La macchina ad Amsterdam è uno dei due anchor del nostro sistema di gestione — il cervello dietro le quinte che gestisce e coordina la nostra flotta. E prima di ogni altra cosa, il punto che conta di più, in parole semplici: questo non è il vault che conserva e serve le vostre credenziali. Quelli girano su un piano completamente separato e indipendente — un sistema globale del tutto diverso — che questo caldo non ha nemmeno sfiorato. Il cervello di gestione e i vault con cui i vostri agenti comunicano effettivamente sono due mondi diversi: una giornata negativa per l'uno non è affatto una giornata negativa per l'altro. Noi applichiamo però a quel cervello di gestione lo stesso standard di tutto il resto — mai un singolo punto di guasto. Per questo ci sono due anchor, per scelta — uno ad Amsterdam (Leaseweb), uno a Osaka (Ablenet). Due continenti. Due provider. Due reti elettriche. Due climi. Un pomeriggio da 40°C nei Paesi Bassi non ha alcuna conseguenza fisica su una macchina in Giappone: meteo diverso, rete elettrica diversa, dominio di guasto completamente diverso. (Curiosità: mentre Amsterdam toccava i 40°C sotto un code red nazionale, Osaka si attestava intorno ai 29°C nel mezzo della stagione delle piogge — undici gradi in meno, dall'altra parte del mondo, su un sistema meteorologico del tutto indipendente. Quella differenza è il progetto.) I due anchor restano in sincronizzazione continua, così né l'uno né l'altro sono mai molto indietro rispetto all'altro. Se un'ondata di caldo, un guasto alla rete elettrica o un incidente del provider avessero messo Amsterdam offline, lo scenario peggiore sarebbe un failover breve e delimitato verso l'altra parte del pianeta — non un'interruzione del servizio.

La resilienza non è una funzionalità di un vault per credenziali. È il prodotto.

Un vault per credenziali è l'elemento più portante di uno stack: ogni app, pipeline e agente si autentica attraverso di esso. Quando risponde, tutto funziona; quando non può farlo, tutto si ferma contemporaneamente. È questa asimmetria a far sì che la resilienza non sia qualcosa che si aggiunge in un secondo momento. Non si vuole scoprire, nel giorno più caldo di un secolo, se il proprio unico data center, nella propria unica città, sulla propria unica rete elettrica, regga il caldo. Lo si decide in una giornata fresca, rifiutando di scommettere l'azienda su un solo clima. Noi questa scelta l'abbiamo fatta tempo fa: nessuna singola regione, provider, rete elettrica o sistema meteorologico può mai essere l'intera storia.

La versione onesta

Nulla rende un'infrastruttura immune. Il meteo va in avaria, le reti elettriche vanno in avaria, i provider vanno in avaria — e chiunque vi dica il contrario sta vendendo qualcosa. Quello che si sceglie davvero è se l'avarìa di uno solo di questi elementi possa trascinare giù anche voi. Noi abbiamo scelto due emisferi, così la risposta è no. Questa settimana ha messo alla prova quella scelta nel modo più letterale possibile, e la prova è stata noiosa: Amsterdam ha continuato a servire durante il caldo, e anche se non lo avesse fatto, il progetto aveva già la risposta pronta a Osaka.

Costruire per il disastro nel giorno in cui non sta accadendo

Questa è l'intera disciplina. La giornata fresca è quella in cui si costruisce per quella calda; la giornata calda è quella in cui si è discretamente contenti di averlo fatto. Questa settimana è stata una giornata calda — da record — e per noi è stata un non-evento. Ed è esattamente ciò che deve essere.

Un merito va riconosciuto: Leaseweb ha gestito il caldo come fanno i bravi operatori — avviso tempestivo, azione protettiva, nessun dramma. I migliori provider vi avvisano prima che ci sia un problema. Il nostro compito è solo fare in modo che, quando un sito attraversa una brutta giornata, non sia mai stato l'unico sito.

Clavitor (@clavitorai) è il vault per credenziali costruito per gli agenti di IA, e contro di essi. clavitor.ai

Fonti

[1] NL Times — Dutch heatwave now official; historic Code Red hot-weather alert (primo "code red" nazionale della storia per il caldo estremo; ondata di caldo di giugno più lunga dall'inizio delle registrazioni nel 1901): https://nltimes.nl/2026/06/25/dutch-heatwave-now-official-historic-code-red-hot-weather-alert-debated

[2] DutchReview — NL temperatures to reach up to 40 degrees (temperature massime nell'entroterra vicine ai 40°C): https://dutchreview.com/news/netherlands-up-to-40-degrees-then-plummet-to-21-degrees-25062026/