Speicherfehler legten Salesforces zentralen Switch und dessen Failover lahm – 900.000 Abonnenten ausgesperrt

Am 6. Januar 2009 ging salesforce.com dunkel. Ab 20:39 UTC (etwa Mittag pazifischer Zeit) konnten Kunden sich nicht anmelden und nicht auf ihre CRM-Daten zugreifen; The Register berichtete, dass mehr als 900.000 Abonnenten aus den Anwendungen ausgesperrt waren, auf denen sie ihre Geschäfte betreiben. Business Insider bezifferte den vollständigen Ausfall auf 30 bis 40 Minuten. Für ein Unternehmen, dessen Verkaufsargument war, dass Betriebe ihre wichtigsten Daten seiner Cloud anvertrauen könnten, fiel der größte Teil einer Stunde totalen Versagens mitten in den Arbeitstag.

Salesforces eigene Erklärung, die danach veröffentlicht wurde: „ein zentrales Netzwerkgerät fiel aufgrund von Fehlern bei der Speicherzuweisung aus. Der Ausfall führte dazu, dass es aufhörte, Daten weiterzuleiten, löste aber kein ordnungsgemäßes Failover auf das redundante System aus, da die Fehler bei der Speicherzuweisung auch auf dem Failover-System vorhanden waren.“ Mit anderen Worten: Das redundante Gerät fiel auf dieselbe Weise aus wie das primäre, und die Plattform musste mit manuellen Schritten wiederhergestellt werden.

Der Vorfall legte außerdem einen Fehler zweiter Ordnung offen. Salesforces öffentliches „Trust“-Status-Dashboard – die Seite, mit der das Unternehmen für seine Zuverlässigkeit warb – war zusammen mit dem Produkt ausgefallen, sodass Kunden nicht erkennen konnten, ob sie die Einzigen waren, die betroffen waren. Hunderte wandten sich an Twitter, um den Ausfall zu bestätigen – eine frühe Demonstration dafür, dass bei einem Ausfall einer SaaS-Plattform auch ihre Kommunikationsschicht ausfällt, sofern diese nicht bewusst außerhalb des Wirkungsbereichs gehalten wird.

Rund 40 Minuten totalen Dienstausfalls für mehr als 900.000 Abonnenten, mitten am Geschäftstag, ohne funktionierendes Failover.

Das Failover-Gerät trug denselben Defekt bei der Speicherzuweisung wie das ausgefallene primäre Gerät, sodass der „redundante“ Pfad den Datenverkehr nie übernahm.

Das Failover wurde nicht ordnungsgemäß ausgelöst; die Wiederherstellung des vollen Dienstes erforderte manuelle Wiederherstellungsschritte durch das Betriebsteam.

Das öffentliche Trust-Dashboard lag in derselben Ausfalldomäne, sodass Kunden im Unklaren blieben und den Ausfall selbst über Twitter diagnostizieren mussten.

Redundanz aus identischen Teilen erbt identische Fehler. Wenn die Standby-Einheit denselben Defekt trägt wie das primäre Gerät, ist sie ein Spiegel, kein Puffer – der Failover-Pfad muss diversifiziert werden.

Salesforce veröffentlichte seine Erklärung auf der Trust-Seite, erklärte, die Ursache sei „durch den Work-around behoben“ worden, und erklärte, sein Team werde weiter mit Hardware-Herstellern zusammenarbeiten, um die Ursache genau zu bestimmen und weitere Patches zu ermitteln. The Register und die Wirtschaftspresse rahmten den Ausfall als „dunkle Kehrseite“ des Cloud Computing für ein Unternehmen ein, das Verfügbarkeit als seinen Kernvorteil gegenüber installierter CRM-Software verkaufte. Beobachter der Zuverlässigkeit zogen eine andere Lehre: Alles fällt aus, und was Betreiber unterscheidet, ist, ob Kunden erfahren können, was geschieht – Kommunikation, nicht Verfügbarkeit, war das Versagen.