Salesforce-Großausfall offenbart riskante Cloud-Abhängigkeiten

Der Großausfall während der Dreamforce war nicht unbedingt werbewirksam für Salesforce – das steckte dahinter.Sundry Photography – shutterstock.com



Während seine Flaggschiff-Veranstaltung Dreamforce in vollem Gange war, hatte Salesforce mit einem rund siebeneinhalb Stunden andauernden Serviceausfall zu kämpfen. Dieser unterbrach den Zugriff von Anwendern und verursachte erhebliche Verzögerungen sowie zeitweise auftretende Fehler. Einige Kunden konnten zudem keine neuen Support-Anfragen einreichen.



Der Dienstausfall trat am 16. September um 7:50 Uhr UTC auf und betraf mehrere Instanzen in allen Regionen, wie Salesforce berichtete. Gegen 15:26 Uhr UTC meldete das Unternehmen die Störung als behoben, nachdem es die Systeme mehrere Stunden lang überwacht hatte, um sicherzustellen, dass die eingeleiteten Maßnahmen erfolgreich waren.



Salesforce führte das Problem zunächst auf einen Ausfall einer externen Abhängigkeit zurück, der den alten Anmeldeserver betraf. Eine Kernkomponente des Systems war offenbar einer erhöhten Last ausgesetzt, wodurch ihre Kapazität zur Verarbeitung von Anfragen eingeschränkt war. Salesforce zufolge gab es keine Probleme mit der Infrastruktur von Drittanbietern.



Abgesehen davon, dass der Ausfall für Salesforce zum wohl ungünstigsten Zeitpunkt auftrat, unterstreicht der Vorfall nach Ansicht von Abbas Jaffery, Principal Advisory Director bei der Info-Tech Research Group, ein grundsätzliches Problem der Cloud-Resilienz – und nicht lediglich eines von Legacy-Systemen.



„Die Cloud beseitigt architektonische Abhängigkeiten nicht, sondern macht sie manchmal nur weniger sichtbar. Und wenn die Plattform Ihr System of Record ist, werden diese verborgenen Abhängigkeiten zu einem Unternehmensrisiko und nicht nur zu einem technologischen Risiko“, warnt der Analyst



Ein „temporales“ Datenproblem entsteht



Für Kunden, bei denen Salesforce das Hauptbuchsystem ist, könnten mehrere Stunden mit Authentifizierungs- und Dienstunterbrechungen ein temporales Datenproblem verursachen, erläutert Jaffery. „Ereignisse, die eigentlich zu unterschiedlichen Zeitpunkten hätten stattfinden sollen, können verspätet eintreten, ganz ausbleiben oder in der falschen Reihenfolge ankommen.“



So könne beispielsweise während eines Salesforce-Ausfalls eine Kundeninteraktion über einen anderen Kanal stattfinden. Eine Integration, ein Workflow oder ein geplanter Prozess, der dieses Ereignis normalerweise erfasst oder an andere Systeme weitergibt, jedoch nicht ausgeführt werden.



Das zieht laut dem Analysten mehrere mögliche Folgen nach sich:




Transaktionen und Kundenserviceprozesse verzögerten sich;



bei APIs und Middleware könnten sich Wiederholungsversuche, Timeouts und Warteschlangen anhäufen;



Datensätze könnten vorübergehend inkonsistent werden, geplante Jobs und Workflows ausfallen;



Mitarbeiter verlören zudem möglicherweise den Überblick über die Kundenhistorie oder den Fallstatus – selbst wenn die zugrunde liegenden Daten nicht verloren gegangen sind. Es entstehe eine Datendivergenz.




„Der erste Fehler wäre, anzunehmen, dass der Vorfall vorbei ist, nur weil sich Benutzer anmelden können“, merkt der Analyst an. „Unternehmen sollten unverzüglich in eine Abgleichs- und Integritätsphase übergehen“, rät Jaffery. Dies bedeutet, nicht nur, den interaktiven Zugriff zu überprüfen, sondern auch APIs, Integrationen, geplante Jobs, Warteschlangen, Workflows, Automatisierungen, Authentifizierungsabläufe und nachgelagerte Systeme.



Unternehmen sollten sich dabei folgende Fragen stellen:




