How Complex Systems Fail

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Antworten
Benutzeravatar
Krishty
Establishment
Beiträge: 7974
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

How Complex Systems Fail

Beitrag von Krishty »

(Abgesondert aus dem Thread über Fehlerbehandlung)

Ich verlinkte einen Auszug aus einem Paper, den ich sehr genieße: How Complex Systems Fail

Das Paper ist alt und befasst sich mit Patientensicherheit in Krankenhäusern. Es passt aber (nach allem, was ich lese) wie gespuckt auf solche Dinge wie Energieversorgung, Stadtverwaltung, und Luftfahrzeuge. Einige Dinge würde ich auf noch mehr Bereiche anwenden (warum haben Männer Nippel und warum werde ich meinen Ohrwurm nicht los?) … aber ich schweife ab.

Der Auszug gibt ein paar wichtige Hinweise darauf, wie man komplexe Systeme härtet. Und ich sehe diese Strategien in Energieversorgung, Stadtverwaltung, Luftfahrt … aber ich tue mich schwer, sie in komplexen Software-Systemen zu entdecken!

Noch schwerer tue ich mich damit, das irgendwie in Worte gebacken zu kriegen. Vergebt mir die Wall of Text.

Beispielhaft: Das Paper erklärt gut, warum in meinem Rathaus drei Mal so viele Leute arbeiten, wie man instinktiv denken würde: Von Krankschreibungen über kaputte Drucker und Fremdsprachler bis hin zu abgebrochenen Schlüsseln und Sparmaßnahmen wird jeder Ablauf in der Stadtverwaltung ständig sabotiert. Diese ständigen Failures haben viele Defenses erzwungen, und nichts davon reicht *allein* aus, um meine Stadtverwaltung kollabieren zu lassen. Einige Defenses sehen wie Flaws aus („Warum spreche ich den dritten Sachbearbeiter in drei Tagen?!“) und niemand würde abstreiten, dass das System im Degraded Mode läuft. Auch bewirkt jede Veränderung unvorhergesehene Nebenwirkungen, die die Performance nicht unbedingt verbessern (digitalisiert man die Anträge, wird plötzlich mehr ausgedruckt).

Also, bis der Ransom-Erpresser eures Vertrauens kommt jedenfalls. Denn eine einzelne Ransomware-Attacke reicht allem Anschein nach sehr wohl aus, um das System lahmzulegen. Und obwohl wir solche Angriffe seit Jahrzehnten haben, bilden sich keine Defenses, denn einigen Verwaltungen passiert das ja schon zum zweiten oder dritten Mal. Und die Defenses, die wir haben, reichen offenbar nicht aus, um irgendwas zu retten.

Das finde ich … bemerkenswert.

Ich könnte übrigens auch Hackernews eine Stadtverwaltung von First Principles herleiten lassen, die nur einen Bruchteil der Ressourcen verbraucht, ein Vielfaches schneller ist … und sie wäre garantiert einen Tag nach der Eröffnung an unvorhergesehenen Problemen kollabiert.

Und noch ein Beispiel aus dem anderen Thread: Alle OS-Kernel heutzutage sind komplex und haben gleichzeitig höchste Sicherheitsanforderungen. Nichtsdestotrotz verfolgt man dort eine rigorose Korrektheits-Politik. Die Leute würden auf die Barrikaden gehen, wenn der Linux-Kernel plötzlich dreifach Speicher verbrauchen würde, um alle Datenstrukturen redundant abzuspeichern („wenn nun ein Byte kaputt geschrieben wird, wiegt der Fehler nur noch 33% so schwer“). Es gäbe Shitstorms, wenn der Kernel bei Paging-Fehlern einfachen sagen würde „nun sind die 16 KiB Daten halt weg; egal – der SQL-Prozess wird es schon irgendwie selber erkennen und sich drum kümmern“ statt mit HALT zu dumpen damit man der Ursache auf den Zahn fühlen kann. Aber so ziemlich jedes andere komplexe System (natürlich wie künstlich) hat ganz genau das entwickelt! Augenscheinlich unnötige Redundanz und viel zu viele Schichten!

Natürlich kann Software genau so werden – alle Variablen dreifach an drei verschiedenen Stellen; alle Funktionen fünffach; um jeden Zugriff ein if von dem man nicht weiß, ob es jemals false werden kann – aber ich hatte solche Systeme in der Hand und sie waren unwartbar. Wegschmeißen und neu schreiben.

