Innovazione con sistemi critici per la vita

Ogni azienda dispone di un'infrastruttura "critica". In genere, ciò significa che se il sistema va offline, parti (o tutta) dell'attività si fermeranno fino a quando i tecnici non riusciranno a farlo funzionare di nuovo. Ciò si verifica spesso quando sono necessari aggiornamenti software, hardware o di rete di grandi dimensioni: i sistemi appena distribuiti contengono bug imprevisti che causano un errore di sistema, oppure gli utenti commettono errori con il nuovo sistema perché non hanno familiarità con esso e la produttività si interrompe finché i tecnici non possono risolvere i bug di distribuzione o addestrare gli utenti. Per la maggior parte, un periodo di fermo macchina o ridotta produttività è un rischio accettabile in cambio della promessa di prestazioni ed efficienza migliorate della nuova tecnologia, ma ciò non è universale. La maggior parte delle aziende può permettersi una certa quantità di tempi di inattività senza rischiare molte entrate o inimicarsi i propri clienti.

Ma cosa succede quando i sistemi che devi modificare sono sistemi vitali, in cui la sicurezza della vita dipende dall'essere in grado di utilizzare il sistema in modo affidabile?

Questo articolo si allontana dallo sviluppo software più tradizionale su cui dedichiamo la maggior parte del nostro tempo e, invece, dà uno sguardo all'elemento umano nei sistemi critici per la vita. I miei pensieri su questo argomento derivano dalla mia esperienza come Direttore dell'Information Technology per un servizio di ambulanza dei servizi di emergenza sanitaria, come specialista in tecnologia per un'organizzazione internazionale di risposta ai disastri umanitari e con il mio dottorato di ricerca. in Human Systems Integration completato presso il Massachusetts Institute of Technology.

Prima di iniziare, vorrei spiegare perché questo potrebbe essere rilevante per te. Anche se potrebbe non essere ovvio che il tuo progetto coinvolga effettivamente un sistema critico per la vita, è molto più probabile di quanto potresti pensare. Tutti i seguenti requisiti, oltre a innumerevoli altri argomenti:

• Settore automobilistico. Lavori a un progetto con un produttore di veicoli o uno qualsiasi dei suoi fornitori? Reclutato fuori dall'università da una startup di auto a guida autonoma? Frenata automatica, controllo della velocità di crociera, controllo della corsia, visione artificiale, riconoscimento degli ostacoli, moduli elettronici di controllo del motore, ecc. Ognuno di questi è un sistema critico per la vita, in cui un guasto può essere fatale.
• Aviazione. Quando sei a 30.000 piedi in aria, quasi tutti i guasti del sistema possono essere critici per la vita. Considerando gli eventi recenti con il Boeing 737 MAX, ci sono gli ovvi sistemi critici per la vita di pilota automatico e controllo di volo computerizzato, ma ci sono anche molte cose a cui potresti non pensare. A casa, se la ventola del tuo sistema HVAC si guasta e produce un po' di fumo, apri la finestra o esci per prendere una boccata d'aria fresca. Hai mai provato ad aprire la finestra e ad uscire fuori durante un volo transatlantico? Anche il più semplice dei sistemi, dalle prese di corrente nella cucina ai freni sulle ruote del carrello delle bevande, può essere vitale sugli aerei.
• Comunicazioni. La maggior parte degli sviluppatori o ingegneri, a un certo punto della loro carriera, lavoreranno su un progetto di sistema di comunicazione in un modo o nell'altro. Per molte persone, le telecomunicazioni inizialmente non sembrano fondamentali per la vita; dopo tutto, la civiltà è andata bene prima dei telefoni e di Internet. Come qualcuno che si è schierato in zone disastrate dove l'infrastruttura delle telecomunicazioni è stata distrutta, lascia che ti dica cosa succede effettivamente: le persone si ammalano gravemente o si feriscono e non possono chiamare i servizi di emergenza; i residenti anziani non possono chiamare i propri figli per chiedere loro di ritirare le ricette in farmacia; i soccorritori non possono comunicare con i loro operatori o tra di loro; e le persone che non possono contattare i propri familiari si preoccupano e si mettono in situazioni estremamente pericolose per cercare di trovarli. I sistemi di comunicazione sono assolutamente vitali.

Nel mondo odierno di forte dipendenza dalla tecnologia, progetti che non hai mai considerato nemmeno semi-importanti potrebbero finire per essere una componente vitale di un sistema vitale.

