Die Realität eines Netzwerktechnikers (mit Nudeln und... Salz?)
Als ich kürzlich mit Ingenieuren verschiedene Vorfälle besprach, fiel mir ein interessantes Muster auf.
In diesen Diskussionen taucht immer die Frage nach der „Grundursache“ auf. Treue Leser wissen wahrscheinlich, dass ich es getan habe auf . In vielen Organisationen basiert die Vorfallanalyse vollständig auf diesem Konzept. Sie verwenden verschiedene Techniken zur Identifizierung von Ursache-Wirkungs-Beziehungen, wie z . Diese Methoden gehen von der sogenannten „Linearität der Ereignisse“ als unbestreitbarem Dogma aus.
Wenn man diese Idee in Frage stellt und darauf hinweist, dass Linearität in komplexen Systemen beruhigend täuscht, entsteht eine faszinierende Diskussion. Streitende bestehen leidenschaftlich darauf, dass nur die Kenntnis der „Grundursache“ es uns ermöglicht, zu verstehen, was passiert.
Mir ist ein interessantes Muster aufgefallen: Entwickler und Entwickler reagieren unterschiedlich auf diese Idee. Meiner Erfahrung nach argumentieren Entwickler eher, dass es auf die Grundursache ankommt und dass bei Ereignissen immer Ursache-Wirkungs-Beziehungen hergestellt werden können. Andererseits sind sich DevOps häufiger darin einig, dass eine komplexe Welt nicht immer der Linearität gehorcht.
Ich habe mich immer gefragt, warum das so ist? Was macht Programmierer, die Idee „die Grundursache ist ein Mythos“ so zu kritisieren? Wie ein Immunsystem, das einen Fremdstoff erkennt. Warum reagieren sie so, während die Devops eher geneigt Erwägen Sie diese Idee?
Ich bin mir nicht ganz sicher, aber ich habe einige Gedanken dazu. Es bezieht sich auf die unterschiedlichen Kontexte, in denen diese Fachkräfte ihre tägliche Arbeit ausführen.
Entwickler arbeiten oft mit deterministischen Werkzeugen. Natürlich sind Compiler, Linker, Betriebssysteme – all das sind komplexe Systeme, aber wir sind daran gewöhnt, dass sie ein deterministisches Ergebnis liefern, und wir stellen sie uns als deterministisch vor: Wenn wir die gleichen Eingabedaten bereitstellen, dann erwarten wir normalerweise das gleiche Ausgabe von diesen Systemen. Und wenn es ein Problem mit der Ausgabe („Bug“) gibt, lösen die Entwickler es, indem sie die Eingabedaten analysieren (entweder vom Benutzer oder von einer Reihe von Tools während des Entwicklungsprozesses). Sie suchen nach einem „Fehler“ und ändern dann die Eingabedaten. Dies behebt den „Bug“.
Grundannahme der Softwareentwicklung: Die gleichen Eingabedaten erzeugen zuverlässig und deterministisch den gleichen Output.
Tatsächlich wird ein nicht deterministisches Ergebnis selbst als Fehler betrachtet: Wenn die unerwartete oder fehlerhafte Ausgabe nicht reproduziert wird, neigen Entwickler dazu, die Untersuchung auf andere Teile des Stapels (Betriebssystem, Netzwerk usw.) auszudehnen, die sich ebenfalls verhalten mehr oder weniger deterministisch, wobei mit denselben Eingabedaten das gleiche Ergebnis erzielt wird ... und wenn das nicht der Fall ist, dann wird dies immer noch als Fehler angesehen. Es handelt sich lediglich um einen Betriebssystem- oder Netzwerkfehler.
Auf jeden Fall ist Determinismus für die meisten Arbeiten von Programmierern eine grundlegende, fast selbstverständliche Annahme.
Aber für jeden Entwickler, der den Tag damit verbracht hat, Hardware zusammenzustellen oder eine Cloud-API zu entwickeln, ist die Idee einer vollständig deterministischen Welt (solange es überhaupt möglich ist, alle Eingaben abzubilden!) bestenfalls ein flüchtiges Konzept. Auch wenn man es beiseite legt Erfahrene Ingenieure haben die seltsamsten Dinge auf dieser Welt gesehen. Das wissen sie , ganz zu schweigen von den Millionen anderer Faktoren in der Umwelt.
Daher ist es für erfahrene Ingenieure einfacher, daran zu zweifeln, dass alle Vorfälle eine einzige Grundursache haben, und Techniken wie die „Five Whys“ führen korrekt (und wiederholbar!) zu dieser Grundursache. Tatsächlich widerspricht dies ihrer eigenen Erfahrung, bei der die Puzzleteile in der Praxis nicht so genau zusammenpassen. Daher akzeptieren sie diese Idee leichter.
Natürlich sage ich nicht, dass Entwickler naiv oder dumm sind oder nicht verstehen können, wie Linearität trügerisch sein kann.
Aber es scheint mir, dass eine häufige Reaktion von Entwicklern in diesen Debatten oft damit zu tun hat, dass das Konzept des Determinismus leistet ihnen insgesamt gute Dienste im Arbeitsalltag. Sie stoßen nicht so oft auf Nichtdeterminismus, wie Ingenieure Schrödingers Katzen in ihrer Infrastruktur einfangen müssen.
Dies erklärt möglicherweise nicht vollständig die beobachteten Entwicklerreaktionen, ist aber eine starke Erinnerung daran, dass unsere Reaktionen eine komplexe Mischung aus vielen Faktoren sind.
Es ist wichtig, sich an diese Komplexität zu erinnern, egal, ob wir es mit einem einzelnen Vorfall zu tun haben, an einer Softwarebereitstellungspipeline zusammenarbeiten oder versuchen, die Gesamtwelt zu verstehen.
Source: habr.com