«Come gestiamo sistemi troppo grandi e complessi per essere compresi e controllati, e che falliscono in modo inatteso?» Tweet this

Una notizia di non molti giorni fa è che il tribunale di Oklahoma City ha condannato la Toyota a risarcire un cliente perché secondo quanto è emerso dalle indagini l’incidente in cui si è trovato coinvolto è stato provocato da un bug del software dell’auto.
Ciò che colpisce è che una giuria per la prima volta abbia sottolineato come un bug possa causare non soltanto dei piccoli problemi o dei gravi danni finanziari, ma addirittura essere responsabile di una vita umana.
Come dovremmo valutare l’accaduto se da un semplice bug di un auto cominciassimo a riflettere sulla complessità di un mondo che si avvia ad un estrema automatizzazione, all’internet delle cose?

Consideriamo ad esempio il progetto di Google, ormai già in fase avanzata di prototipo, delle auto che si guidano da sole.
Queste auto si suppone siano intrinsecamente più sicure rispetto a quelle attuali, dal momento che viene eliminata la variabile dell’errore umano.

Ma cosa succede se il sistema che governa l’auto va completamente in blocco, se all’improvviso si smette di ricevere i dati sui semafori o se il navigatore dice all’auto di gettarsi giù da un ponte?

Lo sviluppo dei software ha raggiunto uno stadio di complessità in cui non è possibile controllarne tutti gli aspetti, quindi come facciamo a gestire sistemi troppo grandi per essere compresi completamente, troppo complessi da controllare e che spesso falliscono in modo imprevedibile?

Comprendere il fallimento

Come ci spiega la teoria sul calcolo distribuito, i sistemi distribuiti falliscono spesso e quando lo fanno questo non avviene mai per il fallimento di tutto il sistema, ma solo di alcuni dei suoi molteplici componenti.
Questi errori oltre a essere difficilmente diagnosticabili e prevedibili non sono facilmente riproducibili per eseguire dei test.
La soluzione al problema non può essere unica, è possibile aumentare i test di rilascio o l’integrazione continua, ma non basta.

Occorre ammettere che malfunzionamenti del software come accaduto alla Toyota si possono verificare facilmente, che i nostri sistemi possono fallire in molte maniere inaspettate. Ciò che va cambiato è il nostro modo di pensare ai sistemi che costruiamo e a quelli che già adoperiamo.

Pensare globalmente

Siamo passati dallo sviluppare codice destinato ad essere eseguito su singoli pc a software distribuiti in cloud, che è come un sistema vivente in continua evoluzione.
Dobbiamo partire dal presupposto che il sistema su cui gira il nostro codice sicuramente fallirà in qualche punto e dobbiamo adattare il nostro modo di scrivere codice cercando di immaginare come e dove potrà fallire.
In un ambiente in cui non è possibile prevedere i bug e testare ogni singolo aspetto dei sistemi che creiamo, il continuo monitoraggio dell’applicazione rappresenta l’unico modo per cercare di evitare e se possibile prevedere malfunzionamenti.

I Dati come lingua

Analizzare i dati post problema per cercarne la causa non è un buon modo di procedere in un ambiente distribuito, nel quale i bug spesso non sono riproducibili ma sono dovuti ad una serie di micro cause. Non è così che possiamo raggiungere l’obiettivo.
Chi fa codice deve monitorare continuamente attraverso i dati l’andamento dell’applicazione con lo scopo di creare un sistema che si allerti e ci informi immediatamente al presentarsi del problema.

Il fattore umano

Siamo parti integranti dei sistemi che costruiamo e adoperiamo, e ne influenziamo profondamente il funzionamento.
Condizionati da una cultura poco incline al rischio, nel tentativo di evitare malfunzionamenti cerchiamo di creare sistemi dei quali abbiamo il massimo controllo, inserendo righe su righe di codice che però li appesantiscono, li rendono poco robusti e invece di proteggerli fanno aumentare le possibilità di ulteriori errori.

Quando questo accade si parte all’affannosa ricerca del colpevole, della causa scatenante e di un modo per evitare che si ripeta di nuovo il problema.
Di solito però questo si traduce in altri controlli che rendono il sistema via via sempre più fragile.
La verità è sempre la stessa: che non c’è una ragione sola perché i sistemi falliscono, ma una serie di micro cause ne producono il crollo.
Gli strumenti e le metodologie che abbiamo adoperato fino a poco tempo fa si sono sgretolate e vanno quindi ricercati nuovi modelli per la creazione, la distribuzione e la manutenzione del software.

Per saperne di più: Everything is distributed