Ma se non è rotto, non aggiustarlo

Hai mai sentito o usato la parola “patrimonio” in relazione a un sistema tecnologico? È una parola forte, che evoca pensieri di tradizioni di lunga data, lignaggio e tempi difficili dell'antichità. Nel mondo dell'ingegneria, è usato per indicare progetti che esistono da molto tempo e che hanno dimostrato di funzionare in modo affidabile ed è spesso visto come una caratteristica desiderabile per ridurre i rischi. In realtà, è un eufemismo per la tecnologia arcaica che non è mai stata aggiornata a causa dell'avversione al rischio, ed è pervasivo nei settori in cui i guasti del sistema possono portare a terribili conseguenze.

C'è una buona ragione dietro questa affinità con il software e l'hardware del patrimonio. È noto che funziona, è improbabile che si verifichino bug sconosciuti e i suoi costi sono stabili e prevedibili. Un ottimo esempio è l'industria del volo spaziale: la navicella spaziale russa Soyuz ha lanciato astronauti nello spazio per oltre 50 anni con solo piccole revisioni durante quel periodo, e continua ad essere utilizzata perché è affidabile e sicura. Sfortunatamente, questo significa che è anche estremamente inefficiente rispetto ai design moderni: mentre la Soyuz costa alla NASA 81 milioni di dollari per posto per portare gli astronauti alla stazione spaziale utilizzando il suo hardware storico, SpaceX e Boeing dovrebbero offrire posti per 58 milioni di dollari ciascuno usando i loro moderni modelli di razzi.

È comprensibile che poche persone vogliano aggiornare vecchi sistemi che funzionano ancora; i dirigenti non vogliono correre il rischio, i tecnici non vogliono avere a che fare con il misterioso server nell'armadio con un tempo di attività di 12 anni e i clienti non vogliono dover imparare nuovi progetti. Sfortunatamente, c'è un punto di svolta tra la minimizzazione del rischio e il risparmio sui costi: i progetti del patrimonio dovranno essere aggiornati alla fine, anche in ambienti ad alto rischio .

Il resto di questo articolo copre alcuni dei passaggi più importanti nel processo quando i tuoi sistemi sono critici per la vita, come quelli utilizzati dai primi soccorritori, dalle unità militari o dagli aerei.

Convincere l'ottone

Secondo la mia esperienza, forse la fase più difficile del processo è convincere i decisori e le parti interessate che sono necessari aggiornamenti. I sistemi che operano in ambienti critici per la vita sono spesso governati da un'ampia regolamentazione legale e politica organizzativa, il che significa che devi convincerli che non dovrebbero solo correre il rischio e spendere soldi, ma che dovrebbero anche impegnarsi in ciò che potrebbe facilmente essere diverso anni di tagli burocratici. L'opposizione più forte che dovrai affrontare sarà probabilmente da parte del team legale, che illustrerà in dettagli strazianti la potenziale responsabilità a cui aprirai l'organizzazione introducendo nuove tecnologie. Hanno ragione: la responsabilità è un problema importante e se qualcosa si rompe e qualcuno si fa male o muore, potrebbe essere un enorme onere etico, reputazionale e finanziario.

Indipendentemente dal fatto che tu stia lavorando con una società Fortune 500 o con i vigili del fuoco volontari locali, si tratta sempre della stessa cosa: denaro. Le aziende non vogliono perderlo e le organizzazioni non profit non hanno molto con cui lavorare in primo luogo. L'unico modo affidabile che ho trovato per convincere la leadership di un'organizzazione a correre il rischio di cambiare un sistema vitale è dimostrare che, probabilisticamente, è più probabile che facciano/risparmino denaro che perderlo, o che possono ridurre la loro responsabilità modernizzando la loro tecnologia e migliorando la sicurezza.

