John Allspaw, co-fondatore, Adaptive Capacity Labs

Come i tuoi sistemi continuano a funzionare giorno dopo giorno

Innanzitutto, un po 'di John Allspaw, co-fondatore di Adaptive Capacity Labs, ed ex Chief Technology Officer di Etsy.

In qualità di leader ingegneristico e ricercatore con oltre 20 anni di esperienza nella costruzione e team leader impegnati nell'ingegneria di software e sistemi, Allspaw ha trascorso l'ultimo decennio a collegare approfondimenti da Human Factors, Cognitive Systems Engineering e Resilience Engineering al dominio dell'ingegneria del software e operazioni.

Inoltre autore di due libri, "The Art of Capacity Planning: Scaling Web Resources" e "Web Operations" (O’Reilly Media), Allspaw continua a contribuire alle comunità IT e DevOps attraverso il discorso e la collaborazione su nuove interessanti ricerche.

Abbiamo avuto la fortuna di ospitare John al Summit Enterprise DevOps di San Francisco, dove è salito sul palco per parlare di "Come i sistemi continuano a funzionare giorno dopo giorno". Di seguito, abbiamo trascritto i punti salienti e le principali novità della sua presentazione .

John Allspaw a DOES17 San Francisco

John Allspaw

Come i tuoi sistemi continuano a funzionare giorno dopo giorno

Quello di cui voglio parlare è nuovo. È diverso, e mi sento molto, molto fortemente al riguardo.

Per contribuire a preparare il terreno, la mia tesi di laurea in Fattori umani e sicurezza dei sistemi è stata "Scambi sotto pressione: euristica e osservazioni delle squadre che risolvono le interruzioni dei servizi Internet".

Alcuni di voi potrebbero aver sentito parlare di questo, quello che viene chiamato il Rapporto Stella.

Ad alto livello, questo rapporto è il risultato di un progetto di un anno di un consorzio di partner del settore. IBM, Etsy e IEX, società commerciale, una borsa commerciale a Manhattan. Nel corso di quest'anno, persone del Cognitive Systems Engineering Lab dell'Ohio State University, David Woods, Richard Cook e un certo numero di altre persone hanno esaminato profondamente un incidente in ciascuna di queste organizzazioni.

Hanno trovato questi sei temi ed erano comuni a tutti loro.

Certamente i risultati sono abbastanza importanti. È così che è stata fatta quella ricerca e voglio che tutti voi diate un'occhiata.

Ecco i miei principali takeaway dal rapporto:

  1. Dobbiamo iniziare a prendere sul serio le prestazioni umane in questo settore. Se non lo facciamo, continueremo a vedere sistemi fragili con impatti sempre crescenti sulle nostre attività e sulla società.
  2. Possiamo farlo osservando gli incidenti che vanno al di là di ciò che attualmente facciamo nelle revisioni post-mortem o post-incidente o recensioni post-azione.
  3. Esistono metodi e approcci dallo studio della resilienza in altri settori, ma richiedono un impegno reale da perseguire. Fare questo è sia necessario che difficile, ma si rivelerà un vantaggio competitivo per le aziende che lo fanno bene.

In primo luogo, voglio iniziare con un po 'di base, un po' di un vocabolario che sarà importante mentre ti guido in questo. Descriverò una sorta di immagine, una rappresentazione, come un modello mentale delle tue organizzazioni, e avrà una regione sopra la linea e una regione sotto la linea.

Se immagini ciò che abbiamo rappresentato qui, questo è il tuo prodotto, il tuo servizio, la tua API o qualunque cosa la tua azienda tragga valore e dia ai clienti. Va bene? All'interno, quello che vedi è il tuo codice. Vedi il tuo stack tecnologico. Vedi i dati e alcuni modi diversi di fornire questo, giusto? Presumibilmente su Internet o in qualche altro modo. Ma se restiamo qui, nessuno mi crederà che è quello che chiamiamo il sistema, perché va bene, ma non è davvero completo.

