John Allspaw, medstifter, Adaptive Capacity Labs

Slik fungerer systemene dine dag etter dag

Først litt om John Allspaw, medstifter av Adaptive Capacity Labs, og tidligere teknologisjef for Etsy.

Som ingeniørleder og forsker med over 20 års erfaring med å bygge og lede team som driver med programvare og systemteknikk, har Allspaw brukt det siste tiåret på å bygge bro mellom innsikt fra Human Factors, Cognitive Systems Engineering og Resilience Engineering til domenet software engineering og operasjoner.

Også forfatteren av to bøker, “The Art of Capacity Planning: Scaling Web Resources” og “Web Operations” (O’Reilly Media), fortsetter Allspaw å bidra til IT- og DevOps-samfunnene gjennom å snakke og samarbeide om ny, spennende forskning.

Vi var heldige nok til å være vertskap for John på DevOps Enterprise Summit i San Francisco, hvor han tok til scenen for å snakke om “Hvordan systemer fortsetter å løpe dag etter dag.” Nedenfor har vi transkribert de viktigste takeawayene og hovedhøydepunktene i presentasjonen hans. .

John Allspaw på DOES17 San Francisco

John Allspaw

Slik fungerer systemene dine dag etter dag

Det jeg vil snakke om er nytt. Det er annerledes, og jeg føler veldig, veldig sterkt over dette.

For å hjelpe meg med å sette scenen, var avhandlingen for graden min i menneskelige faktorer og systemsikkerhet "Trade-Offs Under Pressure: Heuristics and Observations Of Teams Resolving Internet Service Outages."

Noen av dere har kanskje hørt om dette, det som kalles Stella-rapporten.

På et høyt nivå er denne rapporten resultatet av et årelangt prosjekt av et konsortium av industripartnere. IBM, Etsy og IEX, handelsselskap, en børs på Manhattan. I løpet av dette året så folk fra Ohio State University Cognitive Systems Engineering Lab, David Woods, Richard Cook og en rekke andre mennesker dypt på en hendelse i hver av disse organisasjonene.

De fant disse seks temaene og var vanlig på tvers av dem alle.

Visst er resultatene ganske viktige. Det er slik forskningen ble gjort som jeg vil at dere alle skal se på.

Her er de viktigste takeawayene mine fra rapporten:

  1. Vi må begynne å ta menneskelige prestasjoner på alvor i denne bransjen. Hvis vi ikke gjør det, vil vi fortsette å se sprø systemer med stadig økende innvirkning på våre virksomheter og for samfunnet.
  2. Vi kan gjøre dette ved å se på hendelser som går utover det vi gjør i postmortems eller anmeldelser etter hendelsen eller etter handling.
  3. Det finnes metoder og tilnærminger fra studiet av spenst på andre områder, men de krever virkelig engasjement for å forfølge. Å gjøre dette er både nødvendig og vanskelig, men det vil vise seg å være et konkurransefortrinn for virksomheter som gjør det bra.

For det første vil jeg starte med litt av en grunnleggende, litt av et ordforråd som kommer til å bli viktig når jeg på en måte leder deg gjennom dette. Jeg skal beskrive et slags bilde, en representasjon, som en mental modell av organisasjonene dine, og det kommer til å ha et område som er over linjen og et område under linjen.

Hvis du forestiller deg hva vi har avbildet her, er dette produktet ditt, tjenesten din, API-en din, eller hva virksomheten din stammer fra og gir til kundene. Greit? Der inne er det du ser koden din. Du ser teknologibunken din. Du ser dataene og noen forskjellige måter å levere dette på, ikke sant? Antagelig over internett eller på en annen måte. Men hvis vi blir her, er det ingen som vil tro meg at det er det vi kaller systemet, fordi det er greit, men det er ikke helt fullstendig.

