John Allspaw, medstifter, Adaptive Capacity Labs

Hur dina system fortsätter att köras dag efter dag

Först lite om John Allspaw, grundare av Adaptive Capacity Labs och tidigare teknikchef för Etsy.

Som ingenjörsledare och forskare med över 20 års erfarenhet av att bygga och leda team som arbetar med mjukvaru- och systemteknik har Allspaw tillbringat det senaste decenniet med att överbrygga insikter från mänskliga faktorer, kognitiv systemteknik och resilience engineering till området för programvaruteknik och operationer.

Även författaren till två böcker, "The Art of Capacity Planning: Scaling Web Resources" och "Web Operations" (O’Reilly Media), fortsätter Allspaw att bidra till IT- och DevOps-samhällena genom att tala och samarbeta om ny, spännande forskning.

Vi hade turen att vara värd för John på DevOps Enterprise Summit i San Francisco, där han gick till scenen för att prata om ”Hur system fortsätter att köras dag efter dag.” Nedan har vi transkriberat de viktigaste takeaways och de viktigaste höjdpunkterna i hans presentation .

John Allspaw på DOES17 San Francisco

John Allspaw

Hur dina system fortsätter att köras dag efter dag

Det jag vill prata om är nytt. Det är annorlunda, och jag känner mig väldigt, väldigt starkt över detta.

För att sätta upp scenen var min avhandling för min examen i mänskliga faktorer och systemsäkerhet "Trade-Offs Under Pressure: Heuristics and Observations Of Teams Resolving Internet Service Outages."

Några av er kanske har hört talas om detta, vad som kallas Stella-rapporten.

På en hög nivå är denna rapport resultatet av ett årlångt projekt av ett konsortium av industripartners. IBM, Etsy och IEX, handelsföretag, ett handelsbörs på Manhattan. Under detta år såg folk från Ohio State University Cognitive Systems Engineering Lab, David Woods, Richard Cook och ett antal andra människor djupt på en incident i var och en av dessa organisationer.

De hittade dessa sex teman och var vanliga i alla av dem.

Visst är resultaten ganska viktiga. Det är så den forskningen gjordes som jag vill att ni alla ska titta på.

Här är mina viktigaste takeaways från rapporten:

  1. Vi måste börja ta mänskliga prestationer på allvar i denna bransch. Om vi ​​inte gör det kommer vi att fortsätta att se spröda system med allt större effekter på våra företag och på samhället.
  2. Vi kan göra detta genom att titta på incidenter som går utöver vad vi för närvarande gör i postmortems eller granskningar efter incidenten eller granskningar efter åtgärden.
  3. Det finns metoder och tillvägagångssätt från studien av motståndskraft i andra områden, men de kräver verkligt engagemang för att sträva efter. Att göra detta är både nödvändigt och svårt, men det kommer att visa sig vara en konkurrensfördel för företag som gör det bra.

Först vill jag börja med lite av en baslinje, lite av ett ordförråd som kommer att bli viktigt när jag på ett sätt leder dig igenom det här. Jag kommer att beskriva en sorts bild, en representation, som en mental modell för dina organisationer, och det kommer att ha en region ovanför och en region under linjen.

Om du föreställer dig vad vi har skildrat här är detta din produkt, din tjänst, ditt API eller vad ditt företag härrör från och ger kunderna. Okej? Där inne är det du ser din kod. Du ser din teknikbunt. Du ser informationen och några olika sätt att leverera detta, eller hur? Förmodligen via internet eller på något annat sätt. Men om vi stannar här, kommer ingen att tro mig att det är det vi kallar systemet, för det är bra, men det är inte riktigt komplett.

Vad som verkligen är kopplat till, och vad många människor har pratat om här i DevOps Enterprise Summit community är allt vi gör för att manipulera det som händer där, och så har vi testverktyg. Vi har övervakningsverktyg. Vi har distribueringsverktyg och allt det som är kopplat till. Det här är de saker som vi använder. Du kan säga att detta är systemet, eftersom många av oss tillbringar vår tid fokuserad på de saker som inte finns i den lilla bubblan där, men alla de saker som finns runt det, men om vi skulle stanna bara med detta, vi kan inte se var det verkliga arbetet händer.

Det vi ska göra här är att vi kommer att rita en linje som vi kallar representationslinjen och sedan gräva lite djupare. Det vi ser här är du. Alla människor som gör saker redo att lägga till i systemet, för att ändra systemet. Du gör den arkitektoniska inramningen. Du gör övervakning. Du håller reda på vad det gör, hur det gör och vad som händer med dem.

