OSTRELLE · LERNEN · MIT ÜBUNGEN

4. Update und Störung mit Rückweg bearbeiten

Du entscheidest anhand konkreter Beobachtungen, ob ein neuer Stand übernehmen darf. Mit konkreten Schritten, eigener Übung, Musterlösung und Erfolgskontrolle.

Eine Testinstanz verantwortlich betreiben · Lektion 4 von 4 · Quellstand 3. November 2026

Das lernst du

Du entscheidest anhand konkreter Beobachtungen, ob ein neuer Stand übernehmen darf.

Ein Update umfasst Anwendung, Adminassets, Runtime-Themes, Starter-/Buchungspakete und gegebenenfalls Datenmigrationen. Ein altes Binary über bereits veränderte Daten zu legen ist kein geprüfter Rollback. Verknüpfe deshalb Quellcommit, Artefakt und Datenstand in deiner Betriebsnotiz.

Readiness, sichtbare Website und Schreibablauf beantworten unterschiedliche Fragen. Eine Startseite mit 200 beweist weder funktionierenden Login noch korrekte Buchungskapazität. Prüfe die Wege, die deine Instanz tatsächlich anbietet. Die hier genannten Kontrollen begründen keinen pauschalen Produktions- oder Sicherheitsnachweis.

Schritt für Schritt

Notiere alten Commit, Image/Artefakt, Datenstand und Runtimepakete. Prüfe die aktuelle Sicherung einschließlich Restorebeleg.
Spiele den neuen Stand zuerst auf eine isolierte Datenkopie. Halte fremde Mails und Zahlungen ausgeschaltet.
Prüfe Health/Readiness, alle angebotenen Seiten und eine echte 404, Login/Logout und mindestens einen berechtigten Schreibablauf.
Teste vorhandene Kontakt-, DOI-, Buchungs- und gegebenenfalls freigegebene Shopwege mit eigenen Testdaten vollständig.
Bei Fehlern erfasse Pfad, Eingabe, Zustand und Antwort. Prüfe vorhersehbar Datenbank, Datenträger, Runtimepakete und Konfiguration; starte nicht blind immer wieder neu.
Übernimm erst nach dem vereinbarten Freigabeweg. Kontrolliere die gleichen Wege nach dem Wechsel und halte den vorher geprüften Rückweg bereit.

Deine Übung

Die neue Startseite funktioniert, aber eine Terminbuchung zeigt „pausiert“. Was prüfst du und darf der Stand allein wegen HTTP200 übernommen werden?

Musterlösung und Erklärung

Du prüfst Onlinebuchungseinstellung, aktive Angebote/Zeitfenster, Mailbereitschaft und das geladene Buchungs-Runtimepaket. Die Readiness und Logs müssen mit dem konkreten Fehler verglichen werden. Eine beabsichtigte Pause wird anders beurteilt als ein durch fehlende Runtimefiles verursachter Ausfall.

HTTP200 der Startseite genügt nicht. Wenn Buchungen zum vereinbarten Leistungsumfang gehören, bleibt die Übernahme bis zum vollständigen positiven und negativen Buchungstest offen. Ein Rückweg stellt Anwendung und Daten kompatibel wieder her.

So prüfst du dein Ergebnis

Commit, Artefakt und Datenstand sind zuordenbar.
Die tatsächlich angebotenen Fachwege wurden geprüft.
Fehler und Rückweg sind konkret; kein bloßes „wird schon gehen“.