„Was ist die primäre Ursache für Probleme mit der Dienstzuverlässigkeit bei Azure, abgesehen von kleinen, aber häufig auftretenden Hardwarefehlern? Änderungen. Eines der Nutzenversprechen der Cloud besteht darin, dass sie kontinuierlich verbessert wird, sodass neue Funktionen und Features sowie Verbesserungen der Sicherheit und Zuverlässigkeit bereitgestellt werden. Da die Plattform sich jedoch kontinuierlich weiterentwickelt, sind Änderungen unvermeidlich. Dies erfordert einen sich grundsätzlich unterscheidenden Ansatz, um Qualität und Stabilität sicherzustellen, als bei einem handelsüblichen Produkt oder herkömmlichen IT-Ansätzen, die darin bestehen, über einen längeren Zeitraum hinweg Tests durchzuführen und Änderungen nach der Bereitstellung zu vermeiden. Dieser Beitrag ist der fünfte der Reihe, die ich mit meinem Blogbeitrag im Juli gestartet habe, in der ich Einblicke in die Vorgänge gewähre, mit denen sichergestellt wird, dass die Zuverlässigkeit von Azure Ihre unternehmenskritischen Workloads unterstützt. Heute beschreiben wir unsere sicheren Bereitstellungsmethoden, die unsere Vorgehensweise zur Verwaltung der Automatisierung von Änderungen umfassen, sodass alle Updates am Code und der Konfiguration klar definierte Phasen durchlaufen. Dadurch werden Regressionen und Fehler ermittelt, bevor sie sich auf Kunden auswirken, oder nur wenige Kunden betreffen, wenn sie nicht in den frühen Phasen erkannt werden. Cristina del Amo Casado vom Compute Engineering-Team hat diese Beiträge verfasst, da sie unsere Initiativen zur sicheren Bereitstellung vorangetrieben hat.“ – Mark Russinovich, CTO, Azure

---

 

Beim lokalen Betrieb von IT-Systemen können Sie versuchen, perfekte Verfügbarkeit zu erreichen, indem Sie vergoldete Hardware verwenden, Ihren Serverraum abschließen und den Schlüssel wegwerfen. Auf der Softwareebene würde die IT-Abteilung normalerweise das Vornehmen von Änderungen weitestgehend verhindern: sie würde vermeiden, Updates für das Betriebssystem und/oder Anwendungen durchzuführen, weil diese zu wichtig für das Unternehmen sind, und Änderungsanforderungen von Benutzern verweigern. Wenn alle das System mit äußerster Vorsicht behandeln, würde dies die fortlaufende Verbesserung des Systems zurückhalten und in einigen Fällen sogar die Sicherheit von Systemen kompromittieren, deren Ausführung so wichtig ist, dass sie keine regelmäßigen Patches erhalten. Wie Mark bereits oben beschrieben hat, funktioniert dieser Ansatz nicht für die Änderungs- und Releaseverwaltung in einer öffentlichen Hyperscale-Cloud wie Azure. Änderungen sind sowohl unvermeidlich als auch vorteilhaft, da Wartungsupdates und Verbesserungen bereitgestellt werden müssen und wir dazu verpflichtet sind, Sicherheitsrisiken schnellstmöglich zu beheben. Da Änderungen nicht vermieden werden können, müssen Microsoft, unsere Kunden und unsere Partner anerkennen, dass Änderungen erwartet und entsprechend geplant werden müssen. Microsoft arbeitet weiterhin daran, Updates möglichst transparent durchzuführen und Änderungen wie im Folgenden beschrieben sicher bereitzustellen. Allerdings sollten auch unsere Kunden die Hochverfügbarkeit beim Entwurf berücksichtigen und von der Plattform übermittelte Wartungsereignisse nach Bedarf nutzen. Letztlich können Kunden in einigen Fällen steuern, dass Updates für die Plattform zu einem für ihre Organisation passenden Zeitpunkt durchgeführt werden.

Sicheres Vornehmen von Änderungen

