Denken in Services und ITIL-Grundbegriffe

Worum es geht

Samstag, 09:15 Uhr. Bei der Sportxpress AG in Dietikon ist im IT-Büro niemand, das Monitoring zeigt alles grün: Beide Webserver antworten auf Ping, die Datenbank läuft, die CPU-Last ist tief. Trotzdem schreiben auf Instagram innert einer halben Stunde zwölf Kundinnen und Kunden: «Euer Shop zeigt nur noch eine Fehlerseite.» Die IT erfährt davon erst, als die Leiterin E-Commerce um 09:50 Uhr anruft.

Was ist hier schiefgelaufen? Die Server waren in Ordnung. Kaputt war der Service: Niemand konnte einkaufen. Das IT-Team hat Geräte überwacht, die Kundschaft hat aber einen Dienst benutzt.

Ramon, Lernender im 2. Lehrjahr als Informatiker Plattformentwicklung, bekommt von seinem Berufsbildner Marco Steiner den Auftrag, den Betrieb des Webshops «planbar» zu machen. Der erste Schritt dazu ist ein Perspektivenwechsel: weg vom Server, hin zum Service. In dieser Lektion lernst du,

• was ein Service ist und woraus er besteht,
• die wichtigsten ITIL-Begriffe (Incident, Service Request, Problem, Change, Event) sicher zu unterscheiden,
• einen Service in einem Servicekatalog so zu beschreiben, dass alle dasselbe darunter verstehen.

Diese Begriffe brauchst du in jeder weiteren Lektion, im Lehrbetrieb und im Kompetenznachweis.

Was ist ein Service?

Stell dir ein Restaurant vor. Als Gast bestellst du ein Menü. Dich interessiert, dass das Essen warm und in vernünftiger Zeit kommt, und zwar während der Öffnungszeiten. Die Küche, das Kühlhaus, der Gemüselieferant und die Spülmaschine sind für dich unsichtbar. Fällt aber das Kühlhaus aus und es gibt nichts zu essen, dann sagst du nicht «das Kühlhaus ist defekt», sondern «das Restaurant funktioniert nicht».

Genau so ist es in der IT. Ein Service ist das, was die Anwender:innen nutzen, um ihre Arbeit oder ihr Ziel zu erreichen: einkaufen, Patientendaten erfassen, Mails versenden. Dahinter stecken viele technische Bausteine, die einzeln niemanden interessieren, solange das Ganze funktioniert.

ITIL beschreibt den Wert eines Services mit zwei Seiten:

Ein Service ohne Nutzen ist sinnlos. Ein Service ohne Gewährleistung ist unbrauchbar: Ein Shop, der jeden Abend abstürzt, hat zwar alle Funktionen, aber niemand verlässt sich darauf.

Die Bausteine: Configuration Items

Die technischen Bausteine eines Services heissen in ITIL Configuration Items (CIs). Dazu gehören Server, VMs, Datenbanken, Netzwerkgeräte, Software, Zertifikate, aber auch externe Leistungen wie ein Zahlungsanbieter. Ramon zeichnet den Webshop so auf, wie eine Bestellung ihn durchläuft:

Fällt ein einzelner Webserver aus, läuft der Shop weiter, denn der Load Balancer schickt die Anfragen zum anderen. Fällt die Datenbank oder der Zahlungsanbieter aus, steht der ganze Service. Diese Unterscheidung wird in Lektion 2 wichtig, wenn du Verfügbarkeiten berechnest.

ITIL in zehn Minuten

ITIL ist eine international verbreitete Sammlung bewährter Praktiken für das IT-Service-Management. Es ist kein Gesetz und keine Software, sondern eine gemeinsame Sprache und ein Baukasten von Abläufen, den jeder Betrieb an seine Grösse anpasst. Ein KMU mit drei Leuten in der IT braucht keine zwanzig Gremien, aber die Grundbegriffe helfen auch dort enorm.

Für den Betrieb sind fünf Begriffe zentral. Du wirst sie jeden Tag hören:

Zwei Feinheiten, die oft falsch gemacht werden:

1. Incident heisst nicht nur Totalausfall. Auch eine Qualitätsminderung ist ein Incident: Der Shop lädt 20 Sekunden pro Seite, Mails kommen mit einer Stunde Verspätung an.
2. Nicht jedes Event ist ein Incident. Eine Platte bei 80 Prozent ist ein Event, vielleicht eine Warnung. Ein Incident wird es erst, wenn der Service beeinträchtigt ist oder unmittelbar beeinträchtigt wird.

So hängen die Begriffe zusammen:

Ein Known Error ist ein Problem, dessen Ursache analysiert ist, das aber noch nicht dauerhaft behoben wurde. Meist gibt es dafür einen Workaround, also eine Umgehungslösung, die den Service vorübergehend wiederherstellt. Mehr dazu in Lektion 6.

Der Servicekatalog

