Salesforce: Nicht autorisiertes OS-Update legt Netzwerk lahm

Unternehmen

Salesforce bietet Multi-Cloud-CRM, Commerce, Analytics und Plattformdienste an, darunter Core Salesforce, Service Cloud, Commerce Cloud, Marketing Cloud, Tableau, MuleSoft, Revenue Cloud und Heroku.

Was passierte bei dem Salesforce-Ausfall?

Salesforce stellte weitreichende Login-Fehler und Funktionsstörungen über mehrere Clouds hinweg fest.

‍

Ein automatisches Betriebssystem-Update, das von einem Prozess ausgeführt wurde, der in der Produktion hätte deaktiviert sein müssen, führte zu einem Neustart der Netzwerkdienste auf den Heroku Private Space-Hosts – jedoch wurden die erforderlichen Routen dabei nicht erneut angewendet.

‍

Der daraus resultierende Verlust der ausgehenden Konnektivität verursachte Kettenreaktionen bei Private-Space-Anwendungen, Teilen des Common Runtime, Datenbanken, MFA-Flows und internen Tools (einschließlich der Heroku-Statusseite).

‍

Durch die getroffenen Maßnahmen zur Fehlerbehebung wurden weitere Updates gestoppt, Routen wiederhergestellt und Hosts recycelt; alle Services galten am 11. Juni 2025 um 05:50 UTC als vollständig wiederhergestellt.

Zeitlicher Ablauf

Wann begann der Salesforce-Incident?

‍

Die Störung begann am 10. Juni um 06:03 UTC, als automatisiertes Monitoring steigende Login-Fehler und API-Timeouts in mehreren Salesforce-Clouds erkannte. Dies war der offizielle Beginn der Störung.

Wie wurde der Salesforce-Incident erkannt und eskaliert?

‍

Bis 06:47 UTC stellten Techniker fest, dass wichtige interne Response-Tools (einschließlich der Heroku-Statusseite) ebenfalls ausgefallen waren – ein Hinweis darauf, dass das Problem die gesamte Plattform betraf.

‍

Ein bereichsübergreifender War Room wurde um 07:00 UTC eingerichtet. Paketverfolgungen zeigten um 10:24 UTC, dass Container ihre Hosts nicht erreichen konnten – das Problem wurde auf Host-Routing eingegrenzt.

‍

Um 11:54 UTC identifizierten Techniker fehlende Netzwerk-Routen auf betroffenen Hosts, und um 13:42 UTC wurde als Auslöser ein automatisiertes Betriebssystem-Update gefunden, das Netzwerkdienste neu startete, aber Routen nicht neu setzte.

Wann wurde der Salesforce-Incident behoben?

‍

Die Gegenmaßnahmen begannen um 15:03 UTC, als das Update-Token widerrufen und die Host-Images mit deaktivierten Updates neu erstellt wurden. Rolling Restarts zwischen 15:03 UTC und 19:18 UTC reduzierten die Fehler signifikant. Das Heroku Dashboard war ab 21:54 UTC wieder voll funktionsfähig, und ein vollständiger Host-Recycle wurde um 05:50 UTC am 11. Juni abgeschlossen – zu diesem Zeitpunkt galten alle Services als wiederhergestellt.

• TTD: 44 Minuten (06:03 → 06:47 UTC)
• TTR: 23 Stunden 47 Minuten (06:03 UTC 10. Juni → 05:50 UTC 11. Juni)

Wie hat Salesforce auf die Störung reagiert?

Das Technology-Team von Salesforce umfasste Techniker von Heroku, Netzwerktechnik, weiteren Cloud-Gruppen und einem Upstream-Anbieter.

‍

Ihre unmittelbaren Aufgaben bestanden darin, die automatischen Updates zu deaktivieren, fehlende Netzwerkrouten wiederherzustellen, Host-Images neu zu erstellen, das Update-Token zu widerrufen und rollierende Neustarts über alle Hosts hinweg zu koordinieren.

‍

Während die Haupt-Statusseite nicht verfügbar war, wurden Updates über den HerokuStatus-Account auf X veröffentlicht, bis die reguläre Kommunikation wiederhergestellt war.
‍

Wer war vom Salesforce-Serviceausfall betroffen und wie schwer war die Beeinträchtigung?

Am stärksten beeinträchtigt:

• Private-Space-Anwendungen verloren ausgehende Konnektivität – Kundendashboards und Apps waren gestört.
• Ca. 9 % der Postgres-Datenbanken führten automatisierte Failover durch; einige High-Availability-Failover wurden pausiert.

Teilweise betroffen:

• ₁ % der Common-Runtime-Apps hatten Netzwerkprobleme.
• MFA-basierte Logins für Marketing Cloud, MuleSoft, Tableau und Commerce Cloud fielen zeitweise aus.
• Order-Platzierung (OCI/SOM) und Service-Cloud-Messaging verzögerten sich.

Wie kommunizierte Salesforce während des Ausfalls?

Salesforce gab regelmäßige Updates über die Statusseite, solange sie verfügbar war. Danach wechselte das Unternehmen zum HerokuStatus-X-Account und später auf E-Mail-Benachrichtigungen, sobald die Dienste stabilisiert waren. Die Updates waren sachlich und von Entschuldigungen begleitet, sie informierten über Fortschritte und Meilensteine der Wiederherstellung.

Welche Muster zeigte der Salesforce-Serviceausfall?

• Lücken in der Umgebungskontrolle: Produktions-Hosts ließen nicht autorisierte OS-Updates zu.
• Single Point of Failure im Routing: Fehlende Routen führten zum vollständigen Verbindungsverlust für betroffene Hosts.
• Abhängigkeit von geteilter Infrastruktur: Statusseite und E-Mail-System liefen auf der gleichen betroffenen Plattform – dies verzögerte die Kommunikation.
• Hoher manueller Aufwand bei der Wiederherstellung: Fehlende Automatisierung für systemweite Restarts verzögerte die Fehlerbehebung.

Zu den geplanten Maßnahmen gehören strengere Unveränderbarkeit für Host-Images, isolierte Betriebstools, verbesserte Überwachung der Netzwerkroutenintegrität und übergreifende Automatisierung von Korrekturmaßnahmen.

Kurzfassung

Am 10.–11. Juni 2025 entfernte ein automatisiertes OS-Update auf Heroku-Hosts wichtige Netzwerk-Routen und unterbrach mehrere Salesforce-Clouds für fast 24 Stunden. Durch das Deaktivieren der Updates, den Entzug von Tokens und das Recycling der Hosts wurden die Dienste wiederhergestellt – mit dem klaren Learning: striktere Update-Kontrollen, redundante Kommunikationsinfrastruktur und automatisierte Recovery-Tools sind unabdingbar.

‍