Võrguinseneri tegelikkus (nuudlite ja... soolaga?)
Hiljuti inseneridega erinevaid intsidente arutades märkasin huvitavat mustrit.
Nendes aruteludes kerkib alati päevakorda “juurpõhjuse” küsimus. Tõenäoliselt teavad ustavad lugejad, et mul on edasi . Paljudes organisatsioonides põhineb intsidentide analüüs täielikult sellel kontseptsioonil. Nad kasutavad põhjuse-tagajärje seoste tuvastamiseks erinevaid tehnikaid, nt . Need meetodid eeldavad nn sündmuste lineaarsust kui vaieldamatut dogmat.
Kui vaidlustate selle idee ja juhite tähelepanu sellele, et lineaarsus on keerulistes süsteemides rahustavalt petlik, sünnib põnev arutelu. Vaidlejad väidavad kirglikult, et ainult teadmine "juurpõhjust" võimaldab meil toimuvat mõista.
Märkasin huvitavat mustrit: arendajad ja arendajad reageerivad sellele ideele erinevalt. Minu kogemuse kohaselt väidavad arendajad tõenäolisemalt, et algpõhjus on oluline ja sündmustes saab alati luua põhjuse ja tagajärje seoseid. Teisest küljest nõustuvad DevOps sagedamini sellega, et keeruline maailm ei allu alati lineaarsusele.
Olen alati mõelnud, miks see nii on? Mida teeb programmeerijad kritiseerima ideed "põhjus on müüt" niimoodi? Nagu immuunsüsteem, mis tunneb ära võõragendi. Miks nad niimoodi reageerivad, samal ajal kui devops pigem kaldu kaaluda seda ideed?
Ma pole päris kindel, aga mul on selle kohta mõned mõtted. See on seotud erinevate kontekstidega, milles need spetsialistid oma igapäevast tööd teevad.
Arendajad töötavad sageli deterministlike tööriistadega. Muidugi, kompilaatorid, linkerid, operatsioonisüsteemid - kõik need on keerulised süsteemid, kuid oleme harjunud sellega, et need annavad deterministliku tulemuse ja kujutame neid ette deterministlikena: kui esitame samad sisendandmed, siis tavaliselt eeldame sama väljund nendest süsteemidest. Ja kui väljundiga on probleem (“viga”), siis lahendavad arendajad selle sisendandmete analüüsimise teel (kas kasutajalt või arendusprotsessi käigus tööriistakomplektilt). Nad otsivad "viga" ja muudavad seejärel sisendandmeid. See parandab "vea".
Tarkvaraarenduse põhieeldus: samad sisendandmed toodavad usaldusväärselt ja deterministlikult sama väljundit.
Tegelikult peetakse mittedeterministlikku tulemust ise veaks: kui ootamatut või vigast väljundit ei taastata, siis kipuvad arendajad laiendama uurimist pinu teistele osadele (operatsioonisüsteem, võrk jne), mis samuti käituvad. enam-vähem deterministlikult, andes sama tulemuse samade sisendandmetega... ja kui see nii ei ole, siis peetakse seda siiski veaks. See on lihtsalt nüüd operatsioonisüsteemi või võrgu viga.
Igal juhul on determinism enamiku programmeerijate jaoks põhieeldus, mis on peaaegu iseenesestmõistetav.
Kuid iga devopsi mehe jaoks, kes on veetnud päeva riistvara kokku kogudes või pilve API-t välja nuputades, on idee täiesti deterministlikust maailmast (nii kauaks, kuni on isegi võimalik kõiki sisendeid kaardistada!) parimal juhul üürike kontseptsioon. Isegi kui see kõrvale panna , kogenud insenerid on näinud kõige kummalisemaid asju siin maailmas. Nad teavad seda , rääkimata miljonitest muudest keskkonnateguritest.
Nii on kogenud inseneridel lihtsam kahelda, et kõikidel intsidentidel on üks algpõhjus ja sellised tehnikad nagu "Viis miks" viivad õigesti (ja korratavalt!) selle algpõhjuseni. Tegelikult on see vastuolus nende endi kogemusega, kus pusletükid praktikas nii kenasti ei sobi. Seetõttu aktsepteerivad nad seda ideed kergemini.
Muidugi ma ei väida, et arendajad on naiivsed, rumalad või ei suuda mõista, kuidas lineaarsus võib olla petlik.
Kuid mulle tundub, et arendajate tavaline reaktsioon nendes aruteludes on sageli seotud tõsiasjaga, et determinismi mõiste teenib neid üldiselt hästi igapäevatöös. Nad ei kohta mittedeterminismi nii sageli kui insenerid peavad oma infrastruktuuril Schrödingeri kasse püüdma.
See ei pruugi täielikult seletada täheldatud arendaja reaktsioone, kuid see on võimas meeldetuletus, et meie reaktsioonid on paljude tegurite kompleksne segu.
Seda keerukust on oluline meeles pidada, olenemata sellest, kas tegemist on ühe juhtumiga, teeme koostööd tarkvara tarnetoruga või püüame mõista maailma laiemalt.
Allikas: www.habr.com