Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Runbook zur Umstellung
Wie bereits erwähnt, können Migrationen komplex sein, da sie aus vielen beweglichen Teilen bestehen, die Hardware, Software, Mitarbeiter, Prozesse und Organisation umfassen. Um Erfolg, Konsistenz und eventuelle Beschleunigung sicherzustellen, ist ein gut durchdachter Plan, der von allen Beteiligten dokumentiert und akzeptiert wird, in allen Phasen der Migration unerlässlich. Ein solcher Plan kann mithilfe eines Runbooks zur Umstellung dokumentiert werden.
Ein Runbook für die Umstellung deckt alle Aktivitäten ab, die für eine bestimmte Migration abgeschlossen werden müssen. Es handelt sich um einen umfassenden und detaillierten Leitfaden zu folgenden Themen:
+ Aktivitäten
+ Geplanter Zeitplan
+ Zeitstempel der tatsächlichen Aktivität
+ Erfolgskriterien für jeden Schritt
+ Eigenverantwortung für jeden Schritt
Stellen Sie sich bei der Vorbereitung des Cutover-Runbooks die folgenden Fragen und geben Sie die Antworten in Ihrem Plan an.
| Frage | Warum ist es wichtig |
| --- | --- |
| Benötigt die Umstellung eine Ausfallzeit? | Längere Ausfallzeiten wirken sich auf das Benutzererlebnis aus. Versuchen Sie bei der Erstellung Ihres Umstellungsplans, die Ausfallzeiten Ihrer Anwendung oder Ihres Systems so gering wie möglich zu halten. |
| Müssen Sie die Daten vor der Umstellung synchronisieren? | Wenn Sie die Speicherebene, z. B. Amazon Elastic Block Store (Amazon EBS) -Volumes oder Amazon Simple Storage Service (Amazon S3) -Buckets, vor der Übernahme migrieren, ohne einen kontinuierlichen Replikationsmechanismus zu verwenden, gerät die Speicherebene möglicherweise nicht mehr synchron. Stellen Sie in solchen Fällen sicher, dass Sie eine endgültige Synchronisierung durchführen, nachdem Sie die Quelldienste heruntergefahren haben, aber bevor Sie mit der Umstellung beginnen. |
| Wer sollte über die geplante Umstellung informiert sein? | Informieren Sie alle Beteiligten und Benutzer über die geplante Ausfallzeit. |
| Möchten Sie die Migration in kleinere Teile aufteilen oder alles auf einmal migrieren? | Wenn Sie ein kompliziertes System migrieren, ist es sinnvoll, die Migration in Phasen aufzuteilen und mehrere Umstellungen durchzuführen. Sie können beispielsweise zuerst die Datenschicht migrieren. |
| Benötigen Sie Unterstützung durch externe Anbieter? | Möglicherweise müssen Sie sich einige Wochen vor Ihrer geplanten Umstellung an die externen Anbieter wenden, um deren Verfügbarkeit sicherzustellen. Erkundigen Sie sich beim Anbieter nach allen Lizenzierungsaspekten, die Sie beachten sollten. |
| Benötigen Sie für einen Teil des Prozesses eine besondere Genehmigung? | Holen Sie sich einige Wochen vor der geplanten Umstellung alle erforderlichen Genehmigungen ein. |
# Runbook-Vorlage für die Umstellung
Ein Runbook für die Umstellung sollte alle Aktivitäten enthalten, die während der Umstellung durchgeführt werden. Ebenso wichtig ist es jedoch, vor der Migration eine Vorlage oder eine Checkliste zu erstellen. Die Vorlage sollte Aktivitäten enthalten, die vor der Migration abgeschlossen werden müssen.
Beide Vorlagen (die zu einem einzigen Dokument zusammengeführt werden können) sollten Antworten auf die folgenden Fragen enthalten:
+ Welche Aktivitäten sollen durchgeführt werden?
+ Wer wird die Aktivitäten durchführen?
+ Wann sollten die Aktivitäten durchgeführt werden?
Dieser Abschnitt enthält ein Beispiel für eine Checkliste vor der Migration, eine Runbook-Vorlage für die Umstellung und einen Rollback-Plan. Die Aufgabe trägt IDs dazu bei, die Kommunikation schneller und effektiver zu gestalten.
## Checkliste vor der Migration
| Aufgaben-ID | Aufgabe | -Abhängigkeit | Team | Eigentümer | Datum der Fertigstellung | Status | Hinweise |
| --- | --- | --- | --- | --- | --- | --- | --- |
| P1 | Dokument zur Zielarchitektur genehmigt. | | | | | | |
| P2 | Das Zielkonto für die Anwendung ist vorhanden. | | | | | | |
| P3 | Virtual Private Cloud (VPC) und Subnetze für die Anwendung sind vorhanden. | | | | | | |
| P4 | Das Migrationsteam hat Zugriff auf das Zielanwendungskonto und verfügt über die erforderlichen AWS Identity and Access Management (IAM-) Berechtigungen. | | | | | | |
| P5 | Das Anwendungsteam hat den erforderlichen Zugriff auf das Zielanwendungskonto und dessen Ressourcen. | | | | | | |
| P6 | Änderungsantrag gestellt und genehmigt. | | | | | | |
| P7 | Konnektivität zwischen Quell- und Zielumgebung hergestellt und getestet. | | | | | | |
| P8 | Die Kontaktliste des Anwendungsteams ist dokumentiert. | | | | | | |
| P9 | Überprüfung des Umstellungsplans mit den wichtigsten Interessengruppen. | | | | | | |
| P10 | Die Backup-Aktivitäten vor der Migration wurden abgeschlossen. | | | | | | |
| P11 | Bestätigen Sie, ob zusätzliche Support-Kontakte eingerichtet werden sollen. | | | | | | |
| P12 | Bestätigen Sie die Ressourcen für jede Anwendung: Wer wird jede einzelne Anwendung starten und beenden? | | | | | | |
| P13 | Der endgültige Umstellungsplan wurde allen beteiligten Teams vorgelegt. | | | | | | |
| S.14 | Mitteilung über den Beginn der Umstellung an wichtige Interessengruppen. | | | | | | |
| S. 15 | Rückblick auf die Zeit nach der Umstellung geplant. | | | | | | |
Ebenso wichtig ist es, die vorherigen Punkte in einem Problemprotokoll zu dokumentieren, um den Überblick zu behalten oder, falls etwas schief geht, den Vorgang wieder auf den richtigen Weg zu bringen.
## Runbook für die Umstellung
| Aufgaben-ID | Aufgabe | -Abhängigkeit | Team | Eigentümer | Geplantes Startdatum/Uhrzeit | Geplantes Enddatum/Uhrzeit | Tatsächliches Startdatum/Uhrzeit | Tatsächliches Enddatum und Uhrzeit | Status | Hinweise |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C1 | Senden Sie eine Informationsnotiz an alle Beteiligten, in der Sie darüber informiert werden, dass der Antrag gemäß den Angaben in der CR nicht verfügbar sein wird. | | | | | | | | | |
| C2 | Bestätigen Sie die Sicherung der Quellserver und Datenbanken. | | | | | | | | | |
| C3 | Stoppen Sie die Anwendungs- und DB-Dienste auf den Quellservern. | | | | | | | | | |
| C4 | Fahren Sie die Quellserver herunter. | | | | | | | | | |
| | **Meilenstein 1** **Die Aktivitäten vor der Umstellung wurden abgeschlossen** | | | | | | | | | |
| C5 | Führen Sie die Migration auf der Grundlage Ihres Migrationsansatzes durch (z. B. AWS Application Migration Service für lift-and-shift). | | | | | | | | | |
| C6 | Überprüfen Sie die Infrastruktur (Zielserver sind betriebsbereit). | | | | | | | | | |
| | **Meilenstein 2** **Die Migration ist abgeschlossen** | | | | | | | | | |
| C7 | Aktualisieren Sie die DNS-Server so, dass sie auf die neu erstellten Endpunkte verweisen. | | | | | | | | | |
| C8 | Überprüfen Sie die DNS-Änderungen. | | | | | | | | | |
| | **Meilenstein 3** **Aktivitäten nach der Migration — Infrastruktur fertiggestellt** | | | | | | | | | |
| C9 | Starten Sie die Anwendungs- und Datenbankdienste auf den Zielservern. | | | | | | | | | |
| C10 | Wenden Sie anwendungsspezifische Konfigurationsänderungen an (verweisen Sie beispielsweise auf neue IP-Adressen). | | | | | | | | | |
| | **Meilenstein 3** **Aktivitäten nach der Migration — Anträge abgeschlossen** | | | | | | | | | |
| C11 | Führen Sie Anwendungstests nach der Migration durch — Technische Überprüfung. | | | | | | | | | |
| C12 | Führen Sie Anwendungstests nach der Migration durch — Geschäftsverifizierung | | | | | | | | | |
| C13 | Teilen Sie allen wichtigen Interessenträgern mit, dass die Migration abgeschlossen ist. | | | | | | | | | |
| | **Meilenstein 4** **Die Tests nach der Migration sind abgeschlossen** | | | | | | | | | |
## Rollback-Plan
| Aufgaben-ID | Aufgabe | -Abhängigkeit | Team | Eigentümer | Status | Hinweise |
| --- | --- | --- | --- | --- | --- | --- |
| R1 | Beenden Sie die Anwendungs- und Datenbankdienste auf den Zielservern. | | | | | |
| R2 | Fahren Sie die Zielserver herunter. | | | | | |
| R3 | Machen Sie das Update auf den DNS-Servern rückgängig (um auf die Quellserver zurückzuverweisen). | | | | | |
| R4 | Überprüfen Sie die DNS-Änderungen. | | | | | |
| R5 | Starten Sie die Quellserver. | | | | | |
| R6 | Synchronisieren Sie Daten zurück zu den Quellservern (falls erforderlich). | | | | | |
| R7 | Starten Sie die Anwendungs- und Datenbankdienste auf den Quellservern. | | | | | |
| R8 | Führen Sie Anwendungstests durch — Technische Überprüfung. | | | | | |
| R9 | Führen Sie Anwendungstests nach der Migration durch — Geschäftsverifizierung. | | | | | |
| R10 | Teilen Sie allen wichtigen Beteiligten mit, dass die Migration rückgängig gemacht wurde. | | | | | |
## Beispielvorlage für die Rehost-Strategie
Eine der in diesem Bereich am häufigsten verwendeten Migrationsstrategien vom Typ R ist die Rehost-Strategie, wobei der Application Migration Service das Migrationstool der Wahl ist. Sie können die [Beispielvorlage](samples/cutover-runbook_template.zip) als Basisdokument in einem Rehost-Szenario verwenden. Die Vorlage enthält wichtige Aktivitäten, die bei tatsächlichen Kundenkontakten angetroffen wurden. Sie bietet auch Platz für Anwendungsteams, um ihre Aufgaben und Aktivitäten hinzuzufügen. Die Schritte im vorherigen Abschnitt können Ihnen als erste Hilfestellung für die Erstellung Ihres eigenen benutzerdefinierten Runbooks für die Umstellung nach Bedarf dienen.