John Allspaw, medstifter af adaptive kapacitetslaboratorier

Hvordan dine systemer kører dag efter dag

Først lidt om John Allspaw, medstifter af Adaptive Capacity Labs og tidligere Chief Technology Officer for Etsy.

Som ingeniørleder og forsker med over 20 års erfaring i opbygning og førende teams, der beskæftiger sig med software og systemteknik, har Allspaw tilbragt det sidste årti med at bygge bro over indsigt fra menneskelige faktorer, kognitiv systemteknik og resilience Engineering til domænet af software engineering og operationer.

Også forfatteren af ​​to bøger, “The Art of Capacity Planning: Scaling Web Resources” og “Web Operations” (O’Reilly Media), fortsætter Allspaw med at bidrage til IT- og DevOps-samfundene gennem tale og samarbejde om ny, spændende forskning.

Vi var heldige nok til at være vært for John på DevOps Enterprise Summit i San Francisco, hvor han tog til scenen for at tale om “Hvordan systemer kører dag efter dag.” Nedenfor har vi transkribert de vigtigste takeaways og de vigtigste højdepunkter i hans præsentation .

John Allspaw i DOES17 San Francisco

John Allspaw

Hvordan dine systemer kører dag efter dag

Hvad jeg vil tale om er nyt. Det er anderledes, og jeg føler mig meget, meget stærkt ved dette.

For at hjælpe med at sætte scenen var min afhandling for min grad i menneskelige faktorer og systemsikkerhed "Trade-Offs Under Pressure: Heuristics and Observations Of Teams Resolving Internet Service Outages."

Nogle af jer har måske hørt om dette, hvad der kaldes Stella-rapporten.

På et højt niveau er denne rapport resultatet af et årlange projekt fra et konsortium af industripartnere. IBM, Etsy og IEX, handelsselskab, en handelsbørs i Manhattan. I løbet af dette år kiggede folk fra Ohio State University Cognitive Systems Engineering Lab, David Woods, Richard Cook og en række andre mennesker dybt på en hændelse i hver af disse organisationer.

De fandt disse seks temaer og var fælles på tværs af dem alle.

Resultaterne er bestemt meget vigtige. Det er sådan denne forskning blev udført, som jeg vil have jer alle til at se på.

Her er mine vigtigste afhentninger fra rapporten:

  1. Vi er nødt til at begynde at tage menneskelige præstationer alvorligt i denne branche. Hvis vi ikke gør det, fortsætter vi med at se skøre systemer med stadigt stigende indvirkning på vores virksomheder og samfundet.
  2. Vi kan gøre dette ved at se på hændelser, der går ud over, hvad vi i øjeblikket gør i postmortems eller anmeldelser efter hændelsen eller efter handlinger.
  3. Der findes metoder og tilgange fra studiet af modstandsdygtighed på andre områder, men de kræver reelt engagement i at forfølge. Dette er både nødvendigt og vanskeligt, men det vil vise sig at være en konkurrencefordel for virksomheder, der gør det godt.

Først vil jeg starte med en lille smule af en baseline, lidt af et ordforråd, der vil være vigtigt, når jeg slags leder dig gennem dette. Jeg vil beskrive en slags billede, en repræsentation som en mental model for dine organisationer, og det kommer til at have en over-the-line region og en under-the-line region.

Hvis du forestiller dig, hvad vi har afbildet her, er dette dit produkt, din service, din API eller hvad din virksomhed får værdi af og giver til kunderne. Okay? Inde der, hvad du ser er din kode. Du kan se din teknologibunke. Du ser dataene og nogle forskellige måder at levere disse på, ikke? Formodentlig over internettet eller på en anden måde. Men hvis vi bliver her, vil ingen tro mig, at det er det, vi kalder systemet, fordi det er fint, men det er ikke rigtig komplet.

Hvad der virkelig er forbundet, og hvad mange mennesker har talt om her i DevOps Enterprise Summit-samfundet, er alt det, vi laver for at manipulere, hvad der foregår derinde, og derfor har vi testværktøjer. Vi har overvågningsværktøjer. Vi har distributionsværktøjer og alt det, der er tilsluttet tilsluttet. Dette er de ting, vi bruger. Man kan sige, at dette er systemet, fordi mange af os bruger vores tid på at fokusere på de ting, der ikke er inde i den lille boble der, men alle de ting, der er omkring det, men hvis vi skulle bo bare med dette, vi kan ikke se, hvor reelt arbejde sker.