Was ist an komplexen Software-Systemen anders als an komplexen Systemen in Energieversorgung, Gesundheitsverwaltung, Luft- und Raumfahrt? Warum überleben solche Systeme in anderen Domänen?

Ist digital tatsächlich so viel anders als Analog, dass sich ein Kampf gegen die Entropie mehr lohnt als eine Kapitulation? (Meine CPU kann vier Milliarden Mal pro Sekunde fehlerfrei addieren, 40 Jahre lang – finde mal ein Zahnrad, das sich eine Milliarde Mal fehlerfrei dreht!)

Ich frage auch, weil ich bei Machine Learning / GAI einen Trend zu Redundanz und Degraded Performance beobachte. Sollte sich herausstellen, dass solche Systeme von Natur aus nützlicher sind als das, was gerade auf eurer CPU läuft, möchte ich das lieber jetzt wissen als später. Allein die Implikationen für End-to-End-Tests vs. Unit Tests wären enorm.
Safety is a characteristic of systems and not of their components

Safety is an emergent property of systems; it does not reside in a person, device or department of an organization or system.
P.S.: Letzte Beispiele für heute sind noch Speech Recognition und Robotik. Beide Bereiche waren gefühlt (denn was weiß ich schon) bis 2000 von simplen Systemen mit hohen Korrektheitsanforderungen dominiert, und beide performten lächerlich. Seit sie von Systemen chaotischer Natur mit deutlich mehr Redundanz und deutlich schlechterer Performance abgelöst wurden, haben beide erst so richtig abgehoben. Diese Beschwerde über Speech Recognition von 2010 mag heute noch nachvollziehbar sein, aber schaut mal, wie sich die Kurve durch Deep Learning entwickelt hat.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
xq
Establishment
Beiträge: 1567
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: How Complex Systems Fail

Beitrag von xq »

Ist digital tatsächlich so viel anders als Analog, dass sich ein Kampf gegen die Entropie mehr lohnt als eine Kapitulation? (Meine CPU kann vier Milliarden Mal pro Sekunde fehlerfrei addieren, 40 Jahre lang – finde mal ein Zahnrad, das sich eine Milliarde Mal fehlerfrei dreht!)
Kleiner Senf meinerseits dazu: Ich bastel zur Zeit sehr aktiv an einem Computer, mit FPGA, Elektronik und hohen Frequenzen. Und es tritt ein Problem auf, dass mein System beim Daten übertragen sich irgendwo verklemmt. Woran genau das liegt, weiss ich nicht. Der Code an sich ist fehlerfrei, das Protokoll ist trivial genug dafür. Leider ist die echte Welt nicht ideal und bei 80 MHz glitcht es fröhlich durch die Gegend. Wenn jetzt also irgendwo ein elektrisches Signal einen Glitch auf der Leitung auslöst, muss die Logik dahinter das rausfiltern.

Die Software selbst merkt davon schon gar nichts mehr, wenn die HW das richtig tut. Ergo muss man sich hier schon nicht mehr um nen Failure State kümmern. Und ich bin auch schon auf dem Level von "Da liegt HIGH oder LOW an" und nicht "Da liegen jetzt 0.4V an, das sind nach LVTTL jetzt ein "LOW"-Pegel. Das übernimmt schon der Digitaleingang für mich. Ergo sind in solchen Systemen, und vorallem auch in aktuellen Computern so massiv viele Fehlerkorrektur-Systeme schon am werkeln, dass man sich tatsächlich relativ gut auf die Annahme, "es geht schon nix schief" in Software verlassen kann. Und wenn man doch einen Fehler findet, kann man das auf einem Level unter der Software fixen, und die Assumptions der Software bleiben die selben: "Bits flippen nicht willkürlich".
Schönes Beispiel hier: ECC-RAM

Ergo muss ich in meiner Software zwar alle "logischen" Fehler abfangen, aber keine spurious Errors wie "hups, da sind jetzt halt die Daten weg, die müssen wir jetzt wo anders herbekommen".

In der analogen Welt ist halt die harte Realität am Werkeln, wohingegen in so einer CPU eine schöne heile Welt herrscht
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Alexander Kornrumpf
Moderator
Beiträge: 1993
Registriert: 25.02.2009, 13:37

Re: How Complex Systems Fail

Beitrag von Alexander Kornrumpf »

