So vermeiden Sie ungeplante Ausfälle bei Upgrades
Die Migration Ihrer Geschäftssysteme in die Cloud bringt zahlreiche Vorteile. Ein zentraler Pluspunkt von Managed Services: Sie müssen den Betrieb nicht mehr selbst auf eigener Infrastruktur stemmen, mit eigenen technischen Ressourcen und gewachsenen Betriebsprozessen. Stattdessen profitieren Sie gegen eine Servicegebühr vom gebündelten Wissen und der Erfahrung des Anbieters. Ein Managed Database Service bietet viele weitere Vorteile, etwa bei Sicherheit, Ressourcenzuweisung und Feature-Integration.
In diesem Artikel geht es um eine Funktion, die bei mehreren Cloud-Anbietern verfügbar ist und auf den ersten Blick wie ein müheloser Gewinn für die Routinewartung wirkt. Sie hat jedoch ihren Preis: Im schlimmsten Fall führt sie zu einem kritischen Ausfall – und zu einem Disaster-Szenario, auf das niemand vorbereitet ist, weil die Ressourcen und Kompetenzen der früheren Self-Hosted-Welt schlicht nicht mehr verfügbar sind.
Die Rede ist von automatischen Minor-Version-Updates.
Warum sind Produkt-Upgrades wichtig?
Jede Organisation hat ihre eigenen Prozesse und Kontrollmechanismen, gewachsen über viele Jahre und geprägt von den jeweiligen Produkten und internen Tools. Diese Prozesse können sehr robust, gerade ausreichend oder fragil sein. Ein Managed Service mag zwar das Gefühl von mehr Stabilität und operativer Schlagkraft vermitteln – die Notwendigkeit zu testen ersetzt er aber nicht. Cloud, Managed Services, Automatisierung, IaC und Frameworks ersetzen kein sauberes Prozessmanagement.
Die Datenbank ist in jedem Unternehmen eine kritische Komponente. Sie ist nicht die einzige – aber das Fehlen einer funktionierenden Datenbank hat in vielen Organisationen massive Auswirkungen auf die Geschäftsfähigkeit.
Jedes Produkt bringt im Laufe der Zeit Deprecations von Features und Syntax, End-of-Life-Meldungen und Sicherheits-Patches mit sich. Diese Änderungen erfordern eine fortlaufende Pflege der Infrastruktur, auf der Ihre Anwendungen laufen. Produkt-Updates kommen in Form von Minor-Upgrades und Major-Updates. Bewerten Sie beide Upgrade-Typen aus Sicht des Geschäftsrisikos gleich.
Ein ungetestetes Minor-Upgrade kann Ihr Produktivsystem lahmlegen.
Die Standard-Upgrade-Methode bei Managed Services
Viele Services unterschiedlicher Cloud-Anbieter stellen Tools und Automatisierung für wiederkehrende Routineaufgaben bereit – darunter auch Minor-Version-Upgrades.
Ein Beispiel aus AWS RDS: Wenn Sie über die AWS Console eine neue Datenbank anlegen, sehen Sie zunächst mehrere Dutzend Konfigurationsoptionen – aber längst nicht alle. Erst über "Additional Configuration" am Seitenende werden sämtliche Setup-Optionen sichtbar.
Auf dieser zusätzlichen Seite müssen Sie ganz nach unten scrollen, bis Sie den Bereich Maintenance erreichen. Dort ist "Enable auto minor version upgrade" standardmäßig aktiviert.
Wo dieser Managed-Service-Ansatz problematisch wird
Diese Standardeinstellung bringt mehrere grundlegende Probleme mit sich:
- Minor-Upgrades werden im wöchentlichen Wartungsfenster nach Ermessen von AWS eingespielt. Das passiert nicht zwangsläufig im nächsten Wartungsfenster und kann sich um mehrere Wochen verzögern.
- AWS unterscheidet nicht zwischen Test- und Produktivumgebung. Wenn mehrere Umgebungen auf automatisches Upgrade gestellt sind, kann es passieren, dass alle in derselben Woche aktualisiert werden – oder eben nur einige.
- AWS priorisiert Long-Term-Support-(LTS-)Releases nicht gegenüber Minor-Version-Upgrades. In der AWS-RDS-Dokumentation heißt es sogar wörtlich: "We recommend that you don't set the AutoMinorVersionUpgrade parameter to true for LTS versions. Doing so could lead to your DB cluster being upgraded to a non-LTS version."
- Bei einem Minor-Upgrade legt AWS RDS keinen Wiederherstellungspunkt an, mit dem Sie bei Folgeproblemen zurückrollen könnten. Die Point-in-Time-Restore-Funktion hilft hier nur bedingt: Sie setzt die aktuell laufende, bereits aktualisierte Datenbankversion nicht auf den Stand vor dem Upgrade zurück.
- Wartungsfenster werden in der Regel zu Zeiten geringer Systemauslastung gelegt – also genau dann, wenn auch am wenigsten technisches Personal verfügbar ist. Läuft im Wartungsfenster ein ungeplantes Upgrade, verlängert das die Ausfallzeit zusätzlich.
Minor-Versionen werden nicht automatisch im nächsten Wartungsfenster eingespielt.
Ein Minor-Version-Upgrade ist genauso bedeutsam wie ein neues internes Produkt-Release. Würden Sie ein neues, ungetestetes internes Release einfach automatisch in Produktion ausrollen, während der Großteil Ihres Teams gar nicht erreichbar ist?
Best Practice für Minor-Version-Upgrades
Im Grunde ganz einfach: Testen und verifizieren.
"Enable auto minor version upgrade" ist zwar ein praktisches Feature, das den Aufwand für regelmäßige Wartung reduziert. Gleichzeitig verleitet es dazu, sich um Steuerung der Ausführung und um Recovery-Optionen nicht mehr aktiv zu kümmern. Die Datenbank ist häufig eine kritische Komponente im Technologie-Stack. Sie braucht laufendes Monitoring, Management und Wartung – genau wie jede andere kritische Systemkomponente.
Der Rollout einer neuen Minor-Version sollte in jeder Umgebung einem kontrollierten und dokumentierten Prozess folgen. Dazu gehört das schrittweise Vorgehen über die Umgebungsstufen hinweg bis in die Produktion, also etwa Dev, Test, Stage und Prod. Ein Upgrade sollte automatisiert ausgeführt und durch einen Menschen überwacht werden – auch dann, wenn Hunderte oder Tausende Datenbankserver betroffen sind. Upgrades sollten nur dann laufen, wenn die nötigen Ressourcen online verfügbar sind: Operations-Teams, die die Infrastruktur betreuen, und Engineering-Ressourcen, die einspringen können, falls eine unvorhergesehene oder ungetestete Situation einen Incident auslöst.
Die einzelnen Schritte des Upgrade-Prozesses sind organisationsspezifisch. Ein Pre-Upgrade-Snapshot sollte aber immer dazugehören. In der Regel sollten Releases für Produktivumgebungen erst mit ausreichendem zeitlichen Abstand erfolgen – etwa eine oder mehrere Wochen, nachdem die Version in anderen Umgebungen freigegeben und verifiziert wurde.
Eine Produktivdatenbank sollte niemals eine neuere Version haben als eine Datenbank im Release-Testzyklus.
Es ist nicht ratsam, Ihre Datenbank auf dem ältesten Point Release laufen zu lassen. Damit wird ein Minor-Version-Upgrade zwangsläufig zum kritischen Pfad – und AWS gibt keinen festen Zeitplan für Deprecation und Entfernung vor. Genauso wenig empfiehlt es sich, immer auf dem allerneuesten Point Release zu sein. Die Community hat dort möglicherweise noch keine Probleme entdeckt, und es gibt unter Umständen wenig Material für die Fehlersuche im Netz.
Als Best Practice gilt: Rollen Sie jedes Point Release zu einem für Ihr Geschäft passenden Zeitpunkt aus und kombinieren Sie nicht mehrere Minor-Versionen in einem einzigen Upgrade. Wenn ein bekannter Bug erst in einer neuen Version behoben ist, bleibt Ihnen womöglich keine Wahl: Dann müssen Sie auch außerhalb Ihrer dokumentierten Geschäftsrichtlinie testen, verifizieren und aktualisieren.
Kurz gesagt: Handeln Sie IMMER proaktiv.
Minor-Version-Upgrades erkennen
In den letzten Monaten hat AWS ein neues Feature eingeführt, das Empfehlungen über die AWS CLI und die Console bereitstellt. Bisher war es deutlich aufwendiger, die Verfügbarkeit neuer Versionen zu ermitteln: Release Notes durchgehen, neue Versionen verfolgen oder Events in anderen Umgebungen überwachen, in denen das Feature aktiviert war.
Diese Informationen liefert nun das Kommando describe-db-recommendations. HINWEIS: Verfügbar ab CLI-Version 2.15.3. Um dieses Update zu finden, müssen Sie das Changelog Zeile für Zeile durchgehen. Wer die CLI nicht regelmäßig aktualisiert, braucht eine neuere Version, um das Kommando nutzen zu können.
Ausgabe von describe-db-recommendations
$ aws rds describe-db-recommendations
{
"RecommendationId": "",
"TypeId": "config_recommendation::old_minor_version",
"Severity": "informational",
"ResourceArn": "arn:aws:rds:region:123456789:cluster:mydb",
"Status": "active",
"Detection": "**[resource-name]** is not running the latest minor DB engine version",
"Recommendation": "Upgrade to latest engine version",
"Description": "Your database resources aren't running the latest minor DB engine version. The latest minor version contains the latest security fixes and other improvements.",
"RecommendedActions": [\
{\
"ActionId": "",\
"Operation": "modifyDbCluster",\
"Parameters": [\
{\
"Key": "EngineVersion",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "DBClusterIdentifier",\
"Value": "mydb"\
}\
],\
"ApplyModes": [\
"immediately",\
"next-maintenance-window"\
],\
"Status": "ready",\
"ContextAttributes": [\
{\
"Key": "Recommended value",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "Current engine version",\
"Value": "8.0.mysql_aurora.3.04.1"\
}\
]\
}\
```\
### Ausgabe in der AWS Console\
In der AWS Console des RDS-Service ist im linken Menü der Eintrag "Recommendations" hervorgehoben. Beispiel:\
\
### **Liste der RDS-Empfehlungen**\
In der Liste der Empfehlungen sehen Sie die betroffenen Server mit dem Hinweis "is not running the latest monitor DB engine version".\
\
### Details zu einer einzelnen Empfehlung\
Sie können zu jeder Empfehlung weitere Details abrufen und so die vollständige Konfiguration der Ressource sowie die Verweise auf die zugehörige Dokumentation einsehen.\
\
Fazit\
Wenn Sie dieses Wissen mit einem regelmäßig geplanten Job kombinieren, der diese Hinweise erfasst und verteilt, können Sie sich gezielt auf ein empfohlenes Minor-Version-Upgrade vorbereiten. Zusätzliche Validierungen und vorbereitete Recovery-Schritte, die zu Ihren geschäftlichen Anforderungen und Ressourcen passen, erhöhen die Sicherheit deutlich, dass Minor-Version-Upgrades ohne Auswirkungen auf die Produktion ablaufen.\