Überspringen zu Hauptinhalt

Sieben Fehler, die dir den Go-live in die Cloud vermiesen können

Die AWS Architektur ist ready, alle Anpassungen umgesetzt. Ihr seid bereit für den finalen Go-live. Aus Erfahrung können wir sagen, dass auch auf den letzten Metern noch ärgerliche Fehler passieren können. Im Folgenden haben wir unsere Top 7 der wichtigsten Fallstricke zusammengefasst, auf die ihr beim Go-live achten solltet.

1. Fehler: DNS TTL nicht angepasst

TTL steht für „Time to Live“ und bezieht sich darauf, wie lange DNS-Einstellungen (Domain Name System) im DNS-Cache zwischengespeichert werden sollen, bevor sie automatisch aktualisiert werden. Das DNS funktioniert ähnlich wie eine Telefonauskunft: Die Domain wird vom DNS in die zugehörige IP-Adresse umgewandelt. Wenn eine DNS-Änderung vorgenommen wird, dauert es einige Zeit, bis es der Rest des Internets bemerkt. Wie lange genau, hängt von der Einstellung deiner DNS TTL ab. 

Geht man also live und die DNS TTL ist auf 12 oder 24 Stunden gesetzt (was meist standardmäßig eingestellt ist), hast man ein Problem. Euren Kunden wird dann noch einige Stunden die zwischengespeicherte Version angezeigt, je nachdem wann sie zuletzt auf eurer Seite waren. Man sollte also spätestens einen Tag vor dem Go-live die DNS TTL noch einmal überprüfen und wenn nötig auf 5 Minuten einstellen.

2. Fehler: A-Record auf den Loadbalancer gesetzt

AWS Loadbalancer und CloudFront Endpunkte werden über eine URL angesprochen und besitzen keine feste IP. Möchte man nun einen A-Record auf einen dieser Endpunkte setzen, kommt man in das Dilemma, dass dies nicht möglich ist. 

Die Lösung für das Problem besteht in dem Setzen eines CNAME-Records auf den Endpunkt, was eine Subdomain, wie z.B. “www.[…]”  voraussetzt. Damit der A-Record nicht verloren ist, bieten wir unseren Kunden einen Redirect-Service an, der den A-Record auf die Subdomain “www.” weiterleitet, welche wiederum auf den Endpunkt zeigt. Noch tiefgehender haben wir das in unserer Knowledge Base erklärt: zu den Techie Details.

3. Fehler: Migration nicht getestet

Ein weiterer häufiger Fehler: Die  Migration wird nicht durch umfassende Tests vorbereitet, sodass die einzelnen Migrationsschritte deutlich länger dauern als geplant. Dadurch kann während des Go-live einiges schiefgehen: 

Ist einmal die Wartungsseite geschaltet, beginnt die Go-live-Phase und damit das Zeitfenster für die Migration. Häufig wird der zeitliche Rahmen für die Migration im Vorfeld auf Grundlage von geschätzten Werten definiert. Erst in diesem Stadium wird bemerkt, dass das Exportieren und Importieren der Datenbank deutlich länger dauert als geplant. Ebenso kann es mit dem Sync der Mediendateien verlaufen, die nicht vorsynchronisiert wurden. Nachdem der DNS geschwenkt wurde, ist die Seite live. Allerdings kann es vorkommen, dass die Bestellungen nicht im WaWi ankommen, wenn dort die neue IP nicht gewhitelisted wurde und ebenso die Cronjobs nicht gestartet wurden. In diesem Fall wurden häufig  auf dem alten System die Cronjobs nicht gestoppt.

4. Fehler: Den Go-live spontan vorziehen

Eure Arbeiten an der neuen Applikation bzw. dem Relaunch sind sehr intensiv. Entsprechend kann es vorkommen, dass ihr eure Test- und Entwicklungsphase schneller habt beenden können, als geplant. Einem vorgezogenen Go-live scheint damit nichts im Wege zu stehen. Um schnellstmöglich, den vorgezogenen Go-live zu realisieren, bleibt dann keine andere Möglichkeit, als den beteiligten Managed Service Provider (MSP) und die betreuende Agentur (falls vorhanden) sehr kurzfristig  von dem neu geplanten Go-live Termin zu informieren. 

Allerdings haben auch wir als euer MSP noch einige Vorkehrungen vor dem Go-live umzusetzen: so müssen eventuell die Ressourcen für den Live-Betrieb vergrößert und das Monitoring aller Komponenten aktiviert werden. Eine so spontane Verschiebung des Go-live ist auf unserer Seite  meist nicht seriös realisierbar. Im Sinne eines reibungslosen Go-live ist es ratsam, den vereinbarten Zeitplan möglichst einzuhalten. Was passieren könnte, wenn man den Go-live trotzdem im Alleingang durchzieht, erklären wir im nächsten Punkt.

5. Fehler: Einfach live gehen und niemanden informieren

Im Punkt 4 haben wir bereits erläutert, dass auch auf unserer Seite als MSP noch einige Anpassungen gemacht werden müssen. Im Falles eines nicht abgestimmten Go-live wäre unser Monitoring noch nicht aktiv. Das bedeutet, unser Service Team würde keine Benachrichtigungen bekommen, wenn es zu Fehlern auf eurer AWS-Umgebung kommt; unsere Kollegen könnten im Störungsfall somit auch nicht eingreifen. Außerdem werden die AWS-Ressourcen beim Live-Gang auf die benötigte Größenordnung angepasst. Erfolgt dies nicht, ist es möglich, dass eure Webseite überlastet wird. Im schlimmsten Fall kommt es zu Downtimes, die vermeidbar gewesen wären.

6. Fehler: Beim Go-live manuelle Änderungen auf Instanzebene durchführen

Manchmal fallen notwendige Änderungen erst in der letzten Sekunde auf. Wenn ihr Änderungen innerhalb der AWS-Umgebung durchführt, dann sollte unbedingt darauf geachtet werden,  diese Änderungen im Repository und eurer Code-Basis zu persistieren. Ansonsten gibt es Probleme beim nächsten Deployment und deine Webseite ist down.

7. Fehler: Kein Ablaufplan für den Go-live

“Das wird schon schiefgehen!“, sagt ihr euch vor dem Go-live und startet mit dieser Einstellung. Schnell merkt ihr, dass ihr gar nicht genau wisst, wo ihr anfangen sollt und welche Abhängigkeiten zwischen den einzelnen Schritten bestehen. Ihr startet den Datenbankexport und vergesst eine Wartungsseite zu schalten, sodass ein Teil neuer Bestellungen oder Contents nicht mit auf die Umgebung übertragen werden. Gleiches geschieht mit neuen Registrierungen.  Bei den Mediendaten läuft es auch nicht besser. Erst jetzt fällt auf, dass ihr den Go-live nicht allen Personen kommuniziert habt, die davon Bescheid wissen sollten und sich bei euch melden, warum die Applikation nicht erreichbar ist. Ein Riesenchaos!

Damit dieses Fiasko nicht stattfindet, hilft vor dem Go-live der Dialog mit eurem MSP, der euch mit seiner Erfahrung gerne unterstützt.

Fazit

Neben einigen technischen Details liegt der Schlüssel zu einem gelungenen Go-live also auch in guter Kommunikation zwischen alle Beteiligten. 

Weitere Details zu dem Weg in die Cloud mit root360 findet ihr  auch im folgenden Beitrag: Cloud Enablement: Unser Projektablauf Schritt für Schritt erklärt

Für weitere Fragen könnt ihr gerne einen Beratungstermin mit uns vereinbaren: zum Kalender.

An den Anfang scrollen