A hálózatmérnök valósága (tésztával és... sóval?)
Nemrég, miközben különféle incidensekről beszéltem a mérnökökkel, egy érdekes mintára lettem figyelmes.
Ezekben a vitákban mindig felmerül a „kiváltó ok” kérdése. A hűséges olvasók valószínűleg tudják, hogy igen on . Sok szervezetben az incidenselemzés teljes mértékben ezen a koncepción alapul. Különféle technikákat alkalmaznak az ok-okozati összefüggések azonosítására, mint pl . Ezek a módszerek vitathatatlan dogmaként tételezik fel az úgynevezett „események linearitását”.
Ha megkérdőjelezi ezt az elképzelést, és rámutat arra, hogy a linearitás megnyugtatóan megtévesztő az összetett rendszerekben, lenyűgöző vita születik. A vitázó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át vettem észre: a fejlesztők és a fejlesztők eltérően reagálnak erre az ötletre. Tapasztalataim szerint a fejlesztők nagyobb valószínűséggel érvelnek amellett, hogy a kiváltó ok számít, és az eseményekben mindig létre lehet hozni ok-okozati összefüggéseket. Másrészt a DevOps gyakrabban egyetért abban, hogy egy összetett világ nem mindig engedelmeskedik a linearitásnak.
Mindig azon töprengtem, hogy ez miért van? Mit teszi programozók, hogy így kritizálják a „kiváltó ok egy mítosz” gondolatot? Mint egy immunrendszer, amely felismeri az idegen ágenst. Miért reagálnak így, miközben a devops inkább hajlamos fontolja meg ezt az ötletet?
Nem vagyok benne teljesen biztos, de van néhány gondolatom ezzel kapcsolatban. Ez azokhoz a különböző környezetekhez kapcsolódik, amelyekben ezek a szakemberek napi munkájukat végzik.
A fejlesztők gyakran determinisztikus eszközökkel dolgoznak. Természetesen a fordítók, linkerek, operációs rendszerek mind összetett rendszerek, de megszoktuk, hogy determinisztikus eredményt adnak, és determinisztikusnak képzeljük el: ha ugyanazokat a bemeneti adatokat adjuk meg, akkor általában ugyanazt a kimenetet várjuk el. ezekből a rendszerekből. Ha pedig probléma adódik a kimenettel („bug”), akkor azt a fejlesztők a bemeneti adatok elemzésével oldják meg (akár a felhasználótól, akár egy eszközkészletből a fejlesztési folyamat során). Keresnek egy "hibát", majd megváltoztatják a bemeneti adatokat. Ez javítja a "hibát".
A szoftverfejlesztés alapfeltevés: ugyanazok a bemeneti adatok megbízhatóan és determinisztikusan ugyanazt a kimenetet állítják elő.
Valójában a nem determinisztikus eredmény maga is hibának minősül: ha a váratlan vagy hibás kimenet nem reprodukálódik, akkor a fejlesztők hajlamosak a vizsgálatot kiterjeszteni a verem más részeire (operációs rendszer, hálózat stb.), amelyek szintén jobban viselkednek. vagy kevésbé determinisztikusan, ugyanazon bemeneti adatokkal ugyanazt az eredményt produkálva... és ha nem így van, akkor ez még mindig hibának számít. Ez csak most egy operációs rendszer vagy hálózati hiba.
Mindenesetre a determinizmus alapvető, szinte magától értetődő feltevés a programozók legtöbbje számára.
De minden devops srác számára, aki hardver felhalmozásával vagy egy felhő API kitalálásával töltötte a napot, a teljesen determinisztikus világ ötlete (amíg lehetséges az összes bemenet feltérképezése!) a legjobb esetben is csak futó ötlet. Még ha félreteszed is , tapasztalt mérnökök látták a világ legfurcsább dolgait. Tudják ezt , nem is beszélve a környezet milliónyi egyéb tényezőjéről.
Így a tapasztalt mérnökök könnyebben kételkedhetnek abban, hogy minden incidensnek egyetlen kiváltó oka van, és az olyan technikák, mint az „Öt miért” helyesen (és megismételhetően!) ehhez a kiváltó okhoz vezetnek. Valójában ez ellentmond a saját tapasztalatuknak, ahol a kirakós darabok nem illeszkednek olyan szépen a gyakorlatban. Ezért könnyebben elfogadják ezt a gondolatot.
Természetesen nem azt mondom, hogy a fejlesztők naivak, hülyék, vagy képtelenek felfogni, hogy a linearitás mennyire megtévesztő.
De nekem úgy tűnik, hogy a fejlesztők közös reakciója ezekben a vitákban gyakran összefügg azzal a ténnyel, hogy a determinizmus fogalma összességében jól szolgálja őket a mindennapi munkában. Nem találkoznak olyan gyakran nondeterminizmussal, mint amennyire a mérnököknek el kell kapniuk Schrödinger macskáit az infrastruktúrájukon.
Ez nem feltétlenül magyarázza meg teljesen a megfigyelt előhívó reakciókat, de erőteljes emlékeztető arra, hogy reakcióink sok tényező összetett keveréke.
Fontos emlékeznünk erre az összetettségre, akár egyetlen incidensről van szó, akár egy szoftverszállítási folyamaton dolgozunk, akár a tágabb világot próbáljuk megérteni.
Forrás: will.com