My Geocode

Migration

Eine Checkliste für den Wechsel Ihres API-Hosts ohne Ausfallzeit

· 3 Min. Lesezeit · My Geocode · #ohne-ausfallzeit#migrations-checkliste#geokodierung#deployment#devops

Einen API-Host in der Produktion ohne Ausfall zu wechseln, ist machbar, erfordert aber, die Änderung als Deployment mit eigenem Risikoprofil zu behandeln und nicht als einzeilige Konfigurationsänderung, die direkt in die Produktion geschoben wird. Der Unterschied zwischen einer reibungslosen Umstellung und einem Vorfall liegt fast immer in der Vorbereitung, nicht im Moment des eigentlichen Wechsels.

Vor der Umstellung:

  • Besorgen Sie die Zugangsdaten für den neuen Host frühzeitig und prüfen Sie, dass sie in einer Staging- oder Testumgebung mit realen Anfragemustern funktionieren, nicht nur mit einem einzelnen manuellen Testaufruf
  • Instrumentieren Sie Ihre Anwendung so, dass sie protokolliert, welcher Host jede Anfrage bedient hat, wenn auch nur vorübergehend, damit Sie den Fortschritt des Rollouts überprüfen und Probleme im Nachhinein nach Host eingrenzen können
  • Stellen Sie sicher, dass Ihr Konfigurationssystem das Ändern des Host-Werts ohne vollständiges erneutes Deployment der Anwendung unterstützt, ob über eine Umgebungsvariable, ein Feature-Flag oder einen Remote-Konfigurationsdienst, denn ein Prozess mit einem Deployment pro Änderung reagiert langsamer, wenn mitten in der Umstellung etwas schiefgeht

Während der Umstellung:

  • Führen Sie die Änderung schrittweise statt auf einmal ein, wenn Ihre Infrastruktur das unterstützt: ein Anteil des Traffics, ein Server oder eine Region nach der anderen oder ein unkritischer Endpunkt vor den anderen
  • Beobachten Sie Fehlerraten und Antwortzeiten während des Rollout-Zeitfensters in Echtzeit und vergleichen Sie sie direkt mit Ihren Ausgangswerten vor der Umstellung statt mit einem angenommenen akzeptablen Bereich
  • Halten Sie die Zugangsdaten des bisherigen Hosts in diesem Zeitfenster aktiv und bereit, damit ein Zurückwechseln eine Konfigurationsänderung ist und kein neues Deployment

Nach der Umstellung:

  • Lassen Sie den neuen Host für einen festgelegten Beobachtungszeitraum mit vollem Traffic laufen, bevor Sie die Migration als abgeschlossen betrachten, denn manche Probleme treten erst unter anhaltender Last oder zu bestimmten Tageszeiten auf
  • Vergleichen Sie die tatsächlichen Antwortdaten des alten und des neuen Hosts für eine Stichprobe identischer Anfragen, wenn Sie beide protokolliert haben, um subtile Datenunterschiede zu finden, die Fehlerraten allein nicht zeigen würden
  • Legen Sie die Zugangsdaten des alten Hosts erst still, wenn der Beobachtungszeitraum ohne Probleme verstrichen ist, und zwar an einem konkret festgelegten Datum statt „irgendwann“

Da die Kompatibilitäts-Hosts von My Geocode die exakte Anfrage- und Antwortstruktur eines Anbieters nachbilden, beschränkt sich die eigentliche Codeänderung bei einer kompatibilitätsbasierten Migration häufig auf den Hostnamen und die Zugangsdaten, wodurch in der riskantesten Phase der Umstellung weniger neuer Code eingeführt wird. Die Authentifizierung selbst unterstützt vier Varianten, X-API-Key-Header, Authorization: Bearer, HTTP-Basic-Authentifizierung oder einen Query-Parameter, sodass dieser Teil der Änderung je nach Aufbau Ihrer bestehenden Client-Bibliothek oft eine reine Konfigurationsänderung statt einer Codeänderung sein kann.

Bei einer Migration ohne Ausfallzeit geht es weniger um raffinierte Infrastruktur als um Disziplin: gründlich vorbereiten, schrittweise ausrollen, genau beobachten und einen Weg zurück offenhalten, bis Sie sicher genug sind, ihn nicht mehr zu brauchen.

Mehr zu Migration