Nu kommer du att märka att var och en av dessa människor har någon form av mental representation om vad detta system är. Om du tittar på det lite närmare ser du att ingen av dem är desamma. Det är förresten mycket karakteristiskt för dessa typer av roller. Ingen har samma representation av vad som ligger under linjen.

Sammanfattningsvis är detta vår modell av världen, och den inkluderar inte bara de saker som kör där, utan alla er, de typer av aktiviteter du utför, det kognitiva arbetet som du gör för att hålla den världen fungerande . Om vi ​​leker med detta lite mer, hamnar vi med den här typen av modell. Den här modellen har en representationslinje som går igenom mitten, och du interagerar med världen under linjen via en uppsättning representationer.

Dina interaktioner är aldrig med själva sakerna. Du ändrar inte faktiskt systemen.

Det du gör är att du interagerar med representationen och att representation är något om vad som händer nedan. Du kan tänka på de gröna sakerna som de skärmar du tittar på under dagen, men den enda information du har om systemet kommer från dessa representationer. De är bara ett litet nyckelhål. Höger?

Det som är betydelsefullt med det är att alla aktiviteter du gör, alla att observera, dra slutsatsen, förutse, planera, korrigera, alla dessa saker måste göras via dessa representationer, så det finns en värld över linjen och en värld under linjen, och även om du och vi mestadels talar om världen under linjen som om det är väldigt verkligt, som om det är väldigt konkret, som om det är något som det är saken, här är överraskningen.

Här är den stora saken - du får aldrig se det.

Det finns inte. I verklig mening finns det ingen under linjen som du faktiskt kan röra vid. Du ser aldrig koden köras. Du ser aldrig att systemet faktiskt fungerar. Du rör aldrig på de sakerna.

Det du gör är att du manipulerar en värld som du inte kan se via en uppsättning representationer, och det är därför du behöver bygga de mentala modellerna, dessa föreställningar, de förståelser om vad som händer. Det är de saker som driver den manipulationen. Det är inte världen under linjen som gör det. Det är din konceptuella förmåga att förstå de saker som har hänt tidigare, de saker du gör nu och varför du gör dessa saker, vad som är viktigt och varför det som faktiskt betyder något.

När du antar detta perspektiv, när du går bort att tanken att under linjen är det du har att göra med och förstår att du verkligen arbetar ovanför raden förändras alla möjliga saker.

Det du ser i Stella-rapporten och det projektet och andra projekt som vi har arbetat med tar den åsikten och förstår vad det verkligen betyder att ta världen ovan på allvar. Det här är en stor avvikelse från mycket av det du har sett tidigare, men jag tror att det är en fruktbar riktning som vi måste ta.

Med andra ord, dessa kognitiva aktiviteter (se nedan) hos både individer och tillsammans i team upp och ner i organisationen är det som gör att verksamheten faktiskt fungerar. Nu har jag studerat detta i detalj här ganska länge här, och jag kan berätta det här. Det fungerar inte som vi tror.

Slutligen, för att sätta upp denna ram, är den viktigaste delen av denna idé att allt detta förändras över tid. Det är en dynamisk process som pågår. Detta är analysenheten. När vi har tagit den ramen kan vi ställa några frågor. Vi kan ställa några frågor om ovanför linjen så här.

"Hur fungerar vår programvara verkligen, jämfört med hur den beskrivs i wiki och i dokumentation och i diagrammen? Vi vet att de inte är heltäckande, de är inte helt korrekta. ”

"Hur bryts vår programvara verkligen, jämfört med hur vi trodde att den skulle gå sönder när vi designade skyddsanordningar och brytare och skyddsräcken?"

"Vad gör vi för att det ska fungera?"

Fråga: Föreställ dig din organisation. Vad skulle hända om idag klockan sex skulle alla dina företag ta handen från tangentbordet? De svarar inte på några sidor. De tittar inte på några varningar. De rör inte någon del av det, applikationskod eller nätverk eller någon av dem. Är du säker på att din tjänst kommer att vara igång efter en dag?

Frågan är då hur man upptäcker vad som händer ovanför linjen. Det finns ett par saker. Vi kan lära oss av studier av andra högtempo-domäner med hög konsekvens, och om vi gör det kan vi se att vi kan studera incidenter. (Observera: när jag säger ”händelser”, menar jag avbrott, försämringar, överträdelser, olyckor, nästan misslyckanden och fel - i grund och botten otrevliga eller oväntade händelser).

