Rollback: Die Live-Umgebung wird auf eine bekannte, fehlerfreie Vorgängerversion zurückgesetzt.
Der Besucher sieht die Karte weiterhin; der Inhalt ist zwar veraltet, aber konsistent.
Aus der Veröffentlichung nehmen: Die Karte wird für Besucher gesperrt oder in den Status „derzeit nicht verfügbar“ versetzt.
Dies kann bei kritischen Sicherheitsfehlern oder völlig fehlerhafter Geometrie erforderlich sein; in den meisten Szenarien wird jedoch zunächst ein Rollback bevorzugt.
Denn das vollständige Schließen der Karte kann die Anzahl der Supportanfragen erhöhen.
- Kleiner Inhaltsfehler (falscher Name, fehlender Pin): wenn möglich, schneller Hotfix; andernfalls Rollback.
- Fehlerhafte Routengrafik / falsche Etagenverknüpfung: Rollback hat Vorrang.
- Veröffentlichung eines falschen Standorts: Entfernung aus der Veröffentlichung + Veröffentlichung des korrekten Plans.
- Verdacht auf Sicherheits- oder Zugriffsverletzung: Entfernung und Zugriffskontrolle.
Faustregel: Fügen Sie Ihrem Veröffentlichungsablauf das Label „Letzte bekannte funktionierende Version“ hinzu.
Kennzeichnen Sie diese Version nach jedem erfolgreichen Feldtest; damit im Panikfall das Ziel klar ist.
Was passiert auf der Besucherseite?
Wenn der Besucher nach einem Rollback die Seite aktualisiert, sieht er den vorherigen Plan.
Bei einer offenen Sitzung kann die alte (fehlerhafte) Version aufgrund des Caches kurzzeitig erhalten bleiben; berücksichtigen Sie daher bei kritischen Rollbacks auch das Verhalten des CDN- und Browser-Caches.
Der Nutzer könnte das Gefühl haben, dass sich die Karte plötzlich verändert hat; dies ist ein zu erwartender Nebeneffekt.
Das Betriebsteam kann eine kurze Notiz im Informationsbereich hinterlassen: „Die digitale Karte wurde vorübergehend auf die vorherige Version zurückgesetzt, ein Update ist in Arbeit.“
Wenn sich die Version während der Route ändert, können die Schritte durcheinander geraten.
Daher sollte die Entscheidung zur Rücknahme so schnell wie möglich und in einem Schritt getroffen werden; aufeinanderfolgende Teillösungen strapazieren den Besucher zusätzlich.
In der mobilen App oder am Kiosk kann eine erzwungene Aktualisierung erforderlich sein; legen Sie die Vorgehensweise im Voraus fest.
Wer darf ein Rollback durchführen? Rolle und Berechtigung
Es ist riskant, wenn jeder Redakteur die Live-Version zurücksetzen kann; dass niemand dies tun kann, ist jedoch noch riskanter.
Weisen Sie im Workspace die Berechtigungen zum Veröffentlichen und Zurücksetzen nur bestimmten Rollen zu.
Erstellen Sie eine Notfall-Pikettliste: Wer wird angerufen, über welchen Bildschirm wird der Vorgang durchgeführt, wer wird informiert?
Das Verhindern unbefugter Versuche verringert auch das Risiko, dass ein Entwurf versehentlich als „gute Version“ angesehen wird.
- Überprüfen Sie den Vorfall: anhand von mindestens zwei Quellen (Support + Vor-Ort-Prüfung oder Screenshot).
- Wählen Sie die letzte bekannte funktionierende Version aus.
- Führen Sie das Rollback durch und überprüfen Sie es über die Besucher-URL.
- Protokollieren Sie: wann, wer, warum, auf welche Version wurde zurückgegesetzt.
- Beheben Sie die Ursache in einem separaten Zweig; veröffentlichen Sie denselben Fehler nicht vorschnell erneut.
Vor dem Rollback: Veröffentlichungshygiene
Das beste Rollback ist das, das gar nicht erst nötig ist.
Eine Checkliste vor der Veröffentlichung, Staging-/Vorschau- und kritische Routentests senken die Fehlerquote.
Das Aufteilen großer Änderungen in kleine Veröffentlichungen verringert die Rollback-Fläche.
Der Ansatz „Lasst uns alles über Nacht erneuern“ macht einen Rollback unvermeidlich.
Trennen Sie den Entwurf klar von der Live-Umgebung.
Verwenden Sie einen genehmigten Veröffentlichungsablauf, anstatt direkt in der Live-Umgebung Änderungen vorzunehmen.
Zeigen Sie dem internen Team mit einer Amber-Warnung an, dass „diese Version noch nicht den Feldtest durchlaufen hat“ – nicht den Besuchern.
Korrekturzyklus nach dem Rollback
Ein Rollback ist nicht das Ende des Vorfalls, sondern die Rückkehr zum Ausgangspunkt.
Speichern Sie die fehlerhafte Version, ohne sie zu löschen; sie dient als Lernprotokoll.
Klassifizieren Sie die Grundursache: Daten (falscher POI), Geometrie (fehlerhafter Bereich), Route (Verbindung), Prozess (falscher Standort ausgewählt), Berechtigung (falsche Person hat veröffentlicht).
Ordnen Sie jeder Kategorie eine dauerhafte Maßnahme zu: Checklistenpunkt, automatische Überprüfung, zusätzliche Freigabe.
- Überprüfen Sie die Korrektur zunächst in der Vorschau.
- Gehen Sie die drei kritischen Routen erneut durch (Eingang–Ziel, Toilette, Ausgang).
- Überprüfen Sie mittels Suche, ob kritische Bezeichnungen vorhanden sind.
- Veröffentlichen Sie den Beitrag und aktualisieren Sie das Label „zuletzt als gut bekannt“.
Kommunikation und Transparenz
Interne Teams sollten das Rollback nicht verheimlichen.
Kurzer Vorfallbericht: Auswirkungen, Dauer, korrigierte Version, nächste Schritte.
Dem Besucher müssen nicht alle technischen Details erklärt werden; aber der Informationsschalter und das Sicherheitsteam sollten denselben Wortlaut verwenden.
Bei wiederkehrenden Vorfällen an die Geschäftsleitung als „Prozesslücke“ melden; nicht nur als Einzelfehler.
Anwendungstipps für DrawMap360
Halten Sie die Versionshistorie übersichtlich; aussagekräftige Versionshinweise („Umbenennung der POIs in Etage 2“, „Korrektur der Verbindung zu Aufzug A“) beschleunigen die Auswahl in Paniksituationen.
Trennen Sie die Berechtigungen zum Veröffentlichen und Rückgängigmachen durch rollenbasierten Zugriff.
Wenn im Workspace mehrere Orte vorhanden sind, zeigen Sie bei der Veröffentlichungsbestätigung den Ortsnamen erneut an, um das Risiko einer Veröffentlichung am falschen Ort zu vermeiden.
Bei Störungen im Maßstab und im Routendiagramm ist ein Rollback schneller als das Neuzeichnen der Geometrie von Grund auf.
Überprüfen Sie nach dem Rollback erneut die Suchsynonyme und die Ausrichtung der Beschriftungen; die Rückkehr zur alten Version kann unter Umständen auch einige neue Korrekturen wiederherstellen.
Häufig gestellte Fragen
Ist bei jedem Fehler ein Rollback erforderlich?
Nein.
Bei Problemen mit geringen Auswirkungen, wie z. B. einem einzelnen Rechtschreibfehler, kann ein Hotfix die sauberere Lösung sein.
Bei Verlust von Routen, Stockwerkverbindungen oder ganzen POIs ist ein Rollback in der Regel sicherer.
Löscht ein Rollback neue Korrekturen?
Das Zurücksetzen der Live-Umgebung auf eine ältere Version entfernt alle Änderungen, die seit dieser Version vorgenommen wurden, aus der Live-Umgebung.
Deshalb ist es wichtig, die „letzte bekannte funktionierende Version“ richtig auszuwählen und die Korrektur anschließend mit einem sauberen Release einzuspielen.
Verwenden Sie separate Zweige bzw. Versionsdisziplinen, damit Ihre Entwürfe nicht verloren gehen.
Was ist, wenn der Besucher immer noch die fehlerhafte Karte sieht?
Möglicherweise handelt es sich um einen nicht aktualisierten Cache oder eine nicht aktualisierte Sitzung des Kiosks.
Eine erzwungene Aktualisierung, ein Neustart des Kiosks und kurze TTL-Richtlinien sollten in die Vorgehensweise aufgenommen werden.
Verwenden Sie zur Überprüfung ein inkognito-Fenster oder ein anderes Gerät.
Was sollten wir als ersten Schritt tun?
Markieren Sie heute die „letzte bekannte funktionierende Version“, legen Sie die für das Rollback zuständigen Personen fest und führen Sie eine Desktop-Übung durch.
Reduzieren Sie anschließend den Rollback-Bedarf, indem Sie die Checkliste vor der Veröffentlichung verschärfen.
Fazit
Das Rückgängigmachen eines veröffentlichten Plans ist kein Panikknopf, sondern ein bewusster operativer Schritt.
Unterscheiden Sie zwischen Rollback und Entfernung aus dem Live-Betrieb, klären Sie die Zuständigkeiten, messen Sie die Auswirkungen auf die Besucher und beseitigen Sie die Grundursache.
Etablieren Sie mit DrawMap360 bereits ab der ersten Veröffentlichung die Gewohnheit des Versionierens und Rollbacks; wissen Sie im Voraus, was zu tun ist, wenn eine falsche Version live geschaltet wird.
Sind Sie bereit, Ihre Raumkarte mit sicheren Veröffentlichungen und Rollbacks zu verwalten?
Starten Sie kostenlos
oder
sehen Sie sich das Produkt unter drawmap360.com an.