Det, vi skal gøre her, er, at vi tegner en linje, som vi kalder repræsentationslinjen, og graver derefter lidt dybere. Hvad vi ser her er dig. Alle de mennesker, der gør ting klar til at føje til systemet, til at ændre systemet. Du laver den arkitektoniske indramning. Du foretager overvågning. Du holder styr på, hvad det gør, hvordan det gør det, og hvad der foregår med dem.

Nu vil du bemærke, at hver enkelt af disse mennesker har en slags mental repræsentation af, hvad dette system er. Hvis du ser lidt nærmere på det, ser du, at ingen af ​​dem er ens. I øvrigt er det meget karakteristisk for disse typer roller. Ingen har den samme repræsentation af hvad der er under linjen.

For at opsummere, dette er vores verdensmodel, og det inkluderer ikke kun de ting, der kører der, men alle jer, de slags aktiviteter, du udfører, det kognitive arbejde, du laver for at holde denne verden fungerende . Hvis vi leger med dette lidt mere, ender vi med denne form for model. Denne model har en repræsentationslinje, der går gennem midten, og du interagerer med verdenen under linjen via et sæt repræsentationer.

Dine interaktioner er aldrig med tingene i sig selv. Du ændrer faktisk ikke systemerne.

Det, du gør, er, at du interagerer med repræsentationen, og at repræsentationen er noget ved det, der foregår nedenfor. Du kan tænke på de grønne ting som de skærme, du ser på i løbet af dagen, men den eneste information, du har om systemet, kommer fra disse repræsentationer. De er bare et lille nøglehul. Ret?

Hvad der er væsentligt ved det, er, at alle de aktiviteter, du udfører, alle at observere, udlede, forudse, planlægge, korrigere, alle disse slags ting skal udføres via disse repræsentationer, så der er en verden over linjen og en verden under linjen, og selvom du og vi for det meste taler om verdenen under linjen, som om den er meget reel, som om den er meget konkret, som om det er noget, det er det, her er overraskelsen.

Her er big deal - du får aldrig se den.

Det findes ikke. I en reel forstand er der intet under den linje, du faktisk kan røre ved. Du kan aldrig nogensinde se koden køre. Du ser aldrig, at systemet faktisk fungerer. Du rører aldrig ved disse ting.

Det, du gør, er, at du manipulerer en verden, som du ikke kan se via et sæt af repræsentationer, og det er derfor, du er nødt til at opbygge disse mentale modeller, disse forestillinger, disse forståelser om, hvad der foregår. Det er de ting, der driver denne manipulation. Det er ikke verdenen under linjen, der gør det. Det er din konceptuelle evne til at forstå de ting, der er sket i fortiden, de ting, du gør nu, og hvorfor du gør disse ting, hvad der betyder noget, og hvorfor det, der betyder noget, faktisk betyder noget.

Når du har vedtaget dette perspektiv, når du skridt væk, at tanken om, at under linjen er det, du har at gøre med, og forstår, at du virkelig arbejder over linjen, ændres alle mulige ting.

Det, du ser i Stella-rapporten og det projekt og andre projekter, som vi har været engageret i, tager denne opfattelse og forstår, hvad det virkelig betyder at tage ovenstående verden alvorligt. Dette er en stor afgang fra meget af det, du alle har set tidligere, men jeg synes, det er en frugtbar retning, som vi er nødt til at tage.

Med andre ord, disse kognitive aktiviteter (se nedenfor) hos både individer og samlet i teams op og ned i organisationen er det, der får virksomheden til at fungere. Nu har jeg undersøgt dette i detaljer her i lang tid, og jeg kan fortælle jer dette. Det fungerer ikke som vi tror, ​​det gør.

Til sidst, for at indstille denne ramme, er den vigtigste del af denne idé, at alt dette ændrer sig over tid. Det er en dynamisk proces, der løber. Dette er enheden for analyse. Når vi har taget den ramme, kan vi stille nogle spørgsmål. Vi kan stille nogle spørgsmål om over linjen som denne.

