La realo de retinĝeniero (kun nudeloj kaj... salo?)
Lastatempe, diskutante diversajn okazaĵojn kun inĝenieroj, mi rimarkis interesan ŝablonon.
En ĉi tiuj diskutoj, la demando pri "radika kaŭzo" senescepte aperas. Fidelaj legantoj verŝajne scias, ke mi havas sur . En multaj organizoj, okazaĵanalizo baziĝas tute sur tiu koncepto. Ili uzas malsamajn teknikojn por identigi kaŭz-efikaj rilatoj, kiel ekzemple . Ĉi tiuj metodoj supozas la tielnomitan "linearecon de la okazaĵoj" kiel nedisputeblan dogmon.
Kiam vi defias ĉi tiun ideon kaj atentigas, ke lineareco estas trankvilige trompa en kompleksaj sistemoj, naskiĝas fascina diskuto. Disputantoj pasie insistas, ke nur scio pri la "radika kaŭzo" permesas al ni kompreni kio okazas.
Mi rimarkis interesan ŝablonon: programistoj kaj devopoj reagas malsame al ĉi tiu ideo. Laŭ mia sperto, programistoj pli verŝajne argumentas, ke la radika kaŭzo gravas kaj ke kaŭzo-efikaj rilatoj ĉiam povas esti establitaj en eventoj. Aliflanke, DevOps pli ofte konsentas, ke kompleksa mondo ne ĉiam obeas linearecon.
Mi ĉiam demandis min kial tio estas? Kio faras programistoj kritiki la ideon "la radika kaŭzo estas mito" tiel? Kiel imunsistemo, kiu rekonas fremdan agenton. Kial ili reagas tiel, dum la devops prefere inklina konsideri ĉi tiun ideon?
Mi ne estas tute certa, sed mi havas kelkajn pensojn pri tio. Ĝi rilatas al la malsamaj kuntekstoj en kiuj ĉi tiuj profesiuloj plenumas sian ĉiutagan laboron.
Programistoj ofte laboras kun determinismaj iloj. Kompreneble, kompililoj, ligiloj, operaciumoj - ĉio ĉi estas kompleksaj sistemoj, sed ni kutimas al tio, ke ili donas determinisman rezulton, kaj ni imagas ilin kiel determinismajn: se ni provizas la samajn enigajn datumojn, tiam ni kutime atendas la sama eligo de ĉi tiuj sistemoj. Kaj se estas problemo kun la eligo ("cimo"), tiam la programistoj solvas ĝin analizante la enigajn datumojn (ĉu de la uzanto aŭ de aro da iloj dum la disvolva procezo). Ili serĉas "eraron" kaj poste ŝanĝas la enigajn datumojn. Ĉi tio korektas la "cimon".
Baza supozo de programaro: la samaj enigdatenoj fidinde kaj determinisme produktas la saman produktaĵon.
Fakte, nedeterminisma rezulto estas mem konsiderata cimo: se la neatendita aŭ erara eligo ne estas reproduktita, tiam programistoj emas etendi la esploron al aliaj partoj de la stako (operaciumo, reto, ktp.), kiuj ankaŭ kondutas. pli-malpli determinisme, produktante la saman rezulton per la samaj enirdatenoj... kaj se tio ne estas la kazo, tiam ĉi tio ankoraŭ estas konsiderata cimo. Ĝi ĵus estas operaciumo aŭ reto-cimo.
Ĉiukaze, determinismo estas baza, preskaŭ donita supozo por la plej multaj el la laborprogramistoj faras.
Sed por iu ajn devopsulo, kiu pasigis la tagon kolektante aparataron aŭ eltrovante nuban API, la ideo de tute determinisma mondo (dum eĉ eblas mapi ĉiujn enigaĵojn!) estas pasema koncepto en la plej bona kazo. Eĉ se vi flankenmetas ĝin , spertaj inĝenieroj vidis la plej strangajn aferojn en ĉi tiu mondo. Ili scias tion , sen mencii la milionojn da aliaj faktoroj en la medio.
Do estas pli facile por spertaj inĝenieroj dubi, ke ĉiuj okazaĵoj havas ununuran radikan kaŭzon, kaj teknikoj kiel la "Kvin Kial" ĝuste (kaj ripeteble!) kondukos al tiu radika kaŭzo. Fakte, ĉi tio kontraŭdiras ilian propran sperton, kie la enigmopecoj ne konvenas tiel bonorde en la praktiko. Tial ili akceptas ĉi tiun ideon pli facile.
Kompreneble, mi ne diras, ke programistoj estas naivaj, stultaj aŭ nekapablaj kompreni kiel lineareco povas esti trompa.
Sed ŝajnas al mi, ke ofta reago de programistoj en ĉi tiuj debatoj ofte rilatas al la fakto, ke la koncepto de determinismo entute bone servas ilin en ĉiutaga laboro. Ili ne renkontas nedeterminismon tiel ofte kiel inĝenieroj devas kapti la katojn de Schrödinger sur sia infrastrukturo.
Ĉi tio eble ne plene klarigas la observitajn programistajn reagojn, sed ĝi estas potenca rememorigilo, ke niaj reagoj estas kompleksa miksaĵo de multaj faktoroj.
Gravas memori ĉi tiun kompleksecon, ĉu ni traktas ununuran okazaĵon, ĉu ni kunlaboras pri programaro livero-dukto aŭ provas kompreni la pli larĝan mondon.
fonto: www.habr.com