Optimiere das System, nicht seine Komponenten
Hammings erste Regel der Systemtechnik
Hammings Kernprinzip aus Kap. 28: Optimiert man die Komponenten, wird man wahrscheinlich die Systemleistung ruinieren.
Er illustrierte es mit der Geschichte des Differentialanalysators. Zwei Einheiten sollten verbunden werden. Die Entwickler verbesserten die Verstärker in der zweiten Einheit. Am Abnahmetag führte Hamming den Standardtest durch — löse y'' + y = 0, plotte y gegen y', erwarte einen Kreis. Der Test schlug fehl. Ursache: die verbesserten Verstärker zogen mehr Strom durch die Erdungsschaltung. Die Erdung war für die ursprüngliche Auslegung ausgelegt. Sie war nicht für den neuen Strompegel ausgelegt. Die Schnittstelle brach, nicht die Komponente.
Seine Verallgemeinerung: Die meisten Systemausfälle lassen sich auf Schnittstellen zurückführen, nicht auf Komponenten. Komponenten werden entworfen, getestet und zertifiziert. Schnittstellen werden als nachträglicher Gedanke entworfen, selten getestet und nie unabhängig zertifiziert. Wenn sich eine Komponente ändert, ändert sich ihr Schnittstellenverhalten. Nichts nachgelagert wurde für diese neue Schnittstelle ausgelegt.
Wesentliche Asymmetrie: Eine 10×-Verbesserung einer Komponente kann zu einer 10×-Verschlechterung des Systems führen, wenn die Komponente eine begrenzte Schnittstelle speist. Die Verbesserung addiert sich nicht — sie subtrahiert.
Das Bildungssystem als gescheitertes System-Engineering
Hammings Bildungsbeispiel
Hamming wandte dieses Prinzip auf die Bildung an. Die Optimierung individueller Fachnoten – das Einüben von Schülern zur Maximierung der Testergebnisse in jedem Fach – führt zu Schülern, die in einzelnen Tests gut abschneiden, aber Wissen nicht über Disziplinen hinweg integrieren können.
Jede Komponente (Fachnote) verbessert sich. Das System (Bildung, definiert als integriertes Verständnis) verschlechtert sich. Die Schnittstelle zwischen den Fächern — die Fähigkeit des Schülers, Wissen über Domänen hinweg anzuwenden — wurde nie optimiert. Sie verkümmerte.
Das ist kein Zufall der Umsetzung. Es ist strukturell. Wenn man Komponentenleistung misst und belohnt, erhält man Komponentenoptimierung. Schnittstellen sind für Komponentenmetriken unsichtbar.
Seine Empfehlung: Finde den Engpass im System, dann frage, was flussabwärts passiert, wenn man ihn entfernt. Die Beseitigung eines Engpasses überflutet die nächste Warteschlange. Eine uneingeschränkte Optimierung wird zu einer neuen Einschränkung.
Verfolgung der Schnittstellenverschlechterung
Hamming zeigte, dass die Verbesserung einer Komponente ihr Schnittstellenverhalten verändert — und der Rest des Systems war auf die alte Schnittstelle ausgelegt.
Knoten, Warteschlangen, Surge-Scores
Ein MOAD-Fabrikmodell
Jeder Software-Abhängigkeitsgraph bildet eine Fabrik. Jeder Knoten ist eine Arbeitsstation. Jede Kante ist eine Warteschlange. Arbeit gelangt in die Warteschlange eines Knotens, wird verarbeitet und fließt in nachgelagerte Warteschlangen.
Zwei Scores charakterisieren jeden Knoten:
Surge-Score = Speedup × In-Degree
Wie viel Arbeit flussabwärts strömt, wenn dieser Engpass beseitigt wird. Ein Knoten mit In-Degree 5 (5 vorgelagerte Abhängigkeiten, die alle in ihn münden) und einem 100-fachen Speedup erzeugt einen 500-fachen Surge flussabwärts.
Betweenness = In-Degree + Out-Degree
Wie zentral diese Arbeitsstation für den gesamten Fluss ist. Hohe Betweenness bedeutet, dass viele Pfade durch diesen Knoten verlaufen.
Zwei Archetypen:
Workaholic-Knoten: hohe Betweenness, hoher Surge-Score. Dies ist der Engpass. Jede Warteschlange davor staut sich wegen ihm. Entfernt man diesen Engpass, ohne die Kapazität danach zu erhöhen, bricht alles danach gleichzeitig zusammen.
Glutton-Knoten: hoher Out-Degree, niedriger Surge-Score. Verbraucht alles, was ihm zugeführt wird. Spürt keinen Schmerz, weil sein Engpass intern ist, nicht im Durchsatz. Die Maschine, die vergisst anzuhalten — Arbeit kommt rein, nichts geht raus, und der Knoten meldet „beschäftigt“ für immer.
MOAD-0001 & MOAD-0005: Ein Kopplungsfall
Der GHC-Fall
Vor einem MOAD-0001-Patch im GHC-Abhängigkeitsauflöser: N=50.000 Abhängigkeiten benötigten 17 Minuten zum Bauen. Danach: 10 Sekunden. Beschleunigung: 100×.
Was passiert downstream? Jeder Build-Cache, Artifact-Store und CI-Runner, der sich auf 17-Minuten-Batch-Ankünfte eingestellt hatte, erhält nun 100× mehr abgeschlossene Builds pro Stunde. Caches, die für 60 Build-Artefakte pro Stunde ausgelegt waren, erhalten nun 6.000.
Dies ist MOAD-0005: der Cache-Stampede-Defekt. Jeder Cache-Key wird gleichzeitig verfehlt, weil kein Cache auf die neue Ankunftsrate vorerwärmt wurde. Die Behebung von MOAD-0001 erzeugt MOAD-0005.
Die Kopplung ist nicht zufällig. Sie ist strukturell. Jede O(N²) → O(N)-Beschleunigung mit In-Degree > 1 erzeugt einen Surge-Score über 1. Ein Surge-Score über 100 ist ein MOAD-0005-Kandidat.
Staging Before Disclosure
Ein Build-System verarbeitet 1.000 Paket-Abhängigkeitsgraphen pro Stunde. Du patchst MOAD-0001 in seiner Graph-Traversierung und reduzierst die Build-Zeit von 60 Minuten auf 30 Sekunden — eine 120-fache Beschleunigung. Das System verarbeitet nun 120.000 Graphen pro Stunde.
Wann stoppen: Die Halt Condition
Die Halt-Bedingung
Ein Patch erfüllt die Halt-Bedingung — d. h.: nicht offenlegen — wenn alle vier Bedingungen gleichzeitig erfüllt sind:
1. Der Patch befindet sich in einem Live-System (gemergt, deployed)
2. Keine Betreuer sind für die Auswirkungen in nachgelagerten Systemen zuständig
3. Der nachgelagerte Defekt (MOAD-0005) ist nicht behoben
4. Beschleunigung >= 100×
Alle vier zusammen = das Baby weint. Weisen Sie das Team vor dem Zusammenführen zu, nicht danach.
Ein Knoten ohne Betreuer läuft wie eine Workstation ohne Arbeiter. Arbeit häuft sich an. Jemand bricht zusammen. Das Permacomputer-Prinzip: Sie reparieren den Dispatch-Algorithmus nicht, ohne die Fahrer zu stagen. Drei Fahrer, drei Millionen Menschen: Das Entblocken des Algorithmus erzeugt eine stampfende Herde unversorgter Anfragen statt einer schnelleren Auslieferung.
WALL-E: Vielfraße & Workaholics
Das WALL-E-Modell
Pixars WALL-E zeigt ein Fabrikmodell-Versagen in seiner deutlichsten Form. Vielfraße auf Schwebestühlen, ohne Reibung gefüttert. Workaholics — WALL-E, EVE — sterben an ihren Stationen, um den Nachschub am Laufen zu halten.
Der Vielfraß-Knoten (die Menschen auf Schwebestühlen) hat maximalen Out-Degree: Er konsumiert alles, was ihm zugeführt wird, und produziert nichts. Sein Surge-Score ist null — er ist eine Senke. Er spürt keinen Schmerz, weil sich nichts an seinem Ausgang ansammelt. Er konsumiert einfach.
Der Workaholic-Knoten (WALL-E) hat die maximale Betweenness: alles fließt durch ihn. Er nimmt alle Eingaben auf. Er erzeugt die einzige Ausgabe. Seine Surge-Bewertung würde, falls er jemals durch ein schnelleres Modell ersetzt würde, alle nachgelagerten Warteschlangen gleichzeitig überfluten.
Der Defekt im WALL-E-System liegt nicht bei den Vielfraßen. Es ist der fehlende Betreuer: niemand ist dafür zuständig, die Arbeitsstationen auszugleichen. Niemand hat die Kapazität vor dem Ausführen des Algorithmus bereitgestellt.
Der pip-Fall: Pre-Disclosure-Checkliste
Du entdeckst MOAD-0001 im Python-pip-Abhängigkeitsauflöser. Gemessene Beschleunigung: 200×. pip läuft auf etwa 400 Millionen Installationen pro Tag. PyPI stellt die Pakete bereit.