Ein Cutover-Runbook für die Migration schreiben, mit einer Uhr an jedem Schritt

Der Unterschied zwischen einer Migration, die fünf Minuten sichtbare Ausfallzeit kostet, und einer, die ein Wochenende frisst, ist selten die Hardware. Er liegt darin, ob die finale Umschaltung (Cutover) vor der Nacht als Folge zeitlich begrenzter, prüfbarer, umkehrbarer Schritte aufgeschrieben und geprobt wurde, bis die Zeiten bekannt waren. So schreiben wir dieses Dokument.

Das Problem: Die Nacht ist die schlechteste Zeit zum Nachdenken

Jede Entscheidung, die im Fenster getroffen wird (welcher Sync zuerst läuft, wie lange man auf ein Replikat wartet, wann man aufgibt und zurückrollt), wird von müden Menschen unter Druck getroffen, meist mit dem Betreiber der Website am Telefon. Das Ziel eines Runbooks ist, dass niemand im Fenster etwas entscheiden muss, das in der Woche davor hätte entschieden werden können.

Eine Aufgabenliste ist kein Runbook. Ein Runbook hat fünf Spalten.

Die fünf Spalten

Schritt	Budget	Verantwortlich	Prüfung	Weg zurück
Schreibzugriffe auf der Quelle einfrieren	2 Min.	app	Admin-Login abgewiesen, Bestellwarteschlange leer	das Einfrieren aufheben
Letzter Datei-Sync	3 Min.	ops	rsync listet keine weiteren Änderungen	nicht nötig, Quelle unberührt
Datenbank final aufholen und befördern	3 Min.	db	GTID auf beiden Seiten gleich, Ziel read write	Ziel zurückstufen, Quelle auftauen
DNS und Load Balancer umschalten	2 Min.	net	neuer Origin antwortet über den öffentlichen Namen	den Eintrag zurücksetzen
Smoke-Tests	5 Min.	app	Checkliste aus Seiten, Login, Checkout, Suche	DNS zurücksetzen

Budget ist die Zeit, die der Schritt in der Probe gebraucht hat, plus eine Marge. Verantwortlich ist eine Person, kein Team. Prüfung ist eine beobachtbare Tatsache, nicht «sieht gut aus». Weg zurück ist die genaue Aktion, die den Schritt rückgängig macht, und wenn ein Schritt keinen Weg zurück hat, ist er der Punkt ohne Wiederkehr und muss als solcher markiert sein.

Vor dem Fenster: Verschieben Sie fast alles früh

Der Cutover sollte nur bewegen, was sich seit dem letzten Sync geändert hat. Alles andere passiert Tage vorher, während die Quelle weiter bedient:

• Bauen Sie das Ziel frisch nach gemessenen Spezifikationen, statt Images der alten Server wiederherzustellen.
• Befüllen Sie die Datenbank aus einem physischen Backup und halten Sie sie per Replikation aktuell. In der Nacht ist das Aufholen eine Sache von Sekunden an Delta.
• Synchronisieren Sie Dateien vorab, wiederholt, damit der letzte Durchlauf klein ist. Machen Sie am Vortag einen Trockenlauf, um zu sehen, was der letzte Durchlauf bewegen wird:

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
      source:/var/www/ /var/www/ | wc -l

• Kopieren Sie Suchindizes mit dem Remote-Reindex der Suchmaschine selbst, statt die Inhalte durch die Anwendung neu zu crawlen.
• Senken Sie die DNS-TTLs auf wenige Minuten, mindestens zwei alte TTLs vor dem Fenster, damit die Resolver den langen Wert vergessen haben, wenn Sie umschalten. Prüfen Sie, was die Welt tatsächlich sieht:

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Proben Sie auf einer Kopie, mit Stoppuhr

Führen Sie den gesamten Cutover mindestens einmal gegen eine Kopie des Ziels aus, mit denselben Befehlen, in derselben Reihenfolge, und stoppen Sie jeden Schritt. Die Probe liefert die Budget-Spalte. Sie liefert auch die Überraschungen: den Datei-Sync, der wegen eines fehlenden Flags Millionen unveränderter Dateien langsam durchläuft, den Replikationsbenutzer, dem ein Privileg fehlt, den Health Check, der auf den falschen Pfad zeigt.