Ciò che è realmente connesso e di cui molte persone hanno parlato qui nella comunità del Summit aziendale DevOps sono tutte le cose che facciamo per manipolare ciò che accade lì dentro, e quindi abbiamo strumenti di test. Abbiamo strumenti di monitoraggio. Abbiamo strumenti di distribuzione e tutte le cose che sono un po 'cablate. Queste sono le cose che usiamo. Si potrebbe dire che questo è il sistema, perché molti di noi passano il tempo a concentrarsi su quelle cose che non si trovano all'interno della piccola bolla lì, ma su tutte le cose che lo circondano, ma se dovessimo rimanere solo con questo non sarà in grado di vedere dove avviene il vero lavoro.

Quello che faremo qui è, tracciamo una linea che chiamiamo la linea di rappresentazione, e quindi scaviamo un po 'più a fondo. Quello che vediamo qui sei tu. Tutte le persone che stanno preparando cose da aggiungere al sistema, per cambiare il sistema. Stai facendo l'inquadramento architettonico. Stai monitorando. Tieni traccia di ciò che sta facendo, come lo sta facendo e cosa sta succedendo con loro.

Ora noterai che ognuna di queste persone ha una sorta di rappresentazione mentale su ciò che quel sistema è. Se lo guardi un po 'più da vicino, vedrai che nessuno di loro è uguale. A proposito, è molto caratteristico di questi tipi di ruoli. Nessuno ha la stessa rappresentazione di ciò che è al di sotto della linea.

Riassumendo, questo è il nostro modello di mondo e include non solo le cose che ci stanno correndo, ma tutti voi, il tipo di attività che state svolgendo, il lavoro cognitivo che state facendo per mantenere quel mondo funzionante . Se giochiamo un po 'di più con questo, finiremo con questo tipo di modello. Questo modello ha una linea di rappresentazione che attraversa il centro e interagisci con il mondo sotto la linea attraverso una serie di rappresentazioni.

Le tue interazioni non sono mai con le cose stesse. In realtà non cambi i sistemi.

Quello che fai è interagire con la rappresentazione e quella rappresentazione è qualcosa di ciò che sta succedendo di seguito. Puoi pensare a quelle cose verdi come agli schermi che stai guardando durante il giorno, ma le uniche informazioni che hai sul sistema provengono da queste rappresentazioni. Sono solo un piccolo buco della serratura. Giusto?

La cosa significativa è che tutte le attività che fai, tutte le osservazioni, inferire, anticipare, pianificare, correggere, tutto quel genere di cose devono essere fatte attraverso quelle rappresentazioni, quindi c'è un mondo sopra la linea e un mondo sotto la linea, e sebbene tu e noi parliamo principalmente del mondo sotto la linea come se fosse molto reale, come se fosse molto concreto, come se fosse qualcosa che è questo, ecco la sorpresa.

Ecco il grosso problema: non puoi mai vederlo.

Non esiste In un certo senso, non c'è sotto la linea che puoi effettivamente toccare. Non vedrai mai, mai eseguire il codice. Mai e poi mai vedere il sistema effettivamente funzionare. Non tocchi mai quelle cose.

Quello che fai è manipolare un mondo che non puoi vedere attraverso un insieme di rappresentazioni, ed è per questo che devi costruire quei modelli mentali, quelle concezioni, quelle comprensioni su ciò che sta succedendo. Queste sono le cose che stanno guidando quella manipolazione. Non è il mondo sotto la linea che lo sta facendo. È la tua capacità concettuale di comprendere le cose che sono successe in passato, le cose che stai facendo ora e perché stai facendo quelle cose, ciò che conta e perché ciò che conta davvero.

Una volta adottata questa prospettiva, quando ti allontani dall'idea che sotto la linea è la cosa con cui hai a che fare, e capisci che stai davvero lavorando sopra la linea, ogni sorta di cose cambia.

Quello che vedi nel Rapporto Stella, in quel progetto e in altri progetti con cui siamo stati coinvolti è quello di prendere visione di ciò e capire cosa significa veramente prendere sul serio il mondo al di sopra della linea. Questa è una grande deviazione da molto di ciò che avete visto in passato, ma penso che sia una direzione fruttuosa che dobbiamo prendere.