Phew, ich weiß gar nicht wo ich anfangen soll. Ich versuche es kurz zu halten aber ich befürchte ich werde einiges im weiteren Verlauf der Diskussion weiter entpacken müssen um überhaupt verstanden zu werden. Im Zweifel einfach nachfragen. tl;dr: Ich verstehe die Frage nicht.

Der Artikel den du verlinkt hast benutzt zwar das Wort "Komplexe Systeme" befasst sich aber nach meiner Lesart tatsächlich hauptsächlich mit der Rolle von Menschen ("practitioners") in - mangels eines besseren Worts - komplexen Umgebungen.

Die Art wie Menschen, nach Lesart des Artikels, mit komplexen Umgebungen interagieren ist fundamental verschieden davon wie - wenn überhaupt - Software im Allgemeinen mit komplexen Umgebungen interagiert. So weit so richtig. Warum ist das überraschend wo Software und Menschen nun doch - bisher - sehr verschieden sind? Wo ist der "practitioner" innerhalb eines Softwaresystems? Warum glaubst du, dass klassische Software, mangels inhäntem "practitioner", überhaupt inhärent so sein _könnte_ wie die Systeme aus dem Artikel?

Argumentierbar ist der _Betrieb_ eines großen Softwaresystems mit dem Betrieb sagen wir eines Kraftwerks zumindest entfernt vergleichbar, aber es gibt keinen Grund anzunehmen, dass die Redundanzen _im Code_ zu finden sein müssten. Realistisch stellst du halt eine zweite Node daneben dann hast du Redundanz. Das ist genau das was wir beobachten. Wo ist das Mysterium?

Schalten wir mal in einen höheren Gang. Beachte dieses phantastisch gute Symbolvideo, das soweit ich das beurteilen kann genau auf deiner sprichwörtlichen Wellenlänge liegt:



Wenn sich deine Fragestellung nicht an dem Modell in dem Video erörtern lässt, dann betrifft sie nicht die Schnittmenge aus komplexen Systemen und Software (denn beides sehen wir dort in Reinkultur) sondern etwas drittes.

Ich weiß leider nicht wie dieser spezielle Roboter programmiert ist, aber mein Halbwissen sagt mir, dass man wahrscheinlich eine Differentialgleichung lösen muss um das klassisch zu machen und dass ein Roboter den Trick auch durch Reinforcement Learning lernen kann. Das ist intuitiv auch plausibel denn du kannst einen Ball fangen, aber du kannst keine Differentialgleichung lösen (no offense, das generische "du" ist gemeint). In einem praktisch sehr relevanten Sinne ist es einfacher das Reinforcement Learning Problem für das Doppelpendel hinzuschreiben, als die Differentialgleichung zu lösen. Das ist, in einer Nussschale, die KI Revolution, die du gerade beobachtest.

