Verkligheten för en nätverksingenjör (med nudlar och... salt?)
Nyligen, när jag diskuterade olika incidenter med ingenjörer, märkte jag ett intressant mönster.
I dessa diskussioner kommer alltid frågan om "grundorsaken" upp. Trogna läsare vet nog att jag har på . I många organisationer bygger incidentanalys helt på detta koncept. De använder olika tekniker för att identifiera orsak- och verkan-samband, som t.ex . Dessa metoder antar den så kallade "händelsernas linjäritet" som en obestridlig dogm.
När du utmanar denna idé och påpekar att linjäritet är betryggande bedrägligt i komplexa system föds en fascinerande diskussion. Disputanter insisterar passionerat på att endast kunskap om "grundorsaken" tillåter oss att förstå vad som händer.
Jag märkte ett intressant mönster: utvecklare och devops reagerar olika på den här idén. Enligt min erfarenhet är utvecklare mer benägna att hävda att grundorsaken spelar roll och att orsak och verkan alltid kan etableras i händelser. Å andra sidan är DevOps oftare överens om att en komplex värld inte alltid lyder linjäritet.
Jag har alltid undrat varför detta är? Vad gör programmerare att kritisera idén "grundorsaken är en myt" på det sättet? Som ett immunsystem som känner igen en främmande agent. Varför reagerar de på detta sätt, medan devoperna ganska benägen överväga denna idé?
Jag är inte helt säker, men jag har några tankar kring detta. Den relaterar till de olika sammanhang där dessa yrkesverksamma utför sitt dagliga arbete.
Utvecklare arbetar ofta med deterministiska verktyg. Naturligtvis kompilatorer, länkare, operativsystem - alla dessa är komplexa system, men vi är vana vid det faktum att de ger ett deterministiskt resultat, och vi föreställer oss dem som deterministiska: om vi tillhandahåller samma indata, förväntar vi oss vanligtvis samma utdata från dessa system. Och om det finns ett problem med utdata ("bugg"), löser utvecklarna det genom att analysera indata (antingen från användaren eller från en uppsättning verktyg under utvecklingsprocessen). De letar efter ett "fel" och ändrar sedan indata. Detta fixar "buggen".
Grundläggande antagande om mjukvaruutveckling: samma indata producerar tillförlitligt och deterministiskt samma utdata.
Faktum är att ett icke-deterministiskt resultat i sig betraktas som en bugg: om den oväntade eller felaktiga utdata inte reproduceras, tenderar utvecklare att utvidga undersökningen till andra delar av stacken (operativsystem, nätverk, etc.), som också beter sig mer eller mindre deterministiskt, producerar samma resultat med samma indata... och om så inte är fallet, då anses detta fortfarande vara ett fel. Det är just nu ett operativsystem eller nätverksbugg.
I vilket fall som helst är determinism ett grundläggande, nästan självklart antagande för de flesta av det arbete som programmerare gör.
Men för alla devops-killar som har tillbringat dagen med att samla ihop hårdvara eller hitta ett moln-API, är idén om en helt deterministisk värld (så länge det ens är möjligt att kartlägga alla ingångar!) i bästa fall ett flyktigt koncept. Även om man lägger det åt sidan , har erfarna ingenjörer sett de konstigaste sakerna i denna värld. Det vet de , för att inte tala om miljontals andra faktorer i miljön.
Så det är lättare för erfarna ingenjörer att tvivla på att alla incidenter har en enda grundorsak, och tekniker som de "fem varför" kommer korrekt (och upprepade gånger!) att leda till den bakomliggande orsaken. Detta motsäger faktiskt deras egen erfarenhet, där pusselbitarna inte passar så snyggt i praktiken. Därför accepterar de denna idé lättare.
Naturligtvis säger jag inte att utvecklare är naiva, dumma eller oförmögna att förstå hur linjäritet kan vara vilseledande.
Men det förefaller mig som om en vanlig reaktion från utvecklare i dessa debatter ofta har att göra med att begreppet determinism tjänar dem bra överlag i det dagliga arbetet. De möter inte odeterminism så ofta som ingenjörer måste fånga Schrödingers katter på deras infrastruktur.
Detta kanske inte helt förklarar de observerade utvecklarens reaktioner, men det är en kraftfull påminnelse om att våra reaktioner är en komplex blandning av många faktorer.
Det är viktigt att komma ihåg denna komplexitet, oavsett om vi har att göra med en enstaka incident, samarbetar i en mjukvaruleveranspipeline eller försöker förstå den bredare världen.
Källa: will.com