Planung von Wellen

In der Wellenplanung ist eine Abhängigkeitsgruppe eine Sammlung von Anwendungen und Infrastrukturen, die technische und nichttechnische Abhängigkeiten aufweisen, die nicht gelöst werden können. Aufgrund dieser Abhängigkeiten müssen die Anwendungen und die Infrastruktur in einer Abhängigkeitsgruppe gleichzeitig oder an einem bestimmten Datum migriert werden. Beispielsweise werden eine Anwendung, die auf einer virtuellen Maschine ausgeführt wird, und eine Datenbank, die auf einer separaten virtuellen Maschine läuft, für die Anforderungen mit geringer Latenz oder hohem Datenverkehr und komplexen Abfragen gelten, wahrscheinlich zusammen migriert, anstatt eine Komponente in der Cloud und die andere vor Ort zu betreiben. Ebenso werden unabhängige Anwendungen, die über eine API mit ähnlichen Anforderungen mit niedriger Latenz interagieren, gleichzeitig migriert.

Migrationswellen dauern in der Regel 4 bis 8 Wochen und können ein oder mehrere Migrationsereignisse beinhalten. Abhängigkeitsgruppen werden zu Wellen zusammengefasst, sodass eine Welle eine oder mehrere Abhängigkeitsgruppen enthalten kann. Die Welle beinhaltet auch andere Aktivitäten, die für die Migration erforderlich sind. Dazu gehören die Einrichtung derAWS Infrastruktur (wie landing zone, Sicherheit und Betrieb), Migrationstools und Migrationsaktivitäten wie Datenreplikation, Umstellungsplanung, Tests und Support nach der Migration.

Um den Erfolg zu messen und den Fortschritt zu verfolgen, sollten die Wellen an den Ergebnissen und Geschäftstreibern ausgerichtet werden. Dies wird auch die Wellendauer und die Abhängigkeitsgruppen beeinflussen, die eine Welle enthält. Der Abschluss einer Welle sollte eine messbare Leistung widerspiegeln. Bei der Planung einer Welle können auch andere Faktoren kombiniert werden, beispielsweise technische Leitprinzipien. Wellen können beispielsweise nach der Umgebung (z. B. Entwicklung, Test, Produktion) oder nach der Migrationsstrategie (z. B. Rehost Wave, Replatform Wave) definiert werden.

Um effektive und zuverlässige Pläne für Migrationswellen zu erstellen, müssen Sie sich einen vollständigen Überblick über das Anwendungsportfolio, die zugehörige Infrastruktur (Rechenleistung, Speicher, Netzwerke), die Abhängigkeitszuordnung und die Migrationsstrategie verschaffen.

Im Abschnitt zur Festlegung einer Ausgangsbasis für das Anwendungsportfolio wurden vier Kategorien von technischen Abhängigkeiten beschrieben. Diese Abhängigkeiten tragen zur Entstehung von Migrationswellen und zur Definition von Abhängigkeitsgruppen bei. Die Abhängigkeitsgruppen werden durch die Kritikalität der Abhängigkeit bestimmt. Darüber hinaus müssen nichttechnische Abhängigkeiten berücksichtigt werden. Beispielsweise beeinflussen Zeitpläne für Anwendungsversionen, Wartungsfenster und wichtige Geschäftstermine wie die Verarbeitung zum Monatsende oder die Verarbeitung zum Quartalsende den Wave-Plan.

Stellen Sie fest, ob die Abhängigkeit weich oder schwer ist. Eine weiche Abhängigkeit ist eine Beziehung zwischen zwei oder mehr Vermögenswerten oder zwischen einer Anlage und einer Einschränkung, die nicht vom Standort der Komponenten abhängt. Beispielsweise können zwei Systeme, die in demselben lokalen Netzwerk (oder derselben Infrastruktur) betrieben werden, voneinander getrennt werden, indem eines dieser Systeme in die Cloud verschoben wird, während das andere vor Ort verbleibt. Ein anderes Beispiel ist ein System, das während eines Wartungsfensters migriert werden kann, ohne die Wartungsaktivitäten zu beeinträchtigen.