Vad gör incidenter intressanta? Det är uppenbart att förlorade intäkter och rykte påverkar en viss verksamhet. Jag vill hävda ett par andra skäl till att incidenter är intressanta. Den ena är att incidenter formar utformningen av nya komponentundersystem och arkitekturer. Med andra ord, händelser i går informerar morgondagens arkitekturer. Det vill säga, incidenter hjälper till att driva våra fantasier om hur vi kan göra våra system bättre, och därför menar jag att händelser under linjedriften ändras över linjen.

Det är saken. Detta kan kosta riktiga pengar. Incidenter kan ibland ha nästan tyst eller osynliga effekter, ibland betydande. Just nu delar många människor upp en monolit i mikrotjänster. Många gör det eftersom det ger en viss mängd robusthet som du inte har. Var får du det?

Du får information om incidenter.

En annan anledning att titta på incidenter är att de tenderar att föda nya former av förordningar, policyer, normer, efterlevnad, revision, begränsningar etc. Ett annat sätt att säga detta är att händelser i går informerar morgondagens regler som påverkar bemanningen , budgetar, planering, färdplaner och mer. Låt mig ge dig ett exempel: I finansiell handel har SEC inrättat förordningen SCI. SCI, är förmodligen den mest omfattande och detaljerade delen av efterlevnaden i modern mjukvarutid. SEC har gått och varit mycket uttryckligt. Vi har detta som en reaktion på flashkraschen 2010 till Knight Capital, BATS IPO, Facebook IPO. Det är en reaktion på incidenter.

Även om du går tillbaka lite längre, citeras det ofta att PCI DSS kom till när MasterCard och Visa jämförde anteckningar, insåg att de tappade ungefär 750 miljoner dollar under tio år, så incidenter har betydande, och förresten, jag kan, som en tidigare CTO för ett offentligt företag, kan jag försäkra er att detta är en mycket dyr, distraherande och oundvikligen en betungande albatross för alla dina organisationer. Incidenter är betydelsefulla också på detta sätt, men om vi tänker på incidenter som möjligheter, om vi tänker på incidenter som meddelanden, kodade meddelanden som under linjen skickar över linjen, och ditt jobb är att avkoda dem, om du tänker på incidenter som saker som aktivt försöker få din uppmärksamhet till delar av systemet som du trodde att du hade en tillräcklig förståelse för men som du inte gjorde det, detta är påminnelser om att du måste kontinuerligt ompröva hur säker du är på hur allt fungerar.

Om du håller med den här uppfattningen öppnas en hel massa saker. Det finns möjlighet till ny utbildning, nytt verktyg, nya organisationsstrukturer, ny finansieringsdynamik och eventuellt insikter som dina konkurrenter inte har.

Incidenter hjälper oss att mäta deltaet mellan hur ditt system fungerar och hur vi tror att ditt system fungerar, och detta delta är nästan alltid större än vi föreställer oss. Jag vill hävda kanske ett annat tag som du kanske är van vid, och det är detta. Incidenter är inte planerade investeringar i företag, i ditt företags överlevnad. Det är oerhört värdefulla möjligheter att förstå hur ditt system fungerar, vilka sårbarheter i uppmärksamhet finns och vilka konkurrensfördelar du inte strävar efter.

Om du tänker på incidenter så bränner de pengar, tid, rykte, personal etc. Dessa är oundvikliga sänkta kostnader. Något är intressant med den här typen av investeringar. Du kontrollerar inte storleken på investeringen, så därför kvarstår frågan, hur kommer du att maximera avkastningen på investeringen?

När vi tittar på incidenter är det den typen av frågor som vi hör och det är ganska förenligt med vad forskare hittar i andra komplexa system, domäner. Vad gör det? Varför gör det det? Vad kommer det att göra härnäst? Hur kom det in i detta tillstånd? Vad händer? Om vi ​​gör Y, kommer det att hjälpa oss ta reda på vad vi ska göra? Blir det värre? Det ser ut som det är fixat, men är det? Om vi ​​gör X, kommer det att förhindra att det blir värre, eller kommer det att göra det värre? Vem annars ska vi ringa som kan hjälpa oss? Är detta vår fråga, eller attackeras vi? Detta är förenligt med många andra områden. Flyg, flygkontroll, särskilt inom automatiseringsdomäner.

En annan sak som är anmärkningsvärd är att början på varje incident är ofta osäker eller tvetydig om det är den som sjunker oss eller inte. I början av en incident vet vi helt enkelt inte, särskilt om det innehåller enorma mängder osäkerhet och enorma mängder av tvetydighet. Om det är osäkert och tvetydigt, betyder det att vi har uttömt våra mentala modeller. De passar inte med det vi ser, och dessa frågor uppstår. Endast eftertanke kommer att berätta om det var händelsen som förde ned företaget eller om det var en tuff tisdag eftermiddag.

