Realita sieťového inžiniera (s rezancami a... soľou?)
Nedávno som si pri preberaní rôznych incidentov s inžiniermi všimol zaujímavý vzorec.
V týchto diskusiách sa vždy objavuje otázka „hlavnej príčiny“. Verní čitatelia asi vedia, že mám na . V mnohých organizáciách je analýza incidentov úplne založená na tomto koncepte. Používajú rôzne techniky na identifikáciu vzťahov príčina-následok, ako napr . Tieto metódy predpokladajú takzvanú „lineárnosť udalostí“ ako nespornú dogmu.
Keď spochybníte túto myšlienku a poukážete na to, že linearita je v zložitých systémoch upokojujúco klamlivá, zrodí sa fascinujúca diskusia. Diskutujúci vášnivo trvajú na tom, že iba poznanie „hlavnej príčiny“ nám umožňuje pochopiť, čo sa deje.
Všimol som si zaujímavý vzorec: vývojári a vývojári reagujú na túto myšlienku odlišne. Podľa mojich skúseností vývojári s väčšou pravdepodobnosťou tvrdia, že na hlavnej príčine záleží a že vzťahy medzi príčinami a následkami môžu byť vždy založené na udalostiach. Na druhej strane, DevOps sa častejšie zhodujú v tom, že zložitý svet nie vždy dodržiava linearitu.
Vždy som sa pýtal, prečo je to tak? Čo robí aby programátori takto kritizovali myšlienku „hlavnou príčinou je mýtus“? Ako imunitný systém, ktorý rozpozná cudzieho agenta. Prečo takto reagujú, kým devops skôr naklonený zvážiť túto myšlienku?
Nie som si úplne istý, ale mám o tom pár myšlienok. Týka sa rôznych kontextov, v ktorých títo odborníci vykonávajú svoju každodennú prácu.
Vývojári často pracujú s deterministickými nástrojmi. Samozrejme, kompilátory, linkery, operačné systémy sú všetko zložité systémy, ale sme zvyknutí, že dávajú deterministický výsledok, a predstavujeme si ich ako deterministické: ak poskytneme rovnaké vstupné dáta, potom zvyčajne očakávame rovnaký výstup. z týchto systémov. A ak sa vyskytne problém s výstupom („chyba“), vývojári ho vyriešia analýzou vstupných údajov (buď od používateľa alebo zo sady nástrojov počas procesu vývoja). Hľadajú „chybu“ a následne menia vstupné údaje. Toto opravuje "chybu".
Základný predpoklad vývoja softvéru: rovnaké vstupné dáta spoľahlivo a deterministicky produkujú rovnaký výstup.
V skutočnosti sa nedeterministický výsledok sám o sebe považuje za chybu: ak sa neočakávaný alebo chybný výstup nereprodukuje, vývojári majú tendenciu rozšíriť vyšetrovanie na ďalšie časti zásobníka (operačný systém, sieť atď.), ktoré sa tiež správajú viac alebo menej deterministicky, produkujúc rovnaký výsledok s rovnakými vstupnými údajmi... a ak to tak nie je, potom sa to stále považuje za chybu. Teraz je to chyba operačného systému alebo siete.
V každom prípade je determinizmus základným, takmer samozrejmým predpokladom pre väčšinu práce programátorov.
Ale pre každého devopsa, ktorý strávil deň skladaním hardvéru alebo vymýšľaním cloudového API, je myšlienka úplne deterministického sveta (pokiaľ je vôbec možné zmapovať všetky vstupy!) prinajlepšom prchavý koncept. Aj keď ho odložíte , skúsení inžinieri videli najpodivnejšie veci na tomto svete. Oni to vedia , nehovoriac o miliónoch ďalších faktorov životného prostredia.
Pre skúsených inžinierov je teda jednoduchšie pochybovať o tom, že všetky incidenty majú jedinú hlavnú príčinu a techniky ako „Päť Prečo“ správne (a opakovane!) povedú k tejto hlavnej príčine. V skutočnosti je to v rozpore s ich vlastnou skúsenosťou, kde dieliky skladačky v praxi až tak nepasujú. Preto túto myšlienku ľahšie prijímajú.
Samozrejme, nehovorím, že vývojári sú naivní, hlúpi alebo nedokážu pochopiť, ako môže byť linearita klamlivá.
Ale zdá sa mi, že bežná reakcia vývojárov v týchto debatách často súvisí s tým, že koncept determinizmu celkovo im slúži dobre v každodennej práci. Nestretávajú sa s nedeterminizmom tak často, ako musia inžinieri chytať Schrödingerove mačky na svojej infraštruktúre.
To nemusí úplne vysvetliť pozorované reakcie vývojárov, ale je to silná pripomienka, že naše reakcie sú komplexnou zmesou mnohých faktorov.
Je dôležité mať na pamäti túto zložitosť, či už sa zaoberáme jedným incidentom, spolupracujeme na dodávaní softvéru alebo sa snažíme pochopiť širší svet.
Zdroj: hab.com