Hva som egentlig henger sammen, og hva mange mennesker har snakket om her i DevOps Enterprise Summit-samfunnet, er alt vi gjør for å manipulere det som foregår der inne, og derfor har vi testverktøy. Vi har overvåkningsverktøy. Vi har distribusjonsverktøy og alt det som er tilkoblet. Dette er tingene vi bruker. Du kan si at dette er systemet, fordi mange av oss bruker tiden vår på å fokusere på de tingene som ikke er inne i den lille boblen der, men alle tingene som er rundt det, men hvis vi skulle holde på med dette, vi vil ikke kunne se hvor virkelig arbeid skjer.

Det vi skal gjøre her er, vi kommer til å tegne en linje som vi kaller representasjonslinjen, og så grave litt dypere. Det vi ser her er deg. Alle menneskene som gjør ting klare til å legge til systemet, for å endre systemet. Du gjør den arkitektoniske innrammingen. Du overvåker. Du holder rede på hva den gjør, hvordan den gjør det og hva som skjer med dem.

Nå vil du legge merke til at hver enkelt av disse menneskene har en slags mental representasjon av hva det systemet er. Hvis du ser litt nærmere på det, vil du se at ingen av dem er like. Forresten, det er veldig karakteristisk for denne typen roller. Ingen har den samme representasjonen av det som er under linjen.

For å oppsummere, dette er vår verdensmodell, og den inkluderer ikke bare de tingene som kjører der, men alle dere, hvilke aktiviteter du utfører, det kognitive arbeidet du gjør for å holde den verdenen til å fungere . Hvis vi leker med dette litt mer, ender vi opp med denne typen modeller. Denne modellen har en representasjonslinje som går gjennom midten, og du samhandler med verden under linjen via et sett med representasjoner.

Interaksjonene dine er aldri med tingene selv. Du endrer faktisk ikke systemene.

Det du gjør er at du samhandler med representasjonen og at representasjonen er noe med det som foregår nedenfor. Du kan tenke på de grønne tingene som skjermene du ser på i løpet av dagen, men den eneste informasjonen du har om systemet kommer fra disse representasjonene. De er bare et lite nøkkelhull. Ikke sant?

Det som er viktig med det er at alle aktivitetene du gjør, alle å observere, utlede, forutse, planlegge, korrigere, alle de slags ting må gjøres via disse representasjonene, så det er en verden over linjen og en verden under linjen, og selv om du og vi for det meste snakker om verden under linjen som om den er veldig ekte, som om den er veldig konkret, som om det er noe som er tingen, her er overraskelsen.

Her er det veldig bra - du får aldri se det.

Den eksisterer ikke. I ekte forstand er det ingen under linjen du faktisk kan berøre. Du ser aldri noen gang koden kjøres. Du ser aldri at systemet faktisk fungerer. Du berører aldri de tingene.

Det du gjør er at du manipulerer en verden du ikke kan se via et sett av representasjoner, og det er derfor du trenger å bygge de mentale modellene, de forestillingene, forståelsene om hva som skjer. Det er de tingene som driver denne manipulasjonen. Det er ikke verden under linjen som gjør det. Det er din konseptuelle evne til å forstå tingene som har skjedd i fortiden, tingene du gjør nå og hvorfor du gjør disse tingene, hva som betyr noe og hvorfor det som faktisk betyr noe.

Når du har tatt i bruk dette perspektivet, når du går bort fra at ideen om at under linjen er det du har å gjøre med, og forstår at du virkelig jobber over linjen, endres alle slags ting.

Det du ser i Stella-rapporten og det prosjektet og andre prosjekter som vi har vært engasjert i, tar det synspunktet, og forstår hva det egentlig betyr å ta verden over på alvor. Dette er en stor avgang fra mye av det du har sett tidligere, men jeg tror det er en fruktbar retning vi må ta.

Med andre ord, disse kognitive aktivitetene (se nedenfor) hos både individer og samlet i team opp og ned i organisasjonen er det som får virksomheten til å fungere. Nå har jeg studert dette i detalj her, og jeg kan fortelle deg dette. Det fungerer ikke slik vi tror det gjør.

Til slutt, for å sette denne rammen opp, er den viktigste delen av denne ideen at alt dette endres over tid. Det er en dynamisk prosess som pågår. Dette er analyseenheten. Når vi tar den rammen, kan vi stille noen spørsmål. Vi kan stille noen spørsmål om over linjen som denne.