Welche Transaktionen sind während des Ausfalls fehlgeschlagen, wurden nur teilweise abgeschlossen oder doppelt ausgeführt?



Welche geplanten oder asynchronen Prozesse wurden nicht ausgeführt?



Waren die Wiederholungsversuche der Integrationen erfolgreich oder entstand dadurch ein Rückstau, beziehungsweise ein „Retry Storm“?



Sind die nachgelagerten Systeme jetzt wieder mit Salesforce konsistent?




Security-Teams empfiehlt Jaffery zudem, das Verhalten von Authentifizierung und Sessions, privilegierte Zugriffe, Zugangsdaten von Integrationen sowie alle während der Wiederherstellung vorgenommenen Notfalländerungen zu überprüfen.



„Die wichtigste Frage lautet nicht, ob Salesforce wieder verfügbar ist. Stattdessen sollte man danach fragen, was aus geschäftlicher Sicht während des Ausfalls hätte passieren sollen. Und anschließend nachzuweisen, ob es tatsächlich passiert ist“, so der Analyst.



Es geht nicht nur um ‚Legacy‘-Komponenten im Stack



Eine architektonische Erkenntnis aus dem Salesforce-Ausfall sei, dass eine Legacy-Komponente nicht groß sein muss, um kritisch zu sein, betont Jaffery: „Das Alter der Komponente ist weniger entscheidend als ihre Position im Abhängigkeitsnetz, ihr potenzieller Schadensradius sowie die Qualität ihrer Isolation und Fehlerbehandlung.“



Das zeige auch der Verlauf dieses Vorfalls, so der Analyst weiter: „Aufgrund eines erhöhten Ressourcenverbrauchs blieben Anfragen beim Warten auf einen internen Login-Dienst hängen. Die Untersuchung führte zu einem Fehler bei einer externen Abhängigkeit, der wiederum Auswirkungen auf einen älteren Login-Server offenbarte.“



Salesforce erklärte schließlich, dass zentrale Systemkomponenten einer erhöhten Last ausgesetzt waren, wodurch ihre Kapazität zur Verarbeitung von Anfragen eingeschränkt wurde.



Das sei eine klassische Frage der Resilienz, betont Jaffery: Bleibt der Ausfall einer einzelnen Abhängigkeit auf diese Komponente beschränkt – oder entwickelt er sich zu einem plattformweiten Ausfall?



Modernisierung sollte deshalb nicht einfach daran gemessen werden, wie viel alte Technologie ersetzt wurde, merkt er an. Berücksichtigt werden sollten auch die Konzentration von Abhängigkeiten, deren Isolation, eine kontrollierte Degradierung („graceful degradation“), Wiederherstellungspfade und der mögliche Schadensradius eines Ausfalls.



„Für Enterprise Architects ist das die eigentliche Erkenntnis.“



Durch Agentic AI ausgelöst, durch Entlassungen verschärft?



Derzeit gebe es keine offensichtlichen Anzeichen dafür, dass es sich um einen Sicherheitsvorfall handelt, merkt David Shipley, CEO von Beauceron Security, an. „Im Moment weist der Vorfall sämtliche Merkmale eines Updates auf, das furchtbar schiefgelaufen ist.“



Shipley verweist auf einen Vorfall im Dezember 2025, als Amazons interner KI-Programmieragent „Kiro“ einen 13-stündigen AWS-Ausfall in einer Region auf dem chinesischen Festland verursacht hatte. „Ich wäre nicht überrascht, wenn bei einer Katastrophe dieser Größenordnung KI-Agenten im Spiel waren“, so der Analyst.



Die umfangreichen Entlassungen bei Salesforce in den letzten Jahren könnten sich ebenfalls negativ auf den Ausfall und die Wiederherstellung ausgewirkt haben, fügt er hinzu. „Dass dies ausgerechnet während der Dreamforce passiert, muss für die Vertriebs- und Kunden-Support-Teams die reinste Hölle gewesen sein. Um die Kundenbeziehungen wieder aufzubauen, dürfte auf sie nun jede Menge Arbeit zukommen.“ (mb)



Dieser Artikel basiert auf einem Beitrag der Schwesterpublikation CIO.com.