Eine harte Abhängigkeit ist eine vom Standort abhängige Beziehung zwischen zwei oder mehr Vermögenswerten oder zwischen einem Vermögenswert und einer Einschränkung. Beispielsweise weisen zwei Systeme, die im selben lokalen Netzwerk betrieben werden und bei der Kommunikation zwischen dem Anwendungsserver und dem Datenbankserver stark auf eine geringe Latenz angewiesen sind, eine starke Abhängigkeit auf. Die Verlagerung nur eines dieser Systeme in die Cloud würde zu Funktions- oder Leistungsproblemen führen, die nicht gelöst werden können. Ebenso können nichttechnische Gründe wie die Verfügbarkeit von Ressourcen (z. B. das Team, das die Migration durchführt) oder betriebliche Einschränkungen wie Wartungsfenster, in denen zwei Systeme nur in einem bestimmten Zeitfenster migriert werden können, zu einer starken Abhängigkeit dieser Ressourcen führen.

Um einen Plan für die Migrationswelle zu erstellen, ermitteln Sie Ihre Abhängigkeitsgruppen, indem Sie Abhängigkeiten analysieren, idealerweise aus einer äußerst vertrauenswürdigen Datenquelle, wie z. B. speziellen Discovery-Tools, und kombinieren Sie diese Informationen mit den Kriterien für die Anwendungspriorisierung und den betrieblichen Umständen. Die Anwendungen, die in der Priorisierungsrangliste ganz oben stehen, sollten auf Ihre ersten Migrationswellen ausgerichtet sein. Ermitteln Sie die Wellenkapazität (die Anzahl der Anwendungen, die eine Welle enthalten kann) auf der Grundlage der Ressourcenverfügbarkeit, der Risikotoleranz, der geschäftlichen und technischen Einschränkungen, der Erfahrung und der Fähigkeiten. Erwägen Sie die Zusammenarbeit mitAWS Professional Services- oderAWS Migrationskompetenzpartnern, die Ihnen während des gesamten Prozesses Experten zur Seite stellen können.

Die Priorisierungskriterien sind ein erster Hinweis auf die Reihenfolge, in der Sie Ihre Anwendungen in die Cloud verschieben werden. Abhängigkeitsgruppen werden jedoch die tatsächliche Determinante für die Anwendungen sein, die zu einem bestimmten Zeitpunkt verschoben werden. Dies liegt daran, dass Anwendungen, denen eine hohe Priorität eingeräumt wird, starke Abhängigkeiten zu Anwendungen haben können, die in der Rangliste im mittleren oder unteren Bereich stehen.

Die Migrationsstrategie wird auch die Zusammensetzung einer Welle beeinflussen. Beispielsweise wird eine Anwendung mit hoher Priorität, für die eine Refactor-Strategie erforderlich ist, für die möglicherweise mehrere Wochen oder Monate an Analyse, Design, Tests und Vorbereitungen erforderlich sind, wahrscheinlich zu einem späteren Zeitpunkt veröffentlicht.

Einen Wellenplan erstellen

Eine Voraussetzung für die Migration einer Welle von Anwendungen sind die Daten des Anwendungsportfolios und die detaillierte Anwendungsbewertung der Gruppe von Anwendungen, die im Zuge der Migration migriert werden. Die detaillierte Bewertung sollte die Liste der Anwendungen in der Wave, die zugehörigen Infrastrukturdetails, ein Zieldesign und eine Migrationsstrategie für jede Anwendung beinhalten.

Die Etablierung von Eigenverantwortung und Steuerung der Welle ist der Schlüssel zur Verwaltung und Nachverfolgung der Wave-Arbeit, der Programmadhängigkeiten, des Change-Managements, der Probleme und Risiken. Stellen Sie sicher, dass ein Governance-Rahmen für die Verwaltung des Plans vorhanden ist.

Um den Wellenplan zu skizzieren, beginnen Sie mit einem Standard-Wellenkonstrukt. Was passiert innerhalb einer Welle? Nachdem die anfängliche Eingabe definiert wurde, kann die Welle beginnen. In der Regel werden die Aktivitäten wie folgt sein:

1. Verfeinern Sie den Umstellungsplan. In dieser Aktivität sollten die Runbooks und Schritte beschrieben werden, die zum Zeitpunkt der Migration unternommen werden müssen, einschließlich der Abstimmung mit anderen internen und externen Teams.

2. Verfeinern Sie den Rollback-Plan. Was muss getan werden, um die Anwendungen rückgängig zu machen, wenn etwas schief geht?

3. Bereiten Sie die Zielinfrastruktur vor. Sie können beispielsweise dieAWS landing zone erstellen oder erweitern (AWSKonto, Sicherheit, Netzwerk, Infrastrukturdienste, andere unterstützende Infrastruktur).

4. Testen Sie die Zielinfrastruktur.

5. Bedienen Sie die Migrationstools. Installieren Sie beispielsweise Replikationsagenten und starten Sie die Datenübertragung.

6. Führen Sie einen Umstellungsplan durch und führen Sie Probeläufe durch. Gruppieren Sie alle teilnehmenden Teammitglieder und überprüfen Sie alle Schritte im Voraus.

7. Überwachen Sie die Datenreplikation und die Infrastrukturbereitstellungen.

8. Bestätigen Sie die Betriebsbereitschaft der Infrastruktur und der Anwendungen inAWS.

9. Bestätigen Sie die Sicherheitsbereitschaft.

10. Bestätigen Sie gegebenenfalls die Einhaltung gesetzlicher und regulatorischer Anforderungen (z. B. Workload-Validierung vor und nach der Migration).

11. Migrieren Sie die Anwendungen zuAWS und führen Sie Tests vor dem Go-Live-Betrieb durch.

12. Bieten Sie Unterstützung nach der Migration für einen Zeitraum, z. B. 3 Tage, an, in dem die Betriebsteams und die Migrationsteams vollständig verfügbar sind, um Probleme zu lösen und Optimierungen vorzunehmen.

13. Führen Sie eine Überprüfung nach der Migration durch. Dokumentieren Sie die gewonnenen Erkenntnisse und integrieren Sie sie in future Wellen.

14. Führen Sie den Abschluss der Welle durch, indem Sie die Betriebsübergabe bestätigen und die Kennzahlen für die Berichterstattung einholen.

Wie lange jede dieser Aktivitäten dauert, hängt von der Komplexität des Umfangs, der Wellenkapazität, den beteiligten Personen und Ihren individuellen Umständen ab. Wenn möglich, sind kleinere Wellen vorzuziehen, da dadurch die Auswirkungen von Verzögerungen oder Migrationsblockaden verringert werden. Bestimme zusammen mit deinen Teams die Standarddauer einer Welle.

Fahren Sie als Nächstes mit der Analyse der Daten fort, um eine erste übergeordnete Struktur aus leeren Wellen zu erstellen (der noch keine Anwendung zugewiesen wurde). Berücksichtigen Sie die folgenden Fragen:

• Was ist die Gesamtdauer des Migrationsprogramms?

• Was sind die Fristen?

• Gibt es feste Austrittstermine für Rechenzentren?

• Gibt es Enddaten für den Kollokationsvertrag?

• Was sind die Aktualisierungszyklen für Anwendung und Infrastruktur?

• Was sind die Wartungs- und Release-Zyklen für Anwendungen?

• Gibt es Termine, an denen Migrationen vermieden werden sollten (z. B. Releases- und Wartungszyklen, Jahresende, Feiertage, Bearbeitung am Monatsende)?

