De realiteit van een netwerkingenieur (met noedels en... zout?)
Toen ik onlangs verschillende incidenten met ingenieurs besprak, merkte ik een interessant patroon op.
In deze discussies komt steevast de vraag naar de “grondoorzaak” naar voren. Trouwe lezers weten waarschijnlijk dat ik dat heb gedaan op . In veel organisaties is de incidentanalyse volledig op dit concept gebaseerd. Ze gebruiken verschillende technieken om oorzaak-gevolgrelaties te identificeren, zoals . Deze methoden gaan uit van de zogenaamde “lineariteit van gebeurtenissen” als een onbetwistbaar dogma.
Wanneer je dit idee ter discussie stelt en erop wijst dat lineariteit geruststellend bedrieglijk is in complexe systemen, ontstaat er een fascinerende discussie. Disputanten benadrukken hartstochtelijk dat alleen kennis van de ‘oorzaak’ ons in staat stelt te begrijpen wat er gebeurt.
Ik merkte een interessant patroon op: ontwikkelaars en ontwikkelaars reageren verschillend op dit idee. Mijn ervaring is dat ontwikkelaars eerder zullen beweren dat de hoofdoorzaak er toe doet en dat oorzaak-gevolgrelaties altijd in gebeurtenissen kunnen worden vastgesteld. Aan de andere kant zijn DevOps het er vaker over eens dat een complexe wereld niet altijd aan lineariteit voldoet.
Ik vroeg me altijd af: waarom is dit? Wat merken programmeurs die het idee “de grondoorzaak is een mythe” op deze manier bekritiseren? Zoals een immuunsysteem dat een vreemd agens herkent. Waarom reageren ze zo, terwijl de devops eerder geneigd overweeg dit idee?
Ik ben er niet helemaal zeker van, maar ik heb er wel een paar gedachten over. Het heeft betrekking op de verschillende contexten waarin deze professionals hun dagelijkse werk uitvoeren.
Ontwikkelaars werken vaak met deterministische tools. Natuurlijk, compilers, linkers, besturingssystemen - dit zijn allemaal complexe systemen, maar we zijn eraan gewend dat ze een deterministisch resultaat opleveren, en we beschouwen ze als deterministisch: als we dezelfde invoergegevens leveren, verwachten we meestal de dezelfde output van deze systemen. En als er een probleem is met de uitvoer (“bug”), dan lossen de ontwikkelaars dit op door de invoergegevens te analyseren (hetzij van de gebruiker, hetzij van een reeks tools tijdens het ontwikkelingsproces). Ze zoeken naar een "fout" en wijzigen vervolgens de invoergegevens. Hiermee wordt de "bug" opgelost.
Basisaanname van softwareontwikkeling: dezelfde invoergegevens produceren op betrouwbare en deterministische wijze dezelfde uitvoer.
In feite wordt een niet-deterministisch resultaat zelf als een bug beschouwd: als de onverwachte of foutieve uitvoer niet wordt gereproduceerd, hebben ontwikkelaars de neiging het onderzoek uit te breiden naar andere delen van de stapel (besturingssysteem, netwerk, enz.), die zich ook gedragen min of meer deterministisch, hetzelfde resultaat opleveren met dezelfde invoergegevens... en als dat niet het geval is, dan wordt dit nog steeds als een bug beschouwd. Het is nu gewoon een besturingssysteem- of netwerkfout.
Hoe dan ook is determinisme een fundamentele, bijna vanzelfsprekende aanname voor het meeste werk dat programmeurs doen.
Maar voor elke devops-man die de hele dag bezig is met het verzamelen van hardware of het uitzoeken van een cloud-API, is het idee van een volledig deterministische wereld (zolang het maar mogelijk is om alle inputs in kaart te brengen!) op zijn best een vluchtig concept. Zelfs als je het opzij legt hebben ervaren ingenieurs de vreemdste dingen op deze wereld gezien. Dat weten ze , om nog maar te zwijgen van de miljoenen andere factoren in het milieu.
Het is dus gemakkelijker voor ervaren ingenieurs om eraan te twijfelen dat alle incidenten één enkele hoofdoorzaak hebben, en technieken zoals de ‘Vijf Waarom’ zullen correct (en herhaalbaar!) naar die hoofdoorzaak leiden. Sterker nog, dit is in tegenspraak met hun eigen ervaring, waarbij de puzzelstukjes in de praktijk niet zo netjes passen. Daarom accepteren ze dit idee gemakkelijker.
Natuurlijk zeg ik niet dat ontwikkelaars naïef of dom zijn, of niet kunnen begrijpen hoe lineariteit bedrieglijk kan zijn.
Maar het lijkt mij dat een veel voorkomende reactie van ontwikkelaars in deze debatten vaak te maken heeft met het feit dat het concept van determinisme bedient hen over het algemeen goed in het dagelijkse werk. Ze worden niet zo vaak met non-determinisme geconfronteerd als ingenieurs de katten van Schrödinger op hun infrastructuur moeten betrappen.
Dit verklaart misschien niet volledig de waargenomen reacties van ontwikkelaars, maar het is een krachtige herinnering dat onze reacties een complex mengsel van vele factoren zijn.
Het is belangrijk om deze complexiteit te onthouden, of we nu te maken hebben met een enkel incident, samenwerken aan een softwareleveringspijplijn of proberen de bredere wereld te begrijpen.
Bron: www.habr.com