Il software che si cura da solo, per un futuro più affidabile

A luglio 2024 improvvisamente il mondo si fermò – voli cancellati, treni fermi, media bloccati, banche e piazze finanziarie in tilt… – a causa di una panne informatica globale, dimostrando, se mai ce ne fosse bisogno, la nostra dipendenza dal digitale. La colpa fu di un bug nell’aggiornamento di CrowdStrike, società statunitense di sicurezza informatica con più di 20’000 abbonati, che colpì i sistemi operativi di Microsoft con effetti a catena in tutto il mondo.

Anche per evitare episodi come questo, gli informatici stanno studiando come sviluppare non tanto sistemi senza errori, ma software adattivi che abbiano la capacità di evitarli e di autocorreggersi in modo più o meno autonomo. Tra coloro i quali stanno lavorando a questo obiettivo vi è Mauro Pezzè, Professore di ingegneria del software presso la Facoltà di scienze informatiche dell’Università della Svizzera italiana e all’Università di Milano Bicocca.

Professor Pezzè, partiamo dal caso dell’estate scorsa: come può un aggiornamento mandare in tilt il mondo?

Il software è di gran lunga il prodotto umano più complesso. Windows, ad esempio, conta circa 50 milioni di linee di codice. Ormai siamo arrivati a una dimensione tale per cui non è più possibile per una singola mente umana vedere il sistema nella sua complessità, quindi è necessario creare un team composto da persone con più competenze diversificate. Quando si trova un difetto lo si corregge toccando solo quell’elemento, che deve essere integrato alla perfezione, altrimenti succede un disastro. Windows è fatto bene, però ha quasi 40 anni: quando lo usiamo è come se volassimo su un Boeing 747 degli anni 80, quando lo ripariamo pure.

Se non vi è una visione di insieme, non vi sono problemi di conoscenza?

Certo. È per questo che qui all’Usi non insegniamo la sola programmazione, ma anche l’astrazione, ossia la capacità di cogliere la complessità e l’unicità del sistema al di là dei dettagli. Una capacità caratteristica dell’essere umano.

Esiste un software senza errori?

Qualunque prodotto umano che abbia una certa complessità non può essere esente da errori. Ho scritto un libro, l’ho riletto attentamente e ad alta voce parola per parola, l’ha corretto un editor, è stato controllato in pre-stampa, eppure contiene ancora errori. E stiamo parlando di un oggetto di una complessità infinitamente inferiore a un software.

Se da qualche parte il software o l’algoritmo contengono un errore, non si rischia di continuare a replicarlo?

Assolutamente sì. Il software commette errori quanto l’essere umano, ma lavora in modo diverso, quindi commette errori diversi. Perché il software non è intelligente, perlomeno non nel senso umano del termine. È comunque un’opportunità per poter lavorare meglio, per fare cose che altrimenti non saremmo in grado di fare o faremmo in un tempo quasi infinito.

Noi umani però, quando commettiamo errori, ce ne possiamo accorgere e possiamo correggerli. Il software no…

Appunto per questo all’Usi stiamo lavorando a quello che chiamano ‘self-healing software system’, un sistema in cui il software si autocorregge. È importante che il software sia sempre sotto il nostro controllo, oltre che usato in modo intelligente. Faccio un esempio. Nessuno costruisce un edificio perché bruci, ma, nonostante ciò, un incendio è sempre possibile, per cui abbiamo inventato dei sistemi per rilevare il fuoco e fermarlo prima che si propaghi. In informatica idem: progettiamo il sistema affinché non possa verificarsi un cortocircuito generale.

Quindi non correggiamo l’errore, bensì ne blocchiamo le conseguenze…

Ci sono due linee di ricerca: alcuni ricercatori studiano sistemi per correggere automaticamente l’errore, anche se in realtà suggeriscono correzioni al programmatore in modo che questi possa risolvere. Altri invece, come noi, cercano di prevedere e prevenirlo, perché l’errore non si può eliminare.

E questi sistemi funzionano?

Funzionano così come funzionano i sistemi antincendio: non è che oggi non ci siano più incendi, però ce ne sono molti di meno rispetto al secolo scorso e a quanti ce ne sono nei Paesi meno attenti alla prevenzione. Per cui possiamo dire che sì, funzionano bene anche se non in modo ottimale. Naturalmente l’autoadattività rispetto ai sistemi antincendio ha una storia molto più breve, per cui deve ancora maturare, ma senza questa avremmo avuto una quantità di bug maggiore rispetto a quella che abbiamo oggi.

Arriveremo mai a un software in grado di non fare errori?

