Microsoft erklärt fünfstündigen Komplettausfall von Visual Studio Online

Microsoft hat jetzt zu einem fünfstündigen Ausfall von Visual Studio Online ausführlich Stellung genommen. Er ereignete sich am 14. August; Microsoft-Manager Brian Harry beschreibt ihn nachträglich als „einer der schlimmsten Zwischenfälle, die wir bei VS Online je hatten.“

Visual Studio Online besteht aus Team Foundation Server und einigen verwandten Diensten, die auf Azure laufen. Am 14. August wurden seine Shared Platform Services (SPS) von Datenbank-Updates überwältigt, die so stark aufliefen, dass Aufrufe blockiert wurden, erklärt Harry.

Was genau den Ausfall auslöste, wisse man bis heute nicht, räumt der Microsoft-Manager ein. Einige Konfigurationsänderungen sorgten für deutlich erhöhten Traffic zwischen TFS und SPS, und einiger solcher Traffic bestand aus Lizenzprüfungen, die nicht richtig deaktiviert worden waren. Gleichzeitig ergab sich eine Spitze bei den Latenzen und den fehlgeschlagenen Service-Bus-Messages.

Harry zählt auch einige „Kernfehler“ auf, die laut Microsofts Analyse zu dem Problem beitrugen, darunter einen Bug im Portal Extension Service von Azure. Man habe viel aus dem Zwischenfall gelernt.

„Zurück zu vergangenem Dienstag … Wir sind nachlässig geworden. Nachlässig ist wahrscheinlich zu grob. Aber wie jedes Team sind wir hin- und hergerissen, ob wir zuerst unsere Cornflakes essen oder von den Kunden nachgefragte Fähigkeiten einführen sollen. Im Streben nach schnellem Rhythmus, jeder Sprint ist wichtig und so weiter haben wir zugelassen, dass eine gewisse Präzision nachgelassen hat – oder präziser, nicht mehr in neuen Code eingeflossen ist. Das halte ich für die Kernursache – Entwickler können nie voll die Kosten oder Folgen bemessen, die eine ihrer Änderungen nach sich zieht, weil wir nicht alle Software-Schichten und Abstraktionen überblicken können und es keine automatischen Regressionstests gibt, um erhöhten Ressourcenverbrauch durch neuen Code auszuweisen.“

Microsoft müsse nun Infrastruktur anschaffen, um Änderungen zu messen und Abweichungen der Gesamtkosten auszuweisen, um ähnliche Probleme künftig zu verhindern, schreibt Harry. Auch werde man die Aufrufmuster innerhalb von SPS sowie zwischen SPS und SQL besser analysieren, um ein Warnsystem einzurichten und solche Situationen früher zu erkennen. Zudem arbeite das Team an der Partitionierung und Skalierung der SPS-Konfigurationsdatenbank. Möglicherweise werde man einen Dienst einrichten, um solche Probleme durch Drosseln abzufangen und eine Erholung zu ermöglichen.

[mit Material von Mary Jo Foley, ZDNet.com]

Tipp: Sind Sie ein Fachmann in Sachen Cloud Computing? Testen Sie Ihr Wissen – mit dem Quiz auf silicon.de.