Nehmen Sie jede Lektion in die Runbook-Vorlage auf, nicht nur in die Kopie dieser Migration. So wird die zehnte Migration leichter als die erste.

Schreiben Sie die Go- oder No-Go-Kriterien im Voraus

Vereinbaren Sie vor dem Fenster und mit dem Betreiber der Website, was zutreffen muss, um zu starten, und was ein Rollback auslöst:

• Go: Replikationsverzögerung auf dem Ziel unter einem vereinbarten Wert, letzter Trockenlauf-Sync im Budget, Monitoring auf dem Ziel grün, die in der Spalte Verantwortlich genannten Personen anwesend.
• Rollback-Auslöser: Ein Schritt überschreitet das Doppelte seines Budgets, oder die Smoke-Tests bestehen nicht bis zu einer festen Zeit nach der Umschaltung.

Den Auslöser aufzuschreiben beseitigt den gefährlichsten Instinkt jeder Cutover-Nacht: «Geben wir ihm noch zehn Minuten.» Wenn die Uhr Rollback sagt, rollen Sie zurück, und Sie versuchen es in einer anderen Nacht mit einem besseren Runbook erneut.

Machen Sie den Weg zurück billig

Ein Rollback, das eine Wiederherstellung aus dem Backup erfordert, ist kein Rollback, das jemand freiwillig nutzen wird. Entwerfen Sie jeden Schritt so, dass seine Umkehr schnell ist:

• Die Quelle bleibt unberührt und in Betrieb, bis das Ziel sich bewährt hat. Ihre Daten werden im Fenster nie gelöscht.
• Auf dem Ziel wird alles, was ersetzt wird, umbenannt, nie entfernt. Zurück heißt eine Umbenennung und eine DNS-Änderung.
• Die Beförderung der Datenbank passiert erst, wenn beide Seiten dieselbe GTID melden, sodass eine Rückstufung Sie an eine bekannte Position zurückbringt.
• Konfigurationsänderungen werden als Dateien angewendet, die Sie austauschen können, nicht als Bearbeitungen, die Sie sich merken müssen.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Das Fenster durchführen, dann auditieren

Im Fenster liest eine Person das Runbook laut vor und notiert die tatsächliche Zeit neben jedem Budget. Niemand improvisiert. Wenn der letzte Smoke-Test besteht, lassen Sie die Quelle laufen und beobachten beide Seiten: Der Traffic sollte vom alten Origin abfließen, während die Caches ablaufen. Alles, was nach Ablauf der alten TTL noch an der Quelle ankommt, ist eine Abhängigkeit, die niemand aufgelistet hat, etwa ein Cron-Job, ein API-Client oder eine fest kodierte Adresse, und sie muss gefunden werden, bevor die Quelle abgeschaltet wird.

Vergleichen Sie danach die neue Plattform mit der alten Basislinie: Exposition nach außen, Antwortzeiten, Cache-Trefferquote, Fehlerraten. Erst dann nehmen Sie die Quelle außer Betrieb, und Sie behalten ihre Daten, bis der Betreiber freigegeben hat.

Ihre Checkliste

• Jeder Schritt hat ein Budget, einen Verantwortlichen, eine Prüfung und einen Weg zurück.
• Daten befüllt und Dateien Tage vorher vorsynchronisiert. Das Fenster bewegt nur das Delta.
• TTLs früh gesenkt und von außen verifiziert.
• Eine gestoppte Probe auf einer Kopie, mit den Lektionen in die Vorlage eingearbeitet.
• Go- und Rollback-Kriterien schriftlich vor der Nacht vereinbart.
• Die Quelle intakt behalten, bis das Audit abgeschlossen ist und der Betreiber freigegeben hat.

Wenn ein Umzug bei Ihnen am Horizont steht, helfen wir gern beim Schreiben des Runbooks.

Mit einem Ingenieur sprechen

Related (rows[1])

Verwandte Themen: Managed Rechenzentrumsmigrationen, geprobt · Datenbankreplikation und Offsite-Replikate · Live-Migration und Hypervisor-Ausstieg