Realiteti i një inxhinieri rrjeti (me petë dhe... kripë?)
Kohët e fundit, duke diskutuar incidente të ndryshme me inxhinierë, vura re një model interesant.
Në këto diskutime, çështja e "shkakut rrënjësor" del pa ndryshim. Lexuesit besnikë ndoshta e dinë se e kam mbi . Në shumë organizata, analiza e incidentit bazohet tërësisht në këtë koncept. Ata përdorin teknika të ndryshme për identifikimin e marrëdhënieve shkak-pasojë, si p.sh . Këto metoda supozojnë të ashtuquajturën "linearitet të ngjarjeve" si një dogmë të padiskutueshme.
Kur sfidoni këtë ide dhe vini në dukje se lineariteti është jashtëzakonisht mashtrues në sistemet komplekse, lind një diskutim magjepsës. Mosmarrëveshësit këmbëngulin me pasion se vetëm njohja e "shkakut rrënjësor" na lejon të kuptojmë se çfarë po ndodh.
Vura re një model interesant: zhvilluesit dhe zhvilluesit reagojnë ndryshe ndaj kësaj ideje. Në përvojën time, zhvilluesit kanë më shumë gjasa të argumentojnë se shkaku kryesor ka rëndësi dhe se marrëdhëniet shkak-pasojë mund të vendosen gjithmonë në ngjarje. Nga ana tjetër, DevOps më shpesh bien dakord se një botë komplekse nuk i bindet gjithmonë linearitetit.
Gjithmonë pyesja veten pse është kjo? Çfarë bën programuesit të kritikojnë idenë "shkaku kryesor është një mit" si kjo? Si një sistem imunitar që njeh një agjent të huaj. Pse reagojnë në këtë mënyrë, ndërsa devops mjaft i prirur e konsideroni këtë ide?
Nuk jam plotësisht i sigurt, por kam disa mendime për këtë. Ajo lidhet me kontekstet e ndryshme në të cilat këta profesionistë kryejnë punën e tyre të përditshme.
Zhvilluesit shpesh punojnë me mjete deterministe. Sigurisht, përpiluesit, lidhësit, sistemet operative - të gjitha këto janë sisteme komplekse, por ne jemi mësuar me faktin se ato japin një rezultat determinist dhe i imagjinojmë si përcaktues: nëse ofrojmë të njëjtat të dhëna hyrëse, atëherë zakonisht presim të njëjtin rezultat nga këto sisteme. Dhe nëse ka një problem me daljen ("bug"), atëherë zhvilluesit e zgjidhin atë duke analizuar të dhënat hyrëse (qoftë nga përdoruesi ose nga një grup mjetesh gjatë procesit të zhvillimit). Ata kërkojnë një "gabim" dhe më pas ndryshojnë të dhënat hyrëse. Kjo rregullon "bug".
Supozimi bazë i zhvillimit të softuerit: të njëjtat të dhëna hyrëse prodhojnë në mënyrë të besueshme dhe përcaktuese të njëjtin rezultat.
Në fakt, një rezultat jo-përcaktues konsiderohet në vetvete një gabim: nëse rezultati i papritur ose i gabuar nuk riprodhohet, atëherë zhvilluesit priren të zgjerojnë hetimin në pjesë të tjera të stivit (sistemi operativ, rrjeti, etj.), të cilat gjithashtu sillen pak a shumë në mënyrë deterministe, duke prodhuar të njëjtin rezultat me të njëjtat të dhëna hyrëse... dhe nëse nuk është kështu, atëherë kjo ende konsiderohet një gabim. Tani është një gabim i sistemit operativ ose rrjetit.
Në çdo rast, determinizmi është një supozim bazë, pothuajse i marrë si i mirëqenë për shumicën e punës së programuesve.
Por për çdo djalosh që e ka kaluar ditën duke grumbulluar harduer ose duke gjetur një API cloud, ideja e një bote plotësisht deterministe (për aq kohë sa është e mundur të hartohen të gjitha hyrjet!) është në rastin më të mirë një koncept i shkurtër. Edhe nëse e lini mënjanë , inxhinierë me përvojë kanë parë gjërat më të çuditshme në këtë botë. Ata e dinë atë , për të mos përmendur miliona faktorë të tjerë në mjedis.
Pra, është më e lehtë për inxhinierët me përvojë të dyshojnë se të gjitha incidentet kanë një shkak të vetëm rrënjësor dhe teknikat si "Pesë Pse" do të çojnë në mënyrë korrekte (dhe në mënyrë të përsëritur!) në atë shkak rrënjësor. Në fakt, kjo bie ndesh me përvojën e tyre, ku pjesët e enigmës nuk përshtaten aq mirë në praktikë. Prandaj, ata e pranojnë këtë ide më lehtë.
Sigurisht, nuk po them se zhvilluesit janë naivë, budallenj ose të paaftë për të kuptuar se si lineariteti mund të jetë mashtrues.
Por më duket se një reagim i zakonshëm nga zhvilluesit në këto debate shpesh ka të bëjë me faktin se koncepti i determinizmit u shërben atyre në përgjithësi në punën e përditshme. Ata nuk ndeshen me jodeterminizëm aq shpesh sa inxhinierët duhet të kapin macet e Schrödinger-it në infrastrukturën e tyre.
Kjo mund të mos shpjegojë plotësisht reagimet e vëzhguara të zhvilluesve, por është një kujtesë e fuqishme që reagimet tona janë një përzierje komplekse e shumë faktorëve.
Është e rëndësishme të kujtojmë këtë kompleksitet, pavarësisht nëse kemi të bëjmë me një incident të vetëm, nëse bashkëpunojmë në një tubacion ofrimi softuerësh ose përpiqemi të kuptojmë botën më të gjerë.
Burimi: www.habr.com