”Hvordan fungerer vores software egentlig, mod hvordan det er beskrevet i wiki og i dokumentation og i diagrammerne? Vi ved, at disse ikke er omfattende, de er ikke fuldstændigt nøjagtige. ”

”Hvordan brydes vores software virkelig, i modsætning til, hvordan vi troede, det ville gå i stykker, da vi designet beskyttelses- og afbrydere og beskyttelsesanordninger?”

"Hvad gør vi for at holde det hele fungerende?"

Spørgsmål: Forestil dig din organisation. Hvad ville der ske, hvis i dag klokken seks skulle alle dine virksomheder tage hænderne ud af tastaturet? De besvarer ikke nogen sider. De ser ikke på nogen advarsler. De rører ikke nogen del af det, applikationskode eller netværk eller noget af det. Er du sikker på, at din service vil være i gang efter en dag?

Spørgsmålet er så, hvordan man finder ud af, hvad der sker over linjen. Der er et par ting. Vi kan lære af studiet af andre højtempo-domæner med høj konsekvens, og hvis vi gør det, kan vi se, at vi kan studere hændelser. (Bemærk: Når jeg siger ”hændelser”, mener jeg skader, fornedrelser, brud, ulykker, næsten uheld og fejl - stort set uhensigtsmæssige eller uventede begivenheder).

Hvad gør hændelser interessante? Nå, det åbenlyse er tabte indtægter og omdømme påvirkninger på en bestemt virksomhed. Jeg vil gerne hævde et par andre grunde til, at hændelser er interessante. Den ene er, at hændelser former designet af nye komponentundersystemer og arkitekturer. Med andre ord, begivenheder i går informerer morgendagens arkitekturer. Det vil sige, at hændelser hjælper med at få vores fantasi til, hvordan vi gør vores systemer bedre, og det, jeg mener, er, at hændelser under liniedrevet ændres over linjen.

Det er den ting. Dette kan koste rigtige penge. Begivenheder kan undertiden næsten have stiltiende eller usynlige virkninger, nogle gange betydelige. Lige nu deler mange mennesker op en monolit i mikrotjenester. Mange mennesker gør det, fordi det giver en vis mængde robusthed, som du ikke har. Hvor får du det?

Du bliver informeret om hændelser.

En anden grund til at se på hændelser er, at de har tendens til at føde nye former for forskrifter, politikker, normer, overholdelse, revision, begrænsninger osv. En anden måde at sige dette på er, at begivenheder i går informerer morgendagens regler, som har indflydelse på personale , budgetter, planlægning, køreplaner og mere. Lad mig give dig et eksempel: I finansiel handel har SEC indført forordning SCI. SCI, er sandsynligvis det mest omfattende og detaljerede stykke overholdelse i moderne softwaretid. SEC er gået og været meget eksplicit. Vi har dette som en reaktion på flashnedbruddet i 2010 til Knight Capital, BATS IPO, Facebook IPO. Det er en reaktion på hændelser.

Selv hvis du går lidt længere tilbage, citeres det ofte, at PCI DSS skabte, da MasterCard og Visa sammenlignede noter, indså, at de tabte omkring $ 750 millioner over 10 år, så hændelser har betydelige, og forresten, kan jeg som en tidligere CTO for en offentlig virksomhed, kan jeg forsikre Dem om, at dette er en meget dyre, distraherende og uundgåeligt en byrdefuld albatross for alle dine organisationer. Hændelser er også markante på denne måde, men hvis vi tænker på hændelser som muligheder, hvis vi tænker på hændelser som beskeder, kodede meddelelser, der under linjen sender over linjen, og dit job er at afkode dem, hvis du tænker på hændelser som ting, der aktivt prøver at få din opmærksomhed på dele af systemet, som du troede, du havde en tilstrækkelig forståelse af, men som du ikke gjorde, er dette påmindelser om, at du konstant skal overveje, hvor sikker du er på, hvordan det hele fungerer.

Hvis du nu tager dette synspunkt, åbner en hel masse ting sig. Der er mulighed for ny træning, nyt værktøj, nye organisationsstrukturer, ny finansieringsdynamik og muligvis indsigt, som dine konkurrenter ikke har.

