Nachbetrachtung: Vorfallbericht (Ausfall am 8. Mai 2026)

Am 8. Mai 2026 kam es bei ECSO CLOUD zur ersten größeren Dienstunterbrechung des Jahres. Das betroffene Host-System „col1-compute-amd-101“ erlitt einen kritischen Ausfall, der sich auf mehrere Cloud-Server der Generation 1 auswirkte. Dieser Bericht enthält eine detaillierte technische Analyse des Vorfalls, unserer Reaktion darauf sowie der Maßnahmen, die zur Verhinderung künftiger Vorfälle ergriffen wurden.

Systemübersicht

Host 101 ist eine unserer Rechenressourcen mit Standort in Köln. Er ist mit einer AMD-CPU, 512 GB RAM und 8 TB NVMe-Speicher ausgestattet. Zum Zeitpunkt des Vorfalls hostete das System über 50 aktive Kundenumgebungen.

8. Mai 2026: Feststellung des Vorfalls & erste Reaktion

10:58 Uhr – Kundeninstanzen auf Host 101 waren nicht mehr erreichbar. Die anfängliche Überwachung löste keinen Alarm aus, da die primäre IP-Adresse des Hosts weiterhin reagierte und die Ressourcenzuweisung normal erschien.
13:11 – Die erste manuelle Meldung ging über einen Key Account Manager ein. Dem Kunden wurde empfohlen, ein formelles Ticket zu eröffnen, um eine technische Untersuchung einzuleiten.
13:42 – Ein zweites formelles Ticket ging ein, das ein umfassenderes Problem bestätigte.
13:46 – Der 1st Level Support schloss die erste Diagnose ab. Nachdem der Aufbau einer NoVNC-Verbindung fehlgeschlagen war, wurde der Fall an den 2nd Level Support eskaliert.
14:52 – Der 2nd Level Support identifizierte einen tiefgreifenden Systemfehler. Nachdem der SSH-Zugriff fehlgeschlagen war, wurde ein Hard-Reboot initiiert. Das System blieb jedoch beim Grub-Bootloader hängen.
15:02 – Der 3rd Level Support wurde für eine Untersuchung vor Ort mobilisiert.
15:21 – Grundursache identifiziert: Ein kritischer Kernel-Konflikt (v6.12.63 Debian) verhinderte, dass der RAID-Controller die NVMe-Laufwerke erkannte. Auslöser war eine vorherige Störung bei DE-NIC (der .de-Registrierungsstelle). Ein automatisierter Update-Prozess brach aufgrund des DNS-Ausfalls während der Ausführung ab, was dazu führte, dass das System versuchte, sich mit einer inkompatiblen Kernel-Version selbst zu korrigieren.
16:13 – Alle Kunden mit aktiven Disaster-Recovery-Plänen wurden erfolgreich auf alternative Host-Systeme migriert, wodurch ihre Dienste wiederhergestellt wurden.

9. Mai 2026: Wiederherstellung & Fehlerbehebung

01:51 – Die technischen Teams haben die Kernel-Version erfolgreich zurückgesetzt und alte Artefakte bereinigt. Das System startete zwar, es konnte jedoch keine Netzwerkverbindung hergestellt werden. Nach sechs Stunden intensiver Arbeit legte das Team eine geplante Pause ein.
14:53 – Der 3rd-Level-Support nahm die Fehlerbehebung am Netzwerkstack wieder auf.
23:28 – Eine umfassende Hardware-Prüfung (CPU und RAM) ergab keine Fehler. Allerdings wurden auf der Speicherebene Inkonsistenzen auf Bit-Ebene festgestellt, die wahrscheinlich durch den abrupten Systemstillstand in Kombination mit inkompatiblen Treibern verursacht wurden. Diese wurden nach einer vollständigen Systemsicherung behoben.

10. Mai 2026: Endgültige Lösung

15:42 – Der IT-Leiter identifizierte den letzten Engpass: Eine fehlerhafte Bridge-Konfiguration in der OSV-Datenbank führte dazu, dass das System während der systemd-Startsequenz hängen blieb. Nach dem Löschen und der Neuinitialisierung der Bridges wurden der RAID-Speicher und die Partitionen als fehlerfrei bestätigt.
16:19 – Endgültige Freigabe: Interne Tests bestätigten die vollständige Stabilität. Der offizielle Status wurde um 16:23 Uhr auf „Behoben“ aktualisiert.

Erkenntnisse und zukünftige Prävention

Dieser Vorfall hat mehrere Schwachstellen in unserer aktuellen Infrastruktur und unseren internen Arbeitsabläufen aufgezeigt:

1. Lücken in der Überwachung: Unsere bisherige Überwachung konzentrierte sich auf die Verfügbarkeit der Hosts und nicht auf den Zustand auf Gast-Ebene. Wir haben Netdata nun vollständig in alle Dienste integriert, um detaillierte Echtzeit-Einblicke zu erhalten, die ähnliche Ausfälle sofort erkennen.
2. Interne Koordination: Der Übergang zwischen dem 2. und 3. Support-Level zeigte, dass bessere Diagnoseprotokolle erforderlich sind. Künftig werden wir der Ursachenanalyse Vorrang vor sofortigen „Trial-and-Error“-Wiederherstellungsversuchen einräumen.
3. Kommunikation: Wir erkennen an, dass unsere Kommunikation während dieses Zeitraums unzureichend war. Statusaktualisierungen verzögerten sich, da sich die Mitarbeiter vollständig auf die technische Untersuchung konzentrierten. Wir überarbeiten unsere Richtlinien zur Kommunikation bei Vorfällen, um sicherzustellen, dass Kunden in Echtzeit auf dem Laufenden gehalten werden, unabhängig vom Arbeitsaufwand der Untersuchung.

Wir entschuldigen uns aufrichtig für die Beeinträchtigungen und sind entschlossen, diese Erfahrung zu nutzen, um eine widerstandsfähigere ECSO CLOUD aufzubauen.