"Hvordan fungerer programvaren vår egentlig, i motsetning til hvordan den er beskrevet i wiki og i dokumentasjon og i diagrammer? Vi vet at de ikke er omfattende, de er ikke helt nøyaktige. "

"Hvordan brytes programvaren vår egentlig, i motsetning til hvordan vi trodde den ville gå i stykker når vi tegnet sikrings- og effektbrytere og rekkverk?

"Hva gjør vi for at det hele skal fungere?"

Spørsmål: Se for deg organisasjonen din. Hva ville skje hvis klokka seks i dag klarte å ta hendene fra tastaturet? De svarer ikke på noen sider. De ser ikke på noen varsler. De berører ingen deler av det, programkode eller nettverk eller noe av det. Er du sikker på at tjenesten din vil være i gang etter en dag?

Spørsmålet er da hvordan du oppdager hva som skjer over streken. Det er et par ting. Vi kan lære av studiet av andre høytempo-domener med høy konsekvens, og hvis vi gjør det, kan vi se at vi kan studere hendelser. (Merk: når jeg sier “hendelser”, mener jeg strømbrudd, fornedrelser, brudd, ulykker, nestenulykker og feil - i utgangspunktet ubehagelige eller uventede hendelser).

Hva gjør hendelser interessante? Vel, det åpenbare er tapte inntekter og omdømme innvirkning på en bestemt virksomhet. Jeg vil hevde et par andre grunner til at hendelser er interessante. Den ene er at hendelser former utformingen av nye komponentundersystemer og arkitekturer. Med andre ord, hendelser i går informerer morgendagens arkitekturer. Det vil si at hendelser hjelper til med å tenke våre forestillinger om hvordan vi kan gjøre systemene våre bedre, og det jeg mener er at hendelser under linjedriften endres over linjen.

Det er tingen. Dette kan koste ekte penger. Hendelser kan ha noen ganger nesten stilltiende eller usynlige effekter, noen ganger betydelige. Akkurat nå deler mange mennesker opp en monolit til mikrotjenester. Mange gjør det fordi det gir en viss mengde robusthet du ikke har. Hvor får du det?

Du blir informert om hendelser.

En annen grunn til å se på hendelser er at de har en tendens til å føde nye former for regelverk, retningslinjer, normer, etterlevelse, revisjon, begrensninger, etc. En annen måte å si dette på er at hendelser i går informerer morgendagens regler, som påvirker bemanningen , budsjetter, planlegging, veikart og mer. La meg gi deg et eksempel: I finansiell handel har SEC satt på plass forordning SCI. SCI, er sannsynligvis det mest omfattende og detaljerte samsvaret i moderne programvare-æra. SEC har gått og vært veldig eksplisitt. Vi har dette som en reaksjon på flash-krasjet i 2010 til Knight Capital, BATS IPO, Facebook IPO. Det er en reaksjon på hendelser.

Selv om du går litt tilbake, siteres det ofte at PCI DSS ble til da MasterCard og Visa sammenliknet notater, innså at de tapte rundt 750 millioner dollar i løpet av 10 år, så hendelser har betydelige, og forresten, jeg kan som en tidligere CTO for et offentlig selskap, kan jeg forsikre deg om at dette er en veldig kostbar, distraherende og uunngåelig en tyngende albatross for alle organisasjonene dine. Hendelser er betydningsfulle på denne måten også, men hvis vi tenker på hendelser som muligheter, hvis vi tenker på hendelser som meldinger, er kodede meldinger som sendes over linjen over linjen, og din jobb er å avkode dem, hvis du tenker på hendelser som ting som aktivt prøver å få oppmerksomhet til deler av systemet som du trodde du hadde tilstrekkelig forståelse av, men som du ikke gjorde det, er dette påminnelser om at du kontinuerlig må vurdere hvor trygg du er på hvordan det hele fungerer.

Hvis du nå tar dette synspunktet, åpner det seg en hel haug med ting. Det er en mulighet for ny trening, nytt verktøy, nye organisasjonsstrukturer, ny finansieringsdynamikk og muligens innsikt som konkurrentene dine ikke har.