Disclaimer:
Ich vereinfache natürlich heillos, es ist zu lange her, dass ich das ernsthaft gemacht habe, "don't quote me on that" wie man so schön sagt. Flüchtiges googlen zeigt, dass das alles noch Diplomarbeitsniveau ist (https://www.researchgate.net/publicatio ... er_Systeme) aber ich habe das jetzt nur überflogen.
Auf die Frage wie weit wir davon weg sind, dass Software so intelligent ist, dass sie selbst als "practitioner" im Sinne deines Artikels auftreten kann wirst du sehr verschiedene Antworten bekommen, je nachdem we du fragst. Die konservative Sichtweise ist vermutlich, dass es Probleme gibt, für die es leichter ist die Lösung direkt hinzuschreiben und Probleme gibt, für die es leichter ist das RL-Problem hinzuschreiben. Warum sollte eins "von Natur aus nützlicher" als das andere sein? Der praktische Nutzen ein Doppelpendel balancieren zu können ist überschaubar, um im Beispiel zu bleiben. Der Linux Kernel wäre vermutlich nicht besser wenn er als Lösung eines RL-Problems entstanden wäre.

Um irgendwie zum Ende zu kommen: Der (ein?) Punkt ist, dass "Software die mehr ist wie die Systeme aus dem Paper" _nicht_ so aussieht: "alle Variablen dreifach an drei verschiedenen Stellen; alle Funktionen fünffach; um jeden Zugriff ein if von dem man nicht weiß, ob es jemals false werden kann – aber ich hatte solche Systeme in der Hand und sie waren unwartbar. Wegschmeißen und neu schreiben." Sie sieht mehr aus wie ChatGPT. Das ist eher das Gegenteil von dem was du beschreibst. Ich vermute wenn du wüsstest wieviele ifs so in einem ChatGPT stecken, relativ zum Funktionsumfang würdest du mit den Ohren schlackern.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4186
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: How Complex Systems Fail

Beitrag von Chromanoid »

Microservices, Serverless, Graceful Degradation, Chaos Engineering und Geo-Redundancy sind doch im Grunde die Stoßrichtungen in die größere Anwendungen gehen. Man muss das ganze sicher auf mehreren Abstraktionsebenen betrachten. Jede Abstraktionsebene sollte für sich hinreichend gut funktionieren. Wobei gut hier kein Selbstzweck ist, sondern die Auswirkung auf die User meint...

Ich würde Failure hier immer im Kontext einer User Experience sehen. Wenn mein Zug fünf Minuten später kommt, aber meine Anschlusszüge auf jeden Fall erreicht werden, stört das nicht wirklich. Das gleiche gilt für Software. Die muss so funktionieren, dass mich Fehler nicht stören. Wenn ich drei Stunden Tipp-Arbeit verliere, bin ich richtig angenervt - da ist mir auch egal, dass ich nicht gespeichert habe, der Fehler also auch bei mir liegt.

Zu Tests: https://martinfowler.com/articles/2021-test-shapes.html
Alexander Kornrumpf
Moderator
Beiträge: 1993
Registriert: 25.02.2009, 13:37

Re: How Complex Systems Fail

Beitrag von Alexander Kornrumpf »

Chromanoid hat geschrieben: 04.01.2023, 09:02 Microservices, Serverless, Graceful Degradation, Chaos Engineering und Geo-Redundancy sind doch im Grunde die Stoßrichtungen in die größere Anwendungen gehen. Man muss das ganze sicher auf mehreren Abstraktionsebenen betrachten. Jede Abstraktionsebene sollte für sich hinreichend gut funktionieren. Wobei gut hier kein Selbstzweck ist, sondern die Auswirkung auf die User meint...

Ich würde Failure hier immer im Kontext einer User Experience sehen. Wenn mein Zug fünf Minuten später kommt, aber meine Anschlusszüge auf jeden Fall erreicht werden stört das nicht wirklich. Das gleiche gilt für Software. Die muss so funktionieren, dass mich Fehler nicht stören. Wenn ich drei Stunden Tipp-Arbeit verliere, bin ich richtig angenervt - da ist mir auch egal, dass ich nicht gespeichert habe, der Fehler also auch bei mir liegt.
Und ich glaube das ist der Punkt wo sorgfältigere Definitionen wichtig werden. Wenn du den Monolith "Doppelpendel" in die beiden Microservices "Pendel 1" und "Pendel 2" zerlegst dann wird das beobachtbare Verhalten der beiden Einzelsysteme zusammen nicht das beobachtbare Verhalten des ursprünglichen Gesamtsystems wiedergeben. Das ist die Definition eines komplexen Systems.

Natürlich ist das ein Feature von Microservices, kein Bug. Es kann aber definitionsgemäß nur funktionieren, wenn das gewünschte Verhalten gar nicht das komplexe Verhalten des Gesamtsystems war sondern eben nur die Summe der Einzelsysteme. Also das vorliegt, was man in dem 70ern "accidental complexity" nannte.

Wenn das geht, sollte man es natürlich tun (man braucht dazu keine Microservices, das ist ein Implementierungsdetail, aber das ist eine andere Diskussion). Dann war aber das Problem nie inhärent komplex.

Wenn das gewünschte Verhalten das komplexe Verhalten ist, dann wird eine Zerlegung in Microservices katastrophal scheitern. Das ist wie ein Naturgesetz. Ich würde behaupten, genuin komplexe Probleme sind sehr sehr selten. Die Million-Dollar-Question ist wie man die beiden Problemklassen unterscheidet. Wenn du ein komplexes Software-System vorfindest, liegt es daran, dass der Entwickler zu blöd war, oder ist das Problem wirklich komplex?
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4186
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: How Complex Systems Fail

Beitrag von Chromanoid »

Ich glaube Du unterschätzt wie der gesamte Lebenszyklus mit Wartung, Feature-Entwicklung aber auch Auslieferung von Updates sowie Änderungen der Umgebung z.B. durch Veränderungen der Ausführungsumgebung, Browser-Updates und Co. Teil eines Software-Systems ist. Microservices sind ja eher dafür da, diese Komplexität zu reduzieren - nicht die Komplexität des eigentlichen Problems.
Alexander Kornrumpf
Moderator
Beiträge: 1993
Registriert: 25.02.2009, 13:37

Re: How Complex Systems Fail

Beitrag von Alexander Kornrumpf »

Chromanoid hat geschrieben: 04.01.2023, 09:26 Ich glaube Du unterschätzt wie der gesamte Lebenszyklus mit Wartung, Feature-Entwicklung aber auch Auslieferung von Updates sowie Änderungen der Umgebung z.B. durch Veränderungen der Ausführungsumgebung, Browser-Updates und Co. Teil eines Software-Systems ist. Microservices sind ja eher dafür da, diese Komplexität zu reduzieren - nicht die Komplexität des eigentlichen Problems.
Nein unterschätze ich nicht. Ich würde das was du beschreibst aber nicht Komplexität nennen und ich möchte behaupten das ist auch nicht das was der von Krishty zitierte Artikel meint.

EDIT: Ggf. hatte ich dich auch missverstanden und du meinst, dass du den Betrieb der Software zum "System" Software dazu rechnen willst. Das ist dann keine Frage von über- oder unterschätzen sondern einfach wieder eine Definitionsfrage. Ich hatte im ersten Beitrag schon etwas zu Betrieb gesagt, wir könnten uns da einig sein. Ich glaube aber dass Krishty das Software-Artefakt an sich meinte, siehe wieder "alle Variablen dreifach an drei verschiedenen Stellen; alle Funktionen fünffach; um jeden Zugriff ein if von dem man nicht weiß, ob es jemals false werden kann – aber ich hatte solche Systeme in der Hand und sie waren unwartbar. Wegschmeißen und neu schreiben."
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4186
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: How Complex Systems Fail

Beitrag von Chromanoid »

Ah, ja genau. Ich rechne die Weiterentwicklung und den Betrieb der Software zum "System" Software dazu. Das ist ja zumindest "offiziell" Teil der Softwarequalität.

Ich denke die meisten Systeme sind eben vor allem deshalb "komplex", weil viele komplizierte Dinge aufeinander treffen.

Zum "kleinteiligeren" Software-Teil: Viele, ich eingeschlossen, sind ja zumindest erst mal für mehr WET (write everything twice) und weniger DRY. Denn die "Wrong Abstraction" ist glaube ich eines der größten Risiken für "accidential complexity".

Redundanz im Software-Artefakt selbst finde ich schwierig - also mal abgesehen von ähnlichen Funktionen, die keinen gemeinsamen Code haben (WET). Was ich sinnvoll finde, ist das Prüfen von Zwischenergebnissen anhand von separat gepflegten Plausibilitätsregeln, um Fehlerzustände (ggf. ausgelöst durch Bugs) besser abzufangen.

Nachtrag: Und Machine Learning Kram würde ich da mal ausnehmen, weil es da ja sozusagen zum Algorithmus gehört über "chaotische Redundanz" Wahrscheinlichkeiten und Grenzwerte festzustellen.
Alexander Kornrumpf
Moderator
Beiträge: 1993
Registriert: 25.02.2009, 13:37

Re: How Complex Systems Fail

Beitrag von Alexander Kornrumpf »

Chromanoid hat geschrieben: 04.01.2023, 10:04 Zum "kleinteiligeren" Software-Teil: Viele, ich eingeschlossen, sind ja zumindest erst mal für mehr WET (write everything twice) und weniger DRY. Denn die "Wrong Abstraction" ist glaube ich eines der größten Risiken für "accidential complexity".
Eigentlich gehört es hier nicht zum Thema aber ich will jetzt kein spin-off vom spin-off Thread aufmachen: WET (in dem Sinne wie es in deinem Link diskutiert wird) und DRY sind beides gute Heuristiken. Interessant wird es überhaupt erst da wo man die Nuancen der Situation verstehen muss, um den scheinbaren Widerspruch aufzulösen. Leider fehlen in der Diskussion über Software oft diese Nuancen.

Ich habe z. B. schon öfter sowas gesagt wie "ich bin ein Verfechter von DRY". Ich habe damit nicht gemeint, dass ich WET falsch finde. Ich befürchte aber, dass das Gegenüber das verstanden haben könnte.

Siehe auch: https://zfx.info/viewtopic.php?p=70265#p70265
NytroX
Establishment
Beiträge: 278
Registriert: 03.10.2003, 12:47

Re: How Complex Systems Fail

Beitrag von NytroX »

Ich kenne jedenfalls auch Systeme aus Energieversorgung, Luftfahrt und Logistik, die wunderbar funktionieren. Aber auch gleich 10-100 mal so viele, die es nicht tun - die wurden meistens von Heerscharen an Pseudo-Profi-Entwicklern gebaut, denen ihr Gehalt wichtiger war als das, was sie bauen. (Und damit meine ich nicht nur die Entwickler, sondern auch die "Business-Analysten", die die Prozesse dazu gemacht haben und die "Manager" die Entscheidungen treffen.
Menschliches Versagen eben.

Mal ein nicht-Software Beispiel:
Am Flughafen Berlin Brandenburg war die Rolltreppe einen halben Meter zu kurz, um zum oberen Stockwerk zu gelangen. Glaubt ihr, die Handwerker wissen nicht, was ein Zollstock ist? Und Architekten gabs keine/hatten alle gerade Urlaub?
Gleiches Beispiel, da lagen Kabel nebeneinander, die niemals nebeneinander liegen durften. Hat das einer falsch gelegt, der es nicht wusste? Und niemand kontrolliert? Was war mit den anderen Teammitgliedern oder dem Aufseher/Vorarbeiter? Alle planlos und blind?

Wohl kaum... das ist alles gewollte, gut-geplante menschliche Dummheit. (ist natürlich übertrieben - was ich meine ist, dass jeder aus anderen persönlichen Gründen an so einem System arbeitet, und in >>50% ist das Ziel der einzelnen Personen nicht der Erfolg oder die Korrektheit des Systems)

Ich lehne mich einfach mal aus dem Fenster und behaupte folgendes:
Die Eigenschaft, die ein komplexes System ausmacht, ist, dass viele Menschen beteiligt sind. Rätsel gelöst ;-)

In der analogen Welt ist halt die harte Realität am Werkeln, wohingegen in so einer CPU eine schöne heile Welt herrscht
Genau genommen ist die echte Welt digital (quantisiert), wenn es nach Max Planck geht. Das "analoge" entsteht durch die Verwendung verschiedener Bezugssysteme in den Berechnungen (insbesondere durch die Raumzeit) :-P
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 487
Registriert: 05.07.2003, 11:17

Re: How Complex Systems Fail

Beitrag von Lord Delvin »

Ich finde es passt zum Originalthema nur bedingt; muss da auch noch zwei-drei Kommentare loswerden wenn ich die Ruhe finde.
Aber erstmal ein paar Gedanken hierzu:

Ein Problem bei vielen Softwarelösungen ist, dass sie eine relativ geringe Wertschöpfung haben die kaum die Personalkosten deckt. Es ist einfach nicht wie ein Kernkraftwerk wo es letztlich egal ist ob es 6 oder 25 Mrd.€ kostet, weil es am Ende über die Lebenszeit hunderte Mrd.€ wieder reinbringt. D.h. man hat einen sehr hohen Druck möglichst günstige Lösungen zu finden. Das führt dazu, dass quasi alle pip/npm/maven/go(wie auch immer das funktioniert; scheint einfach code von github runterzuladen) verwenden. Die Prüfung ob das, was man da gerade eingebaut hat wirklich funktioniert erfolgt meistens nur sehr indirekt, was an der Stelle extrem gefährlich ist. Außerdem ist der Ausbau von Abhängigkeiten aus Bestandssoftware idR sehr teuer und wird deswegen meist nur aus triftigem Grund gemacht.

Was mich zu Punkt zwei bringt, an dem die meisten Analogien oben und zu anderen Systemen brechen: Ein kleiner Fehler bringt das ganze System zu Fall und es gibt keine Redundanz. Wenn man systematisch irgendwo in einer Minikomponente ein falsches Zertifikat ausstellt wird jede darüber laufende Kommunikation unterbrochen. Das ist nicht wie ein Kurzschluss in einer Leitung sondern eher wie einer in allen Leitungen. Sowas können echte Systeme in der Regel nicht. Gesetze stellen hier teilweise eine Ausnahme da; mein Beispiel wäre Cum-Ex und ich würde den Gesetzgeber dafür verantwortlich machen; führt aber etwas von der Diskussion weg. Das Problem ist ein Stückweit, dass Software der Bauplan und nicht das Produkt ist. Da bedeutet Redundanz was anderes. Auf Hardwareebene oder Instanzebene gibt es die, wie oben schon erwähnt.

Ein weiteres Problem ist, dass man Software nicht sehen kann. Die Gesetzesanalogie passt da eigentlich auch sehr gut. Es ist einfach eine riesige Ansammlung an Regeln. Und du kannst es auf tausend weisen so verkacken, dass nur eine davon alles zu Fall bringt. Weil man ein Zertifikat nicht ausstellt, weil man in einem UI den Status nicht richtig meldet, weil man irgendeine Berechtigung nicht prüft, weil man irgendwo dynamisch Code nachlädt. Das siehst du den Komponenten nicht an. Und gerade in dieser Cloud-/Microservice-Welt habe zumindest ich jedes Gefühl dafür verloren, was eigentlich angemessen ist. Da gibt es Komponenten die eigentlich nur ein JSON nehmen und dann einen Request basieren und eine Statusmeldung produzieren und du brauchst dafür ein 50MB binary, weil man halt am Ende des Tages noch tausend Sachen Richtung Krypto, Observability, GC, Runtime Config Reload etc. einfach machen muss oder mitbekommt oder Teile dafür mitbekommt, weil es nicht so feingranular gekapselt werden kann, dass man es nicht mitbekäme, weil es dann keiner mehr verwenden könnte.

Mein letzter Gedanke betrifft Komplexität und Größe. Komplexität im Sinne von dem was ich mir bei Tyr gebe habe ich in der Praxis ehrlich gesagt noch nie gesehen. Ich habe ehrlich gesagt noch nie ein Problem gesehen, bei dem ich die Lösung nicht irgendwie kannte oder sie relativ offensichtlich war. Das meiste ist einfach Arbeit oder teuer. Das Problem in der Praxis ist die schiere Größe der Systeme und die Integration. Was dazu führt, dass man mit sehr vielen Leuten reden muss und irgendwie erreichen, dass die Systeme real zusammenpassende Daten produzieren. Wenn du dich darauf verlassen musst, dass sie tatsächlich zusammenpassen, dann kann das Probleme verursachen, vor denen du dich kaum schützen kannst; da geht es dann mehr darum dafür zu sorgen, dass die Bereinigungskosten nicht zu hoch sind.

Letztlich denke ich, dass auch bei Software versucht wird, das System möglichst sicher zu machen. Weil Software aber eben diesen Bauplancharakter hat, muss es dadurch geschehen, dass man die Prüfungen vor der eigentlichen Auslieferung macht. Meine Wahrnehmung ist, dass da in einigen Teilen der Branche sehr viel Energie reinfließt. Das scheint aber obskurerweise mit der Marge zu korrelieren. Obskur, weil meine Erfahrung ist, dass sich die Marge dadurch letztlich erhöht. Die tatsächlichen Instanzen und die Hardware wird ja schon ewig redundant ausgelegt. ECC oder RAID ist ja jetzt nicht der neue Scheiß; Loadbalancer auch nicht :)

EDIT: Einen Gedanken vergessen aufzuschreiben: Manche Probleme sieht jeder, aber keiner ist bereit darauf zu Reagieren. Auf dem Papier käme vermutlich viel Cloudsoftware ohne Frankfurt aus, aber ich will nicht wissen was die Welt macht, wenn das wer mal bombardiert oder einfach nur mal eine Woche kein Wind weht.
XML/JSON in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 487
Registriert: 05.07.2003, 11:17

Re: How Complex Systems Fail

Beitrag von Lord Delvin »

Lord Delvin hat geschrieben: 05.01.2023, 19:42Das führt dazu, dass quasi alle pip/npm/maven/go(wie auch immer das funktioniert; scheint einfach code von github runterzuladen) verwenden. Die Prüfung ob das, was man da gerade eingebaut hat wirklich funktioniert erfolgt meistens nur sehr indirekt, was an der Stelle extrem gefährlich ist.
Sprach er und las dann https://www.heise.de/news/Rust-bis-zu-2 ... ag.beitrag

Und ich dachte das wäre die Existenzberechtigung von Rust. Aber war sicher wirklich nur Unachtsamkeit :)
XML/JSON in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Antworten