Warum HTTP 200 kein Beweis für ein gelungenes Shop-Update ist

Der Fall

Ein JTL-Shop wurde aktualisiert. Anschließend wurden neun zentrale Seiten aufgerufen: Startseite, Kategorien, Artikeldetail, Warenkorb, Kasse. Jede einzelne antwortete mit dem Statuscode 200 — technisch also einwandfrei. Das Update galt als geglückt.

Tatsächlich waren sieben von acht Template-Blöcken still ausgefallen. Die Seiten luden, das Grundgerüst stand, die Navigation funktionierte. Nur fehlte an mehreren Stellen der Inhalt, den diese Blöcke sonst einsetzen. Bemerkt wurde es nicht über eine Fehlermeldung, sondern über den Umsatz.

Warum die Prüfung versagt hat

Der Statuscode beschreibt den Transport, nicht den Inhalt. Er beantwortet die Frage „konnte der Server eine Antwort ausliefern?“ — und die lautet auch dann „ja“, wenn die Antwort halb leer ist.

Template-Systeme verstärken das. Fällt ein Block aus, weil sich nach dem Update eine Variable anders nennt oder eine Funktion umgezogen ist, liefert der Block in der Regel nichts zurück statt einen Fehler zu werfen. Aus Sicht der Seite ist das kein Ausnahmefall, sondern ein leerer Bereich. Und ein leerer Bereich sieht in der Antwort genauso aus wie ein Bereich, in dem gerade nichts anzuzeigen war.

Was stattdessen hilft

Der einzige verlässliche Weg ist der Vergleich mit einem bekannten Zustand. Nicht „antwortet die Seite?“, sondern „antwortet sie so wie vorher?“.

In der Praxis heißt das drei Dinge:

• Vorher messen. Bevor das Update läuft, wird der Ist-Zustand aufgenommen: welche Seiten welchen Umfang haben, welche Blöcke greifen, welche Bausteine sich melden.
• Nicht am Livesystem üben. Die Messung ist nur dann etwas wert, wenn danach eine Entscheidung möglich ist. Am Livesystem ist die Entscheidung bereits gefallen.
• Nachher dasselbe messen und gegenüberstellen. Erst die Differenz zeigt, was verschwunden ist.

Ein Nebenbefund, der Zeit spart

Wer bei JTL-Shop 5 wissen will, was ein Update tatsächlich anfasst, sucht schnell im naheliegenden Verzeichnis für Migrationen. Das ist seit Version 5.4 leer. Die tatsächlich ausgeführten Schritte liegen woanders im Quellbaum. Wer am falschen Ort nachsieht, schließt daraus, ein Update fasse die Datenbank gar nicht an — was nicht stimmt.

Die Messung an einem konkreten Sprung von Version 5.5.4 auf 5.6.2 ergab: zwölf von 544 Tabellen werden verändert. Wenig genug, dass sich ein gezielter Rückweg lohnt — und genug, dass man ihn braucht.