8 grandi fallimenti IT del 2023

Dai file di database danneggiati, all’uso improprio dell’intelligenza artificiale generativa: alcuni disastri informatici di alto profilo che, nel corso di quest’anno, hanno causato danni reali. Che servano da monito.

L’IT fornisce le tubature a quasi tutte le aziende esistenti. Nella maggior parte dei casi, funzionano bene ma, quando qualcosa va storto, può essere più imbarazzante (e più costoso) del più disastroso allagamento del bagno.

Abbiamo raccolto otto casi di grandi fallimenti tecnologici che hanno colpito aziende e altre organizzazioni nel 2023. Naturalmente, ogni problema è un momento di insegnamento, e ci auguriamo che questi disastri possano servire da ammonimento mentre cercate di gestire i vostri potenziali problemi informatici nel 2024.

Problemi tecnici nei cieli

Il settore delle compagnie aeree ha tutti gli elementi necessari per produrre storie di orrore informatico davvero terribili: è dominato da aziende enormi e da grandi burocrazie governative, e richiede un coordinamento quasi perfetto di migliaia di aeromobili e milioni di passeggeri, dove qualsiasi ritardo può causare guasti a cascata che portano a ritardi o, addirittura, peggio. Poiché le aziende storiche esistono da tanto tempo, molte di esse gestiscono sistemi informatici con alcuni elementi vecchi di anni o decenni. Onestamente, è un miracolo che il sistema funzioni. Sia la United Airlines [in inglese] che la Hawaiian Airlines [in inglese] hanno subito interruzioni di servizio nel 2023 a causa di aggiornamenti software non funzionanti, mentre la Southwest ha concluso l’anno precedente con un tracollo dei viaggi di Natale [in inglese], imputato a sistemi obsoleti.

Probabilmente il peggior disastro informatico delle compagnie aeree del 2023 si è però verificato sul versante governativo. La FAA gestisce un database chiamato Notice to Air Missions (NOTAM) che fornisce una fonte automatizzata e centralizzata di informazioni su questioni come le piste chiuse o le interruzioni delle attrezzature nei vari aeroporti, o i pericoli lungo le varie rotte. L’11 gennaio il NOTAM è andato in tilt, causando un “ground stop” a livello nazionale che ha bloccato tutti i decolli [in inglese], anche se gli aerei in volo hanno potuto proseguire verso le loro destinazioni.

L’interruzione è stata ricondotta a un file di database danneggiato; un appaltatore stava lavorando per correggere un problema di sincronizzazione tra i database live e quelli di backup e ha finito per corromperli entrambi [in inglese]. L’ingegnere ha “sostituito un file con un altro” in un “onesto errore che è costato milioni al Paese” [in inglese], e l’incidente ha portato con sé alcune ovvie lezioni per assicurare che i dati critici siano sottoposti a un backup ridondante, soprattutto se si ha intenzione di armeggiare con questo genere di sistema.

Il fragile processo di backup della NYSE

La FAA non è stata l’unica organizzazione a scoprire che il suo processo di backup, che dovrebbe aiutare a evitare un disastro, ne ha generato uno a sua volta. Anche la Borsa di New York ha affrontato una crisi simile a gennaio. Il NYSE ha saggiamente collocato i suoi server di backup a Chicago, a centinaia di chilometri di distanza da Wall Street, per fungere da locazione alternativa dei dati nel caso in cui una crisi colpisca la parte bassa di Manhattan; un po’ meno saggiamente, il suo backup giornaliero si basa su un processo in cui i dipendenti devono fisicamente accendere e spegnere i sistemi al momento opportuno.

Avviare e arrestare i processi digitali ogni giorno alla stessa ora è infatti un’operazione che i computer sanno fare piuttosto bene e che le persone tendono a sbagliare di tanto in tanto, per cui era forse inevitabile che si verificasse una crisi. E così è stato il 24 gennaio, quando un dipendente di Chicago non ha spento il server di backup al momento giusto [in inglese]. Di conseguenza, quando le contrattazioni sono iniziate a New York alle 9:30, i computer del NYSE hanno pensato di continuare la sessione di trading del giorno precedente e hanno ignorato le aste di apertura del giorno, che dovrebbero fissare i prezzi iniziali di molti titoli. Il risultato è stato una serie di violente oscillazioni del mercato e numerose transazioni a prezzi errati che hanno dovuto essere annullate con grandi spese. La lezione: mai mandare un umano a fare il lavoro di un computer, soprattutto se il lavoro del computer è piuttosto semplice.

Nello spazio, nessuno può cancellare la vostra licenza software

