A hálózati mérnök valósága (tésztával és... sóval?)
Nemrégiben, miközben különféle incidensekről beszélgettem mérnökökkel, egy érdekes mintázatot vettem észre.
Ezekben a vitákban mindig felmerül a „kiváltó ok” kérdése. A hűséges olvasók tudni fogják, hogy én… on Sok szervezetben az incidenselemzés teljes mértékben ezen a koncepción alapul. Különböző technikákat alkalmaznak az ok-okozati összefüggések azonosítására, például Ezek a módszerek vitathatatlan dogmaként feltételezik az úgynevezett „események linearitását”.
Amikor megkérdőjelezzük ezt az elképzelést, és rámutatunk, hogy komplex rendszerekben a linearitás megnyugtatóan megtévesztő, lenyűgöző vita bontakozik ki. A vitatkozók szenvedélyesen ragaszkodnak ahhoz, hogy csak a „kiváltó ok” ismerete teszi lehetővé számunkra, hogy megértsük, mi történik.
Érdekes mintázatot vettem észre: a fejlesztők és a DevOps szakemberek eltérően reagálnak erre az elképzelésre. Tapasztalataim szerint a fejlesztők inkább azt állítják, hogy a kiváltó okok számítanak, és hogy az ok-okozati összefüggések mindig megállapíthatók az eseményekben. A DevOps szakemberek ezzel szemben inkább egyetértenek abban, hogy egy komplex világ nem mindig engedelmeskedik a linearitásnak.
Mindig azon tűnődtem, hogy miért van ez így? Mi erők Miért kritizálják a programozók a „kiváltó ok egy mítosz” ötletet? Olyan ez, mint amikor az immunrendszer felismer egy idegen anyagot. Miért reagálnak így, miközben a DevOps… meglehetősen hajlamos fontolóra venni ezt az ötletet?
Nem vagyok teljesen biztos benne, de van egy gondolatom ezzel kapcsolatban. Ez összefügg azokkal a különböző kontextusokkal, amelyekben ezek a szakemberek a napi munkájukat végzik.
A fejlesztők gyakran determinisztikus eszközökkel dolgoznak. Természetesen a fordítók, linkerek és operációs rendszerek mind összetett rendszerek, de hozzászoktunk ahhoz, hogy determinisztikus eredményeket produkálnak, és pontosan úgy képzeljük el őket: ugyanazokkal a bemeneti adatokkal jellemzően ugyanazt a kimenetet várjuk ezektől a rendszerektől. És ha probléma van a kimenettel ("hiba"), a fejlesztők a bemeneti adatok elemzésével oldják meg (akár a felhasználótól, akár egy fejlesztőeszköz-készletből). Megtalálják a "hibát", majd módosítják a bemeneti adatokat. Ez kijavítja a "hibát".
A szoftverfejlesztés alapvető feltételezése, hogy ugyanazok a bemeneti adatok megbízhatóan és determinisztikusan ugyanazt a kimenetet állítják elő.
Valójában egy nemdeterminisztikus eredmény önmagában is hibának tekinthető: ha egy váratlan vagy hibás kimenet nem reprodukálható, akkor a fejlesztők hajlamosak kiterjeszteni a vizsgálatot a verem más részeire (operációs rendszer, hálózat stb.), amelyek szintén többé-kevésbé determinisztikusan viselkednek, ugyanazon bemeneti adatok esetén ugyanazt az eredményt produkálva... és ha ez nem így van, még mindig hibának számít. Már csak egy operációs rendszeri vagy hálózati hiba.
Mindenesetre a determinizmus egy alapvető, szinte magától értetődő feltételezés a programozók által végzett munka nagy részében.
De bármely DevOps szakember számára, aki egy napot azzal töltött, hogy hardvereket rackekbe építsen, vagy felhő API-kkal babráljon, egy teljesen determinisztikus világ gondolata (feltéve, hogy egyáltalán van mód az összes bemeneti adat leképezésére!) legjobb esetben is csak múlékony elképzelés. Még ha félretesszük is... tapasztalt mérnökök már a legfurcsább dolgokat látták ezen a világon. Tudják, hogy , nem is beszélve a környezet milliónyi egyéb tényezőjéről.
Tehát a tapasztalt mérnökök nagyobb valószínűséggel kérdőjelezik meg azt az elképzelést, hogy minden incidensnek egyetlen kiváltó oka van, és hogy az olyan technikák, mint az „Öt Miért”, megbízhatóan (és ismételhetően!) ehhez a kiváltó okhoz vezetnek. Valójában ez ellentmond a saját tapasztalataiknak, ahol a kirakós darabjai a gyakorlatban nem illeszkednek olyan szépen egymáshoz. Ezért fogékonyabbak erre az elképzelésre.
Természetesen nem azt mondom, hogy a fejlesztők naivak, buták, vagy képtelenek megérteni, hogy a linearitás hogyan lehet megtévesztő.
De úgy tűnik nekem, hogy a fejlesztők szokásos reakciója ezekben a vitákban gyakran azzal a ténnyel függ össze, hogy a determinizmus fogalma összességében jól szolgálja őket A mindennapi munkájuk során. Ritkábban találkoznak nemdeterminizmussal, mint amennyire a mérnököknek Schrödinger macskáival kell megküzdeniük az infrastruktúrájukban.
Ez talán nem magyarázza meg teljesen a megfigyelt fejlesztői reakciókat, de erőteljes emlékeztető arra, hogy reakcióink számos tényező összetett keverékei.
Fontos emlékezni erre az összetettségre, akár egyetlen incidens elhárításáról van szó, akár egy szoftverszállítási folyamaton működünk együtt, akár a tágabb világ megértését próbáljuk megérteni.
Forrás: will.com