Bei der Planung der Bereitstellung von Releases in unseren Rechenzentren besteht eine der wichtigsten Voraussetzungen für unsere Prozesse darin, dass davon ausgegangen werden muss, dass die Bereitstellung der Änderung zu einem unbekannten Problem führen kann. Deshalb muss die Planung die Ermittlung eines solchen Problems mit möglichst geringen Auswirkungen beinhalten, und es müssen automatische Schutzmaßnahmen für das Problem ergriffen werden, wenn dieses auftritt. Selbst wenn ein Entwickler eine Änderung als unbedenklich einstuft und garantiert, dass sie sich nicht auf den Dienst auswirkt, kann selbst die kleinste Änderung an einem System ein Risiko für die Stabilität des Systems darstellen. Daher bezieht sich der Begriff „Änderungen“ in diesem Kontext auf alle Arten neuer Releases: sowohl Änderungen am Code als auch Änderungen an der Konfiguration. In den meisten Fällen sind die Auswirkungen auf das Verhalten eines Systems durch eine Konfigurationsänderung weniger ausschlaggebend. Es gilt jedoch genau wie bei Codeänderungen, dass eine Konfigurationsänderung nicht vollkommen risikofrei ist und einen verborgenen Codefehler oder neuen Codepfad auslösen kann.

Teams nutzen ähnliche Prozesse für verschiedene Azure-Dienste, um die Auswirkungen von Änderungen zu verhindern oder zumindest zu reduzieren. Hierzu wird zunächst mithilfe von Tests und Integrationsüberprüfungen sichergestellt, dass Änderungen eine gewisse Qualität aufweisen, bevor sie bereitgestellt werden. Nach dieser Bestätigung wird die Änderung allmählich implementiert und die Integrität wird dabei ständig überwacht, sodass in relativer Isolation ermittelt werden kann, ob es zu unerwarteten Auswirkungen kommt, die bei den Tests nicht festgestellt wurden. Eine Änderung, die zu Problemen führt, sollte niemals in die Produktion gelangen. Daher werden Vorkehrungen getroffen, um dies nach Möglichkeit zu vermeiden. Diese allmähliche Bereitstellung ermöglicht uns, Probleme in geringerem Umfang (bzw. mit geringeren Auswirkungen) zu ermitteln, bevor es zu größeren Auswirkungen kommen kann.

Azure erzielt die Automatisierung von Änderungen gemäß des oben beschriebenen allgemeinen Prozesses mithilfe eines Frameworks für sichere Bereitstellungen. Mit diesem soll sichergestellt werden, dass alle Code- und Konfigurationsänderungen einen Lebenszyklus in verschiedenen Phasen durchlaufen, in denen Integritätsmetriken überwacht werden, um automatische Aktionen und Warnungen auszulösen, wenn eine Beeinträchtigung erkannt wird. Diese Phasen (die in der folgenden Grafik veranschaulicht werden) reduzieren das Risiko dafür, dass sich Softwareänderungen negativ auf Ihre bestehenden Azure-Workloads auswirken.

Diese Grafik veranschaulicht eine vereinfachte Darstellung unserer Bereitstellungspipeline, die links mit Entwicklern beginnt, die den Code bearbeiten, auf ihren eigenen Systemen testen und an die Stagingumgebungen pushen. Diese Integrationsumgebung ist im Allgemeinen für Teams vorgesehen, die eine Teilmenge von Azure-Diensten betreuen und die Interaktionen ihrer jeweiligen Komponenten testen müssen. Zum Beispiel teilen sich Kerninfrastrukturteams wie Compute-, Netzwerk- und Speicherteams eine Integrationsumgebung. Jedes Team führt synthetische Tests und Stresstests für die Software in dieser Umgebung durch und durchläuft diese, bis stabile Ergebnisse erzielt werden. Sobald aus den Ergebnissen der Qualitätsprüfungen hervorgeht, dass ein Release, ein Feature oder eine Änderung bereit für die Produktion ist, stellen sie die Änderungen in den Canary-Regionen bereit.

Canary-Regionen