Ciò significa che devi fare i conti. Qual è la probabilità che si verifichino tempi di inattività prolungati o futuri arresti anomali a causa di bug (basati su implementazioni precedenti nell'organizzazione o dati di altre organizzazioni)? Qual è l'impatto previsto in caso di guasto e quanto costerebbe? Al contrario, quali sono le prestazioni attese o i guadagni di affidabilità e quanto varrebbero? Se riesci a dimostrare che c'è un'alta probabilità che uscirai in vantaggio, ci sono buone probabilità che otterrai il via libera.

Non riguarda te

Potresti avere familiarità con la frase "da ingegneri, per ingegneri", un idioma che suggerisce che gli ingegneri hanno costruito qualcosa per essere utilizzato da persone con qualifiche simili alle loro. È un evento estremamente comune ed è stato uno dei principali fattori precipitanti per l'ascesa degli studi sull'usabilità dei computer all'inizio degli anni '90. Come ingegneri, abbiamo spesso modelli mentali diversi di come funzionano i sistemi tecnologici rispetto all'utente finale medio, portando a una tendenza a progettare sistemi partendo dal presupposto che l'utente finale sappia già come funzionano. Nei sistemi convenzionali, questo porta a errori e clienti insoddisfatti; nei sistemi vitali, può portare alla morte.

Si consideri il caso del volo Air France 447. Il 1 giugno 2009, l'Airbus A330 si trovava sull'Oceano Atlantico in rotta da Rio de Janeiro a Parigi. I cristalli di ghiaccio hanno ostruito i tubi di Pitot, causando incongruenze nelle misurazioni della velocità dell'aria. Il computer di volo ha disinserito l'autopilota, riconoscendo che non poteva pilotare in modo affidabile l'aereo stesso con dati di velocità errati. Si è quindi inserito in una modalità "inviluppo di volo esteso" , che ha consentito ai piloti di eseguire manovre che il computer normalmente non consentiva. Potete immaginare gli ingegneri che hanno costruito il sistema pensando “se l'autopilota si disinserisce, probabilmente è perché c'è una situazione in cui i piloti potrebbero aver bisogno di un controllo extra! "

Questo è il naturale filo di pensiero per gli ingegneri, che capiscono che tipo di cose potrebbero causare il disinnesto del pilota automatico. Per i piloti non è stato così. Hanno costretto l'aereo a una ripida salita verso l'alto, ignorando gli avvisi di "STALLO", fino a quando non ha perso tutta la velocità relativa ed è precipitato nell'oceano. Tutti i 228 passeggeri e l'equipaggio sono stati uccisi. Sebbene ci siano più idee sull'esatta motivazione delle loro azioni, la teoria prevalente è che i piloti presumevano che il computer di volo avrebbe impedito input di controllo che avrebbero bloccato l'aereo (che è vero per il normale inviluppo di volo) e non si sono resi conto che era passato alla modalità inviluppo esteso perché non condividevano il modello mentale degli ingegneri della logica che guidava le decisioni del computer.

Sebbene sia un percorso un po' tortuoso, questo ci porta al mio punto principale: le azioni che si desidera che gli utenti intraprendano in condizioni specifiche devono essere le azioni che sembrano naturali per l'utente .

Gli utenti possono essere istruiti a seguire procedure specifiche, ma semplicemente non ricorderanno sempre la cosa giusta da fare o capiranno cosa sta succedendo in condizioni di stress elevato. È tua responsabilità progettare software, controlli e interfacce in modo intuitivo che spinga gli utenti a voler intrinsecamente fare le cose che dovrebbero.

Ciò significa che è assolutamente fondamentale che gli utenti finali siano coinvolti in ogni singola fase del processo di progettazione e sviluppo. Non ci possono essere ipotesi su ciò che probabilmente faranno gli utenti; deve essere tutto basato sull'evidenza. Quando si progettano interfacce, è necessario condurre studi per determinare i modelli di pensiero che inducono negli utenti e adattarli secondo necessità. Quando si testano i nuovi sistemi, è necessario testarli con utenti reali in ambienti reali in condizioni realistiche. E sfortunatamente, quando modifichi i tuoi progetti, devi ripetere questi passaggi da capo.

Sebbene ogni sistema complesso sia unico, vorrei citare tre considerazioni di progettazione, in particolare, che dovrebbero essere applicate universalmente:

• I controlli dovrebbero essere rappresentativi delle azioni che invocano. Fortunatamente, questo è abbastanza comune, generalmente visto sotto forma di selezione di icone rilevanti per i pulsanti della GUI o forme rilevanti per i controlli fisici. I pulsanti "Nuovo file" utilizzano l'icona di un foglio di carta bianco e le leve del carrello di atterraggio negli aerei hanno una manopola a forma di ruota. Tuttavia, è facile diventare compiacenti. Perché vediamo ancora le icone del floppy disk da 3,5" per i pulsanti "Salva"? Qualcuno di età inferiore ai 25 anni sa cos'è un floppy disk? Continuiamo a usarlo perché pensiamo che sia rappresentativo, ma in realtà non lo è più. Richiede uno sforzo costante per garantire che le rappresentazioni dei controlli siano significative per gli utenti, ma è anche necessario e difficile bilanciarlo con la continuità.
• Se un sistema di allarme si rompe, deve essere rilevabile. Utilizziamo spesso spie luminose che si attivano in caso di problemi, come un indicatore rosso lampeggiante. È ottimo per attirare l'attenzione di un utente, ma cosa succede se la luce si brucia? Il veicolo spaziale utilizzato nelle missioni lunari Apollo aveva dozzine di spie luminose per tutti i tipi di sistemi, ma non funzionavano in modo convenzionale. Invece di illuminarsi quando c'era un problema, rimanevano accese quando tutto andava bene e si spegnevano quando c'era un problema. Ciò ha assicurato che una spia di avvertimento bruciata non avrebbe fatto perdere agli astronauti un errore di sistema potenzialmente fatale. Non sto dicendo che dovresti usare questo design, dal momento che le lampadine hanno fatto molta strada in termini di affidabilità dagli anni '60, ma dà un'idea di quanto debba essere approfondita parte della tua pianificazione. Quante volte un sistema è andato in crash ma non lo sapevi, perché la registrazione o le notifiche non funzionavano correttamente?
• Le transizioni di modalità devono essere ovvie per l'utente. Cosa succede se un Airbus A330 passa dalla modalità di controllo normale alla modalità di controllo avanzata senza che l'utente se ne accorga e improvvisamente l'aereo fa cose che l'utente non pensava di poter fare? Cosa succede se un'auto a guida autonoma disinserisce il pilota automatico, lasciando all'utente inaspettatamente il pieno controllo? Cosa succede quando c'è una transizione importante nella modalità o nella funzionalità che richiede un cambiamento immediato nelle azioni dell'utente, ma l'utente impiega uno o due minuti per capire cosa è appena successo? Sebbene in un sistema complesso possa essere necessaria una varietà di modalità operative, le modalità non possono passare senza preavviso, spiegazione e interazione con l'utente adeguati.

Portare fuori dal negozio i sistemi critici per la vita

In linea con le migliori pratiche del settore, una fase beta è fondamentale per l'implementazione di nuovi sistemi vitali. I test della tua nuova tecnologia potrebbero averti aiutato a correggere la maggior parte dei bug e dei problemi di usabilità, ma possono emergere pericoli nascosti quando deve essere utilizzata insieme ad altri sistemi in ambienti reali. Nella disciplina dell'ingegneria dei sistemi, questo è noto come "emergenza". Le proprietà emergenti sono "comportamenti imprevisti che derivano dall'interazione tra i componenti di un'applicazione e il loro ambiente" e per loro stessa natura sono essenzialmente impossibili da rilevare in un ambiente di laboratorio. Invitando un gruppo rappresentativo di utenti finali a provare il tuo nuovo sistema sotto un'attenta supervisione, molte di queste proprietà possono essere rilevate e valutate per le conseguenze negative che potrebbero apparire nella distribuzione su vasta scala.

Un altro argomento che emerge spesso nelle discussioni sull'architettura con i miei clienti è quello dell'implementazione graduale. Questa è la scelta tra sostituire gradualmente elementi di un sistema preesistente con elementi di uno nuovo fino a quando alla fine tutto viene sostituito e cambiare tutto in una volta. Ci sono pro e contro per ciascuno: un'implementazione graduale consente un graduale acclimatamento degli utenti al nuovo design, assicurando che le modifiche avvengano in quantità gestibili e gli utenti non siano sopraffatti; d'altra parte, può trascinare il processo per lunghi periodi e provocare uno stato di transizione costante. I rollout immediati sono utili in quanto "strappano il cerotto" e velocizzano le cose, ma gli improvvisi cambiamenti drastici possono sopraffare gli utenti.

Per i sistemi critici per la vita, ho scoperto che le implementazioni graduali sono generalmente più sicure, poiché consentono la valutazione incrementale dei singoli componenti in un ambiente di produzione e consentono reversioni più piccole se è necessario ripristinare qualcosa. Questo è qualcosa che deve essere valutato caso per caso, tuttavia.

Normalizzazione della Devianza

OK, quindi i tuoi test utente ti hanno aiutato a progettare un sistema intuitivo, la tua fase beta ha identificato problemi emergenti, il tuo lancio graduale ha permesso agli utenti di familiarizzare con il design e tutto funziona senza intoppi. Hai finito, vero? Sfortunatamente no.

I problemi con il tuo sistema sorgeranno inevitabilmente, non c'è modo di aggirarlo. Quando gli utenti incontrano questi problemi, spesso svilupperanno soluzioni alternative invece di segnalare il problema al team tecnico. Le soluzioni alternative diventeranno una pratica standard, condivisa come "suggerimenti" dai veterani ai principianti. La sociologa Diane Vaughan ha coniato una frase per descrivere questo fenomeno: "normalizzazione della devianza". Gli utenti diventano così abituati al comportamento deviante che non riescono a ricordare che è, in effetti, deviante.

L'esempio classico è lo Space Shuttle Challenger: si osservava regolarmente che un componente dei propulsori a razzo solido si erodeva durante il lancio, e sebbene tutti sapessero che l'erosione dei componenti dei razzi era una cosa negativa, succedeva così spesso che le deroghe venivano regolarmente emesse ed era considerato normale. Il 28 gennaio 1986, il problema che tutti inizialmente sapevano non doveva essere consentito, ma che si erano normalizzati, provocò l'esplosione del Challenger e la morte di sette astronauti.

In qualità di amministratore di un sistema vitale, spetta a te impedire che si verifichino tali eventi. Studia come i tuoi utenti interagiscono con il sistema. Ombreggiali per un paio di giorni e verifica se utilizzano soluzioni alternative impreviste. Invia periodicamente sondaggi per richiedere modifiche e miglioramenti suggeriti. Dedica tempo e impegno a migliorare il tuo sistema prima che i tuoi utenti trovino il modo di aggirare i problemi senza di te.

Allenamento per prestazioni sotto pressione

Accade spesso che i guasti nei sistemi vitali si verifichino quando gli utenti soffrono di stress, picchi di adrenalina e visione a tunnel. È successo ai piloti dell'Air France 447, è successo ai paramedici che non ricordano come far funzionare il cardiofrequenzimetro al loro primo paziente in arresto cardiaco, ed è successo ai soldati che non riescono a far funzionare correttamente le loro radio mentre sono sotto tiro.

Alcuni di questi rischi sono migliorati utilizzando design intuitivi come discusso in precedenza, ma questo da solo è insufficiente. Soprattutto negli ambienti in cui si verificano scenari di stress elevato ma si verificano raramente, è essenziale addestrare gli utenti non solo a come utilizzare il sistema, ma anche a pensare chiaramente in tali condizioni. Se gli utenti memorizzano le azioni relative alle apparecchiature operative, non possono far fronte a guasti imprevisti perché le azioni apprese potrebbero non essere più appropriate; se si allenano a pensare in modo logico e chiaro sotto stress, possono rispondere a circostanze mutevoli e aiutare il tuo sistema a rimanere in vita quando qualcosa si rompe.

Conclusione

Ovviamente, lo sviluppo, la distribuzione e la manutenzione del software vitale è molto più complesso di quanto possa essere descritto in dettaglio in un singolo articolo. Tuttavia, queste aree di considerazione possono aiutarti a darti un'idea migliore di cosa aspettarti quando stai pensando di lavorare su un progetto del genere. In sintesi:

• L'innovazione è necessaria, anche quando tutto funziona senza intoppi
• È difficile convincere i dirigenti che il rischio vale la pena, ma i numeri non mentono
• Gli utenti finali devono essere coinvolti in ogni fase del processo
• Testare e ripetere il test con utenti reali in ambienti reali in condizioni realistiche
• Non dare per scontato di aver capito bene la prima volta; anche se funziona, potrebbero esserci problemi non rilevati di cui i tuoi utenti non ti stanno parlando.
• Forma i tuoi utenti non solo su come utilizzare il sistema, ma anche su come pensare in modo chiaro e adattarsi sotto stress.

In conclusione, vorrei sottolineare che nei complessi sistemi critici per la sicurezza, le cose a un certo punto andranno storte, indipendentemente dalla pianificazione, dai test e dalla manutenzione che esegui. Quando quei sistemi sono critici per la vita, è del tutto possibile che un guasto possa portare alla perdita della vita o di un arto.

Nel caso in cui una simile tragedia si verifichi con qualcosa di cui sei responsabile, sarà un peso schiacciante sulla tua coscienza e probabilmente penserai che avresti potuto prevenirla se avessi prestato più attenzione o lavorato di più. Forse è vero, forse no, ma è impossibile prevedere ogni possibile accadimento.

Lavora meticolosamente, non essere presuntuoso e renderai il mondo un posto migliore.