In altre parole, queste attività cognitive (vedi sotto) in entrambe le persone e collettivamente in team su e giù per l'organizzazione sono ciò che fa funzionare effettivamente l'azienda. Ora, ho studiato questo in dettaglio per un po 'di tempo qui, e posso dirtelo. Non funziona come pensiamo che funzioni.

Infine, per impostare questo frame, la parte più importante di questa idea è che tutto questo cambia nel tempo. È un processo dinamico in corso. Questa è l'unità di analisi. Una volta che abbiamo preso quella cornice, possiamo fare alcune domande. Possiamo fare alcune domande su above the line in questo modo.

"Come funziona davvero il nostro software, rispetto a come è descritto nel wiki e nella documentazione e nei diagrammi? Sappiamo che quelli non sono comprensivi, non sono completamente accurati ".

"In che modo il nostro software si rompe davvero, rispetto a come pensavamo che si sarebbe rotto quando abbiamo progettato protezioni, interruttori automatici e guardrail?"

"Cosa facciamo per far funzionare tutto?"

Domanda: immagina la tua organizzazione. Cosa succederebbe se oggi alle sei tutte le tue aziende togliessero le mani dalla tastiera? Non rispondono a nessuna pagina. Non guardano alcun avviso. Non toccano alcuna parte di esso, il codice dell'applicazione o le reti o parte di esso. Sei sicuro che il tuo servizio sarà attivo e funzionante dopo un giorno?

La domanda quindi è come scoprire cosa succede sopra la linea. Bene, ci sono un paio di cose. Possiamo imparare dallo studio di altri domini ad alto tempo e ad alta conseguenza e, se lo facciamo, possiamo vedere che possiamo studiare gli incidenti. (Nota: quando dico "incidenti", intendo interruzioni, degradazioni, violazioni, incidenti, mancati incidenti e problemi tecnici, in sostanza eventi avversi o imprevisti).

Cosa rende interessanti gli incidenti? Bene, quello ovvio è la perdita di entrate e impatti sulla reputazione di una determinata attività. Voglio affermare un paio di altri motivi per cui gli incidenti sono interessanti. Il primo è che gli incidenti modellano la progettazione di nuovi sottosistemi e architetture di componenti. In altre parole, gli incidenti di ieri informano le architetture di domani. Cioè, gli incidenti aiutano ad alimentare la nostra immaginazione su come migliorare i nostri sistemi, e quindi quello che intendo è, gli incidenti sotto la linea guidano i cambiamenti sopra la linea.

Questa è la cosa. Questo può costare soldi veri. Gli incidenti possono avere a volte effetti quasi taciti o invisibili, a volte significativi. In questo momento, molte persone stanno dividendo un monolito in micro-servizi. Molte persone lo fanno perché fornisce una certa robustezza che non hai. Dove lo prendi?

Sei informato dagli incidenti.

Un altro motivo per esaminare gli incidenti è che tendono a dare vita a nuove forme di regolamenti, politiche, norme, conformità, audit, vincoli, ecc. Un altro modo di dire questo è che gli incidenti di ieri informano le regole di domani, che influenzano il personale , budget, pianificazione, tabelle di marcia e altro ancora. Lasciatemi fare un esempio: nel trading finanziario, la SEC ha messo in atto il regolamento SCI. SCI è probabilmente la parte di conformità più completa e dettagliata dell'era del software moderno. La SEC è diventata ed è stata molto esplicita. Abbiamo questo come reazione al crollo del 2010 di Knight Capital, BATS IPO, Facebook IPO. È una reazione agli incidenti.

Anche se torni un po 'più indietro, viene spesso citato il fatto che PCI DSS è nato quando MasterCard e Visa hanno confrontato le note, rendendosi conto che hanno perso circa $ 750 milioni in 10 anni, quindi gli incidenti sono significativi e, a proposito, posso, come ex CTO di una società pubblica, posso assicurarvi che si tratta di un albatro molto costoso, che distrae e inevitabilmente gravoso per tutte le vostre organizzazioni. Gli incidenti sono significativi anche in questo modo, ma se pensiamo agli incidenti come opportunità, se pensiamo agli incidenti come messaggi, i messaggi codificati che sotto la linea vengono inviati sopra la linea e il tuo compito è decodificarli, se pensi agli incidenti come cose che cercano attivamente di attirare la tua attenzione su parti del sistema di cui pensavi di avere una comprensione sufficiente ma che non hai fatto, questi sono promemoria che devi riconsiderare continuamente quanto sei fiducioso su come funziona tutto.