Incidenter ger kalibrering av hur beslut är fokuserade, om hur uppmärksamhet är fokuserad, om hur samordning är fokuserad, om hur eskalering är fokuserad. Effekterna av tidspress, effekterna av osäkerhet, påverkan av tvetydighet och konsekvenserna av konsekvenser. Forskning validerar dessa möjligheter.

"Vi bör titta djupt på incidenter som" icke-rutinmässiga utmanande händelser, eftersom dessa tuffa fall har den största potentialen för att avslöja delar av expertis och relaterade kognitiva fenomen. "
- Gary Klein, upphovsmannen till naturalistisk beslutsfattande forskning.

Det finns en familj av välslitna metoder, metoder och tekniker. Kognitiv uppgiftsanalys. Processspårning. Konversationsanalys. Den kritiska beslutsmetoden. Hur vi tror att postmortems har värde ser lite ut så här:

En händelse inträffar. Kanske kommer någon att sätta ihop en tidslinje. Vi har lite av ett möte. Kanske har du en mall och du fyller i den, och sedan kan någon göra en rapport eller inte, och sedan har du äntligen actionobjekt. Vi tror att det största värdet, kanske det mest värdefulla värdet, är där du befinner dig i en debriefing och människor går igenom tidslinjen och du gillar: "Åh, min Gud. Vi vet allt detta. ”

Detta är inte vad forskningen visar. Forskningen visar att om vi samlar subjektiva och objektiva data från flera platser, beteendedata, vad folk sa, vad människor gjorde, var de tittade, vilka vägar i diagnos följde de och var inte fruktbara? Väl underlättade debriefings får människor att kontrastera och jämföra sina mentala modeller som nödvändigtvis är felaktiga. Du kan producera olika resultat, inklusive saker som bootcamp, ombordmaterial, utbildning för ny hyra. Du kan ha underlättningsåterkoppling om du bygger ett program för att utbilda facilitatorer. Du kan göra färdplanändringar, verkligen betydande förändringar baserat på vad du lär dig.

Jag kan berätta det här av någon erfarenhet. Det finns inget mer insiktsfullt för en ny ingenjör eller en ingenjör som bara börjar i sin karriär än att vara i ett rum med en veteraningenjör som känner till alla krök och krokar som förklarar saker som de kanske aldrig har sagt högt. De har kunskap. De kan rita bilder och diagram som de aldrig har ritat förut eftersom de tror att alla andra vet det. Gissa vad? Det gör de inte. Det största värdet är faktiskt här, eftersom kvaliteten på dessa resultat beror på kvaliteten på den, den omkalibreringen. Detta är en öppning för att kalibrera mentalmodeller.

Från Stella-rapporten "informerar och kalibrerar människors modeller om hur systemet fungerar, deras förståelse för hur det är sårbart och vilka möjligheter som finns för utforskning."

I mycket av forskningen, i all den forskning som ingår i Stella-rapporten, och den passar också med min erfarenhet hos Etsy, en av, reflektionens starkaste från människor som gör detta på ett underlättat sätt att göra detta jämförande och kontrasterande. "Jag visste inte att det fungerade på det sättet." Sedan finns det alltid andra, "Hur fungerade det någonsin?" Vilket är roligt tills du inser att det är allvarligt. Vad det betyder är hur jag inte bara trodde att det fungerade på ett annat sätt. Nu kan jag inte ens föreställa mig, jag kan inte ens rita en bild i mitt sinne av hur det kan ha fungerat. Det borde vara mer oroande. Förresten, jag vill säga att detta inte är anpassning. Som jag sa, via representationer har vi nödvändigtvis ofullständiga mentala modeller. Tanken är inte att ha samma mentala modeller, eftersom de alltid är ofullständiga, eftersom saker alltid förändras och för att de kommer att vara felaktiga. Vi vill inte att alla ska ha samma mentala modell eftersom alla har samma blinda fläckar.

Blameless - går tillbaka till blogginlägget som jag skrev 2012

"Blameless" är tabeller. Det är nödvändigt, men det räcker inte. Du kan bygga en miljö, en kultur, en omfamning, en slags välkomnande organisation som stöder och tillåter människor att berätta historier i alla smutsiga detaljer, ibland pinsamma detaljer, utan rädsla för vedergällning, så att du verkligen kunde göra framsteg, och när du förstår vad som händer kan du ställa in det villkoret och fortfarande inte lära dig så mycket. Det räcker inte. Det är nödvändigt, men inte tillräckligt. Det jag talar om är mycket mer ansträngning än typiska recensioner efter incidenten. Höger? Det är här en analytiker, en facilitator kan förbereda, sortera, organisera, analysera beteendedata. Vad folk säger, vad folk gör. Det finns ett flertal data som de kan sifta igenom för att förbereda för debriefings, en grupp debriefing eller en en-till-en debriefing, gå utöver ... Postmortems antydar till rikedom av incidenter. Att följa upp detta kräver mycket arbete.

