La realtà di un ingegnere di rete (con tagliatelle e... sale?)
Recentemente, mentre discutevo di vari incidenti con gli ingegneri, ho notato uno schema interessante.
In queste discussioni emerge invariabilmente la questione della “causa principale”. I lettori fedeli probabilmente sanno che l'ho fatto su . In molte organizzazioni, l’analisi degli incidenti si basa interamente su questo concetto. Usano diverse tecniche per identificare le relazioni di causa-effetto, come ad esempio . Questi metodi assumono come dogma indiscutibile la cosiddetta “linearità degli eventi”.
Quando si sfida questa idea e si sottolinea che la linearità è un inganno rassicurante nei sistemi complessi, nasce una discussione affascinante. I contestatori insistono appassionatamente sul fatto che solo la conoscenza della “causa principale” ci consente di comprendere cosa sta accadendo.
Ho notato uno schema interessante: sviluppatori e sviluppatori reagiscono in modo diverso a questa idea. Nella mia esperienza, gli sviluppatori sono più propensi a sostenere che la causa principale è importante e che le relazioni di causa-effetto possono sempre essere stabilite negli eventi. D’altro canto, i DevOps concordano più spesso sul fatto che un mondo complesso non sempre obbedisce alla linearità.
Mi sono sempre chiesto: perché è così? Che cosa marche programmatori a criticare l'idea "la causa principale è un mito" in questo modo? Come un sistema immunitario che riconosce un agente estraneo. Perché reagiscono in questo modo, mentre il devops piuttosto propenso considerare questa idea?
Non ne sono del tutto sicuro, ma ho alcune riflessioni a riguardo. Si riferisce ai diversi contesti in cui questi professionisti svolgono il loro lavoro quotidiano.
Gli sviluppatori spesso lavorano con strumenti deterministici. Naturalmente, compilatori, linker, sistemi operativi sono tutti sistemi complessi, ma siamo abituati al fatto che danno un risultato deterministico e li immaginiamo come deterministici: se forniamo gli stessi dati di input, di solito ci aspettiamo stesso risultato da questi sistemi. E se c'è un problema con l'output ("bug"), gli sviluppatori lo risolvono analizzando i dati di input (dall'utente o da una serie di strumenti durante il processo di sviluppo). Cercano un "errore" e quindi modificano i dati di input. Questo risolve il "bug".
Presupposto di base dello sviluppo del software: gli stessi dati di input producono in modo affidabile e deterministico lo stesso output.
Infatti, un risultato non deterministico è esso stesso considerato un bug: se l'output inaspettato o errato non viene riprodotto, allora gli sviluppatori tendono ad estendere l'indagine ad altre parti dello stack (sistema operativo, rete, ecc.), che si comportano anch'esse più o meno deterministicamente, producendo lo stesso risultato con gli stessi dati di input... e se non è così, allora questo è ancora considerato un bug. Adesso è solo un bug del sistema operativo o della rete.
In ogni caso, il determinismo è un presupposto basilare, quasi dato per scontato, per la maggior parte del lavoro svolto dai programmatori.
Ma per ogni ragazzo devops che ha passato la giornata ad accumulare hardware o a capire un'API cloud, l'idea di un mondo completamente deterministico (purché sia possibile mappare tutti gli input!) è nella migliore delle ipotesi un concetto fugace. Anche se lo metti da parte , ingegneri esperti hanno visto le cose più strane di questo mondo. Lo sanno , per non parlare dei milioni di altri fattori ambientali.
Quindi è più facile per gli ingegneri esperti dubitare che tutti gli incidenti abbiano un’unica causa principale, e tecniche come i “Cinque Perché” porteranno correttamente (e ripetibilmente!) a quella causa principale. In realtà, ciò contraddice la loro esperienza, in cui i pezzi del puzzle non si adattano così perfettamente nella pratica. Pertanto, accettano questa idea più facilmente.
Naturalmente non sto dicendo che gli sviluppatori siano ingenui, stupidi o incapaci di capire quanto la linearità possa essere ingannevole.
Ma mi sembra che una reazione comune da parte degli sviluppatori in questi dibattiti abbia spesso a che fare con il fatto che il concetto di determinismo li serve bene nel complesso nel lavoro quotidiano. Non incontrano il nondeterminismo così spesso come gli ingegneri devono catturare i gatti di Schrödinger sulle loro infrastrutture.
Ciò potrebbe non spiegare completamente le reazioni osservate degli sviluppatori, ma ci ricorda potentemente che le nostre reazioni sono una miscela complessa di molti fattori.
È importante ricordare questa complessità, sia che si tratti di un singolo incidente, sia che si collabori a una pipeline di distribuzione di software o si cerchi di dare un senso al mondo più ampio.
Fonte: habr.com