La NASA è una meraviglia scientifica che svolge ogni sorta di attività spaziale interessante e stimolante; è anche una tentacolare burocrazia governativa con migliaia di dipendenti e sistemi informatici sotto il suo ombrello. Purtroppo, è più difficile per l’agenzia tenere traccia di tutti quei computer che dei detriti spaziali. Uno studio dell’OIG di quest’anno [in inglese] si è concentrato sulle numerose licenze che la NASA ha acquistato per i prodotti Oracle a supporto del programma Space Shuttle, terminato più di dieci anni fa; di conseguenza, non solo l’agenzia è vincolata alla tecnologia Oracle, ma gli scarsi processi di documentazione fanno sì che la NASA non sia davvero sicura di quanti di questi sistemi Oracle stia effettivamente utilizzando. Di conseguenza, negli ultimi tre anni l’agenzia ha speso 15 milioni di dollari per un software che forse non sta usando, ma non ha voluto rischiare una sua revisione da parte di Oracle che potrebbe concludersi con un bilancio ancora più costoso.

La soluzione a problemi come questo è l’implementazione di un programma di gestione delle risorse software che vi aiuti a capire esattamente quale software state utilizzando e quali licenze vi servono o non vi servono. La buona notizia è che il governo federale degli Stati Uniti ha imposto ad agenzie come la NASA di implementare tali programmi; la cattiva notizia è che, secondo il rapporto dell’OIG, “gli sforzi per implementare un programma di gestione delle risorse software a livello aziendale sono stati ostacolati sia da problemi di budget e di personale, sia dalla complessità e dal volume degli accordi di licenza software dell’agenzia”.

La situazione delle licenze software è confusa

Se la NASA è l’esempio di un’agenzia governativa troppo cauta che paga per un software che potrebbe non utilizzare, il fornitore di servizi cloud Nutanix è stato scosso da uno scandalo lo scorso maggio, quando è emerso che l’azienda stava adottando l’approccio opposto alle licenze software. Nello specifico, Nutanix utilizzava software di terze parti in modo “non conforme” [in inglese], che è un modo eufemistico per dire “senza pagarlo, anche se avrebbe dovuto”.

L’azienda ha utilizzato software di due fornitori diversi per “test di interoperabilità, validazione e proof of concept per i clienti, formazione e assistenza per i clienti”. Sfortunatamente, tutto ciò è avvenuto utilizzando versioni del software contrassegnate solo a scopo di valutazione, un processo che, però, è durato anni. Il problema è stato scoperto da una revisione interna e, poiché i fornitori dovevano essere pagati per l’uso non conforme, Nutanix non è stata in grado di presentare la relazione trimestrale sugli utili alla SEC in tempo perché stava cercando di capire quanto doveva. L’errore ha portato all’abbandono dell’azienda da parte del CIO [in inglese], la cui lezione è, forse, che l’unica cosa peggiore del pagare per un software che non si usa è non pagare per un software che si usa.

Spegnere le luci, la festa è finita

La prossima storia è, tecnicamente, un fallimento informatico che risale al 2021, ma la includiamo nella carrellata di quest’anno perché è stata risolta nel 2023. Per quasi 10 anni, la Minnechaug Regional High School del Massachusetts ha gestito felicemente un sistema di “illuminazione verde” installato dalla 5th Light che regolava automaticamente le luci all’interno e all’esterno della scuola in base alle necessità. Ma, nell’agosto del 2021, insegnanti e studenti hanno notato che le luci rimanevano continuamente accese alla massima luminosità [in inglese]. Si scoprì che il sistema era stato colpito da un malware [in inglese] ed era entrato in una modalità di ripiego in cui le luci non si spegnevano mai.

Ne è seguita una serie di scoperte sconfortanti, che offrono lezioni a chiunque pensi di affidarsi interamente al software per controllare le cose nel mondo reale e fisico. Il sistema di illuminazione high-tech non aveva interruttori manuali che potessero essere semplicemente accesi e spenti, e il software era integrato in altri sistemi scolastici e non poteva essere facilmente sostituito. Il fornitore originale non esisteva più e l’IP era stato comprato e venduto più volte; ci sono volute settimane perché il nuovo proprietario, una società chiamata Reflex Lighting, riuscisse a rintracciare qualcuno che capisse come funzionava il sistema della scuola. Alla fine è stato messo a punto un piano di riparazione, ma a quel punto le interruzioni della supply chain successive al blocco del COVID hanno fatto sì che ci volessero mesi prima che le nuove apparecchiature potessero essere spedite dalla Cina al Massachusetts.

Infine, dopo quasi 18 mesi in cui le luci sono rimaste accese ininterrottamente (e di tanto in tanto le lampadine venivano avvitate a mano secondo le necessità), quest’anno il sistema è stato aggiornato – e sì, è dotato dell’interruttore fisico di accensione e spegnimento che, probabilmente, avrebbe dovuto essere presente fin dall’inizio.

