Parameter Tuning

Systemproblem

Ein Team hat Performance-Probleme im Backend. Die Reaktion des Architekten: "Wir erhöhen den Connection-Pool der Datenbank von 50 auf 100". Das ist Parameter Tuning. Management sieht sinkende Velocity der Entwickler. Die Reaktion: "Wir erhöhen das IT-Budget um 5% und drehen die Bonus-Zahlung um 2% nach oben". Das ganze Unternehmen verhält sich wie ein Fahrer in einem Auto mit Totalschaden, der glaubt, er könne das Auto reparieren, indem er am Radio-Lautstärkeregler (Parameter) dreht.

Intervention

Parameter Tuning ist Level 12 (Der wichtige Boden, der geringste Hebel) nach Meadows. Als eigenständige Intervention ist es fast nutzlos zur Lösung chronischer Krisen. Die System-Aufforderung lautet: Erkenne, wenn dein Team im "Parameter-Wahn" gefangen ist. Stoppe stundenlange Diskussionen in Slack-Kanälen darüber, ob der Kubernetes Liveness-Timeout 10 oder 15 Sekunden betragen soll. Das System ist mathematisch oft völlig unempfindlich gegenüber Parametern, zwinge das Team stattdessen eine Hebel-Ebene höher zu suchen.

Erwartete Wirkung

Das aktive Vermeiden von Parameter-Kämpfen macht enorm viel Arbeitszeit von hochbezahlten Architekten frei. Das Problem mit Parametern: Man kann sie leicht in einem Jira-Ticket erfassen und sie geben einem Lead-Developer das psychologische Gefühl von "sichtbarer Handlung". Wenn man Parameter-Tuning verbietet (Solange keine fundierte Bottleneck-Diagnostik vorliegt), zwingt man das Team zum wirklichen Design-Denken.

Nebenwirkungen und Risiken

Wenn man Parameter Tuning als Allheilmittel einsetzt, maskiert (versteckt) man den zugrundeliegenden strukturellen Fehler (Shifting the Burden). Wenn die Applikation stark viel RAM verbraucht, weil der Algorithmus O(n^2) ist (Systemischer Fehler), und der DevOps-Engineer den RAM im AWS-Dashboard von 8GB auf 16GB (Parameter Tuning) erhöht, ist der Alarm kurzfristig stumm. Aber bei der nächsten Marketing-Kampagne (Scale) sprengt die Applikation die 16GB und reißt alles mit sich. Tuning verbirgt die Krankheit.

Diagramm

Wann diese Intervention wirksam wird

Meadows merkt sarkastisch an: "Parameter-Pushing ist das, was Politiker am meisten tun". Die IT-Abteilung tut das auch. Konstanten (Steuersätze in der Politik, Speicherlimits in der IT) sind wichtig, wenn es um das fine-tuning eines gesunden Systems geht. In der Formel 1 entscheidet der Reifendruck (Parameter) über Hundertstelsekunden. Aber in einem kaputten System wird dich Parameter-Tuning nicht heilen. Du kannst die Titanic nicht retten, indem du die Kapazität der Beiboote von 40 auf 42 Personen (Parameter) optimierst.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

Feedback Loop Redesign verkabelt die Rohre des Autos völlig neu. Goal Reframing bestimmt, in welche Stadt das Auto fährt. Parameter Tuning ist nur der Tempomat auf der Autobahn. Es ist das letzte Prozent, wenn das Fundament stimmt.

Wie du die Intervention sauber einleitest

Wende die "Faktor-10" Regel an. Wenn ein Team in einer Krise ein Ticket einstellt: "Erhöhung Timeout von 30s auf 40s", stell die Gegenfrage: "Wäre das Projekt gerettet, wenn wir den Timeout auf utopische 300s (Faktor 10) stellen?". Wenn die Antwort lautet: "Nein, dann fällt die Datenbank trotzdem aus, nur später", hast du bewiesen, dass der Parameter kein wirksamer Hebelpunkt für dieses Problem ist. Das Ticket sollte dann nicht als eigentliche Lösung behandelt werden. Sucht nach wirksameren Hebeln.

Erste Umsetzungsschritte

Verständnis von "Sensitive Parameters". Es gibt seltene Ausnahmen. In chaotischen Systemen (z.B. Zinseszins, Pandemien, virale Netzwerkeffekte in Social Apps) kann die winzige Veränderung eines Parameters (R-Faktor von 0.99 auf 1.01) das Start-up stark wachsen lassen oder beenden. Wenn du am Parameter schraubst, musst du mathematisch (Nicht aus dem Bauch heraus!) wissen, ob du an einer linearen oder exponentiellen Skala drehst.

Woran du Wirkung erkennst

Gibt es in unseren Incident-Post-Mortems eine Veto-Erlaubnis, die es verbietet, ein Prio-1 Meeting mit dem simplen Beschluss "Wir haben das Threshold-Limit von 80% auf 90% gesetzt" zu beenden, weil uns bewusst ist, dass dies nur eine Kosmetik-Intervention ist?

Quellen

Donella Meadows — Leverage Points, Punkt 12: Numbers/Constants (1999)

John Sterman — Business Dynamics, Kap. 8: Parameter Estimation (McGraw-Hill, 2000)

Wikipedia: Twelve Leverage heavily on Meadow's Level 12, avoiding 'tuning' as an excuse for not fixing the architecture.