Hendelser hjelper oss med å måle deltaet mellom hvordan systemet ditt fungerer og hvordan vi tror at systemet ditt fungerer, og dette deltaet er nesten alltid større enn vi forestiller oss. Jeg vil hevde at det er en annen ting du kanskje er vant til, og det er dette. Hendelser er ikke planlagte investeringer i bedriften, i selskapets overlevelse. Det er enormt verdifulle muligheter for å forstå hvordan systemet ditt fungerer, hvilke sårbarheter i oppmerksomheten som finnes, og hvilke konkurransefortrinn du ikke forfølger.

Hvis du tenker på hendelser, forbrenner de penger, tid, omdømme, personale osv. Dette er uunngåelige synkede kostnader. Noe er imidlertid interessant med denne typen investeringer. Du kontrollerer ikke størrelsen på investeringen, så derfor gjenstår spørsmålet, hvordan vil du maksimere avkastningen på investeringen?

Når vi ser på hendelser, er dette typen spørsmål vi hører, og det er ganske i samsvar med hva forskere finner i andre komplekse systemer, domener. Hva gjør det? Hvorfor gjør det det? Hva vil den gjøre videre? Hvordan kom det inn i denne tilstanden? Hva skjer? Hvis vi gjør Y, vil det hjelpe oss å finne ut hva vi skal gjøre? Blir det verre? Det ser ut som det er løst, men er det? Hvis vi gjør X, vil det forhindre at det blir verre, eller vil det gjøre det verre? Hvem ellers skal vi kalle som kan hjelpe oss? Er dette vårt spørsmål, eller blir vi angrepet? Dette stemmer overens med mange andre felt. Luftfart, flygelederskontroll, spesielt i automatiseringsrike domener.

En annen ting som er bemerkelsesverdig er at begynnelsen på enhver hendelse, den ofte er usikker eller tvetydig om hvorvidt dette er den som synker oss. I begynnelsen av en hendelse vet vi rett og slett ikke, spesielt om den inneholder enorme mengder usikkerhet og enorme mengder uklarhet. Hvis det er usikkert og tvetydig, betyr det at vi har brukt våre mentale modeller. De stemmer ikke overens med det vi ser, og spørsmålene oppstår. Bare etterpåklokskap vil fortelle oss om det var hendelsen som brakte selskapet ned, eller om det var en tøff tirsdag ettermiddag.

Hendelser gir kalibrering om hvordan beslutninger er fokusert, om hvordan oppmerksomhet er fokusert, om hvordan koordinering er fokusert, om hvordan opptrapping er fokusert. Effekten av tidspress, virkningen av usikkerhet, virkningen av tvetydighet og konsekvensene av konsekvenser. Forskning validerer disse mulighetene.

"Vi bør se dypt på hendelser som" ikke-rutinemessige utfordrende hendelser, fordi disse tøffe tilfellene har det største potensialet for å avdekke elementer av kompetanse og relaterte kognitive fenomener. "
- Gary Klein, opphavsmannen til naturalistisk beslutningsprosess.

Det er en familie av godt utslitte metoder, tilnærminger og teknikker. Kognitiv oppgaveanalyse. Prosesssporing. Samtaleanalyse. Den kritiske beslutningsmetoden. Hvordan vi synes postmortems har verdi ser litt slik ut:

En hendelse skjer. Kanskje noen vil sette sammen en tidslinje. Vi har et lite møte. Kanskje har du en mal, og du fyller den ut, og så kan noen lage en rapport eller ikke, og så har du endelig handlinger. Vi tror at den største verdien, kanskje den største verdien, er der du er i en debriefing og folk går gjennom tidslinjen og du vil være: "Herregud. Vi vet alt dette. ”

