Schreiben Sie zuerst das Rollback: eine Vorlage für Routine-Upgrades

Plattformen geraten aus einem einfachen Grund ins Hintertreffen: Jedes Upgrade fühlt sich riskant an, also wird es verschoben, und jede Verschiebung macht das nächste Upgrade größer und noch riskanter. Der Ausweg ist, Upgrades langweilig zu machen. Das heißt eine Vorlage, der Sie jedes Mal folgen, und die wichtigste Zeile darin ist die, die die meisten Teams zuletzt schreiben: wie man zurückkommt.

Wissen Sie, dass ein Release existiert, bevor Sie es brauchen

Wir posten jeden neuen Build mit seinem Changelog am Tag der Veröffentlichung in unseren Betriebs-Chat.

Eine Verfeinerung lohnt sich zu kopieren. Viele Projekte veröffentlichen Fixes für ältere Zweige neben dem aktuellen. Ein Watcher, der blind «neues Release» meldet, kann jemanden dazu verleiten, einen Backport zu installieren, der älter ist als das, was bereits läuft. Wir kennzeichnen solche automatisch als «nicht ausrollen», damit niemand versehentlich einen Schritt zurück macht.

Bereiten Sie die Änderung vor

Lesen Sie das Changelog wie einen Vertrag

In den Release Notes zählen die Migrationen am meisten: Alles, was einmal läuft und sich nicht leicht rückgängig machen lässt, etwa eine Schemaänderung, entscheidet darüber, was Ihr Rollback enthalten muss.

Prüfen Sie jeden Server vorab

Prüfen Sie dann jeden Server, den Sie anfassen werden, nicht die Flotte im Allgemeinen, und gleichen Sie seine Plugins, Erweiterungen und Integrationen mit dem neuen Release ab.

Ein Plugin, an das sich niemand erinnert hat, ist der häufigste Grund, warum ein ansonsten sauberes Upgrade scheitert. Sie pro Server aufzulisten dauert Minuten und nimmt die Überraschung heraus.

Nehmen Sie ein Backup, das Sie tatsächlich angesehen haben

«Der Backup-Job ist gelaufen» ist nicht dasselbe wie «wir haben ein Backup». Nehmen Sie vor der Änderung einen konsistenten Dump und testen Sie ihn:

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Schreiben Sie das Rollback vor der Änderung

Das ist der Schritt, der ein riskantes Upgrade in Routine verwandelt. Schreiben Sie vor dem Start, der Reihe nach, die genauen Schritte auf, die das System dorthin zurückbringen würden, wo es jetzt ist. Auf RPM-basierten Systemen ist die Paketseite meist kurz:

dnf history list | head
dnf history undo <transaction-id>

Und damit sich ein bekannt gutes Paket nicht bewegt, während Sie testen, pinnt es das versionlock-Plugin fest:

dnf versionlock add <package>

Aber Pakete sind selten die ganze Geschichte. Wenn das Release eine Schema-Migration ausführt, lässt Sie ein Rollback nur der Pakete mit altem Code auf neuem Schema zurück. Ihr Rollback muss dann die Wiederherstellung des Dumps enthalten, den Sie gerade genommen haben, und Sie müssen wissen, wie lange dieser Restore dauert. Schreiben Sie alles auf, und proben Sie es, wo immer Sie können, zuerst auf einer Kopie. Ein Rollback, das in dem Moment, in dem etwas schiefgeht, nur in Ihrem Kopf existiert, ist kein Rollback.

Ändern Sie eine Maschine nach der anderen

Auf redundanten Plattformen einen Knoten nach dem anderen. Major-Releases gehen zuerst auf unsere eigenen Instanzen und laufen dort, bevor irgendeine Kundeninstanz sie erhält.

Messen und verifizieren

Messen Sie die Ausfallzeit, statt sie zu schätzen

«Etwa eine Minute» ist geraten. Eine Sonde, die während der gesamten Änderung läuft, gibt Ihnen die echte Zahl. Starten Sie sie, bevor Sie beginnen, und stoppen Sie sie, wenn Sie fertig sind:

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

Danach grenzen die erste und die letzte Zeile im Log, die nicht 200 ist, die Unterbrechung auf eine halbe Sekunde genau ein. Das ist die Zahl, die Sie den Menschen melden, die vom Dienst abhängen, und es ist die Zahl, mit der Sie beim nächsten Mal vergleichen. Über ein Quartal sind diese Messungen der beste Beleg, den Sie haben, dass Upgrades sicherer statt riskanter werden.

Von außen verifizieren, dann das Betriebssystem nachziehen

Wenn das Upgrade fertig ist, lösen Sie einen Testalarm aus, damit Sie wissen, dass das Monitoring den Dienst noch sieht. Nutzen Sie dann dasselbe Fenster, um auch die Pakete des Betriebssystems auf den aktuellen Stand zu bringen. Anwendung und Fundament bleiben im Gleichschritt, und das nächste Upgrade beginnt nicht mit einem Haufen unzusammenhängender Updates.

Die Vorlage

1. Release bemerkt und angekündigt, Backports gekennzeichnet.
2. Changelog auf Sicherheitsfixes, Breaking Changes und Migrationen gelesen.
3. Jeder Server vorab geprüft, einschließlich jedes Plugins.
4. Frisches Backup genommen und geprüft.
5. Rollback geschrieben, Schritt für Schritt, vor der Änderung.
6. Ein Knoten nach dem anderen, Majors zuerst auf den eigenen Systemen.
7. Ausfallzeit mit einer Sonde gemessen, in Sekunden gemeldet.
8. Von außen verifiziert, Betriebssystem im selben Fenster aktualisiert.

Wenn Ihre Plattformen zurückgefallen sind und das nächste Upgrade sich wie ein Projekt anfühlt, helfen wir Ihnen zurück zur Routine. Mit einem Ingenieur sprechen

Related (rows[1])

Verwandte Themen: Aktuelle Plattformen und Upgrade-Disziplin · Schnelle Reaktion auf Schwachstellen, am selben Tag · Flotten-Monitoring und Alarmweiterleitung