Se distinguiamo tra errore e affidabilità ci siamo già: non possiamo garantire che il ponte non crolli, non possiamo garantire che l’aereo non cada, ma possiamo garantire un certo grado di affidabilità, che significa appunto che il software è pensato per prevenire eventuali errori. Esempio banale: quando l’aereo atterra si spegne e si riaccende. Che senso ha? Un uomo al casello non spegne e riaccende l’auto, giusto? Il punto è che se io so che prima o poi si verificherà un errore, ma so anche che questo non accadrà prima di un determinato tempo (poniamo 24 ore), ogni volta che atterro resetto il sistema e ricomincio il conteggio. Si chiama ‘mean time between failure’, il tempo medio tra due fallimenti successivi: nessuno può garantire che un software non commetta errori, ma si può garantire che un software abbia un funzionamento affidabile per un tempo sufficiente.

E al passo successivo, un software intelligente o para-intelligente, che sia non solo autoadattivo ma che si autoripari, è possibile arrivare?

Sì e no. Arriveremo a un software che si autoripara, questo sicuramente. Sulla parola intelligente, per contro, dovremmo invece discuterne. Noi esseri umani siamo in grado di proteggerci da certi errori grossolani perché riusciamo a valutare se una cosa abbia senso. Il software no. Per questo oggi, nonostante tutti i progressi, siamo ancora costretti a scrivere in un linguaggio rigoroso, perché poi è interpretato in modo rigoroso. Il linguaggio naturale è ambiguo, il linguaggio di programmazione è preciso.

Scriveremo ancora i programmi?

Le competenze si sposteranno sempre più dalla scrittura al testing del programma. Quando ho cominciato la mia carriera, si diceva che il testing lo effettuavano quelli che non sapevano programmare; oggi chi fa l’ingegnere software fa molti test, perché siamo passati dalla difficoltà di programmare alla difficoltà di verificare la correttezza del programma. Con ogni probabilità avverrà un profondo cambiamento: anziché avere un programmatore che scrive il codice, lo farà una macchina che qualcuno controllerà.

Lo capiremo?

Probabilmente no, come non capiamo molte cose complesse. Nessun ingegnere conosce tutti i dettagli di un’automobile o di un aereo, nessun linguista tutto il vocabolario italiano, però un uomo di media intelligenza e di media cultura è in grado di decrittare un testo, a dipendenza del livello in maniera più o meno corretta e profonda. David Parnas, uno studioso che ha fatto la storia dell’ingegneria del software e che ha ricevuto un dottorato honoris causa all’Usi nel 2009, afferma che l’ingegneria del software è una disciplina che richiede il lavoro di più persone: un programmatore riesce a leggere e a comprendere il funzionamento anche di migliaia di linee di codice, ma non è in grado di esaminare in un tempo finito un software della dimensione di quelli odierni.

Macchine e uomini parlano due linguaggi diversi o simili?

Il linguaggio di programmazione è scritto affinché la macchina capisca non il senso della cosa ma come effettuarla, quindi è un linguaggio che non è intuitivo. Forse un giorno la macchina comincerà a comprendere i termini del vocabolario, per cui capirà le parole non più come un ordine di lavoro ma come un’entità in sé, un concetto che poi applicherà.

Quindi avrà un’evoluzione semantica?

Probabilmente.

Lei ha spiegato che all’Usi non insegnate agli studenti solo la programmazione, bensì pure l’astrazione. Alla luce delle ultime affermazioni, questo cosa significa?

Significa insegnare il linguaggio di programmazione non come fine, ma come mezzo. Io non posso insegnare a scrivere una poesia, però posso insegnare come utilizzare la lingua per scrivere una poesia. Quello che cerchiamo di insegnare qui non è solo l’uso del linguaggio, ma come andare al di là; insegniamo diversi linguaggi di programmazione non solo perché la ricchezza linguistica è importante, ma perché dà modo di capire quale concetto di programmazione sottendono, in modo da poter comunicare nel miglior modo possibile con la macchina. Un self-healing system ha quattro componenti fondamentali: deve monitorare il sistema, capire cosa fa, predire o interpretare e infine attuare. Noi, in collaborazione con altri istituti di ricerca, in questo momento stiamo lavorando al secondo, ossia quali dati ci servono e come possiamo usarli per prevedere un errore. Andrò a breve in Svezia a un workshop a inviti in cui presenterò i nostri risultati sulla predizione di malfunzionamenti nei cloud dinamici.

Vi sono altri campi di ricerca?

L’altra cosa che facciamo è l’‘automatic workaround’ (soluzioni alternative automatiche), un’idea che secondo me ha un futuro promettente. Si tratta, quando si identifica un errore, di dire al software di trovare – in modo appunto automatico – un pezzo di codice equivalente che sia in grado di fare la stessa cosa di quella che non funziona. Per ora lo abbiamo provato su Google Maps, con buoni risultati.

Una rubrica a cura di