Hændelser hjælper os med at måle deltaet mellem, hvordan dit system fungerer, og hvordan vi synes, dit system fungerer, og dette delta er næsten altid større, end vi forestiller os. Jeg vil gerne hævde en anden tage, som du måske er vant til, og det er dette. Hændelser er ikke planlagte investeringer i virksomhed i din virksomheds overlevelse. Det er enormt værdifulde muligheder for at forstå, hvordan dit system fungerer, hvilke sårbarheder der er opmærksom på, og hvilke konkurrencefordele du ikke forfølger.

Hvis du tænker på hændelser, forbrænder de penge, tid, omdømme, personale osv. Dette er uundgåelige, sunkede omkostninger. Der er dog noget interessant ved denne type investering. Du kontrollerer ikke størrelsen på investeringen, så derfor er spørgsmålet stadig, hvordan vil du maksimere investeringsafkastet på investeringen?

Når vi ser på hændelser, er det den type spørgsmål, vi hører, og det er ret i overensstemmelse med, hvad forskere finder i andre komplekse systemer, domæner. Hvad laver det? Hvorfor gør det det? Hvad gør det derefter? Hvordan kom det ind i denne tilstand? Hvad sker der? Hvis vi gør Y, vil det hjælpe os med at finde ud af, hvad vi skal gøre? Blir det værre? Det ser ud som om det er løst, men er det? Hvis vi gør X, forhindrer det det, at det bliver værre, eller vil det gøre det værre? Hvem ellers skal vi kalde, der kan hjælpe os? Er dette vores problem, eller bliver vi angrebet? Dette er i overensstemmelse med mange andre områder. Luftfart, flyvekontrol, især inden for automatiseringsrige domæner.

En anden ting, der er bemærkelsesværdig, er, at begyndelsen på enhver hændelse, det ofte er usikker eller tvetydig om, om dette er det, der synker os. I begyndelsen af ​​en hændelse ved vi det simpelthen ikke, især om det indeholder enorme mængder usikkerhed og enorme mængder uklarhed. Hvis det er usikkert og tvetydigt, betyder det, at vi har udtømt vores mentale modeller. De passer ikke sammen med det, vi ser, og disse spørgsmål opstår. Kun i eftertid kan vi fortælle os, om det var den begivenhed, der bragte virksomheden ned, eller om det var en hård tirsdag eftermiddag.

Begivenheder giver kalibrering af, hvordan beslutninger er fokuseret, om, hvordan opmærksomhed er fokuseret, om, hvordan koordination er fokuseret, om, hvordan eskalering er fokuseret. Virkningen af ​​tidspress, virkningen af ​​usikkerhed, virkningen af ​​uklarhed og konsekvenserne af konsekvenser. Forskning validerer disse muligheder.

”Vi bør se dybt på begivenheder som” ikke-rutinemæssige udfordrende begivenheder, fordi disse hårde sager har det største potentiale for at afdække elementer af ekspertise og relaterede kognitive fænomener. ”
- Gary Klein, ophavsmand til naturalistisk beslutningsundersøgelse.

Der er en familie af veludslitte metoder, tilgange og teknikker. Kognitiv opgaveanalyse. Processporing. Samtaleanalyse. Den kritiske beslutningsmetode. Hvordan vi synes, at postmortems har værdi ser lidt sådan ud:

Der sker en hændelse. Måske vil nogen sammensætte en tidslinje. Vi har lidt af et møde. Måske har du en skabelon, og du udfylder den, og så kan nogen muligvis udarbejde en rapport eller ej, og så har du endelig handlinger. Vi tror, ​​at den største værdi, måske måske den onliest værdi, er hvor du er i en debriefing, og folk går gennem tidslinjen, og du er ligesom, "Åh, min Gud. Vi ved alt dette. ”

