“80% Fehlerquote… und der Support hat immer noch keine Antwort: Wenn ein Major Release sich wie ein Glücksspiel anfühlt”

Das Upgrade, das mehr kaputtmacht, als es repariert

Zwischen ein paar Bugs und etwas grundlegend Instabilem liegt ein Unterschied. Wenn jemand von einer Fehlerquote von 80 % bei Installationen berichtet, ist diese Grenze klar überschritten. Das ist kein einzelner schlechter Server und keine falsch konfigurierte Umgebung, das ist ein Muster. Updates scheitern, Neuinstallationen scheitern, und selbst nach zwei Wochen mit dem Support gibt es keine Lösung.

So eine Situation bremst nicht nur, sie lässt einen daran zweifeln, ob das Upgrade überhaupt die richtige Entscheidung war. Wenn schon die Installation nicht zuverlässig läuft, fühlt sich alles danach wie ein Risiko an.

Die Reaktion der Community: „Ja … das betrifft nicht nur Sie"

Auffällig ist, wie schnell andere einsteigen, und zwar nicht mit Lösungen, sondern mit Wiedererkennung.

„Gleiches Problem", sagt jemand, der ein Dutzend Installationen jongliert und von der Zahl der Probleme schon überwältigt ist. Ein anderer beschönigt nichts: Gerade beschweren sich einfach zu viele Leute.

An diesem Punkt hört ein Problem auf, isoliert zu sein, und wird zur gemeinsamen Erfahrung. Das verändert das Verhalten. Statt intensiver zu troubleshooten, fangen die Leute an zu zögern. Rollouts werden pausiert, Zeitpläne infrage gestellt, und man sucht nach Gründen zu warten statt nach Gründen weiterzumachen.

Die Workarounds, die sich wie Rätselraten anfühlen

Dann kommen die Fixes, oder zumindest die Versuche. Jemand schlägt vor, die Start-Timeouts der Windows-Dienste über die Registry anzupassen. Ein anderer teilt ein Skript, das ServicesPipeTimeout erhöht, nur damit Dienste zuverlässig starten. Manchmal funktioniert das sogar.

Wie eine echte Lösung fühlt es sich trotzdem nicht an, sondern als würde man am System herumstochern, bis es sich fügt. Selbst die Leute, die diese Fixes nutzen, geben das zu. „Immer noch von Problemen durchzogen", sagt einer, offensichtlich nicht überzeugt, dass das Problem wirklich gelöst ist.

Darin steckt der Unterschied zwischen Troubleshooting und Stabilisierung. Das eine bringt Sie über den Fehler hinweg, das andere gibt Ihnen Vertrauen, und genau dieses Vertrauen fehlt gerade.

Wenn Fixes noch mehr Fragen aufwerfen

Je tiefer man gräbt, desto merkwürdiger wird es. Manche sagen, das Problem verschwinde auf neuerer Hardware, aber nicht auf älteren Systemen, selbst wenn ansonsten alles identisch ist. Andere verweisen auf PostgreSQL-Anpassungen, manche erwähnen API-Dienste, die nicht starten, und wieder andere berichten von Backup-Diensten, die schon nach wenigen Starts hängen bleiben.

Eine einzelne Grundursache gibt es nicht, nur Bruchstücke von Erklärungen, die sich nicht ganz zusammenfügen. Genau das macht die Lage gefährlich. Ohne klares Muster lassen sich Probleme nicht vorhersehen, kein Fix standardisieren und kein Rollout im großen Stil mit Zuversicht planen.

Das Performance-Problem, mit dem niemand gerechnet hat

Auch wenn Installationen gelingen, wird die Geschichte kaum besser. „Im Vergleich zu Version 12 sehr träge", merkt ein Nutzer fast beiläufig an. Ein anderer bereut das Upgrade komplett, nachdem er mit hängenden Diensten und kaputten Funktionen zu kämpfen hatte, etwa einem „Copy To", das sich nicht einmal aktivieren lässt.

Hier summiert sich die Frustration. Eine neue Version, die schwer zu installieren ist, danach aber besser läuft, ist eine Sache. Eine Version, die sich insgesamt schlechter anfühlt, ist etwas anderes. Dann behebt man nicht mehr nur Installationsprobleme, sondern stellt das Upgrade selbst infrage.

Die alte Regel, die immer wiederkehrt

Irgendwann fällt der Satz, den jeder erfahrene Admin schon einmal gehört hat: „Warten Sie ein paar Monate nach einem Major Release."

Das klingt fast wie eine Plattitüde, wirkt in solchen Momenten aber weniger wie ein Ratschlag als wie Überlebensinstinkt. Early Adopters nehmen den Schlag hin, finden Bugs, testen Grenzfälle und kämpfen mit Instabilität. Alle anderen schauen zu, warten und entscheiden für sich, ob das Risiko es wert ist. Gerade jetzt entscheiden sich viele fürs Warten.

Drei verschiedene Reaktionen auf dieselbe Situation

Interessant ist, wie unterschiedlich die Leute auf dasselbe Chaos reagieren. Eine Gruppe macht trotzdem weiter, troubleshootet, wendet Registry-Anpassungen an, testet Hardware-Unterschiede und tut alles, um es zum Laufen zu bringen.

Eine andere Gruppe friert Upgrades komplett ein. „Ich bleibe bei Version 12", sagt jemand, nicht aus Bequemlichkeit, sondern aus Vorsicht.

Und dann gibt es eine dritte Gruppe, die sich verbrannt fühlt. Bedauern macht sich breit, das Vertrauen sinkt, und das Upgrade wird zu etwas, das sie am liebsten nie angefasst hätten. Falsch ist keine dieser Reaktionen, sie hängen davon ab, wie viel Instabilität ein Team verkraften kann oder will.

Warum die Kombination schwerer wiegt als einzelne Bugs

Bugs passieren, jedes Major Release hat sie, und das überrascht niemanden. Hier sticht die Kombination heraus: hohe Fehlerquoten, uneinheitliche Fixes, Performance-Bedenken und ein Support, der nicht schnell genug Antworten geliefert hat. Erst die Anhäufung dieser Probleme untergräbt das Vertrauen.

Die Erkenntnis, die sich etwas zu vertraut anfühlt

Darin steckt ein Muster, das über ein einzelnes Produkt hinausgeht. Major Releases versprechen Verbesserungen, neue Funktionen und bessere Performance. Sie bringen aber auch Unbekannte mit, also Abhängigkeiten, Grenzfälle und Wechselwirkungen, die erst in realen Umgebungen auftauchen. Häufen sich diese Unbekannten, fühlt sich selbst etwas so Routinemäßiges wie eine Installation wie ein Glücksspiel an.

Ob sich Version 13 irgendwann stabilisiert, ist dabei kaum die Frage, denn das wird sie wahrscheinlich. Schwerer wiegt die einfachere Frage: Wollen Sie derjenige sein, der herausfindet, wo es kaputtgeht?