Continue Reading

Esempi drammatici e banali di resilienza hanno incoraggiato la ricerca dell’ingegneria della resilienza. La possibilità di sfruttare o migliorare deliberatamente la resilienza è allettante. Ma cos’è esattamente l’ingegneria della resilienza?

Esistono almeno due formule possibili: in primo luogo, l’ingegneria che sfrutta ciò che sappiamo sui sistemi resilienti e, in secondo luogo, l’ingegneria che modella la resilienza stessa. L’osso è un utile esempio di resilienza e di entrambi i tipi di ingegneria della resilienza. L’esempio mostra come la resilienza e l’ingegneria della resilienza siano correlate e anche cosa potrebbe comportare l’ingegneria della resilienza in altri contesti.

Richard Cook è un medico, ricercatore ed educatore.
È coautore di “Operating at the Sharp End: The Complexity of Human Error”, “Adapting to New Technology in the Operating Room”, A Tale of Two Stories: Contrasting Views of Patient Safety, “Gaps in the Continuity of Care and Progress on Patient Safety” e “’Going Solid’: A Model of System Dynamics and Consequences for Patient Safety” oltre a numerosi capitoli di libri e altri scritti. Ha ricevuto nel 1999 il Peter Kiewit Memorial Award della Annenberg Foundation e nel 2001 la McGovern Medal for Medical Writing dell’American Medical Writers Association.

—

Per partecipare alla conversazione sull’ingegneria della resilienza nel settore tecnologico, twittate con l’hashtag #REdeployConf.

Per ulteriori informazioni su REdeploy, controlla https://re-deploy.io

________

Un’organizzazione resiliente si adatta efficacemente alle sorprese.

Qui usiamo la definizione proposta da David Woods. Prima di entrare più nel dettaglio sulla resilienza, è importante distinguerla da un concetto diverso che Woods chiama robustezza.

Quando parliamo di progettazione di sistemi ad alta disponibilità, di solito si parla di tecniche come ridondanza, tentativi, fallback e failover. Pensiamo a cosa potrebbe andare storto (ad esempio, guasto del server, partizione di rete) e progettiamo il nostro sistema per gestire con le adeguate garanzie queste situazioni.

Woods usa il termine robustness – robustezza – per riferirsi a sistemi progettati per gestire efficacemente modalità di guasto note.

La resilienza, d’altra parte, descrive quanto bene il sistema sia in grado di gestire problemi che non erano prevedibili dal progettista. Puoi pensare alla robustezza come alla capacità di affrontare bene le incognite conosciute e alla resilienza come alla capacità di affrontare bene le incognite sconosciute.

Quattro concetti per la resilienza e le implicazioni per il futuro dell’ingegneria della resilienza di Woods (originale:  Four concepts for resilience and the implications for the future of resilience engineering) discute quattro diversi usi comuni del termine resilienza. In particolare, descrive perché considera la robustezza un concetto diverso.
La resilienza è un verbo (originale: Resilience is a verb) è un altro documento su come Woods definisce la resilienza.

Questa è una guida introduttiva alla lettura sulla Resilience Engineering – ingegneria della resilienza.

I documenti chiave sono organizzati in temi:

Cambiare prospettiva su incidenti e sicurezza

L’ingegneria della resilienza come campo di studio è emersa dalla comunità scientifica della safety. Ecco perché si vedranno spesso esempi tratti dall’aviazione e dalla medicina, oltre ad altre aree critiche per la sicurezza come il trasporto marittimo, il volo spaziale, l’energia nucleare e la ferrovia.

E’ per questo motivo che i primi documenti che si associano all’ingegneria della resilienza sono reazioni ai precedenti modi di pensare agli incidenti in particolare e alla safety in generale.

Si noti che gli approcci tradizionali alla sicurezza spesso si concentrano sulla riduzione al minimo della variabilità associata al lavoro umano, utilizzando tecniche come procedure documentate e meccanismi di applicazione per la deviazione da esse.

Per quelli di noi che lavorano su cloud web services, non abbiamo questa eredità di procedure applicate con cui fare i conti.

Nuovo look/nuova vista
Il “nuovo look” o “nuovo punto di vista” si riferisce a un cambiamento di prospettiva su come accadono gli incidenti, che si concentra sulla comprensione del modo in cui le azioni intraprese dagli attori coinvolti nell’incidente erano razionali, date le informazioni che quegli attori avevano nel momento in cui gli eventi si stavano svolgendo .

Johan Bergström della Lund University ha tre eccellenti video brevi (<10 minuti):

• È stato un guasto tecnico o un errore umano?
• Tre trappole analitiche nelle indagini sugli incidenti
• Due punti di vista sull’errore umano