Dette er ikke, hvad forskningen viser. Forskningen viser, at hvis vi samler subjektive og objektive data fra flere steder, adfærdsdata, hvad folk sagde, hvad folk gjorde, hvor de kiggede, hvilke muligheder i diagnosen fulgte de og var ikke frugtbare? Godt lette debriefings får folk til at kontrastere og sammenligne deres mentale modeller, der nødvendigvis er mangelfulde. Du kan producere forskellige resultater, herunder ting som bootcamp, onboarding materialer, træning i ny leje. Du kan få feedback fra faciliteringen, hvis du bygger et program til at uddanne facilitatorer. Du foretager muligvis ændringer i køreplanen, virkelig markante ændringer baseret på det, du lærer.

Jeg kan fortælle dig dette af en eller anden erfaring. Der er intet mere indsigtsfuld over for en ny ingeniør eller en ingeniør, der lige starter i deres karriere end at være i et rum med en veteraningeniør, der kender alle de kriker og kroker, der forklarer ting, som de måske aldrig nogensinde har sagt højt. De har viden. De tegner måske billeder og diagrammer, som de aldrig har tegnet før, fordi de tror, ​​at alle andre ved det. Gæt hvad? De gør det ikke. Den største værdi er faktisk her, fordi kvaliteten af ​​disse resultater afhænger af kvaliteten af ​​den, denne rekalibrering. Dette er en åbning for at kalibrere mentale modeller igen.

Fra Stella-rapporten "informerer og kalibrerer folks modeller for, hvordan systemet fungerer, deres forståelse af, hvordan det er sårbart, og hvilke muligheder der er til rådighed for efterforskning."

I en masse af forskningen, i al den forskning, der er indeholdt i Stella-rapporten, og den passer også til min erfaring hos Etsy, en af ​​reflektionens stærkeste fra mennesker, der gør dette på en lettere måde at gøre dette sammenligning og kontrasterende. ”Jeg vidste ikke, at det fungerede på den måde.” Så er der altid andet, ”Hvordan fungerede det nogensinde?” Hvilket er sjovt, indtil du er klar over, at det er alvorligt. Hvad det betyder er, måden ikke kun jeg troede, at den fungerede på en anden måde. Nu kan jeg ikke engang forestille mig, jeg kan ikke engang tegne et billede i mit sind om, hvordan det muligvis kunne have fungeret. Det burde være mere foruroligende. For øvrig vil jeg sige, at dette ikke er justering. Som jeg sagde, via repræsentationer har vi nødvendigvis ufuldstændige mentale modeller. Ideen er ikke at have de samme mentale modeller, fordi de altid er ufuldstændige, fordi ting altid ændrer sig, og fordi de kommer til at være defekte. Vi ønsker ikke, at alle skal have den samme mentale model, for da har alle de samme blinde pletter.

Blameless - går tilbage til blogindlægget, som jeg skrev i 2012

"Blameless" er tabelindsatser. Det er nødvendigt, men det er ikke tilstrækkeligt. Du kan opbygge et miljø, en kultur, en favnende, en slags indbydende organisation, der understøtter og giver folk mulighed for at fortælle historier i alle de rodede detaljer, sommetider pinlige detaljer uden frygt for gengældelse, så du virkelig kunne gøre fremskridt, og i forståelsen af ​​hvad der sker, kan du indstille den tilstand og stadig ikke lære meget. Det er ikke tilstrækkeligt. Det er nødvendigt, men ikke tilstrækkeligt. Hvad jeg taler om er meget mere kræfter end typiske anmeldelser efter hændelsen. Ret? Det er her en analytiker, en facilitator kan forberede, sortere, organisere, analysere adfærdsdata. Hvad folk siger, hvad folk gør. Der er en række data, som de kan sigtes igennem for at forberede debriefings, en gruppe-debriefing eller en en-til-en-debriefing, der går ud over ... Postmortems antyder begivenhedernes rigdom. Opfølgning på dette tager meget arbejde.

For øvrig er alle generelt så udmattede efter en virkelig, en stressende afbrydelse eller hændelse eller begivenhed, at nogle gange alt bliver krystalklart. Det er bagspejlsens kraft, og fordi det ser så krystalklart ud, virker det ikke produktivt at have en debriefing, fordi du tror, ​​du allerede ved det hele. Det andet spørgsmål er, at briefinger efter postmortem også er begrænset af tiden. Du har kun konferencelokalet i en time eller to. Alle er virkelig travlt, og uret tikker, så det er en udfordring at gøre det rigtig godt, selv i betragtning af disse forskningsmetoder.