Plotten Sie anhand dieser Überlegungen die Wellen in einen Plan ein. Um den Migrationsprozess zu beschleunigen, empfehlen wir, wenn möglich, sich überlappende Wellen zu überlappen. Der Schlüssel zu überlappenden Wellen liegt darin, zu definieren und zu berücksichtigen, was innerhalb einer Welle passiert. In der Regel finden die Bereitstellungsaktivitäten, die Validierung der Zielinfrastruktur und die Datensynchronisierung in der ersten Hälfte einer Welle statt. Die zweite Hälfte konzentriert sich auf die eigentliche Migration, das Testen und die Betriebsübergabe. Das bedeutet, dass an jeder Hälfte des Prozesses verschiedene Teams beteiligt sind und dass Sie einige Effizienzsteigerungen erzielen können. Sobald beispielsweise das Team, das an der Vorbereitung der Zielinfrastruktur beteiligt ist, seine Arbeit abgeschlossen hat, kann es mit der Arbeit an den Anforderungen der nächsten Welle beginnen. Im Allgemeinen ist es vorzuziehen, dass die meisten Wellen eine ähnliche Länge und Struktur haben, um Migrationen wie in einer Fabrik anzugehen. Während des Wellenplanungsprozesses kann die Größe einer bestimmten Welle jedoch erweitert werden, um Abhängigkeiten oder Betriebsanforderungen zu erfüllen.

Bestimmen Sie anschließend anhand der identifizierten Abhängigkeitsgruppen die maximale Größe einer Welle in Bezug auf die Anzahl der Abhängigkeitsgruppen, die sie enthalten kann. Die Wellengröße wird in der Regel von der Risikobereitschaft (z. B. wie viel parallel Veränderung toleriert werden kann) und der Ressourcenverfügbarkeit (z. B. wie viele parallel Änderungen mit den verfügbaren Ressourcen, Fähigkeiten und dem Budget durchgeführt werden können) bestimmt. Lassen Sie sich bei der frühen Planung jedoch nicht durch den Ressourcenbedarf und die Verfügbarkeit einschränken. Wellen, die mehr als eine Abhängigkeitsgruppe enthalten, können in future Iterationen in kleinere Wellen zerlegt werden.

Nachdem die Abhängigkeitsgruppen für eine bestimmte Welle bestätigt wurden, überprüfen Sie die Ressourcenanforderungen für die Migration der Welle. Erwägen Sie, die Wellengröße (die Anzahl der darin enthaltenen Abhängigkeitsgruppen) an die Ressourcenanforderungen anzupassen. Dies kann zu kleineren oder größeren Wellen führen. Iterieren Sie den Wellenplan nach Bedarf, bis alle Wellen definiert sind.

Bewältigung von Veränderungen

Das Anwendungsportfolio und die zugehörige Infrastruktur werden sich im Laufe des Lebenszyklus von Migrationsprogrammen ändern. Langfristige Migrationsprogramme gehen Hand in Hand mit der normalen Geschäftsentwicklung und dem Wandel. Anwendungen entwickeln sich ständig weiter, während sie darauf warten, migriert zu werden. Server werden hinzugefügt oder entfernt, neue Infrastruktur wird vor Ort bereitgestellt. Es wird erwartet, dass der Umfang einer Welle oder einer Abhängigkeitsgruppe Änderungen erfordern wird. Änderungen sind insbesondere erforderlich, wenn kurz vor dem Migrationsdatum eine bisher unbekannte Abhängigkeit identifiziert wird oder ein neuer Server in das Inventar aufgenommen wird. Manchmal kann dies während der Migration selbst passieren.

Änderungen des Geltungsbereichs wirken sich auf Abhängigkeitsgruppen und -wellen aus. Um mit Veränderungen umzugehen und die Auswirkungen zu minimieren, ist es wichtig, einen Mechanismus zur Kontrolle des Geltungsbereichs einzurichten. Ein Mechanismus zur Kontrolle der Änderung des Geltungsbereichs erfordert die Definition einer einzigen Informationsquelle für den Geltungsbereich. Dabei kann es sich um ein Tool zur Verwaltung des Umfangs oder um eine CSV-Datei, eine Tabelle oder eine Datenbank handeln, wie sie in der Steuerung des Migrationsprogramms definiert sind. Sie müssen Änderungen identifizieren, die Auswirkungen analysieren und die Änderungen den relevanten Stakeholdern mitteilen, damit diese Maßnahmen ergreifen können. Der Wellenplan wird daraufhin wiederholt.