Canary-Regionen werden in der Öffentlichkeit als Regionen für den „frühen Zugriff auf Updates“ (Early Updates Access Program) bezeichnet und sind im Prinzip vollständig ausgestattete Azure-Regionen mit einem Großteil der Azure-Dienste. Eine der Canary-Regionen verfügt über Verfügbarkeitszonen, die andere nicht. Zusammen bilden sie ein Regionspaar, sodass die Georeplikationsfunktionen von Daten überprüft werden können. Diese Canary-Regionen werden für vollständige Überprüfungen auf Produktionsebene und Behandlung von Szenarios im großen Stil. In diesen Regionen werden einige Erstanbieterdienste (für interne Kunden) und Drittanbieterdienste gehostet. Außerdem laden wir eine kleine Gruppe externer Kunden in das Programm ein, um den Umfang und die Komplexität der behandelten Szenarios zu erhöhen. Durch diese Maßnahmen soll sichergestellt werden, dass Canary-Regionen ähnliche Nutzungsmuster wie öffentliche Azure-Regionen aufweisen. Azure-Teams führen außerdem Stresstests und synthetische Tests in diesen Regionen durch. Außerdem werden regelmäßig Fault-Injection-Verfahren oder Notfallwiederherstellungsübungen in der Region oder Verfügbarkeitszone durchgeführt, um die Ermittlungs- und Wiederherstellungsworkflows zu testen, die in echten Fällen ausgeführt werden würden. Bei diesen Übungen soll separat und gemeinsam sichergestellt werden, dass die Software die höchstmögliche Qualität aufweist, bevor Änderungen für das breite Spektrum an Kundenworkloads in Azure bereitgestellt werden.

Pilotphase

Sobald die Ergebnisse aus der Canary-Region angeben, dass keine bekannten Probleme ermittelt werden, kann die progressive Bereitstellung beginnen. Diese beginnt zunächst mit der Pilotphase. In dieser Phase können wir die Änderungen testen. Dies erfolgt zwar weiterhin in einem kleinen Maßstab, aber mit einer höheren Vielfalt an Hardware und Konfigurationen. Diese Phase ist insbesondere für Software wie zentrale Speicherdienste und zentrale Compute-Infrastrukturdienste wichtig, die Hardwareabhängigkeiten aufweisen. Beispielsweise bietet Azure Server mit GPUs, großen Serverarbeitsspeicher, Standardserver, mehrere Generationen und Typen von Prozessoren, InfiniBand und mehr. Dadurch wird also Test-Flighting für die Änderungen und möglicherweise die Ermittlung von Problemen ermöglicht, die in kleineren Tests nicht erkannt werden würden. In jedem einzelnen Schritt sorgen gründliche Integritätsüberwachung und verlängerte Testzeiten dafür, dass potenzielle Fehlermuster aufgedeckt werden. Dadurch wird der Vertrauensgrad der Änderungen erhöht, und das Gesamtrisiko wird für unsere Kunden gleichzeitig stark reduziert.

Sobald die Ergebnisse der Pilotphase als gut genug befunden werden, erlauben die Bereitstellungssysteme die inkrementelle Integration in weitere Regionen. Während der gesamten Bereitstellung in die umfassenderen Azure-Regionen respektieren die Bereitstellungssysteme die Verfügbarkeitszonen (d. h. eine Änderung wird innerhalb einer Region nur in eine Verfügbarkeitszone bereitgestellt) und die Regionspaare (jede Region wird für georedundanten Speicher mit einer zweiten Region gekoppelt). Eine Änderung wird also zunächst in einer Region bereitgestellt, bevor sie auch in der gekoppelten Region bereitgestellt wird. Im Allgemeinen bedeutet das, dass die Änderungen nur bereitgestellt werden, wenn keine negativen Auswirkungen festgestellt werden.

Sichere Bereitstellungsmethoden in Aktion

Aufgrund der globalen Skalierung von Azure wird der gesamte Rolloutprozess automatisiert durchgeführt und mithilfe von Richtlinien gesteuert. Diese deklarativen Richtlinien und Prozesse (nicht die Entwickler selbst) bestimmen, wie schnell Software bereitgestellt wird. Richtlinien werden zentral definiert und umfassen obligatorische Integritätsmeldungen für die Überwachung der Softwarequalität sowie obligatorische Testzeiten zwischen den verschiedenen oben beschriebenen Phasen. Die Software durchläuft gewisse Testzeiten in jeder Phase, um sicherzustellen, dass die Änderung mit der gesamten Bandbreite an Dienstworkloads getestet werden kann. Beispielsweise würden verschiedene Organisationsbenutzer den Dienst morgens benutzen, während Kunden der Spielebranche ihn erst abends nutzen. Außerdem werden über einen längeren Zeitraum neue virtuelle Computer oder Ressourcen von Kunden erstellt.

