IT-Störung

In jeder IT-Landschaft – ob klassisch on-prem, hybrid oder cloudbasiert – ist es nur eine Frage der Zeit, bis ein Major Incident auftritt. Ein Server fällt aus, ein zentraler Dienst ist nicht mehr erreichbar, oder ein Sicherheitsvorfall legt Teile des Betriebs lahm. Entscheidend ist wie professionell damit umgegangen wird.

Was ist ein Major Incident?

Ein Major Incident ist eine schwerwiegende Störung, die den Betrieb eines oder mehrerer geschäftskritischer IT-Services beeinträchtigt.

Die Auswirkungen sind in der Regel:

– Hohe Dringlichkeit
– Große Reichweite (mehrere Nutzer, Systeme oder Standorte betroffen)
– Eskalation bis in das Management

Typische Beispiele:

Exchange-Server nicht erreichbar → kein Mailverkehr möglich
Authentifizierungsdienste fallen aus → niemand kann sich anmelden
Produktionssysteme nicht verfügbar → Geschäftsprozesse stehen still

Praxisbeispiel: Proxmox-Ausfall durch Netzwerkproblem

In einem Unternehmen trat ein schwerwiegender Ausfall innerhalb eines produktiven Proxmox-Clusters auf. Mehrere virtuelle Maschinen waren plötzlich instabil, es kam zu nicht nachvollziehbaren Latenzen und Storage-Fehlern in einem Ceph-Storage-Verbund.

Die ersten Symptome:

– Hohe I/O-Wartezeiten
– sporadische Timeouts im Management-Interface
– Storage-Fehlermeldungen in den Logs

Sofortmaßnahmen:
Um den Betrieb kurzfristig zu stabilisieren, wurde eine gezielte Abschaltung einzelner Switches im Storage-Verbund vorgenommen. Diese Maßnahme führte unmittelbar zu einer Beruhigung der Umgebung – ein starker Hinweis auf eine Netzwerkschleife oder ein STP-/VLT-Problem.

Root Cause Analysis:
Die RCA zeigte: In einem bestimmten VLAN kam es zu einem Loop, vermutlich ausgelöst durch fehlerhafte Spanning-Tree-Konfiguration in Verbindung mit einem Firmware-Bug auf den Dell-Switches. VLANs, die über VLT verbunden waren, verhielten sich unterschiedlich – eine detaillierte Analyse der Trunk-Ports, Firmwarestände und MAC-Adresstabellen brachte schließlich die Ursache ans Licht.

Dauerhafte Maßnahmen:

– Firmware-Update der betroffenen Switches
– Anpassung der STP- und VLT-Konfiguration
– Separierung von Ceph- und VM-Netzwerk zur besseren Fehlereingrenzung in Zukunft
– Ausbau des Monitorings zur frühzeitigen Erkennung von Netzwerkloops

Lernpunkt:
Die schnelle Wiederherstellung war nur möglich, weil das Team sofort handlungsfähig war – doch die nachhaltige Stabilisierung gelang erst durch konsequente Ursachenanalyse und Architekturkorrekturen.

Drei Phasen für den professionellen Umgang mit Major Incidents

Sofortmaßnahmen & Kommunikation

Ziel ist es, den Schaden schnell zu begrenzen und erste Transparenz zu schaffen:

Einschätzung: Was ist betroffen? Wie viele Nutzer?

Workarounds: Gibt es eine temporäre Lösung?

Kommunikation: Frühzeitig, regelmäßig, adressatengerecht (IT, Fachbereich, Management)

Systemstabilisierung & Wiederherstellung

Technische Analyse und temporäre Wiederherstellung

Koordination mit Dienstleistern oder Herstellern

Absicherung des wiederhergestellten Zustands durch Monitoring

Root Cause Analysis & Lessons Learned

Analyse der technischen und organisatorischen Ursachen

Ableitung und Umsetzung nachhaltiger Maßnahmen

Dokumentation und interne Wissenssicherung

Fazit: Geschwindigkeit, Struktur und Nachhaltigkeit

Ein Major Incident ist kein Zeichen von Schwäche – sondern eine Chance, die eigene Krisenfestigkeit zu beweisen. Wer strukturiert, transparent und nachhaltig handelt, schützt nicht nur Systeme, sondern auch das Vertrauen von Kunden, Partnern und Kollegen.

Neugierig geworden?
Ob akute Störung oder strategische IT-Architektur – ich unterstütze Sie zuverlässig und lösungsorientiert.

Jetzt Erstgespräch vereinbaren

Störungen im IT-Betrieb kosten nicht nur Geld – sie untergraben auch das Vertrauen in die IT-Abteilung. Besonders bei wiederkehrenden Incidents entsteht schnell der Eindruck, man habe die Lage nicht im Griff. Doch was, wenn nicht die Symptome, sondern die Ursachen konsequent beseitigt werden? Genau hier setzt die Root Cause Analysis (RCA) an – und wird zum Schlüssel für nachhaltige IT-Stabilität.