Dette er ikke hva forskningen viser. Forskningen viser at hvis vi samler subjektive og objektive data fra flere steder, atferdsdata, hva folk sa, hva folk gjorde, hvor de så ut, hvilke veier i diagnosen fulgte de og var ikke fruktbare? Godt tilrettelagte debriefings får folk til å kontrastere og sammenligne sine mentale modeller som nødvendigvis er feil. Du kan gi forskjellige resultater, inkludert ting som bootcamp, onboarding materialer, opplæring på ny leie. Du kan ha tilbakemelding om tilrettelegging hvis du bygger et program for å trene tilretteleggere. Du kan gjøre endringer i veikart, virkelig betydningsfulle endringer basert på hva du lærer.

Jeg kan fortelle deg dette fra litt erfaring. Det er ikke noe mer innsiktsfullt av en ny ingeniør eller en ingeniør som bare begynner i karrieren enn å være i et rom med en veteraningeniør som kjenner alle kriker og kroker som forklarer ting som de kanskje aldri noen gang har sagt høyt. De har kunnskap. De tegner kanskje bilder og diagrammer som de aldri har tegnet før fordi de tror alle andre vet det. Gjett hva? Det gjør de ikke. Den største verdien er faktisk her, fordi kvaliteten på disse resultatene er avhengig av kvaliteten på den, den rekalibreringen. Dette er en åpning for å kalibrere mentale modeller.

Fra Stella-rapporten "informerer og kalibrerer menneskers modeller om hvordan systemet fungerer, deres forståelse av hvordan det er sårbart og hvilke muligheter som er tilgjengelige for utforskning."

I mye av forskningen, i all forskningen i Stella-rapporten, og det passer med min erfaring hos Etsy også, en av refleksjonens sterkeste fra folk som gjør dette på en tilrettelagt måte å gjøre dette sammenligning og kontrast. "Jeg visste ikke at det fungerte på den måten." Så er det alltid andre, "Hvordan fungerte det noen gang?" Som er morsom til du skjønner at det er alvorlig. Hva det betyr er at ikke bare jeg trodde det fungerte på en annen måte. Nå kan jeg ikke en gang forestille meg, jeg kan ikke en gang tegne et bilde i tankene mine om hvordan det kunne ha fungert. Det burde være mer foruroligende. For øvrig vil jeg si at dette ikke er justering. Som jeg sa, via representasjoner har vi nødvendigvis ufullstendige mentale modeller. Tanken er ikke å ha de samme mentale modellene, fordi de alltid er ufullstendige, fordi ting alltid endrer seg, og fordi de kommer til å være feil. Vi ønsker ikke at alle skal ha den samme mentale modellen, for da har alle de samme blinde flekkene.

Skyldløs - går tilbake til blogginnlegget som jeg skrev i 2012

“Blameless” er tabellinnsatser. Det er nødvendig, men det er ikke tilstrekkelig. Du kan bygge et miljø, en kultur, en omfavnelse, en slags innbydende organisasjon som støtter og lar folk fortelle historier i alle de rotete detaljene, noen ganger pinlige detaljer, uten frykt for gjengjeldelse, slik at du virkelig kan gjøre fremgang, og når du skal forstå hva som skjer, kan du sette den tilstanden opp og fremdeles ikke lære så mye. Det er ikke tilstrekkelig. Det er nødvendig, men ikke tilstrekkelig. Det jeg snakker om er mye mer krefter enn typiske anmeldelser etter hendelsen. Ikke sant? Det er her en analytiker, en tilrettelegger kan forberede, sortere, organisere, analysere atferdsdata. Hva folk sier, hva folk gjør. Det er en rekke data som de kan sile gjennom for å forberede debriefings, en gruppe debriefing, eller en en-til-en debriefing, som går utover ... Postmortems antydning til rikheten av hendelser. Det tar mye arbeid å følge opp dette.

Forresten, alles generelt er så utmattet etter en virkelig, stressende strømbrudd eller hendelse eller hendelse at noen ganger blir alt krystallklart. Det er etterpåklokskapens kraft, og fordi det virker så krystallklart, virker det ikke produktivt å ha en debriefing, fordi du tror du allerede vet alt. Den andre saken er at orientering etter postmortem også begrenses av tiden. Du har bare konferanserommet i en time eller to. Alle er veldig opptatt, og klokken tikker, så dette er en utfordring for å gjøre dette veldig bra, selv gitt de forskningsmetodene.