Damit alle vom Gleichen reden, beschreibt die IT ihre Services in einem Servicekatalog. Das ist eine Liste aller Services, die die IT anbietet, mit den wichtigsten Angaben pro Service. Er kann ein Wiki, ein Kapitel im Betriebshandbuch oder ein Modul im Ticketsystem sein. Entscheidend ist der Inhalt.

Ein guter Katalogeintrag beantwortet diese Fragen:

Schritt für Schritt: Katalogeintrag für den Webshop

Ramon setzt sich mit Lea Brunner, der Leiterin E-Commerce, zusammen. So geht er vor:

Schritt 1: Nutzen aus Sicht der Benutzer:innen formulieren. Nicht «Webanwendung auf zwei VMs», sondern: «Kundinnen und Kunden suchen, bestellen und bezahlen Sportartikel online. Der Kundendienst sieht Bestellungen und Lieferstatus.»

Schritt 2: Benutzergruppen bestimmen. Externe Kundschaft (rund 4000 Bestellungen pro Woche), Kundendienst (12 Personen), Lager (Kommissionierung über die Schnittstelle), Marketing (Aktionen pflegen).

Schritt 3: Komponenten vom Benutzer her aufzählen. Ramon folgt einer Bestellung durch das System, wie im Diagramm oben: DNS, Internetanschluss und Firewall, Load Balancer, web01 und web02, Datenbank db01, Zahlungsanbieter, Lagerschnittstelle, TLS-Zertifikat. So vergisst er keine externen Teile.

Schritt 4: Servicezeit festlegen. Lea Brunner sagt zuerst: «Der Shop muss immer laufen.» Ramon fragt nach: «Wann bestellen eure Kundinnen und Kunden tatsächlich, und ab wann wäre ein Ausfall teuer?» Ergebnis: Servicezeit 06 bis 23 Uhr, 7 Tage. Nachts läuft der Shop zwar weiter, Ausfälle zählen aber nicht gegen das Ziel.

Schritt 5: Verfügbarkeitsziel und Reaktionszeit vereinbaren. 99.5 Prozent pro Monat innerhalb der Servicezeit. Bei einem Totalausfall reagiert die IT innert 15 Minuten. Wie man das in Minuten umrechnet, lernst du in Lektion 2.

Schritt 6: Verantwortung klären. Service Owner ist Lea Brunner (sie entscheidet über Anforderungen), technisch verantwortlich ist das Plattform-Team mit Marco Steiner.

Schritt 7: Wartung regeln. Geplante Arbeiten dienstags von 05:00 bis 06:30 Uhr, Ankündigung drei Arbeitstage vorher.

Das Ergebnis im Katalog:

Jetzt bist du dran: Bring Python bei, einen Katalogeintrag auf Vollständigkeit zu prüfen. Genau so eine Prüfung bauen viele Betriebe in ihr Wiki oder Ticketsystem ein.

Typische Fehler

• Service mit Server verwechseln. «Der Service ist web01» ist falsch. web01 ist ein CI. Der Service ist «Webshop», und web01 ist einer von mehreren Bausteinen. Wer so denkt, überwacht nur Geräte und merkt Ausfälle zu spät.
• Service Requests als Incidents erfassen. Passwort-Resets, neue Zugänge oder Softwarewünsche sind Requests. Werden sie als Störungen erfasst, sieht jeder Bericht schlechter aus, als der Betrieb wirklich ist.
• Externe Komponenten vergessen. Zahlungsanbieter, DNS-Provider, Cloud-Dienste und Zertifikate fallen auch aus. Gehören sie nicht in die Komponentenliste, sucht im Störungsfall niemand dort.
• «Immer» als Servicezeit akzeptieren. «Immer» ist teuer und meistens gar nicht gemeint. Frag nach, wann der Service wirklich gebraucht wird und was ein Ausfall zu welcher Zeit kostet.
• Katalog einmal schreiben und vergessen. Kommt ein dritter Webserver dazu oder wechselt der Zahlungsanbieter, muss der Eintrag nachgeführt werden. Lege fest, wer ihn mindestens einmal pro Jahr prüft.

Zusammenfassung

• Ein Service ist, was Anwender:innen nutzen. Sein Wert besteht aus Nutzen und Gewährleistung.
• Hinter jedem Service stehen Configuration Items: Server, Software, Netzwerk, Zertifikate und externe Leistungen.
• Incident = ungeplante Unterbrechung oder Qualitätsminderung. Service Request = vereinbarte Leistung auf Anfrage. Problem = Ursache von Incidents. Change = Änderung mit Wirkung auf einen Service. Event = relevante Zustandsänderung.
• Ein Known Error ist ein analysiertes, noch nicht behobenes Problem, meist mit Workaround.
• Der Servicekatalog beschreibt jeden Service mit Nutzen, Benutzergruppen, Komponenten, Servicezeit, Verfügbarkeitsziel, Reaktionszeit, Verantwortlichen und Wartungsfenster.
• Servicezeit und Ziele handelst du mit dem Fachbereich aus, nicht allein in der IT.