Stvarnost mrežnog inženjera (s rezancima i... soli?)
Nedavno sam, dok sam razgovarao o raznim incidentima s inženjerima, primijetio zanimljiv obrazac.
U tim se raspravama uvijek postavlja pitanje "osnovnog uzroka". Vjerni čitatelji vjerojatno znaju da jesam na . U mnogim se organizacijama analiza incidenta u potpunosti temelji na ovom konceptu. Koriste se različitim tehnikama za utvrđivanje uzročno-posljedičnih veza, kao npr . Ove metode pretpostavljaju tzv. “linearnost događaja” kao neospornu dogmu.
Kada osporite ovu ideju i istaknete da je linearnost umirujuće varljiva u složenim sustavima, rađa se fascinantna rasprava. Osporavači strastveno inzistiraju na tome da nam samo znanje o "osnovnom uzroku" omogućuje razumijevanje onoga što se događa.
Primijetio sam zanimljiv obrazac: programeri i devops različito reagiraju na ovu ideju. Po mom iskustvu, vjerojatnije je da će programeri tvrditi da je glavni uzrok bitan i da se uzročno-posljedične veze uvijek mogu uspostaviti u događajima. S druge strane, DevOps se češće slaže da složeni svijet ne poštuje uvijek linearnost.
Uvijek sam se pitao zašto je to tako? Što pravi programeri da tako kritiziraju ideju "osnovni uzrok je mit"? Kao imunološki sustav koji prepoznaje stranog agensa. Zašto oni tako reagiraju, dok devops prilično sklon uzeti u obzir ovu ideju?
Nisam posve siguran, ali imam neka razmišljanja o tome. Odnosi se na različite kontekste u kojima ovi stručnjaci obavljaju svoj svakodnevni posao.
Programeri često rade s determinističkim alatima. Naravno, kompajleri, linkeri, operacijski sustavi - sve su to složeni sustavi, ali navikli smo da daju deterministički rezultat i zamišljamo ih kao determinističke: ako damo iste ulazne podatke, onda obično očekujemo isti izlaz iz ovih sustava. A ako postoji problem s izlazom ("bug"), tada ga programeri rješavaju analizom ulaznih podataka (bilo od korisnika ili iz skupa alata tijekom procesa razvoja). Traže "grešku" i zatim mijenjaju unesene podatke. Ovo ispravlja "bug".
Osnovna pretpostavka razvoja softvera: isti ulazni podaci pouzdano i deterministički proizvode isti izlaz.
Zapravo, nedeterministički rezultat se sam po sebi smatra greškom: ako se neočekivani ili pogrešan rezultat ne reproducira, tada programeri teže proširiti istragu na druge dijelove stoga (operativni sustav, mrežu itd.), koji se također ponašaju više ili manje deterministički, proizvodeći isti rezultat s istim ulaznim podacima... i ako nije, to se i dalje smatra greškom. To je samo greška operativnog sustava ili mreže.
U svakom slučaju, determinizam je osnovna, gotovo uzeta zdravo za gotovo pretpostavka za većinu posla programera.
Ali za svakog devopsa koji je proveo dan skupljajući hardver ili smišljajući API u oblaku, ideja o potpuno determinističkom svijetu (sve dok je uopće moguće mapirati sve ulaze!) je u najboljem slučaju prolazan koncept. Čak i ako ga stavite sa strane , iskusni inženjeri vidjeli su najčudnije stvari na ovom svijetu. Oni to znaju , da ne spominjemo milijune drugih čimbenika u okolišu.
Stoga je iskusnim inženjerima lakše posumnjati da svi incidenti imaju jedan temeljni uzrok, a tehnike poput "Pet zašto" će ispravno (i opetovano!) dovesti do tog temeljnog uzroka. Zapravo, to je u suprotnosti s njihovim vlastitim iskustvom, gdje dijelovi slagalice ne pristaju tako dobro u praksi. Stoga tu ideju lakše prihvaćaju.
Naravno, ne kažem da su programeri naivni, glupi ili da ne mogu razumjeti kako linearnost može biti varljiva.
Ali čini mi se da je uobičajena reakcija programera u ovim raspravama često povezana s činjenicom da koncept determinizma općenito im dobro služi u svakodnevnom radu. Ne susreću se s nedeterminizmom toliko često koliko inženjeri moraju uhvatiti Schrödingerove mačke na svojoj infrastrukturi.
Ovo možda ne objašnjava u potpunosti promatrane reakcije programera, ali je snažan podsjetnik da su naše reakcije složena mješavina mnogih čimbenika.
Važno je zapamtiti ovu složenost, bilo da imamo posla s jednim incidentom, surađujemo li na cjevovodu za isporuku softvera ili pokušavamo shvatiti širi svijet.
Izvor: www.habr.com