Due ottimi documenti introduttivi (ahimè, entrambi con paywall) sono:

• Ricostruire i contributi umani agli incidenti: la nuova visione dell’errore e delle prestazioni di Dekker
• L’errore di contare gli errori di Robert Wears

Un ottimo libro su come mettere in pratica queste idee nelle indagini sugli incidenti è:

• La guida sul campo per comprendere “l’errore umano” di Dekker

Safety-II
Safety-II è una prospettiva sul ruolo che gli esseri umani svolgono nei sistemi critici per la sicurezza, proposta da Erik Hollnagel. Nella prospettiva Safety-II, è il lavoro quotidiano e normale degli esseri umani nel sistema che crea la sicurezza, in contrasto con gli errori umani che la erodono.

• Da Safety-I a Safety-II: A White Paper di Hollnagel è un’introduzione molto leggibile ai concetti di Safety-II.
• Perché le cose vanno bene? di Dekker sul sito web Safety Differently è un altro buon articolo.

Sistemi complessi

Vi siete mai chiesti perché i sostenitori dell’ingegneria della resilienza parlano di “no root cause – nessuna causa principale?”

Un tema ricorrente nell’ingegneria della resilienza riguarda il ragionamento olistico sui sistemi, piuttosto che di scomporre le cose in componenti e ragionare sui componenti separatamente. Questa prospettiva è nota come pensiero sistemico, che è una scuola di pensiero che è stata influente nella comunità dell’ingegneria della resilienza.

Quando vedi il mondo come un sistema, l’idea della causa diventa priva di significato, perché non c’è modo di isolare una causa individuale. Invece, il mondo è una rete intricata di influenze.

Sentirai spesso la frase sistema socio-tecnico. Questo linguaggio sottolinea che i sistemi dovrebbero essere pensati come comprendenti sia gli esseri umani che le tecnologie, invece di pensare agli aspetti tecnologici isolati.

• Come i sistemi complessi falliscono di Richard I. Cook è un ottimo punto di partenza. È un foglio breve e molto facile da leggere.
• Drift into Failure di Sidney Dekker è un libro scritto per un pubblico laico, quindi è anche molto leggibile. Dekker attinge molto dal pensiero sistemico per proporre una teoria su come i sistemi complessi possono evolversi in stati non sicuri.

Coordinazione

I sistemi a cui siamo interessati spesso coinvolgono un insieme di persone che lavorano insieme in qualche modo per portare a termine un compito. Un esempio particolarmente rilevante riguarda una raccolta di ingegneri che lavorano insieme per risolvere i problemi e riparare un sistema durante un incidente in corso.

• Common Ground and Coordination in Joint Activity è un documento spesso citato su ciò che è richiesto alle persone per coordinarsi efficacemente quando lavorano insieme su tasks.

Automazione

Una cosa che noi popolo del software abbiamo in comune con il mondo della sicurezza critica è la maggiore adozione dell’automazione. L’automazione introduce sfide e la natura di queste sfide è un argomento di molti documenti di ingegneria della resilienza.

Potresti sentire la frase joint cognitive system nel contesto dell’automazione. Questi termini si riferiscono a sistemi che svolgono un lavoro cognitivo che sono costituiti da una combinazione di esseri umani e software. Esiste un’intera disciplina di ricerca che studia i sistemi cognitivi congiunti chiamata ingegneria dei sistemi cognitivi, inizialmente sviluppata da David Woods ed Erik Hollnagel, che in seguito avrebbero entrambi svolto un ruolo significativo nello sviluppo del campo dell’ingegneria della resilienza.

Poiché i ricercatori di ingegneria della resilienza come Woods e Hollnagel hanno le loro radici nell’ingegneria dei sistemi cognitivi e a causa dell’uso sempre crescente dell’automazione del software nella società, questa comunità è molto preoccupata per la potenziale fragilità associata allo scarso uso dell’automazione.

• Ironies of automation di Lisanne Bainbridge è un classico articolo sui problemi che l’automazione può introdurre. Il documento è stato originariamente scritto nel 1983 e continua ad essere ampiamente citato.
• Dieci sfide per rendere l’automazione un giocatore di squadra di Klein et al. è un documento più recente che delinea i requisiti affinché l’automazione sia realmente efficace nei sistemi socio-tecnici. Questo lavoro attinge fortemente dal tema del coordinamento discusso in precedenza.

David Woods

