A realità di un ingegnere di rete (cù tagliatelle è... sale ?)
Ricertamenti, mentre discutendu diversi incidenti cù ingegneri, aghju nutatu un mudellu interessante.
In queste discussioni, a quistione di "causa radica" invariabilmente vene. I lettori fideli probabilmente sanu chì aghju nantu . In parechje urganisazione, l'analisi di l'incidentu hè basatu interamente nantu à stu cuncettu. Adupranu diverse tecniche per identificà e relazioni causa è effettu, cum'è . Questi metudi assumenu a chjamata "linearità di l'avvenimenti" cum'è un dogma indiscutibile.
Quandu sfidate sta idea è signalate chì a linearità hè rassicurante ingannosa in sistemi cumplessi, nasce una discussione fascinante. I disputanti insistenu cù passione chì solu a cunniscenza di a "causa radicale" ci permette di capisce ciò chì succede.
Aghju nutatu un mudellu interessante: i sviluppatori è i devops reagiscenu in modu diversu à questa idea. In a mo spirimintà, i sviluppatori sò più prubabile di argumentà chì a causa di a radica importa è chì e relazioni causa-è-effettu ponu sempre esse stabilite in l'eventi. Per d 'altra banda, DevOps più spessu accunsenu chì un mondu cumplessu ùn ubbidisce micca sempre linearità.
Mi sò sempre dumandatu perchè hè questu? Chì face i programatori per criticà l'idea "a causa radicali hè un mitu" cusì? Cum'è un sistema immune chì ricunnosce un agentu straneru. Perchè reagiscenu cusì, mentre chì i devops piuttostu inclinatu cunsiderà sta idea?
Ùn sò micca sanu sicuru, ma aghju qualchì pensamentu nantu à questu. Hè in relazione cù i diversi cuntesti in quale sti prufessiunali facenu u so travagliu di ogni ghjornu.
I sviluppatori spessu travaglianu cù strumenti deterministici. Di sicuru, compilatori, linkers, sistemi operativi - tutti questi sò sistemi cumplessi, ma simu abituati à u fattu chì dà un risultatu deterministicu, è l'imaginemu cum'è deterministicu: se furnimu i stessi dati di input, allora aspittemu di solitu u u listessu output da questi sistemi. È s'ellu ci hè un prublema cù a pruduzzioni ("bug"), allora i sviluppatori risolvenu analizendu i dati di input (o da l'utilizatore o da un set di strumenti durante u prucessu di sviluppu). Cercanu un "errore" è dopu cambià i dati di input. Questu corregge u "bug".
Assunzione basica di u sviluppu di u software: a listessa data di input in modu affidabile è deterministicu produce u listessu output.
In fatti, un risultatu non-deterministicu hè stessu cunzidiratu un bug: se l'output inesperu o erroneatu ùn hè micca ripruduciutu, i sviluppatori tendenu à estenderà l'investigazione à l'altri parti di a pila (sistema operatore, rete, etc.), chì si cumportanu ancu. più o menu deterministically, pruducia u listessu risultatu cù u listessu dati input... è s'ellu ùn hè micca u casu, allora questu hè sempre cunsideratu un bug. Hè ghjustu avà un sistema operatore o bug di rete.
In ogni casu, u determinismu hè un assunzione basica, quasi presa per a maiò parte di i programatori di travagliu.
Ma per qualsiasi tippu di devops chì hà passatu u ghjornu à accumulà hardware o à scopre una API di nuvola, l'idea di un mondu cumplettamente deterministicu (sempre chì hè ancu pussibule di cartografia tutte l'inputs!) Hè un cuncettu fugace à u megliu. Ancu s'ellu si mette da parte , ingegneri sperimentati anu vistu e cose più strane in stu mondu. Sapenu chì , per ùn scurdà di i milioni di altri fattori in l'ambiente.
Dunque, hè più faciule per l'ingegneri sperimentati di dubbità chì tutti l'incidentu anu una sola causa radicale, è tecniche cum'è i "Cinque Perchè" portanu currettamente (è ripetutamente!) à quella causa radicale. In fattu, questu cuntradisce a so propria sperienza, induve i pezzi di puzzle ùn sò micca cusì bè in a pratica. Dunque, accettanu sta idea più facilmente.
Di sicuru, ùn dicu micca chì i sviluppatori sò ingenu, stupidu, o incapaci à capisce cumu a linearità pò esse ingannosa.
Ma mi pari chì una reazione cumuna da i sviluppatori in questi dibattiti spessu hà da fà cù u fattu chì u cuncettu di determinismu li serve bè in generale in u travagliu di ogni ghjornu. Ùn scontru micca u nondeterminismu quant'è spessu l'ingegneri anu da catturà i misgi di Schrödinger nantu à a so infrastruttura.
Questu ùn pò micca spiegà cumplettamente e reazzioni osservati di u sviluppatore, ma hè un ricordu putente chì e nostre reazzioni sò una mistura cumplessa di parechji fatturi.
Hè impurtante di ricurdà sta cumplessità, sia si tratta di un unicu incidente, di cullaburazione in un pipeline di consegna di software, o di pruvà à dà sensu à u mondu più largu.
Source: www.habr.com
