Verkkoinsinöörin todellisuus (nuudeleilla ja... suolalla?)
Äskettäin keskustellessani erilaisista tapauksista insinöörien kanssa huomasin mielenkiintoisen kuvion.
Näissä keskusteluissa "perussyy" nousee aina esiin. Uskolliset lukijat varmaan tietävät sen päälle . Monissa organisaatioissa tapahtumaanalyysi perustuu kokonaan tähän käsitteeseen. He käyttävät erilaisia tekniikoita syy-seuraus-suhteiden tunnistamiseen, kuten . Nämä menetelmät olettavat niin sanotun "tapahtumien lineaarisuuden" kiistattomana dogmana.
Kun haastat tämän ajatuksen ja huomautat, että lineaarisuus on vakuuttavan petollista monimutkaisissa järjestelmissä, syntyy kiehtova keskustelu. Kiistanalaiset väittävät intohimoisesti, että vain tieto "perussyystä" antaa meille mahdollisuuden ymmärtää, mitä tapahtuu.
Huomasin mielenkiintoisen kuvion: kehittäjät ja kehittäjät reagoivat tähän ideaan eri tavalla. Kokemukseni mukaan kehittäjät väittävät todennäköisemmin, että perimmäisellä syyllä on merkitystä ja että tapahtumissa voidaan aina luoda syy-seuraus-suhteita. Toisaalta DevOps on useammin samaa mieltä siitä, että monimutkainen maailma ei aina tottele lineaarisuutta.
Olen aina ihmetellyt miksi tämä on? Mitä merkit ohjelmoijat kritisoivat ajatusta "perussyy on myytti"? Kuin immuunijärjestelmä, joka tunnistaa vieraan aineen. Miksi he reagoivat tällä tavalla, kun taas devops melko taipuvainen harkitse tätä ideaa?
En ole täysin varma, mutta minulla on joitain ajatuksia tästä. Se liittyy erilaisiin konteksteihin, joissa nämä ammattilaiset tekevät päivittäistä työtään.
Kehittäjät käyttävät usein deterministisiä työkaluja. Tietenkin kääntäjät, linkittäjät, käyttöjärjestelmät - kaikki nämä ovat monimutkaisia järjestelmiä, mutta olemme tottuneet siihen, että ne antavat deterministisen tuloksen, ja kuvittelemme ne deterministisiksi: jos toimitamme saman syöttödatan, odotamme yleensä sama tulos näistä järjestelmistä. Ja jos tulostuksessa on ongelma ("vika"), kehittäjät ratkaisevat sen analysoimalla syöttötiedot (joko käyttäjältä tai työkalujoukosta kehitysprosessin aikana). He etsivät "virhettä" ja muuttavat sitten syöttötietoja. Tämä korjaa "bugin".
Ohjelmistokehityksen perusoletus: sama syöttötieto tuottaa luotettavasti ja deterministisesti saman tulosteen.
Itse asiassa epädeterministinen tulos itsessään katsotaan virheeksi: jos odottamatonta tai virheellistä tulostetta ei toisteta, kehittäjät pyrkivät laajentamaan tutkimuksen muihin pinon osiin (käyttöjärjestelmä, verkko jne.), jotka myös käyttäytyvät. enemmän tai vähemmän deterministisesti tuottaen saman tuloksen samalla syöttödatalla... ja jos ei ole, tätä pidetään edelleen virheenä. Se on nyt vain käyttöjärjestelmä- tai verkkovirhe.
Joka tapauksessa determinismi on perusoletus, joka on lähes itsestäänselvyys useimmille ohjelmoijien työlle.
Mutta jokaiselle devops-miehelle, joka on viettänyt päivän laitteiston kokoamiseen tai pilvisovellusliittymän keksimiseen, ajatus täysin deterministisesta maailmasta (niin kauan kuin on mahdollista kartoittaa kaikki syötteet!) on parhaimmillaan ohikiitävä käsite. Vaikka laittaisit sen sivuun , kokeneet insinöörit ovat nähneet tämän maailman kummallisimmat asiat. He tietävät sen puhumattakaan miljoonista muista ympäristön tekijöistä.
Joten kokeneiden insinöörien on helpompi epäillä, että kaikilla tapahtumilla on yksi perimmäinen syy, ja "Viisi syytä" -tekniikat johtavat oikein (ja toistuvasti!) tähän perimmäiseen syyyn. Itse asiassa tämä on ristiriidassa heidän oman kokemuksensa kanssa, jossa palapelin palat eivät sovi käytännössä niin siististi. Siksi he hyväksyvät tämän ajatuksen helpommin.
En tietenkään väitä, että kehittäjät olisivat naiiveja, tyhmiä tai kyvyttömiä ymmärtämään, kuinka lineaarisuus voi olla petollista.
Mutta minusta näyttää siltä, että kehittäjien yleinen reaktio näissä keskusteluissa liittyy usein siihen tosiasiaan, että determinismin käsite palvelee niitä yleisesti hyvin jokapäiväisessä työssä. He eivät kohtaa epädeterminismia niin usein kuin insinöörien täytyy saada kiinni Schrödingerin kissat infrastruktuuristaan.
Tämä ei ehkä täysin selitä havaittuja kehittäjän reaktioita, mutta se on voimakas muistutus siitä, että reaktiomme ovat monimutkainen sekoitus monista tekijöistä.
On tärkeää muistaa tämä monimutkaisuus, olipa kyseessä yksittäinen tapaus, ohjelmistotoimitusprosessin parissa työskenteleminen tai laajemman maailman ymmärtäminen.
Lähde: will.com