Förresten, alla är i allmänhet så utmattade efter en riktigt, en stressig avbrott eller händelse eller händelse att ibland allt blir kristallklart. Det är efterhandens kraft och eftersom det verkar så kristallklart verkar det inte vara produktivt att ha en debriefing, eftersom du tror att du redan vet allt. Den andra frågan är att briefings efter postmortem också begränsas av tiden. Du har bara konferensrummet i en timme eller två. Alla är riktigt upptagna och klockan tickar, så det är en utmaning att göra det riktigt bra, även med tanke på dessa forskningsmetoder.

Den andra frågan, särskilt om du bygger ett utbildningsprogram för debriefing som underlättar som jag gjorde på Etsy, finns det fortfarande utmaningar som dyker upp. Det jag gillar att kalla det är, "Alla har sitt eget mysterium att lösa", eller "Slösa inte min tid på detaljer som jag redan känner till." På ett karikatyriskt sätt kan du tänka på det på detta sätt:

Eftersom du kanske bara har en timme behöver du ta ut så mycket lärande du kan. Allt arbete är kontextuellt. Ditt jobb för att maximera ROI är att upptäcka, utforska och bygga om det sammanhang som arbetet utförs i en incident, hur arbetet och hur människor tänkte ovanför linjen.

Bedömningar är avvägningar och de är kontextuella.

Avslutningsvis kan alla incidenter vara värre. En ytlig uppfattning är att fråga, ”Vad gick fel? Hur bröt det? Vad fixar vi? ”Det här är mycket rimliga frågor. Om vi ​​skulle ta en djupare nivå och vi skulle kunna fråga: "Vad är det som gick för att göra det inte så illa som det kunde ha varit?" Eftersom vi inte uppmärksammar dessa saker och inte identifierar dessa saker, kan vi sluta stödja dessa saker.

Kanske orsaken till att det inte blev värre är att någon heter Lisa och Lisa känner till hennes grejer. Något från forskning är att experter kan se vad som inte finns där. Om du inte stöder Lisa och du inte ens identifierar att orsaken till att det inte blev värre är att Lisa var där. Glöm handlingar för att fixa något för ett ögonblick. Föreställ dig en värld där Lisa går till ett nytt jobb.

Användbar på strategisk nivå är en bättre fråga. ”Hur kan vi stödja, uppmuntra, förespråka och finansiera den ständiga förståelseprocessen i våra system? Och verkligen ta ”över linjen” på ett hållbart sätt?

Var går vi härifrån? Jag har några utmaningar för dig:

  1. Cirkulera Stella-rapporten i ditt företag och starta en dialog. Även om du är för upptagen eller om du inte kan läsa den själv, ge den till människor som gör det. Fråga dem vad som resonerar. Fråga dem vad som inte är vettigt. Fråga dem, starta en dialog.
  2. Titta djupt på hur du hanterar recensioner efter händelser. Det viktigaste är att hitta de personer som är mest bekanta med de röriga detaljerna om hur arbetet görs och fråga dem detta: "Vilket värde tycker du att våra nuvarande recensioner efter incidenten verkligen har?" Och lyssna.
  3. Ta ansvaret för att lära sig mer och snabbare av incidenter än dina konkurrenter. Du bygger antingen en lärande organisation eller tappar för någon.
  4. Vi måste ta mänskliga prestationer på allvar. Denna diskussion händer. Det händer med kärnkraft. Det händer inom medicinen. Det händer inom flyg, flygkontroll, vid brandbekämpning.

Den ökande betydelsen av våra system, den ökande potentialen för ekonomisk, politisk och mänsklig skada när de inte fungerar korrekt och spridningen av beroenden och därmed förknippad osäkerhet gör mig väldigt orolig. Om du tittar på ditt eget system och dess problem tror jag att du håller med om att vi måste göra mycket mer än att erkänna detta problem. Vi måste omfamna det. Vad du kan hjälpa mig med, sprid denna information, dessa idéer och min presentation från DevOps Enterprise Summit San Francisco 2017.

Jag vill höra från dig. Vad resonerade med dig om detta? Vad gjorde det inte? Vilka utmaningar står du inför i din org enligt dessa linjer? Kom berätta. Jag är på Twitter.

Ursprungligen publicerad på itrevolution.com den 30 april 2018.