Nachbetrachtung: Vorfallbericht (Ausfall am 8. Mai 2026)

Am 8. Mai 2026 kam es bei ECSO CLOUD zur ersten größeren Betriebsstörung 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 ergriffen wurden, um künftige Vorfälle zu verhindern.

Systemübersicht

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

8. Mai 2026: Feststellung des Vorfalls und erste Reaktion

10:58 – 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 offizielles 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 eingeleitet. 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 Uhr – 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 Aktualisierungsprozess schlug aufgrund des DNS-Ausfalls während der Ausführung fehl, was dazu führte, dass das System versuchte, sich mit einer inkompatiblen Kernel-Version selbst zu korrigieren.
16:13 Uhr – Alle Kunden mit aktiven Notfallwiederherstellungsplänen wurden erfolgreich auf alternative Host-Systeme migriert, wodurch ihre Dienste wiederhergestellt wurden.

9. Mai 2026: Wiederherstellung und Fehlerbehebung

01:51 – Die technischen Teams haben die Kernel-Version erfolgreich zurückgesetzt und veraltete 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. Auf der Speicherebene wurden jedoch Inkonsistenzen auf Bit-Ebene festgestellt, die wahrscheinlich durch den abrupten Systemstillstand in Verbindung mit inkompatiblen Treibern verursacht wurden. Diese wurden nach einer vollständigen Systemsicherung behoben.

10. Mai 2026: Endgültige Lösung

15:42 Uhr – 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 Uhr – 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, mit denen ähnliche Ausfälle sofort erkannt werden können.
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 derzeit unsere Richtlinien zur Kommunikation bei Vorfällen, um sicherzustellen, dass Kunden unabhängig vom Untersuchungsaufwand in Echtzeit auf dem Laufenden gehalten werden.

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