Abbiamo già fatto riferimento a diversi articoli scritti o co-autori di David Woods. Woods è una forza della natura nel campo dell’ingegneria della resilienza, avendo svolto un ruolo chiave nella creazione del campo stesso. Woods è incredibilmente prolifico e ha introdotto un’ampia varietà di concetti relativi all’ingegneria della resilienza.

Woods è interessato ai principi dell’ingegneria della resilienza che si applicano a un’enorme gamma di diversi tipi di sistemi: sia che si parli degli organi in un organismo biologico fino a organizzazioni come la NASA.

Poiché è interessato ai principi generali, molti dei suoi articoli sono scritti a un livello molto astratto, in cui discute concetti generici come unità di comportamento adattivo o saturazione.

Draghi al confine
David Woods usa la metafora di un sistema che si muove all’interno di un confine nei suoi scritti sull’ingegneria della resilienza, ma in un modo leggermente diverso da Rasmussen.

Woods vede il confine come un involucro di competenza. Esistono due diversi regimi di comportamento del sistema: lontano dal confine e vicino al confine.

Quando un sistema è lontano dal confine, il sistema (e il suo ambiente) si comportano come previsto. Al contrario, quando un sistema si avvicina al confine, accadono sorprese. Woods usa la metafora dei draghi per catturare le sorprese che si verificano quando un sistema si avvicina al confine e come il modello del mondo del sistema viene violato quando entra in questo regime.

È il modo in cui le unità all’interno di un sistema si adattano quando il sistema si sposta vicino al confine, il modo in cui queste unità affrontano i draghi, questa è una delle principali preoccupazioni di Woods.

Essentials of Resilience di Woods, rivisitato, discute il comportamento al confine, sebbene non utilizzi la metafora del drago.

L’universo adattativo
L’idea di Woods dell’universo adattivo è caratterizzata da tre proprietà:

• Le risorse sono limitate
• La sorpresa è fondamentale
• Il cambiamento non si ferma mai

Non ho trovato un buon documento introduttivo per l’universo adattivo, poiché comprende un numero enorme di argomenti, incluso l’argomento dei draghi ai confini di cui abbiamo discusso in precedenza.

Consiglio di guardare il corso breve di Woods sulla Resilience Engineering, che tratta questo argomento. Ho scritto i miei appunti sul corso breve, che potresti trovare utili. In particolare, potrebbero interessarti le mie note di sintesi.

Graziosa estensibilità
Woods ha introdotto la teoria dell’estensibilità aggraziata per catturare il modo in cui i sistemi di successo si adattano efficacemente alla sorpresa. Il documento più rilevante qui è:

La teoria dell’estendibilità aggraziata: regole di base che governano i sistemi adattativi.

Erik Hollnagel: quattro capisaldi, abilità, potenzialità

Quattro capacità essenziali in un sistema resiliente (Hollnagel, 2009):

• LEARNING. Imparare dall’esperienza richiede eventi reali sia di ciò che va bene sia di ciò che va storto, non solo i dati nei database. Ciò richiede la selezione di cosa imparare e come l’apprendimento si riflette nell’organizzazione, ovvero cosa si riflette nei cambiamenti nelle procedure e nelle pratiche. Questa capacità è legata all’affrontare il fatto – factual.
• RESPONDING. Rispondere (compresa la prontezza nel rispondere) alle minacce regolari e irregolari in modo solido e flessibile. Il sistema è progettato per fornire una gamma limitata di risposte. È ancora necessario adattare le risposte in modo flessibile a richieste impreviste. Questa capacità consente di far fronte alla realtà – actual.
• MONITORING. Il monitoraggio in modo flessibile significa che le prestazioni del sistema e le condizioni esterne si concentrano su ciò che è essenziale per l’operazione. Ciò include il monitoraggio interno e il monitoraggio delle condizioni esterne che possono influire sull’operazione. Ciò consentirà di identificare ciò che potrebbe essere critico nel prossimo futuro – future.
• ANTICIPATE. Anticipare minacce e opportunità. È necessario andare oltre l’analisi del rischio e avere l’immaginazione necessaria per vedere cosa potrebbe accadere e vedere gli aspetti chiave del futuro (Westrum, 1993). Non si tratta solo di identificare i singoli eventi, ma anche di come le parti possono interagire e influenzarsi a vicenda. Questa capacità si rivolge a come affrontare gli eventi irregolari, possibilmente anche imprevisti, consentendo così all’organizzazione di far fronte al potenziale – potential.

Hollnagel, E. (2009). The four cornerstones of resilience engineering. In: Nemeth C., Hollnagel E. e Dekker S. (a cura di), Resilience Engineering Perspectives, vol. 2, Preparation and Restoration. Ashgate, Aldershot, UK.

Related Articles

Related