Ora, se si prende questo punto di vista, si aprono un sacco di cose. C'è un'opportunità per una nuova formazione, nuovi strumenti, nuove strutture organizzative, nuove dinamiche di finanziamento e possibilmente approfondimenti che i tuoi concorrenti non hanno.

Gli incidenti ci aiutano a valutare il delta tra come funziona il tuo sistema e come pensiamo che funzioni il tuo sistema, e questo delta è quasi sempre maggiore di quanto immaginiamo. Voglio affermare forse una versione diversa a cui potresti essere abituato, ed è questo. Gli incidenti sono investimenti non pianificati nelle imprese, nella sopravvivenza della tua azienda. Sono opportunità estremamente preziose per capire come funziona il tuo sistema, quali vulnerabilità sono presenti e quali vantaggi competitivi non stai perseguendo.

Se pensi agli incidenti, bruciano denaro, tempo, reputazione, personale, ecc. Questi sono inevitabili costi sommersi. Qualcosa di interessante su questo tipo di investimento, però. Non controlli la dimensione dell'investimento, quindi la domanda rimane: come massimizzerai il ROI su quell'investimento?

Quando osserviamo gli incidenti, questi sono il tipo di domande che ascoltiamo ed è abbastanza coerente con ciò che i ricercatori trovano in altri sistemi complessi, domini. Che cosa sta facendo? Perché lo sta facendo? Cosa farà dopo? Come è arrivato a questo stato? Che cosa sta succedendo? Se facciamo Y, ci aiuterà a capire cosa fare? Sta peggiorando? Sembra che sia stato corretto, ma è? Se facciamo X, impedirà che peggiori o peggiorerà le cose? Chi altri dovremmo chiamare per aiutarci? È questo il nostro problema o siamo stati attaccati? Ciò è coerente con molti altri campi. Aviazione, controllo del traffico aereo, specialmente in settori ricchi di automazione.

Un'altra cosa degna di nota è che l'inizio di qualsiasi incidente, è spesso incerto o ambiguo sul fatto se questo è quello che ci affonda. All'inizio di un incidente, semplicemente non lo sappiamo, soprattutto se contiene enormi quantità di incertezza e enormi quantità di ambiguità. Se è incerto e ambiguo, significa che abbiamo esaurito i nostri modelli mentali. Non si adattano a ciò che stiamo vedendo e sorgono queste domande. Solo il senno di poi ci dirà se quello è stato l'evento che ha fatto crollare la compagnia o se è stato un martedì pomeriggio difficile.

Gli incidenti forniscono una calibrazione su come le decisioni sono focalizzate, su come l'attenzione è focalizzata, su come è focalizzata la coordinazione, su come è focalizzata l'escalation. L'impatto della pressione del tempo, l'impatto dell'incertezza, l'impatto dell'ambiguità e le conseguenze delle conseguenze. La ricerca convalida queste opportunità.

"Dovremmo guardare in profondità gli incidenti come" eventi sfidanti non di routine, perché questi casi difficili hanno il più grande potenziale per scoprire elementi di competenza e fenomeni cognitivi correlati. "
- Gary Klein, il creatore della ricerca decisionale naturalistica.

C'è una famiglia di metodi, approcci e tecniche ben usurati. Analisi delle attività cognitive. Traccia del processo. Analisi della conversazione. Il metodo decisionale critico. Il modo in cui pensiamo che i postmortem abbiano un valore è un po 'così:

Accade un incidente. Forse qualcuno metterà insieme una sequenza temporale. Abbiamo un piccolo incontro. Forse hai un modello e lo compili, quindi qualcuno potrebbe fare un rapporto o no, e poi hai, sì, elementi d'azione, finalmente. Pensiamo che il valore più grande, forse forse il valore più onesto, sia il luogo in cui sei in un debriefing e le persone stanno camminando attraverso la cronologia e tu sei tipo "Oh, mio ​​Dio. Sappiamo tutto questo. "

