Virkeligheden af en netværksingeniør (med nudler og... salt?)
For nylig, mens jeg diskuterede forskellige hændelser med ingeniører, bemærkede jeg et interessant mønster.
I disse diskussioner kommer spørgsmålet om "grundårsagen" uvægerligt op. Det ved trofaste læsere nok, at jeg har på . I mange organisationer er hændelsesanalyse udelukkende baseret på dette koncept. De bruger forskellige teknikker til at identificere årsag-virkning sammenhænge, som f.eks . Disse metoder antager den såkaldte "linearitet af begivenheder" som et indiskutabelt dogme.
Når du udfordrer denne idé og påpeger, at linearitet er betryggende vildledende i komplekse systemer, fødes en fascinerende diskussion. Disputanter insisterer lidenskabeligt på, at kun viden om "rodårsagen" tillader os at forstå, hvad der sker.
Jeg bemærkede et interessant mønster: udviklere og devops reagerer forskelligt på denne idé. Min erfaring er, at udviklere er mere tilbøjelige til at hævde, at den grundlæggende årsag har betydning, og at årsag-og-virkning-relationer altid kan etableres i begivenheder. På den anden side er DevOps oftere enige om, at en kompleks verden ikke altid adlyder linearitet.
Jeg har altid undret mig over, hvorfor dette er? Hvad gør programmører til at kritisere ideen "hovedårsagen er en myte" på den måde? Som et immunsystem, der genkender en fremmed agent. Hvorfor reagerer de på denne måde, mens de devopper temmelig tilbøjelig overveje denne idé?
Jeg er ikke helt sikker, men jeg har nogle tanker om dette. Det relaterer sig til de forskellige kontekster, hvori disse fagpersoner udfører deres daglige arbejde.
Udviklere arbejder ofte med deterministiske værktøjer. Selvfølgelig, compilere, linkere, operativsystemer - alle disse er komplekse systemer, men vi er vant til, at de giver et deterministisk resultat, og vi forestiller os dem som deterministiske: hvis vi leverer de samme inputdata, forventer vi normalt samme output fra disse systemer. Og hvis der er et problem med outputtet ("bug"), så løser udviklerne det ved at analysere inputdataene (enten fra brugeren eller fra et sæt værktøjer under udviklingsprocessen). De leder efter en "fejl" og ændrer derefter inputdataene. Dette retter "fejlen".
Grundlæggende antagelse om softwareudvikling: de samme inputdata producerer pålideligt og deterministisk det samme output.
Faktisk betragtes et ikke-deterministisk resultat i sig selv som en fejl: Hvis det uventede eller fejlagtige output ikke gengives, har udviklere en tendens til at udvide undersøgelsen til andre dele af stakken (operativsystem, netværk osv.), som også opfører sig mere eller mindre deterministisk, producerer det samme resultat med de samme inputdata... og hvis det ikke er tilfældet, så betragtes dette stadig som en fejl. Det er lige nu en operativsystem- eller netværksfejl.
Under alle omstændigheder er determinisme en grundlæggende, næsten givet antagelse for det meste af det arbejde, programmører udfører.
Men for enhver devops-fyr, der har brugt dagen på at samle hardware op eller finde ud af en cloud API, er ideen om en fuldstændig deterministisk verden (så længe det overhovedet er muligt at kortlægge alle input!) i bedste fald et flygtigt koncept. Også selvom du lægger det til side , erfarne ingeniører har set de mærkeligste ting i denne verden. Det ved de , for ikke at nævne de millioner af andre faktorer i miljøet.
Så det er lettere for erfarne ingeniører at tvivle på, at alle hændelser har en enkelt rodårsag, og teknikker som de "fem hvorfor" vil korrekt (og gentagne gange!) føre til den rodårsag. Det strider faktisk mod deres egen erfaring, hvor puslespilsbrikkerne i praksis ikke passer så pænt. Derfor accepterer de lettere denne idé.
Jeg siger selvfølgelig ikke, at udviklere er naive, dumme eller ude af stand til at forstå, hvordan linearitet kan være vildledende.
Men det forekommer mig, at en almindelig reaktion fra udviklere i disse debatter ofte har at gøre med, at begrebet determinisme tjener dem generelt godt i det daglige arbejde. De møder ikke nodeterminisme så ofte, som ingeniører skal fange Schrödingers katte på deres infrastruktur.
Dette forklarer måske ikke fuldt ud de observerede udviklerreaktioner, men det er en stærk påmindelse om, at vores reaktioner er en kompleks blanding af mange faktorer.
Det er vigtigt at huske denne kompleksitet, uanset om vi beskæftiger os med en enkelt hændelse, samarbejder om en softwareleveringspipeline eller forsøger at forstå den bredere verden.
Kilde: www.habr.com