Realita síťového inženýra (s nudlemi a... solí?)
Nedávno jsem si při probírání různých incidentů s inženýry všiml zajímavého vzorce.
V těchto diskusích se vždy objevuje otázka „hlavní příčiny“. Věrní čtenáři asi vědí, že mám na . V mnoha organizacích je analýza incidentů založena výhradně na tomto konceptu. Používají různé techniky pro identifikaci vztahů příčina-následek, jako např . Tyto metody předpokládají takzvanou „linearitu událostí“ jako nezpochybnitelné dogma.
Když tuto myšlenku zpochybníte a poukážete na to, že linearita je ve složitých systémech uklidňujícím způsobem klamná, zrodí se fascinující diskuse. Disputanti vášnivě trvají na tom, že pouze znalost „hlavní příčiny“ nám umožňuje pochopit, co se děje.
Všiml jsem si zajímavého vzorce: vývojáři a vývojáři na tento nápad reagují odlišně. Podle mých zkušeností vývojáři spíše tvrdí, že na hlavní příčině záleží a že vztahy příčina-následek lze v událostech vždy nastolit. Na druhou stranu DevOps častěji souhlasí s tím, že složitý svět se ne vždy podřizuje linearitě.
Vždycky jsem si říkal, proč to tak je? Co dělá aby programátoři takto kritizovali myšlenku „hlavní příčinou je mýtus“? Jako imunitní systém, který rozpozná cizího agenta. Proč reagují tímto způsobem, zatímco devops spíše nakloněný zvážit tuto myšlenku?
Nejsem si úplně jistý, ale mám o tom nějaké myšlenky. Týká se různých kontextů, ve kterých tito odborníci vykonávají svou každodenní práci.
Vývojáři často pracují s deterministickými nástroji. Samozřejmě kompilátory, linkery, operační systémy - to všechno jsou složité systémy, ale jsme zvyklí, že dávají deterministický výsledek, a představujeme si je jako deterministické: pokud poskytujeme stejná vstupní data, pak obvykle očekáváme stejný výstup z těchto systémů. A pokud je problém s výstupem („chyba“), pak jej vývojáři řeší analýzou vstupních dat (buď od uživatele nebo ze sady nástrojů během procesu vývoje). Hledají „chybu“ a následně změní vstupní data. To opravuje "chybu".
Základní předpoklad vývoje softwaru: stejná vstupní data spolehlivě a deterministicky produkují stejný výstup.
Ve skutečnosti je nedeterministický výsledek sám o sobě považován za chybu: pokud neočekávaný nebo chybný výstup není reprodukován, mají vývojáři tendenci rozšířit vyšetřování na další části zásobníku (operační systém, síť atd.), které se také chovají víceméně deterministicky, produkující stejný výsledek se stejnými vstupními daty... a pokud není, pak je to stále považováno za chybu. Je to jen chyba operačního systému nebo sítě.
V každém případě je determinismus základní, téměř samozřejmý předpoklad pro většinu práce programátorů.
Ale pro každého devopsa, který tráví den hromaděním hardwaru nebo vymýšlením cloudového API, je myšlenka zcela deterministického světa (pokud je vůbec možné zmapovat všechny vstupy!) přinejlepším pomíjivý koncept. I když to odložíš , zkušení inženýři viděli nejpodivnější věci na tomto světě. Oni to vědí , nemluvě o milionech dalších faktorů v životním prostředí.
Pro zkušené inženýry je tedy snazší pochybovat o tom, že všechny incidenty mají jedinou hlavní příčinu a techniky jako „Pět proč“ správně (a opakovatelně!) povedou k této hlavní příčině. Ve skutečnosti je to v rozporu s jejich vlastní zkušeností, kdy dílky skládačky v praxi tak úhledně nezapadají. Proto tuto myšlenku snáze přijímají.
Samozřejmě neříkám, že vývojáři jsou naivní, hloupí nebo neschopní pochopit, jak může být linearita klamná.
Ale zdá se mi, že běžná reakce vývojářů v těchto debatách často souvisí s tím, že koncept determinismu slouží jim celkově dobře v každodenní práci. Nesetkávají se s nedeterminismem tak často, jako musí inženýři chytat Schrödingerovy kočky na své infrastruktuře.
To nemusí plně vysvětlit pozorované reakce vývojářů, ale je to silná připomínka, že naše reakce jsou složitou směsí mnoha faktorů.
Je důležité si tuto složitost pamatovat, ať už se zabýváme jedním incidentem, spolupracujeme na procesu dodávání softwaru nebo se snažíme porozumět širšímu světu.
Zdroj: www.habr.com