Questo non è ciò che la ricerca conferma. La ricerca conferma che se raccogliamo dati soggettivi e oggettivi da più luoghi, dati comportamentali, cosa dicono le persone, cosa fanno le persone, dove guardano, quali strade diagnostiche hanno seguito e non sono state fruttuose? Debriefing ben facilitati inducono le persone a contrastare e confrontare i loro modelli mentali che sono necessariamente imperfetti. Puoi produrre risultati diversi, tra cui cose come bootcamp, materiali di onboarding, formazione sui nuovi assunti. Puoi avere un feedback sulla facilitazione se costruisci un programma per formare i facilitatori. Potresti apportare modifiche alla roadmap, cambiamenti davvero significativi in ​​base a ciò che impari.

Posso dirti questo per esperienza. Non c'è niente di più perspicace per un nuovo ingegnere o un ingegnere che ha appena iniziato nella sua carriera che essere in una stanza con un ingegnere veterano che conosce tutti gli angoli e le fessure che spiegano cose che potrebbero non aver mai detto ad alta voce. Hanno conoscenza. Possono disegnare immagini e diagrammi che non hanno mai disegnato prima perché pensano che tutti lo sappiano. Indovina un po? Non lo fanno. Il valore più grande è in realtà qui, perché la qualità di questi risultati dipende dalla qualità di quello, quella ricalibrazione. Questa è un'apertura per ricalibrare i modelli mentali.

Dal Rapporto Stella, "informa e ricalibra i modelli delle persone su come funziona il sistema, le loro comprensioni su come è vulnerabile e quali opportunità sono disponibili per l'esplorazione".

In molte ricerche, in tutte le ricerche contenute nel Rapporto Stella, si adatta anche alla mia esperienza con Etsy, una delle più forti riflessioni da parte di persone che lo fanno in modo facilitato confrontando e contrasto. "Non sapevo che funzionasse in questo modo." Poi ci sono sempre altri, "Come ha mai funzionato?" Che è divertente finché non ti rendi conto che è serio. Ciò significa che non solo ho pensato che funzionasse diversamente. Ora, non riesco nemmeno a immaginare, non riesco nemmeno a disegnare un'immagine nella mia mente di come avrebbe potuto funzionare. Questo dovrebbe essere più inquietante. A proposito, voglio dire che questo non è allineamento. Come ho detto, tramite le rappresentazioni, abbiamo necessariamente modelli mentali incompleti. L'idea non è quella di avere gli stessi modelli mentali, perché sono sempre incompleti, perché le cose cambiano sempre e perché saranno imperfette. Non vogliamo che tutti abbiano lo stesso modello mentale perché tutti hanno gli stessi punti ciechi.

Senza colpa - tornando al post sul blog che ho scritto nel 2012

"Blameless" è la posta in gioco. È necessario, ma non è sufficiente. Potresti costruire un ambiente, una cultura, un abbraccio, una sorta di organizzazione accogliente che supporti e permetta alle persone di raccontare storie in tutti i dettagli disordinati, a volte dettagli imbarazzanti, senza paura di punizione, in modo da poter davvero fare progressi, e nel capire cosa sta succedendo, puoi impostare quella condizione e non imparare ancora molto. Non è sufficiente È necessario, ma non sufficiente. Quello di cui sto parlando è molto più sforzo rispetto alle tipiche recensioni post-incidente. Giusto? Qui è dove un analista, un facilitatore può preparare, raccogliere, organizzare, analizzare i dati comportamentali. Cosa dicono le persone, cosa fanno le persone. Esiste una serie di dati che possono selezionare per preparare i debriefing, un debriefing di gruppo o un debriefing one-to-one, andando oltre ... Postmortems suggerisce la ricchezza degli incidenti. Seguire questo richiede molto lavoro.

A proposito, in genere tutti sono così esausti dopo un'interruzione, un incidente o un evento davvero stressanti che a volte tutto diventa cristallino. Questo è il potere del senno di poi, e poiché sembra così cristallino, non sembra produttivo avere un debriefing, perché pensi di sapere già tutto. L'altro problema è che anche i briefing post-mortem sono limitati dal tempo. Hai solo la sala conferenze per un'ora o due. Tutti sono davvero occupati e il tempo passa, quindi questa è una sfida per farlo davvero bene, anche dato quei metodi di ricerca.

