Analyse: Microsoft liefert erste Details zum Ausfall von Teams, Office und Co.

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

In Pocket speichern vorlesen Druckansicht 202 Kommentare lesen
Portland,,Or,,Usa,-,Aug,10,,2021:,Premium,Microsoft,365

(Bild: Tada Images / Shutterstock.com)

Lesezeit: 3 Min.
Von
  • Benjamin Pfister
Inhaltsverzeichnis

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.

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.

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.

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".

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.

(jvo)