Realnost omrežnega inženirja (z rezanci in ... soljo?)
Nedavno, ko sem z inženirji razpravljal o različnih dogodkih, sem opazil zanimiv vzorec.
V teh razpravah se vedno pojavi vprašanje "osnovnega vzroka". Zvesti bralci verjetno vedo, da sem o . V mnogih organizacijah analiza incidentov v celoti temelji na tem konceptu. Uporabljajo različne tehnike ugotavljanja vzročno-posledičnih zvez, kot npr . Te metode predpostavljajo tako imenovano »linearnost dogodkov« kot neizpodbitno dogmo.
Ko izpodbijate to zamisel in poudarjate, da je linearnost v zapletenih sistemih pomirjujoče varljiva, se porodi fascinantna razprava. Prepirljivci vneto vztrajajo, da nam le poznavanje »osnovnega vzroka« omogoča razumevanje dogajanja.
Opazil sem zanimiv vzorec: razvijalci in devops različno reagirajo na to idejo. Po mojih izkušnjah bodo razvijalci bolj verjetno trdili, da je glavni vzrok pomemben in da je v dogodkih vedno mogoče vzpostaviti vzročno-posledično razmerje. Po drugi strani pa se DevOps pogosteje strinjajo, da kompleksen svet ni vedno podrejen linearnosti.
Vedno sem se spraševal, zakaj je tako? Kaj naredi programerji takole kritizirajo idejo "glavni vzrok je mit"? Kot imunski sistem, ki prepozna tujek. Zakaj reagirajo tako, medtem ko devops precej nagnjen upoštevati to idejo?
Nisem povsem prepričan, vendar imam nekaj misli o tem. Nanaša se na različne kontekste, v katerih ti strokovnjaki opravljajo svoje vsakodnevno delo.
Razvijalci pogosto delajo z determinističnimi orodji. Seveda prevajalniki, povezovalniki, operacijski sistemi - vse to so kompleksni sistemi, vendar smo navajeni, da dajejo determinističen rezultat, in si jih predstavljamo kot deterministične: če podamo enake vhodne podatke, potem običajno pričakujemo enak rezultat iz teh sistemov. In če se pojavi težava z izhodom (»hrošč«), jo razvijalci rešijo z analizo vhodnih podatkov (bodisi od uporabnika bodisi iz nabora orodij med procesom razvoja). Poiščejo »napako« in nato spremenijo vnesene podatke. To popravi "napako".
Osnovna predpostavka razvoja programske opreme: isti vhodni podatki zanesljivo in deterministično proizvedejo enak izhod.
Pravzaprav se nedeterminističen rezultat sam obravnava kot hrošč: če se nepričakovan ali napačen izhod ne reproducira, razvijalci ponavadi razširijo preiskavo na druge dele sklada (operacijski sistem, omrežje itd.), ki se prav tako obnašajo bolj ali manj deterministično, ustvarjanje enakega rezultata z istimi vhodnimi podatki ... in če ni, potem se to še vedno šteje za napako. Gre samo za napako operacijskega sistema ali omrežja.
V vsakem primeru je determinizem osnovna, skoraj samoumevna predpostavka za večino dela programerjev.
Toda za vsakega fanta devopsa, ki je dan preživel z nabiranjem strojne opreme ali odkrivanjem API-ja v oblaku, je zamisel o popolnoma determinističnem svetu (dokler je sploh mogoče preslikati vse vnose!) v najboljšem primeru bežen koncept. Tudi če ga daš na stran , so izkušeni inženirji videli najbolj čudne stvari na tem svetu. To vedo , da ne omenjamo milijonov drugih dejavnikov v okolju.
Zato je izkušenim inženirjem lažje dvomiti, da imajo vsi incidenti en sam temeljni vzrok, tehnike, kot je »Pet zakaj«, pa bodo pravilno (in večkrat!) vodile do tega temeljnega vzroka. Pravzaprav je to v nasprotju z njihovimi lastnimi izkušnjami, kjer se koščki sestavljanke v praksi ne prilegajo tako lepo. Zato to idejo lažje sprejmejo.
Seveda ne trdim, da so razvijalci naivni, neumni ali da ne morejo razumeti, kako je lahko linearnost varljiva.
Vendar se mi zdi, da je pogosta reakcija razvijalcev v teh razpravah pogosto povezana z dejstvom, da koncept determinizma na splošno jim dobro služi pri vsakdanjem delu. Z nedeterminizmom se ne srečujejo tako pogosto, kot morajo inženirji loviti Schrödingerjeve mačke na svoji infrastrukturi.
To morda ne pojasni v celoti opazovanih reakcij razvijalcev, vendar je močan opomnik, da so naše reakcije kompleksna mešanica številnih dejavnikov.
Pomembno si je zapomniti to zapletenost, ne glede na to, ali imamo opravka z enim samim incidentom, sodelujemo pri dobavi programske opreme ali poskušamo razumeti širši svet.
Vir: www.habr.com