L'altro problema, soprattutto se si crea un programma di formazione per facilitare il debriefing come ho fatto a Etsy, ci sono ancora sfide che si presentano. Quello che mi piace chiamarlo è "Ognuno ha il proprio mistero da risolvere" o "Non perdere tempo con i dettagli che già conosco". In un modo da cartone animato, puoi pensarlo in questo modo:

Poiché potresti avere solo un'ora, devi estrarre quanto più apprendimento possibile. Tutto il lavoro è contestuale. Il tuo compito di massimizzare il ROI è scoprire, esplorare e ricostruire il contesto in cui il lavoro viene svolto in un incidente, come il lavoro e come la gente pensava al di sopra della linea.

Le valutazioni sono compromessi e quelli sono contestuali.

In chiusura, tutti gli incidenti possono essere peggiori. Una visione superficiale è chiedere: “Cosa è andato storto? Come si è rotto? Cosa risolviamo? ”Queste sono domande molto ragionevoli. Se dovessimo prendere un livello più profondo, e potremmo chiedere: "Quali sono le cose che sono andate a renderlo non tanto cattivo come avrebbe potuto essere?" Perché non prestiamo attenzione a quelle cose e non ci identifichiamo quelle cose, potremmo smettere di sostenere quelle cose.

Forse il motivo per cui non è peggiorato è perché qualcuno ha chiamato Lisa e Lisa conosce le sue cose. Qualcosa tratto dalla ricerca è che gli esperti possono vedere ciò che non c'è. Se non supporti Lisa e non identifichi nemmeno che il motivo per cui non è peggiorato è perché Lisa era lì. Dimentica gli oggetti d'azione per riparare qualcosa per un momento. Immagina un mondo in cui Lisa va a un nuovo lavoro.

Utile a livello strategico è una domanda migliore. “Come possiamo supportare, incoraggiare, sostenere e finanziare il continuo processo di comprensione nei nostri sistemi? E davvero prendere "al di sopra della linea" in modo sostenuto?

Dove andiamo da qui? Ho alcune sfide per te:

  1. Fai circolare il Rapporto Stella nella tua azienda e avvia un dialogo. Anche se sei troppo occupato o non sei in grado di leggerlo da solo, daglielo alle persone che lo fanno. Chiedi loro cosa risuona. Chiedi loro cosa non ha senso. Chiedi loro, avvia un dialogo.
  2. Guarda in dettaglio come gestisci le recensioni post-evento. Ancora più importante, vai a trovare le persone che hanno più familiarità con i dettagli disordinati di come viene svolto il lavoro e chiedi loro: "Che valore pensi che abbiano le nostre attuali recensioni post-incidente?" E ascolta.
  3. Assumiti la responsabilità di imparare più e più rapidamente dagli incidenti rispetto ai tuoi concorrenti. O stai costruendo un'organizzazione che apprende o stai perdendo con chi lo è.
  4. Dobbiamo prendere sul serio le prestazioni umane. Questa discussione sta accadendo. Sta succedendo nel nucleare. Sta succedendo in medicina. Sta succedendo nell'aviazione, nel controllo del traffico aereo, nella lotta antincendio.

Il crescente significato dei nostri sistemi, il crescente potenziale di danno economico, politico e umano quando non funzionano correttamente e la proliferazione di dipendenze e l'incertezza associata mi rendono molto preoccupato. Se guardi al tuo sistema e ai suoi problemi, penso che sarai d'accordo sul fatto che dobbiamo fare molto di più che riconoscere questo problema. Dobbiamo abbracciarlo. Per cosa puoi aiutarmi, ti preghiamo di diffondere queste informazioni, queste idee e la mia presentazione dal DevOps Enterprise Summit di San Francisco 2017.

Voglio sentirlo da te. Che cosa ha risuonato con te di questo? Cosa no? Quali sfide affronti la tua organizzazione in questo senso? Vieni a dirmelo. Sono su Twitter.

Originariamente pubblicato su itrevolution.com il 30 aprile 2018.