ITIL

ITIL ist das Kochbuch für IT-Abteilungen. Es ist eine Sammlung von "Best Practices" (bewährten Methoden). Es sagt dir nicht, wie man einen Server installiert. Es sagt dir, wie man mit Kunden und Problemen umgeht. Beispiel: "Ein User ruft an: Drucker kaputt." ITIL sagt:

Erstell ein Incident Ticket (Störung).
Löse es schnell (Workaround).
Such später die Ursache (Problem Management), damit es nicht wieder passiert.

Weltweit arbeiten fast alle Konzerne nach ITIL.

Merksatz: Ein Standard-Framework für IT-Service-Management (ITSM), das Prozesse für den Betrieb von IT definiert.

Wichtige Begriffe, die du im Job hören wirst:

Incident: Etwas ist kaputt (Drucker druckt nicht). -> Ziel: Schnell wieder arbeiten können.
Request: Jemand will was neues (Neuer Laptop).
Change: Etwas am Server ändern (Update einspielen). -> Achtung: Gefährlich! Braucht Genehmigung (CAB - Change Advisory Board).

1. CMDB (Configuration Management Database)

Das Herz von ITIL. Eine Datenbank, die alles kennt. "Server A gehört Abteilung B, darauf läuft Software C, und wenn er ausfällt, kann Frau Müller nicht arbeiten." Ohne CMDB weißt du bei einem Ausfall nicht, wen du anrufen musst.

2. SLA (Service Level Agreement)

Der Vertrag zwischen IT und Kunden. "Wir garantieren, dass Prio-1-Probleme in 4 Stunden gelöst sind." ITIL hilft, diese Versprechen zu messen und einzuhalten.

1. ITIL 4 Service Value System (SVS)

Die klassischen Versionen (ITIL v3) waren stark auf den sturen Prozess-Lifecycle (Strategy -> Design -> Transition -> Operation) fokussiert. Das war im Cloud-Zeitalter völlig unbrauchbar. ITIL 4 wirft die Stagnation über Bord und führt das Service Value System ein. Die 34 Management Practices (früher: Prozesse) werden über die Service Value Chain (Plan -> Improve -> Engage -> Design/Transition -> Obtain/Build -> Deliver/Support) orchestriert. Der entscheidende Bruch: Value (Wert) wird gemeinsam mit dem Kunden co-kreiert, nicht mehr nur stur als "Produkt" abgeliefert.

2. Incident vs. Problem Management

In der ITIL Operation-Phase gibt es einen fundamentalen Unterschied, den Juniors oft vermischen:

Incident Management: Der Server brennt. Die Aufgabe ist nicht, das Feuer zu analysieren, sondern es zu löschen (Restoration of Service). Notfalls bootest du den Server stumm neu.
Problem Management: Das Feuer ist aus, der Use arbeitet wieder. Jetzt öffnest du das Problem-Ticket (Root Cause Analysis). Warum brannte er? Du durchforstest Logs nach Memory-Leaks. Dieser methodische Split rettet Millionen: Ein Admin, der während der Ausfallzeit 5 Stunden lang Logs liest ("Ich muss erst den Fehler finden"), zerstört SLA-Zeiten und blockiert das Business.

3. Change Enablement (CAB-Wahnsinn)

Jede größere Modifikation an der Produktionsumgebung muss per RFC (Request for Change) durch das Change Advisory Board (CAB). In klassischen Großkonzernen treffen sich hier Freitags 20 Abteilungsleiter, was den Deployment-Zyklus auf monströse 3 Wochen verzögert. Moderne ITIL-DevOps-Synergien nutzen "Standard Changes". Ein Jenkins-Build, der 1000 Unit-Tests besteht, gilt als hochgradig pre-approved. Das CAB agiert nur noch retrospektiv (Audit) für das Risiko-Setup oder genehmigt nur noch riskante "Normal Changes" (wie die Kern-Migration einer Oracle Datenbank).