Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Einen Rollback planen, bevor Sie irgendetwas migrieren
Ein Rollback-Plan ist der Teil einer Migration, den bei guter Umsetzung niemand je braucht, und genau deshalb wird er gern übersprungen, wenn die Zeit knapp ist. Ihn zu überspringen ist gerade deshalb ein Fehler, weil es viel teurer ist, einen Rollback zu brauchen und keinen zu haben, als einen vorzubereiten, der ungenutzt bleibt.
Die Ausgangsannahme für einen guten Rollback-Plan lautet, dass sich der neue Anbieter in mindestens einer Hinsicht, die Sie nicht vorhergesehen haben, anders verhalten wird als der alte, ganz gleich, wie gründlich Sie vorher getestet haben. Das ist kein Pessimismus, sondern schlicht eine ehrliche Beschreibung dessen, wie Integrationen mit externen Systemen meist verlaufen. Wer um diese Annahme herum plant statt um die Hoffnung, dass die Tests alles erfasst haben, erhält einen besseren Plan.
Ein Rollback-Plan für einen Wechsel des Standortdatenanbieters sollte Folgendes abdecken:
- Einen schnellen Umschaltmechanismus. Ob Feature-Flag, Umgebungsvariable oder ein Konfigurationswert, der zur Laufzeit der Anfrage gelesen wird, statt fest in einen ausgelieferten Build eingebaut zu sein: Die Zugangsdaten und der Endpunkt des alten Anbieters sollten für ein festgelegtes Zeitfenster nach der Umstellung gültig und ohne Code-Deployment wieder einsatzbereit bleiben
- Eine klare Auslösebedingung. Legen Sie im Voraus fest, was konkret einen Rollback rechtfertigen würde: eine Fehlerrate über einem bestimmten Schwellenwert, das Scheitern einer bestimmten Kategorie von Anfragen oder eine gewisse Menge an Nutzerbeschwerden, statt die Entscheidung unter Druck und ohne vereinbarte Messlatte treffen zu müssen
- Einen Verantwortlichen für den Rollback. Eine Person oder eine kleine Gruppe, die ausdrücklich für die Entscheidung über einen Rollback zuständig ist, damit die Entscheidung nicht ins Stocken gerät, während mehrere Leute darauf warten, dass jemand anderes sie trifft
- Ein festgelegtes Ende des Rollback-Zeitfensters. Die Zugangsdaten beider Anbieter unbegrenzt aktiv zu halten, untergräbt den Sinn der Migration; legen Sie ein konkretes Datum fest, nach dem der Zugang zum alten Anbieter endgültig stillgelegt wird
Da die Kompatibilitäts-Hosts von My Geocode die exakte Anfrage- und Antwortstruktur eines Anbieters nachbilden, ist ein Rollback bei einer kompatibilitätsbasierten Migration oft nur eine Konfigurationsänderung zurück auf den alten Host und Schlüssel, ohne dass anderer Parsing-Code neu ausgerollt werden muss. Das verkürzt die Zeit, die ein Rollback im Ernstfall tatsächlich dauert. Allerdings gilt das in beide Richtungen: Es lohnt sich auch, in der Planungsphase einmal bewusst zu testen, dass ein Rollback funktioniert, statt es einfach anzunehmen, denn ein ungetesteter Rollback-Pfad unterscheidet sich kaum davon, überhaupt keinen Rollback-Plan zu haben.
Es lohnt sich auch zu entscheiden, was mit Daten oder Anfragen geschieht, die in dem Zeitraum verarbeitet wurden, aus dem Sie zurückrollen. Wenn über Nacht ein Batch-Job gegen den neuen Anbieter lief, bevor am nächsten Morgen ein Problem entdeckt wurde: Muss dieser Batch erneut verarbeitet werden, oder ist die Abweichung akzeptabel? Wer das im Voraus entscheidet statt während eines tatsächlichen Vorfalls, nimmt einem ohnehin stressigen Moment eine weitere Entscheidung ab.
Ein Migrationsplan, der nur den Weg nach vorn beschreibt, ist im eigentlichen Sinne ein unvollständiger Plan. Die Rollback-Hälfte macht aus einer Migration statt einer Wette ohne Rückweg eine überlegte Entscheidung, die sich sauber rückgängig machen lässt, wenn die Fakten es verlangen.