Det andet spørgsmål, især hvis du bygger et uddannelsesprogram for debriefing, som jeg gjorde på Etsy, er der stadig udfordringer. Det, jeg gerne kalder det, er, "Alle har deres eget mysterium at løse", eller "Spild ikke min tid på detaljer, som jeg allerede kender." På en tegneserievenlig måde kan du tænke på det på denne måde:

Fordi du muligvis kun har en time, er du nødt til at udtrække så meget læring, som du kan. Alt arbejde er kontekstuelt. Dit job for at maksimere ROI er at opdage, udforske og genopbygge den kontekst, hvori der udføres arbejde i en hændelse, hvordan arbejde og hvordan folk tænkte over linjen.

Evalueringer er afvejninger, og de er kontekstuelle.

Afslutningsvis kan alle hændelser være værre. Et overfladisk syn er at spørge: ”Hvad gik galt? Hvordan brød det? Hvad løser vi? ”Dette er meget rimelige spørgsmål. Hvis vi skulle tage et dybere niveau, og vi kunne spørge: "Hvad er de ting, der gik i at gøre det ikke næsten så dårligt, som det kunne have været?" Fordi vi ikke er opmærksomme på disse ting og ikke identificerer disse ting, kan vi stoppe med at støtte disse ting.

Måske er grunden til, at det ikke blev værre, fordi nogen kaldte Lisa, og Lisa kender hendes ting. Noget fra forskning er, at eksperter kan se, hvad der ikke er der. Hvis du ikke støtter Lisa, og du ikke engang identificerer, at grunden til, at det ikke blev værre, er fordi Lisa var der. Glem handlingselementer til at løse noget et øjeblik. Forestil dig en verden, hvor Lisa går til et nyt job.

Nyttigt på strategisk niveau er et bedre spørgsmål. ”Hvordan kan vi støtte, opmuntre, gå ind for og finansiere den kontinuerlige forståelsesproces i vores systemer? Og virkelig tage “over linjen” på en vedvarende måde?

Hvor går vi hen herfra? Jeg har nogle udfordringer for dig:

  1. Cirkulér Stella-rapporten i din virksomhed og start en dialog. Selvom du har det for travlt, eller hvis du ikke er i stand til at læse det selv, skal du give det til folk, der gør det. Spørg dem, hvad der resonerer. Spørg dem, hvad der ikke giver mening. Spørg dem, start en dialog.
  2. Se dybt på, hvordan du håndterer anmeldelser efter begivenheden. Vigtigst er det, at finde de mennesker, der er bedst fortrolige med de rodede detaljer om, hvordan arbejde udføres, og spørg dem om dette: ”Hvilken værdi tror du, at vores aktuelle anmeldelser efter hændelsen virkelig har?” Og lyt.
  3. Tag ansvaret for at lære mere og hurtigere af hændelser end dine konkurrenter. Du bygger enten en lærende organisation, eller du taber til en der er.
  4. Vi er nødt til at tage menneskelige præstationer alvorligt. Denne diskussion sker. Det sker i atomkraft. Det sker inden for medicin. Det sker inden for luftfart, lufttrafikstyring, brandbekæmpelse.

Den stigende betydning af vores systemer, det stigende potentiale for økonomiske, politiske og menneskelige skader, når de ikke fungerer korrekt, og spredningen af ​​afhængigheder og den dertil knyttede usikkerhed gør mig meget bekymret. Hvis du ser på dit eget system og dets problemer, tror jeg, at du er enig i, at vi er nødt til at gøre meget mere end at erkende dette problem. Vi er nødt til at omfavne det. Hvad du kan hjælpe mig med, skal du sprede disse oplysninger, disse ideer og min præsentation fra DevOps Enterprise Summit San Francisco 2017.

Jeg vil gerne høre fra dig. Hvad resonerede med dig om dette? Hvad gjorde det ikke? Hvilke udfordringer står du overfor i din org på disse linjer? Kom fortæl mig. Jeg er på Twitter.

Oprindeligt offentliggjort på itrevolution.com den 30. april 2018.