Lässt sich eine Website aktualisieren, ohne sie offline zu nehmen?

Viele Website-Änderungen lassen sich einspielen, während die bestehende Website erreichbar bleibt. Das ist bei Inhalts- und Designänderungen, neuen Seiten und sorgfältig vorbereiteten Software-Releases oft realistisch.

Das gilt jedoch nicht für jede Änderung. Bei Live-Bestellungen, Kundenkonten, inkompatiblen Softwareversionen, der Infrastruktur oder einem externen Dienst kann ein festes Wartungsfenster nötig sein. Entscheidend ist nicht nur, ob die Website online bleibt. Es geht darum, welche Funktionen verfügbar bleiben, wie wir die Änderung prüfen und was passiert, wenn sie nicht wie erwartet funktioniert.

Welche Website-Updates sind im laufenden Betrieb möglich?

Textkorrekturen, Bildwechsel, neue Beiträge und Seiten sowie einzelne visuelle Anpassungen lassen sich oft vorbereiten und veröffentlichen, ohne die gesamte Website abzuschalten. Auch kleinere Softwareänderungen können so eingespielt werden, wenn Website und Release-Prozess dafür geeignet sind.

Die Art des Updates allein entscheidet nicht. Eine gewöhnliche Inhaltsänderung kann auf einer Website Menüs, Suche, zwischengespeicherte Seiten oder generierte Dateien betreffen, auf einer anderen dagegen nur eine einzelne Seite. Auch vertraute Aufgaben müssen im Zusammenhang mit dem jeweiligen System geprüft werden.

Auch „online“ braucht eine praktische Bedeutung. Eine erfolgreich geladene Startseite beweist nicht, dass Anfragen, Zahlungen, Anmeldungen, Suchfunktionen oder Verwaltungsaufgaben weiterhin funktionieren. Die geschäftlich wichtigen Bereiche der Website müssen separat geprüft werden.

Wovor schützt eine Staging-Website?

Eine Staging-Website ist eine getrennte Umgebung, in der Änderungen vorbereitet und geprüft werden, bevor Besucher sie sehen. So können unfertige Layouts, Texte oder offensichtliche Funktionsfehler während der Arbeit von der öffentlichen Website ferngehalten werden.

Staging verringert Unsicherheit, beseitigt sie aber nicht. Daten, Traffic, Konfiguration, Zugangsdaten, verbundene Dienste oder Serverressourcen können sich von der Live-Umgebung unterscheiden. Ein erfolgreicher Test ist ein hilfreicher Nachweis, aber keine Garantie für identisches Verhalten in der Produktion.

Der Release-Plan muss weiterhin festlegen, was nach der Änderung auf der öffentlichen Website geprüft wird.

Wie kann eine neue Version die alte ohne leere Seite ablösen?

Eine Möglichkeit ist, die neue Version getrennt vorzubereiten, während die bestehende Version Besucher weiter bedient. Erst nach den Tests wird der Traffic umgeleitet. Tritt ein schwerwiegendes Problem auf, kann der Traffic gegebenenfalls zur vorherigen Version zurückgeführt werden.

Dieses Verfahren heißt häufig Blue-Green-Deployment. AWS beschreibt die Methode als Verschiebung des Traffics zwischen zwei Umgebungen mit unterschiedlichen Anwendungsversionen. Ziel sind nahezu keine Ausfallzeiten und ein schnellerer Weg zurück zur vorherigen Umgebung.

Blue-Green-Deployment ist nicht die einzige Möglichkeit. Manche Systeme tauschen Dateien atomar aus, aktualisieren Server nacheinander, leiten nur einen Teil des Traffics auf eine neue Version oder schalten eine fertige Funktion erst frei, wenn alle nötigen Arbeiten abgeschlossen sind. Welche Methode passt, hängt von Website, Hosting, Daten und den Folgen eines Fehlers ab.

Warum sind Datenbankänderungen anders?

Eine Datenbank kann aktuelle Bestellungen, Konten, Buchungen, Formulareingaben, Lagerbestände, Mitgliedschaften oder veröffentlichte Inhalte enthalten. Während eines Releases müssen möglicherweise die alte und die neue Website-Version mit diesen Daten arbeiten können.

Wird die Datenbankstruktur so geändert, dass nur eine Softwareversion sie versteht, ist die Rückkehr zur vorherigen Version möglicherweise nicht mehr einfach. Lange laufende Änderungen können außerdem mit dem normalen Website-Betrieb um Ressourcen konkurrieren. Deshalb trennen manche Releases die Datenbankvorbereitung vom Anwendungsupdate, halten alte und neue Strukturen vorübergehend kompatibel oder verschieben Daten in kontrollierten Schritten.

Der öffentliche Leitfaden von GitLab zu Datenbankmigrationen zeigt, wie detailliert diese Planung werden kann. Er unterscheidet reguläre, nachgelagerte und Hintergrundmigrationen und behandelt Zeitpunkt, Umkehrbarkeit, Transaktionen und Sperrkonflikte. Diese konkreten Verfahren passen nicht zu jeder Website. Der allgemeine Grundsatz ist aber hilfreich: Änderungen an Live-Daten brauchen einen eigenen Release- und Wiederherstellungsplan.

Ist ein Backup dasselbe wie ein Rollback?

