zurück zum Artikel

Laut einem vorläufigen Post-Incident-Report führte mangelnde Qualitätskontrolle zum Ausfall der cloud-basierten Microsoft-Dienste.

Microsoft hat Informationen zu den Ursachen für den Ausfall seiner cloud-basierten Dienste veröffentlicht. Wegen eines Ausfalls im Bereich der Azure Cloud von Microsoft konnte am Mittwochmorgen, den 25. Januar, eine Vielzahl von Nutzenden nicht auf Applikationen und Dienste zugreifen, die über diese Plattform gehostet werden. Darunter unter anderem das weit verbreitete Kollaborationswerkzeug Teams, aber auch andere Microsoft 365 Anwendungen wie Outlook, Word, Excel funktionierten in deren Cloud-basierenden Varianten nicht.

Was war passiert?

Zwischen 08:05 Uhr und 13:43 Uhr unserer Zeit stellten Kunden am Mittwoch Konnektivitätsprobleme fest, die sich in hohen Latenzen, Paketverlusten und Timeouts beim Zugriff auf Azure-Cloud-Ressourcen niederschlugen. Am Tag des Ausfalls nannte Microsoft zunächst lediglich einen Netzwerk-Change als Ursache des Ausfalls. Zur Behebung wurde dieser zurück gerollt. Ein vorläufiger Post-Incident Report von Microsoft liefert nun weitere Details [1].

Ursache war ein geplanter Change an einem WAN-Router. Gemäß der Information des Herstellers aus Redmond sollte eine IP-Adresse auf dem Router verändert werden. Das dazu abgesetzte Kommando an den Router führte zu Nachrichten an alle Router im WAN. Dies führte zu einer Neukalkulation von Weiterleitungsinformationen (Adjacency und Forwarding Tables) auf der Control Plane. Ob es sich um reguläre BGP-Updates handelte, erwähnt Microsoft nicht. Während dieser Neukalkulation konnten die Router die jeweils hindurch fließenden Pakete nicht korrekt weiterleiten. Ob es lediglich ein Lastproblem oder gar ein fehlerhaftes Routing gab, ist dem vorläufigen Report noch nicht zu entnehmen.

Fehler wegen mangelnder Qualitätskontrolle, Reaktion vorbildlich

Der ursächliche Befehl, der das Problem verursachte, verhält sich auf verschiedenen Routern unterschiedlich. Er hatte auf der Routerplattform, auf der er ausgeführt wurde, nicht den vollständigen Qualifizierungsprozess durchlaufen – ein klassischer Fehler also wegen fehlender Qualitätskontrollen im Bereich der Netzwerkautomatisierung. Es war jedoch nicht nur Nord/Süd-Traffic zwischen Clients und Azure betroffen, sondern auch die Konnektivität zwischen Azure-Regionen und Anbindungen über ExpressRoute.

Die Reaktion des Unternehmens war jedoch vorbildlich. Bereits sieben Minuten nach dem Ausfall bemerkte Microsoft die DNS- und WAN-Fehler und führte ein Review der zuvor getätigten Changes durch. Circa eine Stunde nach Beginn begann ein automatisierter Recovery-Prozess im Netzwerk. Die letzte Netzwerkkomponente nahm um 10:35 Uhr wieder ihre Funktion auf. Aufgrund des WAN-Ausfalls waren jedoch auch Automatisierungssysteme für das Monitoring und die automatisierte Außerbetriebnahme von nicht korrekt funktionierenden Netzwerkkomponenten außer Betrieb. Daher kam es noch bis 13:43 Uhr zu Paketverlusten. Viele Router brauchten noch einen manuellen Neustart, getreu dem Motto "Boot tut gut".

Fazit: Folgemaßnahmen

Fehler können passieren. Man muss aber daraus lernen. Microsoft hat nun zunächst Kommandos mit großem Impact geblockt und alle Ausführungen den "safe change guidelines" unterworfen. Der finale Review des Vorfalls soll innerhalb von vierzehn Tagen nach dem Vorfall veröffentlicht werden.

[2]

(jvo [3])

URL dieses Artikels:
https://www.heise.de/-7473885

Links in diesem Artikel:
[1] https://status.azure.com/en-gb/status/history
[2] https://www.heise.de/ix
[3] mailto:jvo@ix.de

Copyright © 2023 Heise Medien