Virkeligheten til en nettverksingeniør (med nudler og... salt?)
Nylig, mens jeg diskuterte ulike hendelser med ingeniører, la jeg merke til et interessant mønster.
I disse diskusjonene kommer spørsmålet om "grunnårsak" alltid opp. Trofaste lesere vet nok at jeg har på . I mange organisasjoner er hendelsesanalyse helt basert på dette konseptet. De bruker ulike teknikker for å identifisere årsak-virkning-sammenhenger, som f.eks . Disse metodene antar den såkalte "lineariteten av hendelser" som et udiskutabelt dogme.
Når du utfordrer denne ideen og påpeker at linearitet er betryggende villedende i komplekse systemer, oppstår en fascinerende diskusjon. Disputanter insisterer lidenskapelig på at bare kunnskap om "grunnårsaken" lar oss forstå hva som skjer.
Jeg la merke til et interessant mønster: utviklere og devops reagerer annerledes på denne ideen. Etter min erfaring er det mer sannsynlig at utviklere argumenterer for at grunnårsaken betyr noe og at årsak-og-virkning-forhold alltid kan etableres i hendelser. På den annen side er DevOps oftere enige om at en kompleks verden ikke alltid adlyder linearitet.
Jeg har alltid lurt på hvorfor dette er? Hva gjør at programmerere til å kritisere ideen "grunnårsaken er en myte" på den måten? Som et immunsystem som gjenkjenner en fremmed agent. Hvorfor reagerer de på denne måten, mens devopene heller tilbøyelig vurdere denne ideen?
Jeg er ikke helt sikker, men jeg har noen tanker rundt dette. Den relaterer seg til de ulike kontekstene disse fagpersonene utfører sitt daglige arbeid i.
Utviklere jobber ofte med deterministiske verktøy. Selvfølgelig, kompilatorer, linkere, operativsystemer - alt dette er komplekse systemer, men vi er vant til det faktum at de gir et deterministisk resultat, og vi forestiller oss dem som deterministiske: hvis vi gir de samme inndataene, forventer vi vanligvis at samme utgang fra disse systemene. Og hvis det er et problem med utdataene ("bug"), løser utviklerne det ved å analysere inndataene (enten fra brukeren eller fra et sett med verktøy under utviklingsprosessen). De ser etter en "feil" og endrer deretter inndataene. Dette fikser "feilen".
Grunnleggende antakelse om programvareutvikling: de samme inngangsdataene produserer pålitelig og deterministisk det samme resultatet.
Faktisk betraktes et ikke-deterministisk resultat i seg selv som en feil: hvis den uventede eller feilaktige utgangen ikke reproduseres, har utviklere en tendens til å utvide etterforskningen til andre deler av stabelen (operativsystem, nettverk, etc.), som også oppfører seg mer eller mindre deterministisk, produsere det samme resultatet med de samme inndataene... og hvis det ikke er det, så regnes dette fortsatt som en feil. Det er akkurat nå en operativsystem- eller nettverksfeil.
Uansett er determinisme en grunnleggende, nesten gitt antagelse for det meste av arbeidet programmerere gjør.
Men for enhver devops-fyr som har brukt dagen på å samle opp maskinvare eller finne ut et sky-API, er ideen om en fullstendig deterministisk verden (så lenge det til og med er mulig å kartlegge alle inngangene!) i beste fall et flyktig konsept. Selv om du legger det til side , erfarne ingeniører har sett de merkeligste tingene i denne verden. Det vet de , for ikke å nevne millioner av andre faktorer i miljøet.
Så det er lettere for erfarne ingeniører å tvile på at alle hendelser har én enkelt årsak, og teknikker som de "fem hvorfor" vil riktig (og gjentatte ganger!) føre til den rotårsaken. Dette strider faktisk mot deres egen erfaring, hvor puslespillbrikkene ikke passer så pent i praksis. Derfor aksepterer de denne ideen lettere.
Jeg sier selvfølgelig ikke at utviklere er naive, dumme eller ute av stand til å forstå hvordan linearitet kan være villedende.
Men det virker for meg som en vanlig reaksjon fra utviklere i disse debattene ofte har å gjøre med at begrepet determinisme tjener dem godt generelt i arbeidshverdagen. De møter ikke nondeterminisme så ofte som ingeniører må fange Schrödingers katter på infrastrukturen deres.
Dette forklarer kanskje ikke de observerte utviklerreaksjonene fullt ut, men det er en kraftig påminnelse om at reaksjonene våre er en kompleks blanding av mange faktorer.
Det er viktig å huske denne kompleksiteten, enten vi har å gjøre med en enkelt hendelse, samarbeider om en programvareleveringspipeline eller prøver å forstå den bredere verden.
Kilde: www.habr.com