Quando un incidente è un vero incidente

La storia della Minnechaug Regional High School è un buon esempio del perché i dispositivi meccanici del mondo reale non sempre si combinano bene con il software. Ma anche l’ingegneria meccanica ed elettrica non è esente da problemi e, a volte, il software può essere d’aiuto. Prendiamo l’esempio dell’MRH-90 Taipan, un elicottero militare utilizzato in Australia; nel 2010 si è verificato un guasto “catastrofico” al motore quando un pilota ha tentato il cosiddetto “avviamento a caldo”, ossia lo spegnimento e il successivo riavvio del motore a metà missione. Il problema meccanico è stato risolto dal software stesso [in inglese]: l’Australian Defence Force ha distribuito una patch per impedire l’avviamento a caldo dell’elicottero.

Purtroppo, la prima regola delle patch software è che funzionano solo se vengono effettivamente distribuite e, nonostante, quella della fattispecie fosse disponibile da quasi un decennio, non è stata installata su tutti i Taipan australiani, causando un avviamento a caldo che ha portato, lo scorso aprile, a un incidente dell’elicottero durante una missione di addestramento [in inglese].

Guasti telefonici a cascata in Australia

L’Australia è stata teatro di un altro guasto informatico di alto profilo, lo scorso novembre, quando Optus, il secondo provider di telecomunicazioni del Paese, è andato in tilt per 12 ore, lasciando metà degli australiani senza telefono o connettività Internet. Il guasto è stato ricondotto alle modifiche di routing inviate da Singtel [in inglese], la società con sede a Singapore proprietaria di Optus; a quanto pare, l’ondata di dati è stata tale da sovraccaricare i router di Optus, che hanno dovuto essere fisicamente riavviati, cosa che ha richiesto molto tempo, date le dimensioni dell’Australia.

Il problema di essere un fornitore di servizi di importanza nazionale è che quando si verifica un guasto informatico di alto profilo, i dirigenti vengono trascinati davanti al Parlamento nazionale per spiegare cosa è andato storto [in inglese], e di certo non aiuta se si dice ai legislatori che il problema era così diffuso e inaspettato che non si aveva un piano per affrontarlo, e che il proprio amministratore delegato porta con sé schede SIM di operatori rivali per assicurarsi di poter continuare a telefonare se l’operatore di cui era responsabile fosse crollato. Forse non sorprende che Kelly Bayer Rosmarin, l’amministratore delegato di Optus, abbia lasciato l’azienda poco dopo. (La lezione dell’enorme interruzione di Optus [in inglese], supponiamo, è di avere un piano di emergenza per tutti i tipi di disastri e di configurare correttamente i router).

Intelligenza artificiale, un vero fallimento

Dal momento che il 2023 è stato l’anno in cui l’intelligenza artificiale generativa è diventata mainstream [in inglese], concluderemo questo elenco con un paio di disastri dell’intelligenza artificiale, anch’essi di alto profilo. In uno dei casi più eclatanti, gli avvocati dello studio Levidow, Levidow & Oberman si sono rivolti a ChatGPT per farsi aiutare nella stesura di memorie legali relative a un loro cliente che ha fatto causa a una compagnia aerea per un infortunio personale. Sfortunatamente per loro e per il loro cliente, ChatGPT ha fatto ciò per cui sta diventando sempre più noto: produrre un documento estremamente plausibile che includeva una serie di errori fattuali [in inglese], tra cui citazioni di molteplici casi giudiziari che non esistevano (una “hallucination”, nel gergo dell’AI). L’avvocato Steven A. Schwartz ha ammesso al giudice che questo era il suo primo utilizzo di ChatGPT per scopi professionali e che “non era consapevole della possibilità che il suo contenuto potesse essere falso”. A sua difesa, aveva chiesto a ChatGPT se le sue citazioni fossero false [in inglese], e il chatbot aveva insistito che potevano “essere trovate in database legali affidabili come LexisNexis e Westlaw”. (Questo non si è rivelato vero).

I fallimenti dell’intelligenza artificiale hanno colpito anche il mondo del giornalismo tecnologico: CNET è stata costretta a ritrattare più di 35 articoli [in inglese] scritti con l’aiuto di uno strumento chiamato Responsible AI Machine Partner, o RAMP. I risultati poco “responsabili” non solo hanno lasciato l’azienda con le uova nel paniere, ma hanno anche provocato una reazione da parte dei suoi lavoratori [in inglese]. La lezione è che l’IA è come qualsiasi altro strumento informatico e non dovrebbe essere usata se non si capisce come funziona o se, nel caso specifico, è ancora a metà.

SUBSCRIBE TO OUR NEWSLETTER