Realnost mrežnog inženjera (sa rezancima i... solju?)
Nedavno, dok sam razgovarao o raznim incidentima sa inženjerima, primijetio sam zanimljiv obrazac.
U ovim raspravama se uvijek postavlja pitanje „korijenskog uzroka“. Vjerni čitaoci vjerovatno znaju da jesam na . U mnogim organizacijama analiza incidenata se u potpunosti zasniva na ovom konceptu. Koriste različite tehnike za identifikaciju uzročno-posledičnih veza, kao npr . Ove metode pretpostavljaju takozvanu „linearnost događaja“ kao neospornu dogmu.
Kada osporite ovu ideju i naglasite da je linearnost u kompleksnim sistemima uvjerljivo varljiva, rađa se fascinantna rasprava. Disputanti strastveno insistiraju na tome da nam samo poznavanje „korijenskog uzroka“ omogućava da shvatimo šta se dešava.
Primijetio sam zanimljiv obrazac: programeri i devops različito reagiraju na ovu ideju. Prema mom iskustvu, programeri će vjerovatnije tvrditi da je osnovni uzrok bitan i da se uzročno-posledični odnosi uvijek mogu uspostaviti u događajima. S druge strane, DevOps se češće slažu da složeni svijet ne poštuje uvijek linearnost.
Uvijek sam se pitao zašto je to tako? Šta pravi programeri da tako kritikuju ideju „osnovni uzrok je mit“? Kao imuni sistem koji prepoznaje stranog agenta. Zašto reaguju ovako, dok devops prilično sklon razmotriti ovu ideju?
Nisam sasvim siguran, ali imam neka razmišljanja o ovome. Odnosi se na različite kontekste u kojima ovi profesionalci obavljaju svoj svakodnevni posao.
Programeri često rade sa determinističkim alatima. Naravno, kompajleri, linkeri, operativni sistemi – sve su to složeni sistemi, ali navikli smo da daju deterministički rezultat, a zamišljamo ih kao determinističke: ako dajemo iste ulazne podatke, onda obično očekujemo isti izlaz iz ovih sistema. A ako postoji problem sa izlazom („bug“), programeri ga rješavaju analizom ulaznih podataka (bilo od korisnika ili iz skupa alata tokom procesa razvoja). Traže "grešku", a zatim mijenjaju ulazne podatke. Ovo popravlja "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šni izlaz ne reprodukuje, programeri teže da prošire istragu na druge dijelove steka (operativni sistem, mreža, itd.), koji se također ponašaju manje-više deterministički, dajući isti rezultat sa istim ulaznim podacima... i ako nije, onda se ovo još uvijek smatra greškom. Sada je to greška operativnog sistema ili mreže.
U svakom slučaju, determinizam je osnovna, gotovo uzeta zdravo za gotovo pretpostavka za većinu poslova programera.
Ali za svakog devops tipa koji je proveo dan skupljajući hardver ili smišljajući cloud API, ideja potpuno determinističkog svijeta (sve dok je čak moguće mapirati sve ulaze!) je u najboljem slučaju prolazan koncept. Čak i ako ga ostavite sa strane , iskusni inženjeri su vidjeli najčudnije stvari na ovom svijetu. Oni to znaju , a da ne spominjemo milione drugih faktora u okruženju.
Stoga je iskusnim inženjerima lakše sumnjati da svi incidenti imaju jedan osnovni uzrok, a tehnike poput „Pet zašto“ će ispravno (i ponovljeno!) dovesti do tog osnovnog uzroka. Zapravo, ovo je u suprotnosti s njihovim vlastitim iskustvima, gdje se dijelovi slagalice ne uklapaju tako uredno u praksi. Stoga lakše prihvataju ovu ideju.
Naravno, ne kažem da su programeri naivni, glupi ili nesposobni da shvate kako linearnost može biti varljiva.
Ali čini mi se da uobičajena reakcija programera u ovim raspravama često ima veze s činjenicom da koncept determinizma generalno im dobro služi u svakodnevnom radu. Oni se ne susreću s nedeterminizmom toliko često koliko inženjeri moraju uhvatiti Schrödingerove mačke na svojoj infrastrukturi.
Ovo možda neće u potpunosti objasniti uočene reakcije programera, ali je snažan podsjetnik da su naše reakcije složena mješavina mnogih faktora.
Važno je zapamtiti ovu složenost, bilo da imamo posla s jednim incidentom, sarađujemo na cevovodu za isporuku softvera ili pokušavamo da shvatimo širi svijet.
izvor: www.habr.com