Cloud-Migration planen: Bestandsaufnahme bis Rückweg
Ein Cloud-Migrationsplan hat vier Teile: Bestandsaufnahme, Umzugsreihenfolge, Testumgebung und Rückweg. Was Ausfälle verursacht und wie man sie vermeidet.
rabbitclip-TeamVeröffentlicht: 5 Min. Lesezeit
Kurz gesagt
Ein Cloud-Migrationsplan besteht darin, das bestehende System zu inventarisieren, die Teile danach zu ordnen, was wovon abhängt, jeden Schritt zu testen, ohne die Live-Website anzufassen, und einen Weg zurück zum alten Aufbau offen zu halten, falls etwas schiefgeht. Fehlen einem Plan diese vier Schritte, ist der Umzug keine Migration, sondern ein Glücksspiel. Das Zeichen eines gelungenen Umzugs ist nicht Tempo, sondern dass die Nutzer überhaupt nichts bemerken.
Die meisten Migrationsprobleme entstehen nicht aus technischer Schwierigkeit, sondern aus einem vergessenen Teil: einer geplanten Aufgabe, die auf dem alten Server läuft, einer E-Mail-Regel oder einer Einstellung, die nur eine Person kannte. Deshalb ist der wertvollste Teil eines Plans nicht die Liste der Aufgaben, sondern eine ehrliche Darstellung dessen, was vorhanden ist.
Wo fängt man an: Wie erstellt man eine Bestandsaufnahme?
Eine Bestandsaufnahme ist eine schriftliche Liste von allem, was umgezogen wird: Websites, Anwendungen, Datenbanken, Dateispeicher, geplante Aufgaben, Domainnamen, SSL-Zertifikate, E-Mail-Konten und Verbindungen zu Drittanbietern. Zu jedem Eintrag notieren Sie, wem er gehört, wie kritisch er ist und wovon er abhängt.
Die Frage, die in dieser Phase am meisten leistet, lautet: Was passiert, wenn dieses Teil ausfällt? Fällt ein Buchungsformular aus, geht Umsatz verloren; fällt ein internes Berichtswerkzeug aus, kommt ein Bericht einen Tag zu spät. Diese Unterscheidung bestimmt die Reihenfolge des Umzugs und das Maß an Ausfallzeit, das Sie hinnehmen können.
- Websites, Anwendungen und die Datenbanken, die sie nutzen.
- Geplante Aufgaben und Skripte, die im Hintergrund laufen.
- Domain-Einträge, DNS-Einstellungen und Zertifikate.
- E-Mail-Konten und die dazugehörigen Weiterleitungen.
- Verbindungen zu Drittanbietern wie Zahlungen, Karten und Analyse.
In welcher Reihenfolge sollten die Teile umziehen?
Die allgemeine Regel lautet, zuerst das zu verschieben, was wenige Abhängigkeiten und wenig Risiko hat. Eine Testumgebung oder ein internes Werkzeug eignet sich für einen ersten Versuch, weil ein Fehler wenig kostet und das Team den Ablauf lernt. Systeme, die Kunden unmittelbar berühren, folgen, sobald sich die Routine eingespielt hat.
Teile, die voneinander abhängen, sollten gemeinsam bedacht werden. Laufen eine Anwendung und ihre Datenbank an verschiedenen Orten, kann die Verzögerung zwischen beiden Geschwindigkeitsprobleme verursachen. Deshalb ist es oft der sicherere Weg, ein System mit seinen zugehörigen Teilen in einem einzigen Schritt umzuziehen.
Wie testet man, ohne die Live-Website anzufassen?
Eine Testumgebung ist eine Kopie, die auf der neuen Infrastruktur aufgebaut wird und für Nutzer noch nicht geöffnet ist. Man zieht eine aktuelle Kopie der Datenbank, betreibt die Anwendung in der neuen Umgebung und probiert jeden wichtigen Ablauf von Hand aus: Anmeldung, Formularversand, Zahlung, E-Mail-Benachrichtigung, Datei-Upload.
Danach beobachtet man das Verhalten unter Last. Wenn der Produktkatalog eines Bodenbelag-Herstellers morgens stark besucht wird, sollte diese Last auch in der Testumgebung simuliert werden. Geschwindigkeitsmessungen sind nur dann zum Vergleich sinnvoll, wenn sie vor und nach dem Umzug auf dieselbe Weise erfolgen.
Schließlich wählt man die Stunde der Umschaltung. Ein Umzug im ruhigsten Abschnitt des Datenverkehrs verkleinert die Wirkung jedes Aussetzers. Weil sich DNS-Änderungen erst mit Zeit verbreiten, ist das Senken des TTL-Werts vor dem Umzug ein eigener vorbereitender Schritt.
- Die neue Umgebung mit einer aktuellen Kopie der Daten aufbauen.
- Anmeldung, Formular, Zahlung und E-Mail-Abläufe von Hand ausprobieren.
- Das Verhalten zu einer stark belasteten Stunde simulieren.
- Die Geschwindigkeit vor und nach dem Umzug auf dieselbe Weise messen.
Warum wird der Rückweg zuerst aufgeschrieben?
Ein Rückfallplan ist die schriftliche Darstellung, welche Schritte Sie zum alten Aufbau zurückführen und wie lange das dauert, falls beim Umzug etwas schiefgeht. Er wird vor dem Umzug vorbereitet, denn ruhiges Nachdenken fällt schwer, sobald das Problem eingetreten ist. Das alte System noch eine Weile unverändert weiterlaufen zu lassen, ist die Grundlage dieses Plans.
Eine wichtige Entscheidung für den Rückfall betrifft die Frage, wohin Daten geschrieben werden. Bestellungen oder Formulare, die nach dem Umzug im neuen System entstehen, können verloren gehen, wenn Sie zum alten zurückkehren. Deshalb legt man vorher fest, wie die Daten im Migrationsfenster synchron gehalten werden oder wann das Schreiben eingefroren wird.
Wann ist der Umzug in die Cloud die falsche Wahl?
Ist das System klein, der Datenverkehr gleichmäßig und das bestehende Hosting läuft ohne Probleme, bringt ein Umzug oft keinen Gewinn. Der Aufwand des Umzugs, die Last der Verwaltung des neuen Aufbaus und das Fehlerrisiko bleiben, während der Ertrag ungewiss ist. Ein Umzug braucht einen Grund: eine Kapazitätsgrenze, ein Bedürfnis nach Betriebskontinuität oder einen unzureichenden bisherigen Anbieter.
Auch ein Umzug kurz vor einer starken Kampagne oder Saison ist schlechtes Timing. Für eine Spa-Gruppe sind die Wochen vor dem Ansturm der Sommerbuchungen eine Zeit, in der das Team keine Zeit hat, Probleme zu beheben. Den Umzug in eine ruhige Phase zu legen ist ebenso wichtig wie der Plan.
Welche Fehler passieren bei einer Migration häufig?
Der häufigste Fehler ist, die Bestandsaufnahme zu überspringen und gleich mit dem Umzug zu beginnen. Ein vergessenes Teil taucht Tage nach dem Umzug auf, in einem Moment, mit dem niemand gerechnet hat. Der zweite Fehler ist, auf der Live-Website statt in einer Testumgebung zu testen, was Ihre Nutzer zum Testteam macht.
Der dritte Fehler ist, das alte System gleich nach dem Umzug abzuschalten. Ein altes System, das nicht eine Weile parallel weiterläuft, nimmt die Möglichkeit der Rückkehr. Der vierte ist, den Umzug im Wissen einer einzigen Person zu belassen; wenn der Ablauf nicht aufgeschrieben ist, kann niemand einspringen, wenn diese Person fehlt.
- Mit dem Umzug ohne Bestandsaufnahme zu beginnen.
- Auf der Live-Website statt in einer Testumgebung zu testen.
- Das alte System gleich nach dem Umzug abzuschalten.
- Den Ablauf im Gedächtnis einer einzigen Person zu belassen.
Ein Cloud-Migrationsplan beginnt mit einer Bestandsaufnahme, ordnet sich nach Abhängigkeiten, wird in einer getrennten Umgebung getestet und durch einen Rückweg abgesichert. Werden diese vier Schritte übersprungen, wird das Ausfallrisiko größer als der Umzug selbst. Wenn Sie besprechen möchten, ob Ihr bestehendes System die Cloud verdient und wie der Umzug geplant werden sollte, vereinbaren Sie gern ein Kennenlerngespräch mit rabbitclip.
Häufige Fragen
Wie lange dauert eine Cloud-Migration?
Das hängt von der Größe des Systems, der Zahl der Abhängigkeiten und dem Umfang der Tests ab. Eine kleine Website kann in ein bis zwei Tagen umziehen; ein System aus vielen verbundenen Teilen kann Wochen brauchen.
Fällt die Website während des Umzugs aus?
Bei gut geplantem Umzug bemerken Nutzer keinen Ausfall. Die neue Umgebung wird vorab aufgebaut und getestet, und die DNS-Änderung erfolgt zu einem Zeitpunkt mit wenig Datenverkehr.
Ist ein Rückfallplan wirklich nötig?
Ja. Ruhige Entscheidungen fallen schwer, sobald ein Problem eingetreten ist. Das alte System eine Weile weiterlaufen zu lassen und die Schritte zurück aufzuschreiben, verhindert, dass aus einem Aussetzer eine Krise wird.
Sollte ich alles auf einmal umziehen?
In der Regel nicht. Mit risikoarmen Teilen anzufangen lässt Sie den Ablauf lernen und Fehler im Kleinen entdecken. Eng verbundene Teile sollten jedoch zusammen umziehen.