Globale Dienste, die diesen Ansatz für die progressive Bereitstellung auf verschiedene Cluster, Regionen oder Dienstringe nicht nutzen können, wenden eine andere Version von progressiven Rollouts gemäß dem Framework für sichere Bereitstellungen an. Diese Dienste nutzen ein Modell, bei dem ihre Dienstinstanzen in mehreren Phasen aktualisiert werden, dabei wird der Datenverkehr mit dem Azure Traffic Manager nach und nach auf die aktualisierten Instanzen umgeleitet. Wenn die Integritätsmeldungen positiv sind, wird mit der Zeit mehr Datenverkehr auf die aktualisierten Instanzen umgeleitet, wodurch der Vertrauensgrad erhöht wird und die Bereitstellung auf weitere Dienstinstanzen angewendet werden kann.

Die Azure-Plattform bietet natürlich auch die Möglichkeit, eine Änderung gleichzeitig für alle Azure-Ressourcen bereitzustellen. Dies kann erforderlich sein, um eine Maßnahme gegen extrem kritische Sicherheitsrisiken zu implementieren. Obwohl unsere Richtlinien für die sichere Bereitstellung obligatorisch sind, können wir die Bereitstellung unter gewissen Notfallbedingungen beschleunigen. Wenn wir ein Sicherheitsupdate beispielsweise wesentlich schneller als üblich veröffentlichen oder eine Fehlerbehebung implementieren müssen, die ein Regressionsrisiko behebt, von dem Kunden bereits stark beeinträchtigt werden. Diese Ausnahmen sind sehr selten. Im Allgemeinen wird bei unseren Bereitstellungstools und -prozessen absichtlich Geschwindigkeit geopfert, um die Wahrscheinlichkeit von Meldungen zu maximieren, sodass Szenarios und Workflows nach Maß durchgeführt werden können, wodurch Probleme wiederum mit möglichst geringen Auswirkungen ermittelt werden können.

Kontinuierliche Verbesserungen

Unsere sicheren Bereitstellungspraktiken und Bereitstellungstools werden anhand der Erkenntnisse aus früheren Ausfällen und Wartungsereignissen stetig weiterentwickelt. Auch dabei verfolgen wir das Ziel, Probleme in möglichst kleinem Maßstab zu erkennen. Beispielsweise haben wir gelernt, wie wichtig es ist, unsere Integritätsmeldungen weiterhin zu bereichern und maschinelles Lernen zu verwenden, um Fehler besser zu korrelieren und Anomalien zu erkennen. Außerdem verbessern wir weiterhin die Art und Weise, wie Pilotphasen und Test-Flighting durchgeführt werden, damit wir eine größere Hardwarevielfalt mit geringerem Risiko abdecken können. Zudem arbeiten wir an unserer Fähigkeit, Rollbacks für Änderungen automatisch durchzuführen, wenn Anzeichen für potenzielle Probleme vorliegen. Außerdem investieren wir weiterhin in Plattformfeatures, die die allgemeinen Auswirkungen von Änderungen reduzieren oder beseitigen.

Allein im letzten Jahr wurden mehr als Tausend neue Funktionen veröffentlicht. Uns ist bewusst, dass eine solche Geschwindigkeit für die Änderungen in Azure überwältigend sein kann. Wie Mark bereits erwähnt hat, ist die Agilität und kontinuierliche Verbesserung der Clouddienste eines der wichtigsten Nutzenversprechen der Cloud. Veränderung ist ein Feature, kein Fehler. Informationen zu den neuesten Releases und Ankündigungen finden Sie stets unter azure.com/updates. Diese Website soll als zentrale Informationsquelle zu aktuellen und bevorstehenden Azure-Produktupdates sowie zur Roadmap für Innovationen dienen, die sich in der Entwicklung befinden. Informationen dazu, wann und in welchen Regionen die verschiedenen Dienste verfügbar sind, finden Sie mithilfe unseres Tools unter azure.com/ProductsbyRegion.