Was ist Root Cause Analysis?

Root Cause Analysis (kurz: RCA) ist ein strukturiertes Verfahren zur Ursachenanalyse von Störungen und Problemen im IT-Betrieb. Ziel ist es, nicht nur die sichtbaren Symptome zu beheben, sondern die zugrunde liegenden Ursachen zu identifizieren und dauerhaft zu beseitigen.

RCA geht also über das klassische Incident Management hinaus. Während dort das Ziel die schnelle Wiederherstellung des Betriebs ist, stellt die RCA die Frage:

Warum ist die Störung überhaupt aufgetreten – und wie verhindern wir, dass sie sich wiederholt?

Warum ist RCA für die IT-Stabilität entscheidend?

In komplexen IT-Landschaften – ob On-Premises, hybrid oder in der Cloud – können Störungen viele Ursachen haben: fehlerhafte Konfigurationen, inkompatible Software-Updates, nicht dokumentierte Abhängigkeiten oder schlicht menschliches Versagen.

Ohne eine konsequente Ursachenanalyse passiert Folgendes:

Wiederkehrende Störungen: Der gleiche Fehler tritt in leicht abgewandelter Form erneut auf.

Aktionismus statt Strategie: Es wird „gefixt“, statt verstanden.

Verlorenes Vertrauen: Nutzer:innen empfinden die IT als unzuverlässig.

Mit Root Cause Analysis wird aus Reaktion eine proaktive Strategie. Die Folge: höhere Verfügbarkeit, weniger Incidents und eine resilientere IT.

RCA in der Praxis – So gehe ich vor

Als IT-Architekt und technischer Projektleiter begleite ich Unternehmen regelmäßig dabei, kritische Incidents strukturiert aufzuarbeiten. Ein bewährtes Vorgehen sieht so aus:

Incident isolieren und dokumentieren

Alle verfügbaren Informationen zum Störfall werden gesammelt:

Wann trat der Fehler auf?

Welche Systeme waren betroffen?

Was wurde bereits unternommen?

Symptom vs. Ursache trennen

Ein häufiger Fehler: das Offensichtliche wird vorschnell zur Ursache erklärt. Ich unterscheide daher systematisch zwischen Symptom, Auslöser und Ursache – z. B. durch 5-Why-Technik oder Fault Tree Analysis.

Technische Spuren sichern

Logdaten, Netzwerkverläufe, Systemmetriken – all das ist essenziell, um das Verhalten retrospektiv zu analysieren. Idealerweise automatisiert und zentralisiert (z. B. über ein SIEM-System).

Architektur- und Prozessbezug prüfen

Manche Ursachen liegen nicht im Code, sondern in der Architektur oder in fehlenden Prozessen:

Gibt es Abhängigkeiten zwischen Systemen, die nicht dokumentiert sind?

Fehlt ein Prozess für Change-Tests oder Rollbacks?

Gab es menschliches Versagen – oder lag es an unklaren Verantwortlichkeiten?

Nachhaltige Lösung implementieren

Die Erkenntnisse führen zu konkreten Maßnahmen – von Konfigurationsanpassungen über Prozessoptimierungen bis hin zu Architektur-Entscheidungen. Wichtig: Lessons Learned dokumentieren und teilen.

RCA und moderne IT-Architekturen: Mehr als Fehlersuche

Besonders bei der Verlagerung von On-Prem in Richtung Azure oder M365 ist RCA ein strategisches Werkzeug:

Migrationen absichern: RCA hilft, Risiken früh zu erkennen – und Migrationen robuster zu planen.

Servicequalität erhöhen: Durch RCA werden nicht nur einzelne Fehler, sondern ganze Schwachstellen im Architekturdesign sichtbar.

Resilienz aufbauen: In Cloud-Umgebungen zählt nicht nur Hochverfügbarkeit, sondern auch schnelle Wiederherstellung und Ursachenvermeidung.

Fazit: Root Cause Analysis lohnt sich – technisch und strategisch

RCA ist keine bürokratische Pflichtübung, sondern ein strategisches Werkzeug zur Qualitätssicherung. Wer RCA konsequent einsetzt, senkt nicht nur die Zahl kritischer Incidents, sondern verbessert die Wahrnehmung der IT-Abteilung im Unternehmen – als verlässlicher Partner und Gestalter stabiler Prozesse.

Neugierig geworden?
Ich unterstütze Unternehmen dabei, RCA als festen Bestandteil ihrer IT-Prozesse zu etablieren – ob im akuten Major Incident oder bei der strategischen Architekturentwicklung.