Nein. Ein Backup ist eine aufbewahrte Kopie von Daten oder Dateien, die sich wiederherstellen lässt. Ein Rollback ist ein vorbereiteter Weg, nach einem fehlgeschlagenen Release zu einem bekannten funktionierenden Zustand zurückzukehren.

Das Einspielen eines Backups kann Zeit kosten und gültige Bestellungen, Anfragen, Bearbeitungen oder Kontoänderungen überschreiben, die danach entstanden sind. Website-Code lässt sich möglicherweise schnell zurücksetzen, doch damit werden weder eine Datenbankänderung noch eine bereits ausgeführte Aktion eines externen Zahlungs-, Buchungs- oder E-Mail-Dienstes rückgängig gemacht.

Ein verantwortungsvoller Plan legt fest, was rückgängig gemacht werden kann, was durch eine weitere Änderung repariert werden muss und wie Daten aus der Umstellungszeit behandelt werden. Die AWS-Empfehlungen für fehlgeschlagene Änderungen raten dazu, Wiederherstellungsschritte vor dem Deployment vorzubereiten und den Erfolg anhand von Monitoring zu beurteilen.

Warum sehen manche nach einem Update noch die alte Seite?

Die Website kann während des gesamten Updates erreichbar bleiben und verschiedenen Besuchern dennoch kurz unterschiedliche Versionen einer Seite oder Datei ausliefern. Browser, Content Delivery Networks, Server-Caches und generierte Seiten können frühere Inhalte behalten, bis sie ablaufen, erneut geprüft oder gezielt gelöscht werden.

Das ist kein Ausfall. Es ist trotzdem relevant, wenn Preise, Bedingungen, Kampagnenangaben, Verfügbarkeit oder andere zeitkritische Informationen geändert werden.

Auch das Löschen von Cache-Inhalten sollte angemessen begrenzt sein. Cloudflare empfiehlt nach Möglichkeit gezieltes Löschen, denn das Leeren des gesamten Caches führt dazu, dass nachfolgende Anfragen wieder den Ursprungsserver erreichen, bis der Cache neu aufgebaut ist. Ein Release-Plan sollte geänderte Seiten und Dateien benennen, statt jeden Cache als einen einzigen entbehrlichen Block zu behandeln.

Wann ist ein Wartungsfenster die verantwortungsvolle Wahl?

Ein Wartungsfenster kann sinnvoll sein, wenn ein vollständig aktiver Betrieb während des Updates ein größeres Risiko darstellt als eine kurze, angekündigte Unterbrechung. Das kann beispielsweise gelten, wenn:

• Live-Daten während des Updates nicht sicher geändert werden können;
• alte und neue Version nicht mit derselben Datenstruktur arbeiten können;
• Infrastruktur oder Netzwerk-Routing in einem kontrollierten Schritt geändert werden müssen;
• ein externer Anbieter eine Unterbrechung verlangt oder keinen parallelen Testweg bietet;
• die bestehende Website noch nicht ausreichend verstanden ist, um sie sicher live zu ändern;
• eine Wiederherstellung klarer und schneller wäre, wenn die Aktivität für eine festgelegte Zeit pausiert.

Das Zeitfenster braucht einen Grund, einen Umfang, eine erwartete Dauer, eine Entscheidung zur Wiederherstellung und einen Kommunikationsplan. Für ein Unternehmen, das auf Anfragen, Bestellungen, Buchungen oder Mitgliederzugänge angewiesen ist, reicht die Mitteilung „Die Website ist wegen Wartungsarbeiten nicht verfügbar“ nicht aus.

Was sollten wir vor der Freigabe des Updates fragen?

• Welche Seiten und Funktionen ändern sich?
• Was können Besucher und Mitarbeitende während der Arbeiten weiterhin tun?
• Wird die Änderung getrennt von der öffentlichen Website vorbereitet?
• Wie werden Anfragen, Zahlungen, Buchungen, Kontoänderungen und andere Live-Daten geschützt?
• Welche Prüfungen bestätigen, dass das Release erfolgreich war?
• Wie sieht der Wiederherstellungsplan aus, falls eine Prüfung fehlschlägt?
• Lässt sich die Software zurücksetzen, ohne gültige neue Daten rückgängig zu machen?
• Beeinflussen Hosting, Zahlung, E-Mail, Identität, Buchungen oder andere externe Dienste den Zeitpunkt?
• Wer entscheidet, ob fortgesetzt, repariert oder zurückgerollt wird?
• Wie und wann werden betroffene Nutzer informiert?

Die Antworten müssen nicht jeden technischen Befehl beschreiben. Sie sollten die Auswirkungen auf das Unternehmen verständlich machen.

Wie geht LINK-V mit Website-Updates um?

Wenn wir eine Website prüfen oder betreuen, sehen wir uns Website, Hosting, CMS, Datenbank, Integrationen, Backups, Zugänge und betriebliche Risiken an, bevor wir das Vorgehen für ein Release festlegen. Die passende Methode hängt von der Änderung und dem vorhandenen System ab.

Unser Ziel ist, dass normale Updates ruhig und angemessen ablaufen. Wenn eine Änderung eine kontrollierte Unterbrechung erfordert, sprechen wir das klar an. Wenn Ihre Website tägliche Verkäufe, Anfragen, Buchungen, Mitgliedschaften oder Veröffentlichungen unterstützt, können wir die Wartungsorganisation und laufende Betreuung beurteilen.