Die realiteit van 'n netwerkingenieur (met noedels en ... sout?)
Ek het onlangs, terwyl ek verskeie voorvalle met ingenieurs bespreek het, 'n interessante patroon opgemerk.
In hierdie besprekings kom die vraag van "worteloorsaak" altyd ter sprake. Getroue lesers weet seker dat ek het op . In baie organisasies is voorvalontleding geheel en al op hierdie konsep gebaseer. Hulle gebruik verskillende tegnieke om oorsaak-en-gevolg verhoudings te identifiseer, soos bv . Hierdie metodes veronderstel die sogenaamde "lineariteit van gebeure" as 'n onbetwisbare dogma.
Wanneer jy hierdie idee uitdaag en daarop wys dat lineariteit gerusstellend misleidend is in komplekse stelsels, word 'n fassinerende bespreking gebore. Disputante dring passievol daarop aan dat slegs kennis van die "worteloorsaak" ons toelaat om te verstaan wat aan die gebeur is.
Ek het 'n interessante patroon opgemerk: ontwikkelaars en devops reageer verskillend op hierdie idee. In my ervaring is ontwikkelaars meer geneig om te redeneer dat die oorsaak saak maak en dat oorsaak-en-gevolg verhoudings altyd in gebeurtenisse vasgestel kan word. Aan die ander kant stem DevOps meer dikwels saam dat 'n komplekse wêreld nie altyd lineariteit gehoorsaam nie.
Ek het altyd gewonder hoekom dit is? Wat maak programmeerders om die idee "die hoofoorsaak is 'n mite" so te kritiseer? Soos 'n immuunstelsel wat 'n vreemde agent herken. Hoekom reageer hulle so, terwyl die devops eerder geneig oorweeg hierdie idee?
Ek is nie heeltemal seker nie, maar ek het 'n paar gedagtes hieroor. Dit hou verband met die verskillende kontekste waarin hierdie professionele persone hul daaglikse werk uitvoer.
Ontwikkelaars werk dikwels met deterministiese gereedskap. Natuurlik is samestellers, skakelaars, bedryfstelsels almal komplekse stelsels, maar ons is gewoond daaraan dat hulle 'n deterministiese resultaat gee, en ons stel hulle voor as deterministies: as ons dieselfde insetdata verskaf, dan verwag ons gewoonlik dieselfde uitset van hierdie stelsels. En as daar 'n probleem is met die uitset ("fout"), dan los die ontwikkelaars dit op deur die insetdata te ontleed (óf van die gebruiker of van 'n stel gereedskap tydens die ontwikkelingsproses). Hulle soek 'n "fout" en verander dan die invoerdata. Dit maak die "fout" reg.
Basiese aanname van sagteware-ontwikkeling: dieselfde insetdata lewer betroubaar en deterministies dieselfde uitset.
Trouens, 'n nie-deterministiese resultaat word self as 'n fout beskou: as die onverwagte of foutiewe uitset nie gereproduseer word nie, is ontwikkelaars geneig om die ondersoek uit te brei na ander dele van die stapel (bedryfstelsel, netwerk, ens.) wat ook meer optree of minder deterministies, wat dieselfde resultaat lewer met dieselfde insetdata... en as dit nie is nie, dan word dit steeds as 'n fout beskou. Dit is nou net 'n bedryfstelsel of netwerkfout.
In elk geval, determinisme is 'n basiese, byna vanselfsprekende aanname vir baie van die werk wat programmeerders doen.
Maar vir enige devops-man wat die dag spandeer het om hardeware op te tel of 'n wolk-API uit te vind, is die idee van 'n heeltemal deterministiese wêreld (solank dit selfs moontlik is om al die insette te karteer!) op sy beste 'n vlietende konsep. Al sit jy dit opsy , het ervare ingenieurs die vreemdste dinge in hierdie wêreld gesien. Hulle weet dit , om nie te praat van die miljoene ander faktore in die omgewing nie.
Dit is dus makliker vir ervare ingenieurs om te twyfel dat alle voorvalle 'n enkele hoofoorsaak het, en tegnieke soos die "Vyf Hoekoms" sal korrek (en herhaaldelik!) tot daardie grondoorsaak lei. Trouens, dit weerspreek hul eie ervaring, waar die legkaartstukke in die praktyk nie so netjies pas nie. Daarom aanvaar hulle hierdie idee makliker.
Natuurlik sê ek nie dat ontwikkelaars naïef, dom is of nie kan verstaan hoe lineariteit bedrieglik kan wees nie.
Maar dit lyk vir my dat 'n algemene reaksie van ontwikkelaars in hierdie debatte dikwels te make het met die feit dat die konsep van determinisme dien hulle oor die algemeen goed in die alledaagse werk. Hulle kom nie so gereeld teë met nondeterminisme as wat ingenieurs Schrödinger se katte op hul infrastruktuur moet vang nie.
Dit verklaar dalk nie die waargenome ontwikkelaarreaksies volledig nie, maar dit is 'n kragtige herinnering dat ons reaksies 'n komplekse mengsel van baie faktore is.
Dit is belangrik om hierdie kompleksiteit te onthou, of ons nou met 'n enkele voorval te doen het, saamwerk aan 'n sagteware-afleweringspyplyn, of probeer om sin te maak van die breër wêreld.
Bron: will.com