Am 28.09. gab es teilweise massive Probleme mit „Diensten der Azure-Cloud“. Auf den ersten Blick war dies kein sensationelles Ereignis, zumal es keinen Totalausfall gab und laut Microsoft-Statistik Europa auch noch am wenigsten betroffen war.
Der Fall und die Fallbeschreibung von Microsoft selbst führen aber deutlich vor, wie wichtig kontinuierliche Verbesserung ist – Lernen aus Incidents gehört da ins Pflichtprogramm. Der Fall zeigt auch auf, wie gefährlich es sein kann, sich bei wichtigen Cloud-Services allzu bequem auf eine erwartungsvolle Konsumentenhaltung zu beschränken.
Aus der „langweiligen ITIL-Theorie“ wird hier ein kommentiertes, anschauliches Praxisbeispiel, in dem sich jeder irgendwie angesprochen fühlen kann. Der damit angeregte prüfende Blick in den Spiegel lohnt sich.
Was ist passiert?
Der Vorfall betraf viele Verbraucher und Geschäftskunden, weil es gravierende Probleme mit Azure Active Directory (Azure AD) gab. Fast alle Microsoft Cloud Services und auch viele in der Azure-Cloud laufende Applikationen von Drittanbietern waren betroffen. Laut Microsoft wurde das Incident durch einen fehlerhaften Update-Vorgang verursacht. Microsoft gab an, dass der Update-Vorgang zunächst in einer Testumgebung validiert, bevor er auf die produktive Umgebung übertragen werden sollte. Jedoch verursachte ein fehlerhafter Code im automatischen Deployment-Prozess, dass die produktive Umgebung ohne vorherige Validierung des Updates davon erfasst wurde.
Probleme und Teilstörungen bei Providerdiensten lassen sich nicht völlig ausschließen. Vergleichbare Beispiele hat es in 2019 und 2020 mit verschiedenen Providern und auch längerer Vorfalldauer gegeben. Das gibt es nicht nur bei Cloud-Services von Microsoft.
Microsoft Bashing soll hier auch nicht stattfinden. Der „ComConsult-Reflex“, sich in solchen Fällen auch die Stellungnahme und Sichtweise eines Herstellers oder Providers am Ende des Falles anzuschauen, hat aber gezeigt:
Dieser Fall ist ein prima Beispiel, um trockenen ITIL- oder BSI-Grundschutz-Empfehlungen Leben einzuhauchen. Hätte er sich nicht ereignet und wäre er nicht so umfassend in der Azure-Status-Historie beschrieben worden, man hätte dies als Beispielfall für eine Schulung erfinden müssen.
Man kann an diesem „Live-Ereignis“ nachvollziehen:
- Wie komplex und verzahnt die aktuelle vernetzte IT-Ausstattung ist
Antwortzeitprobleme bei der Anmeldung führten hier für bestimmte Betroffene zu einem breiten Service-Down-Erlebnis für die Cloud-Dienste. Der Effekt trat dabei je nach Region unterschiedlich stark auf, ein Anzeichen dafür, dass sich ein solches Problem in einer reinen Testumgebung durchaus erfolgreich „tarnen“ konnte. Wer mehr als eine kleine Nischen- oder Insellösung betreibt, muss ab einem bestimmten Punkt die Produktivumgebung schrittweise miteinbeziehen – und dann eben schnell reagieren können.
- Wie aufwändig die Aufgabe und die notwendige Ausstattung eines Providers bzw. IT-Betreibers ist
Trotz mehrstufiger Test- und Deployment-Strategie konnte nicht verhindert werden, dass eine im Detail problematische Änderung sich so weit in der produktiven Infrastruktur ausgewirkt hat. Anscheinend blieb – durch das Zusammentreffen mit einem Problem in der Systemlösung, die den stufenweisen Roll-out in der umfangreichen Cloud-Infrastruktur steuern soll – dieses Problem nicht auf einen ersten, Microsoft-internen Pilotnutzerbereich beschränkt.
- Wie wichtig die Verfügbarkeit von Betriebswerkzeugen ist, mit denen man schnell und effizient reagieren kann, und: wie wichtig ein „Plan B“ und dessen Beherrschung sind
Solche Lösungen sollte man als „Prio-1a-Systeme“ behandeln. Ausgerechnet die für automatischen Rollback vorgesehenen Systeme waren mittelbar auch von dem Fall betroffen, nötige Metadaten waren inkonsistent.
Notgedrungen war manueller Rollback nötig. So etwas dauert naturgemäß länger als ein entsprechender automatisierter Vorgang. Zeit verlieren kann man aber auch dadurch, dass der manuelle Vorgang nicht gut genug beherrscht wird. Im dümmsten, durchaus realistischen Fall muss man erst einmal Personal finden und aktivieren, das ein solches manuelles Vorgehen überhaupt beherrscht.
Wen sollte das interessieren?
Im Grunde genommen gehen die durch den aktuellen Fall vorgeführten Aspekte jeden an, der mit IT zu tun hat – wen also nicht?
Zunächst ist da der Betreiber von IT-Lösungen, intern oder als Dienstleister – dieser hat gleich eine ganze Themenliste, an die er hier aus der Praxis erinnert wird:
- Testkonzept und –Pläne für alle betriebenen Services und Lösungen,
- Deployment mit gestuftem Roll-out und gut beherrschtem Rollback (auch mal manuell, wenn es dumm läuft!), aber auch:
- Beobachten und frühzeitiges Erkennen von Problemen und
- Vorkehrungen, über die er in der Lage ist, gezielt und auch mutig eine Rollback-Entscheidung zu treffen.
Ja, das ist lästig, und ja, das hat man schon tausendmal gehört, aber …
Nichts „aber“ – der Microsoft-Fall zeigt, dass man da durchaus schon organisiert und ausgestattet sein und trotzdem noch in Situationen geraten kann, die Nachbesserungsbedarf aufzeigen. Apropos Nachbesserungsbedarf – auch den Umgang damit, begründet mit „das wollen wir so nicht noch einmal erleben“, führt das aktuelle Microsoft-Beispiel vor.
Offenbar ist eine Nachanalyse erfolgt, so sollte es sein! Das Ergebnis waren die „Next Steps“, die in der Veröffentlichung zum akut gelösten Fall auch benannt werden. Diese betreffen nicht nur die Beseitigung von Restproblemen mit der Rollback-Lösung, sondern auch Zusatzaktivitäten bzgl. Rollback-Übungen und eine Forcierung der Abstützung aller Services auf eine Redundanz im Bereich des fallauslösenden Authentisierungsdienstes.
So sollte man vorgehen – Verbesserungsmöglichkeiten bei Prävention und Reaktionsfähigkeit prüfen, und da auch genügend selbstkritisch sein. Zumindest Vorschläge zur Verbesserung bei „Findings“ kann man machen – die Aufwands- und Kostenfrage ist dann Entscheidersache. Über fachkundige und praktikable Verbesserungsvorschläge, die nicht vorliegen, kann auch niemand entscheiden.
Microsoft hat sich im aktuellen Fall sogar dazu entschlossen, zu typischen Azure-AD-Fallszenarien bei der Benachrichtigung potenziell Betroffener, beschleunigende Maßnahmen einzuleiten.
Damit kommen wir zum „was geht mich das an“-Teil der IT- und Cloud-Service-Nutzer. Bin ich ein IT-Nutzer, habe ich mit den zuvor beleuchteten Bereitstellungsaspekten nichts zu tun. Bin ich Cloud-Service-Nutzer, ist damit eine Entscheidung getroffen worden, das Verfügbarkeitsthema für die zentralen Serviceangebote komplett auf einen externen Anbieter zu verlagern. Aber halt: „komplett“, geht das so einfach?
Der aktuelle Microsoft-Fall zeigt: Auch ein hochzertifizierter und entsprechend organsierter Provider kann keine 100%-Verfügbarkeitsversprechen einlösen. Also muss ich mich selber fragen: Was tun, wenn Provider-Services nicht zur Verfügung stehen? Welche Daten brauche ich trotzdem, kann ich diese auch „offline“ nutzen, und wenn ja, wird das auch beherrscht? Wo liegen evtl. hilfreiche Anleitungen – hoffentlich nicht nur online beim Provider? Nicht für alle Daten und alle IT-Anwendungen muss man sich da rüsten – aber auch diese Auswahl muss erst einmal getroffen werden!
(die offiziellen Ausführungen von Microsoft zum Fall findet man unter https://status.azure.com/en-us/status/history/ , Tracking ID SM79-F88)
Der Netzwerk Insider gehört mit seinen Produkt- und Markt-Bewertungen rund um IT-Infrastrukturen zu den führenden deutschen Technologie-Magazinen. Der Bezug des Netzwerk Insiders ist kostenlos.
