Direkt zum Hauptbereich

Generischer Troubleshooting-Prozess in drei Schritten


Das ITIL-Standardwerk zur Lifcecycle-Phase Service Operation beschreibt für den Prozess Incident Managment in einem klaren Flussdiagramm die einzelnen Prozessschritte. In diesem Artikel stelle ich ergänzend einen generischen Troubleshooting-Prozess in drei Schritten vor.

Gefunden habe ich den generischen Prozess in dem Buch CCENT/CCNA ICND1 100-105 Official Cert Guide, das ich zur Vorbereitung auf die CCENT-Zertigizierungsprüfung gerade durcharbeite.

Das sind die drei Schritte des Troubleshooting-Prozesses:

  1. Problem isolieren und dokumentieren.
    • Das, was man über ein mögliches Problem weiß, sammeln. 
    • Bestätigen, dass tatsächlich ein Problem existiert.
    • Ermitteln, welche Komponenten Teil des Problems sein könnten und welche nicht.
    • Ergebnisse dokumentieren, z. B. in einem Ticket-System.
  2. Problem lösen oder eskalieren.
    • Zugrunde liegende Ursache des Problems (Root Cause) finden und beheben.
    • Falls dies nicht möglich ist, das Problem eskalieren (hierarchisch oder funktional).
  3. Verifizieren oder beobachten.
    Prüfen, ob das Problem tatsächlich gelöst ist, gegebenenfalls über die Zeit beobachten.


Ich finde, das ist ein gutes 'Skelett', an das man dann im Bedarfsfall noch 'Fleisch', zum Beispiel in Form von Fault Tree Analysis, Ishikawa-Diagrammen, Pareto-Analyse, Five Whys, Technical Observation Post, dem PDCA-Zyklus, etc. ergänzen muss. 



#Incident Management, #Problem Management

Kommentare