Det andre problemet, spesielt hvis du bygger et opplæringstilbud for debriefing som jeg gjorde på Etsy, er det fortsatt utfordringer som dukker opp. Det jeg liker å kalle det er, "Alle har sitt eget mysterium å løse," eller "Ikke kast bort tiden min på detaljer jeg allerede vet." På en tegneseriefull måte kan du tenke på det på denne måten:

Fordi du kanskje bare har en time, trenger du å hente ut så mye læring du kan. Alt arbeid er kontekstuelt. Din jobb for å maksimere avkastningen er å oppdage, utforske og gjenoppbygge konteksten som arbeid utføres i en hendelse, hvordan arbeid og hvordan folk tenkte over linjen.

Vurderinger er avveininger, og de er kontekstuelle.

Avslutningsvis kan alle hendelser være verre. Et overfladisk syn er å spørre: “Hva gikk galt? Hvordan gikk det i stykker? Hva løser vi? ”Dette er veldig rimelige spørsmål. Hvis vi skulle ta et dypere nivå, og vi kunne spørre: "Hva er tingene som gikk ut på at det ikke ble så dårlig som det kunne vært?" Fordi vi ikke tar hensyn til disse tingene og ikke identifiserer oss disse tingene, kan vi slutte å støtte disse tingene.

Kanskje grunnen til at det ikke ble verre er fordi noen kalte Lisa, og Lisa kjenner tingene hennes. Noe fra forskning er at eksperter kan se hva som ikke er der. Hvis du ikke støtter Lisa, og ikke en gang identifiserer at grunnen til at det ikke ble verre, er fordi Lisa var der. Glem handlinger for å fikse noe for et øyeblikk. Se for deg en verden der Lisa går til en ny jobb.

Nyttig på strategisk nivå er et bedre spørsmål. Hvordan kan vi støtte, oppmuntre, talsmann og finansiere den kontinuerlige forståelsesprosessen i systemene våre? Og virkelig ta "over streken" på en vedvarende måte?

Hvor går vi herfra? Jeg har noen utfordringer for deg:

  1. Sirkulere Stella-rapporten i selskapet ditt og start en dialog. Selv om du er for opptatt, eller hvis du ikke er i stand til å lese den selv, kan du gi den til folk som gjør det. Spør dem hva som gir gjenklang. Spør dem hva som ikke gir mening. Spør dem, start en dialog.
  2. Se dypt på hvordan du håndterer anmeldelser etter hendelsen. Det viktigste er at du finner de menneskene som er mest kjent med de rotete detaljene om hvordan arbeid blir utført, og spør dem om dette: "Hvilken verdi tror du at våre nåværende vurderinger etter hendelsen virkelig har?" Og lytt.
  3. Ta ansvaret for å lære mer og raskere av hendelser enn konkurrentene. Du bygger enten en lærende organisasjon, eller du taper for en som er.
  4. Vi må ta menneskelige prestasjoner på alvor. Denne diskusjonen skjer. Det skjer i kjernekraft. Det skjer innen medisin. Det skjer innen luftfart, flygeledelse, brannbekjempelse.

Den økende betydningen av systemene våre, det økende potensialet for økonomiske, politiske og menneskelige skader når de ikke fungerer som de skal, og spredning av avhengigheter og tilhørende usikkerhet gjør meg veldig bekymret. Hvis du ser på ditt eget system og dets problemer, tror jeg at du vil være enig i at vi må gjøre mye mer enn å erkjenne dette problemet. Vi må omfavne det. Hva du kan hjelpe meg med, kan du spre denne informasjonen, disse ideene og presentasjonen min fra DevOps Enterprise Summit San Francisco 2017.

Jeg vil høre fra deg. Hva resonerte med deg om dette? Hva gjorde ikke det? Hvilke utfordringer møter du i organisasjonen din i tråd med disse linjene? Kom fortell meg. Jeg er på Twitter.

Opprinnelig publisert på itrevolution.com 30. april 2018.