Premesse
C’è un momento, in ogni sistema informatico complesso, in cui qualcosa di accessorio smette di funzionare: un servizio di cache momentaneamente irraggiungibile, una libreria di parsing opzionale non disponibile su un determinato ambiente, una connessione a un provider esterno che va in timeout.
La domanda tecnica che distingue un sistema maturo da uno fragile non è “questo può succedere”, perché prima o poi succede sempre, ma “cosa fa il sistema quando succede”. Un software di facility management che si blocca interamente perché un componente accessorio non risponde sta chiedendo alla propria infrastruttura una perfezione che nessuna infrastruttura reale può garantire in modo continuativo.
Cos’è la “degradazione controllata”, e in cosa differisce da un errore fatale?
La degradazione controllata è un principio di progettazione secondo cui, quando un componente non essenziale al funzionamento di base del sistema diventa indisponibile, l’applicazione continua a funzionare con una capacità ridotta invece di interrompersi del tutto.
Questo richiede di distinguere esplicitamente, fin dalla progettazione, quali componenti sono davvero critici – il database principale, per esempio, la cui assenza rende impossibile qualunque operazione – e quali sono opzionali o accessori – una cache distribuita, un servizio di notifiche in tempo reale, un motore di parsing avanzato di un formato specifico – la cui assenza dovrebbe comportare una perdita di funzionalità circoscritta e dichiarata, non un errore fatale che si propaga a tutto il resto del sistema.
Un esempio concreto: se le notifiche in tempo reale si basano su un meccanismo di comunicazione continua tra server e client che richiede un’infrastruttura di supporto specifica, e quell’infrastruttura non è disponibile in un determinato ambiente o momento, un sistema ben progettato dovrebbe ricadere automaticamente su un meccanismo alternativo più semplice – un controllo periodico a intervalli regolari – che garantisce comunque la consegna delle notifiche, seppure con una latenza leggermente superiore, invece di lasciare l’utente semplicemente senza notifiche o, peggio, con un’applicazione che smette di rispondere in attesa di una connessione che non arriverà.
Come si progetta un fallback che sia davvero trasparente per l’utente finale?
Un fallback ben progettato non richiede all’utente finale alcuna consapevolezza tecnica di cosa sia cambiato: l’applicazione continua a comportarsi in modo coerente, magari con una prestazione lievemente diversa, ma senza messaggi di errore incomprensibili o funzionalità che smettono di rispondere senza spiegazione.
Questo richiede che ogni punto di integrazione con un componente opzionale sia scritto fin dall’inizio con un percorso alternativo esplicito nel codice, non aggiunto a posteriori come toppa correttiva dopo un incidente in produzione: il codice dovrebbe verificare la disponibilità del componente preferito e, se assente, instradare automaticamente verso l’alternativa, con un log dedicato che segnala la situazione a chi amministra il sistema, ma senza interrompere l’esperienza di chi lo sta usando in quel momento.
Perché anche il parsing di formati tecnici complessi, come un modello BIM pesante, dovrebbe prevedere un meccanismo di ripiego in caso di libreria non disponibile?
Ho parlato, in un articolo precedente dedicato al BIM, di come la compressione e la memorizzazione in cache di un modello IFC dipendano da librerie specialistiche di parsing. Cosa succede se, per qualche motivo – un ambiente non ancora configurato correttamente, una dipendenza temporaneamente non installata – quella libreria non è disponibile nel momento in cui un modello viene caricato?
Un sistema fragile fallirebbe l’intero caricamento con un errore bloccante. Un sistema resiliente dovrebbe invece accettare comunque il caricamento del file, magari rinunciando temporaneamente alla compressione o alla cache ottimizzata, con un avviso esplicito registrato nei log, e recuperare automaticamente la funzionalità completa al primo utilizzo successivo in cui la libreria torna disponibile, invece di lasciare l’utente senza alcuna possibilità di procedere nel frattempo.
Come si comporta un sistema ben progettato quando la configurazione dei metadati non è perfettamente allineata allo schema fisico del database?
È una situazione più comune di quanto si pensi in un sistema config-driven come quelli descritti in questa serie: un campo di metadati che fa riferimento a una colonna del database non ancora creata, magari perché una migrazione non è ancora stata eseguita in un determinato ambiente, o perché una configurazione è stata importata da un contesto diverso.
In questo scenario un sistema fragile genera un errore SQL fatale che blocca l’intera schermata, spesso in modo poco comprensibile per chi non ha accesso al codice sorgente. Un sistema resiliente invece rileva questa condizione e si comporta in modo controllato – ignorando il campo problematico, segnalandolo in modo esplicito, ma lasciando funzionante tutto il resto della schermata – così che un singolo disallineamento di configurazione non comprometta l’intera esperienza operativa di chi sta semplicemente cercando di consultare un elenco di dati che, per il resto, sono perfettamente validi.
Perchè supportare più motori di database contemporaneamente?
Un sistema capace di funzionare sia su un motore di database open source ampiamente diffuso sia su un motore commerciale più consolidato in determinati contesti enterprise, isolando le differenze di dialetto SQL in un unico punto dell’architettura, offre un ulteriore livello di resilienza organizzativa, distinto da quella puramente tecnica di cui ho parlato finora: un’organizzazione non resta vincolata a un’unica scelta di infrastruttura di database, e può orientare questa decisione in base a criteri propri – competenze interne già disponibili, accordi di licenza preesistenti, policy IT consolidate – senza che questa scelta comprometta la disponibilità dell’intero sistema di facility management.
Perché la resilienza tecnica è, in ultima analisi, anche una forma di rispetto per chi usa il sistema ogni giorno sul campo?
Un tecnico che sta cercando di consultare un dato critico durante un intervento urgente, magari con una connessione instabile e poco tempo a disposizione, non dovrebbe mai trovarsi di fronte a un errore generico e incomprensibile causato da un componente accessorio del sistema non disponibile in quel momento. La resilienza tecnica, vista da questa prospettiva, non è solo un principio di ingegneria del software astratto: è una forma di attenzione concreta verso chi, sul campo, ha bisogno che lo strumento funzioni comunque, anche quando le condizioni non sono ideali.
Come misura l’affidabilità del proprio investimento software il proprietario ?
Un sistema che non si interrompe mai per intero, ma degrada in modo controllato e recupera automaticamente la piena funzionalità non appena le condizioni tornano normali, costruisce nel tempo una percezione di affidabilità che va oltre le prestazioni misurate in laboratorio: è l’esperienza cumulativa di anni di utilizzo senza interruzioni traumatiche a determinare se un proprietario considera il proprio investimento software solido o fragile, e questa percezione si costruisce proprio nei momenti di stress del sistema, non in quelli di funzionamento ordinario.
Conclusioni
Progettare per la resilienza significa distinguere fin dall’architettura cosa è davvero critico da cosa è accessorio, prevedere fallback trasparenti per ogni componente opzionale, e trattare le condizioni impreviste – una libreria assente, una configurazione disallineata, un servizio esterno irraggiungibile – come situazioni da gestire con eleganza, non come eccezioni che giustificano un errore fatale.
Con questo si chiude il capitolo dedicato a intelligenza artificiale e osservabilità: nel prossimo articolo affrontiamo un tema che riassume in parte tutti quelli tecnici visti finora, cosa succede davvero quando un sistema di questo tipo incontra la scala reale di un patrimonio con migliaia di asset.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui