Sareko ingeniari baten errealitatea (fideoekin eta... gatzarekin?)
Duela gutxi, ingeniariekin hainbat gorabehera eztabaidatzen ari nintzenean, eredu interesgarri bat nabaritu nuen.
Eztabaida hauetan, "arrazoi kausa"ren auzia beti sortzen da. Irakurle fidelek ziurrenik badakite dudala on . Erakunde askotan, gertakarien analisia kontzeptu honetan oinarritzen da erabat. Kausa-ondorio harremanak identifikatzeko teknika desberdinak erabiltzen dituzte, esaterako . Metodo hauek “gertaeren linealtasuna” delakoa dogma eztabaidaezintzat hartzen dute.
Ideia hau zalantzan jartzen duzunean eta sistema konplexuetan linealtasuna engainagarria dela ziurtatzen duzunean, eztabaida liluragarri bat sortzen da. Disputatzaileek sutsuki azpimarratzen dute "arrazoiaren kausa" ezagutzeak soilik ematen duela gertatzen ari dena ulertzea.
Eredu interesgarri bat nabaritu nuen: garatzaileek eta devopek modu ezberdinean erreakzionatzen dute ideia honen aurrean. Nire esperientziaren arabera, garatzaileek litekeena da arrazoi nagusia axola dela eta kausa-ondorio harremanak beti ezar daitezkeela gertaeretan. Bestalde, DevOps-ek maizago onartzen du mundu konplexu batek ez duela beti linealtasuna betetzen.
Beti galdetu dut zergatik den hau? Zer egiten du programatzaileei "arrazoia mito bat da" ideia kritikatzeko? Agente arrotz bat ezagutzen duen sistema immunologikoa bezala. Zergatik erreakzionatzen dute horrela, devops bitartean makurtuta baizik ideia hau kontuan hartu?
Ez nago guztiz ziur, baina ideia batzuk baditut honi buruz. Profesional hauek eguneroko lana egiten duten testuinguru ezberdinekin erlazionatzen da.
Garatzaileek maiz tresna deterministekin lan egiten dute. Jakina, konpiladoreak, lokailuak, sistema eragileak sistema konplexuak dira, baina ohituta gaude emaitza deterministikoa ematen dutela, eta determinista gisa irudikatzen ditugu: sarrerako datu berdinak ematen baditugu, normalean irteera bera espero dugu. sistema hauetatik. Eta irteeran arazoren bat badago ("akatsa"), garatzaileek konpontzen dute sarrerako datuak aztertuz (erabiltzaileenak edo garapen-prozesuan zehar tresna multzo batekoak). "Errore" bat bilatzen dute eta gero sarrerako datuak aldatzen dituzte. Honek "akatsa" konpontzen du.
Softwarearen garapenaren oinarrizko suposizioa: sarrerako datu berdinek modu fidagarrian eta deterministikoan irteera bera sortzen dute.
Izan ere, emaitza ez-determinista bat bera akatstzat hartzen da: ustekabeko edo okerreko irteera erreproduzitzen ez bada, garatzaileek ikerketa pilaren beste atal batzuetara (sistema eragilea, sarea, etab.) ere portaera handiagoa dutenetara hedatu ohi dute. edo gutxiago deterministikoki, sarrerako datu berdinekin emaitza bera sortuz... eta hala ez bada, orduan hau oraindik akats gisa hartzen da. Oraintxe sistema eragilea edo sareko akats bat da.
Nolanahi ere, determinismoa oinarrizko hipotesi bat da, programatzaileen lan askorentzat ia-ia normaltzat hartuta.
Baina eguna hardwarea pilatzen edo hodeiko API bat asmatzen eman duen edozein devopsentzat, mundu guztiz determinista baten ideia (betiere, sarrera guztiak mapatzea posible bada!) kontzeptu iheskorra da onenean. Alde batera utzita ere , esperientziadun ingeniariek mundu honetako gauzarik bitxienak ikusi dituzte. Hori badakite , inguruneko beste milioika faktore aipatzearren.
Beraz, esperientziadun ingeniarientzat errazagoa da gertakari guztiek sustrai bakarra dutela zalantzan jartzea, eta "Five Whys" bezalako teknikek zuzen (eta behin eta berriz!) eragingo dute sustrai horretara. Izan ere, hau beren esperientziaren kontrakoa da, non puzzlearen piezak praktikan hain txukun egokitzen ez diren. Horregatik, errazago onartzen dute ideia hori.
Noski, ez dut esaten garatzaileak inozoak, ergelak edo linealtasuna nola engainagarria izan daitekeen ulertzeko gai direnik.
Baina iruditzen zait eztabaida hauetan garatzaileen ohiko erreakzio batek determinismoaren kontzeptuarekin zerikusia duela askotan. orokorrean ondo balio die eguneroko lanean. Ez dute ingeniariek Schrödingerren katuak beren azpiegituretan harrapatu behar dituzten bezain maiz aurkitzen ez determinismoa.
Baliteke horrek ez dituela guztiz azaldu behatutako garatzaileen erreakzioak, baina gure erreakzioak faktore askoren nahasketa konplexua direla gogorarazten du.
Garrantzitsua da konplexutasun hori gogoratzea, gertakari bakar bati aurre egiten ari garen, softwarea entregatzeko kanalizazio batean elkarlanean ari garen edo mundu zabalari zentzua ematen saiatzen ari garen.
Iturria: www.habr.com