Services betreiben, warten und überwachen

Ein Dienst ist erst dann fertig, wenn er im Alltag zuverlässig läuft. In diesem Modul lernst du, was einen Service ausmacht und wie man vereinbart, was er leisten muss. Du richtest ein Monitoring mit sinnvollen Schwellwerten ein, behandelst Störungen nach einem klaren Ablauf und unterscheidest zwischen schneller Behebung und Ursachenanalyse. Wartungsarbeiten planst du als kontrollierte Änderungen, und mit Kennzahlen und Betriebsdokumentation zeigst du, wie gut der Service wirklich läuft.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Einen Service beschreiben und Servicelevels festlegen

   Kompetenz A

   Du beschreibst, was ein Dienst für die Anwender:innen leistet, welche Komponenten dahinterstecken und wann er verfügbar sein muss. Mit dem Auftraggeber vereinbarst du messbare Werte wie Verfügbarkeit, Reaktionszeit und Supportzeiten.

   Situation

   Die IT eines Alters- und Pflegeheims betreibt die Pflegedokumentation. Bei Ausfällen ist unklar, wie schnell reagiert werden muss.

   Deine Aufgabe

   Erstelle eine Servicebeschreibung mit Servicelevels.

   Gutes Ergebnis

   Service 'Pflegedokumentation': Webanwendung auf 2 VMs, SQL-Datenbank, Zugriff über Tablets im WLAN. Betriebszeit 24/7, Verfügbarkeit 99.5 Prozent pro Monat (max. ca. 3.6 Std. Ausfall), Reaktion bei Priorität 1 innert 15 Minuten, auch nachts über Pikett.

   ServiceSLAVerfügbarkeitReaktionszeitServicekatalog
2. 2

   Ein Monitoring mit sinnvollen Sensoren und Schwellwerten einrichten

   Kompetenz B

   Du überwachst nicht nur, ob ein Server antwortet, sondern ob der Dienst für die Benutzer:innen funktioniert. Schwellwerte setzt du so, dass Probleme früh auffallen, ohne dass das Team in Fehlalarmen untergeht.

   Situation

   Ein KMU mit 3 Servern und 2 Switches hat kein Monitoring. Letzte Woche lief die Systemplatte des Fileservers voll und niemand konnte mehr speichern.

   Deine Aufgabe

   Richte ein Monitoring für die wichtigsten Dienste ein.

   Gutes Ergebnis

   PRTG mit Sensoren für Ping, CPU, RAM, Plattenplatz (Warnung bei 80, Fehler bei 90 Prozent), Dienststatus (DNS, SMB), HTTPS-Check der Webanwendung, Ablauf des TLS-Zertifikats (Warnung 30 Tage vorher), Switch-Ports per SNMP. Alarm per Mail und Teams, Wiederholung nach 15 Minuten.

   Sensor / CheckSchwellwertSNMPEnd-to-End-CheckAlarmierung
3. 3

   Störungen priorisieren, beheben und sauber dokumentieren

   Kompetenz C

   Du nimmst Störungen strukturiert auf, bestimmst die Priorität aus Auswirkung und Dringlichkeit und arbeitest sie zielgerichtet ab. Ziel ist, den Service so schnell wie möglich wiederherzustellen, und alles Wichtige im Ticket festzuhalten.

   Situation

   Montag 07:40 melden drei Personen aus der Finanzabteilung einer Gemeinde, dass das Steuerprogramm nicht startet. Andere Abteilungen sind nicht betroffen.

   Deine Aufgabe

   Bearbeite die Störung nach einem sauberen Ablauf.

   Gutes Ergebnis

   Ticket als P2 (eine Abteilung, Arbeit blockiert). Prüfung: Applikationsserver läuft, Lizenzdienst gestoppt nach Windows-Update in der Nacht. Dienst neu gestartet, Funktion mit Anwenderin geprüft, Dauer 25 Minuten. Ticket mit Ursache, Lösung und Verweis auf ein Problem-Ticket abgeschlossen.

   IncidentPriorität = Auswirkung x DringlichkeitWorkaroundEskalationTicket-Dokumentation
4. 4

   Wiederkehrende Störungen auf ihre Ursache zurückführen

   Kompetenz D

   Wenn derselbe Fehler immer wieder auftritt, reicht Neustarten nicht. Du sammelst Daten aus Logs und Monitoring, analysierst die Ursache mit einer Methode wie 5 Why und leitest eine dauerhafte Lösung ab.

   Situation

   Der Lizenzdienst des Steuerprogramms ist im letzten Quartal viermal nach einem Patchday ausgefallen.

   Deine Aufgabe

   Finde die Ursache und schlage eine dauerhafte Lösung vor.

   Gutes Ergebnis

   Analyse der Ereignisanzeige: Der Dienst startet vor dem Netzwerk und scheitert. 5 Why führt zu Starttyp 'Automatisch' ohne Verzögerung. Lösung: Starttyp 'Automatisch (verzögert)' plus Wiederherstellungsoption 'Dienst neu starten'. Known Error dokumentiert, seither kein Ausfall.

   Problem ManagementRoot Cause Analysis5 WhyKnown ErrorLogauswertung
5. 5

   Wartungen und Änderungen kontrolliert planen und durchführen

   Kompetenz E

   Updates, Konfigurationsänderungen und Hardwaretausch sind Changes. Du beschreibst sie mit Risiko, Ablauf, Test und Rückweg, holst die Freigabe ein, informierst Betroffene und führst sie im vereinbarten Wartungsfenster durch.

   Situation

   Die Firmware der beiden Core-Switches in einem Spital muss wegen einer Sicherheitslücke aktualisiert werden.

   Deine Aufgabe

   Plane den Change so, dass der Betrieb möglichst wenig gestört wird.

   Gutes Ergebnis

   Change-Antrag mit Risiko 'mittel', Wartungsfenster Dienstag 23:00 bis 01:00, Switch A zuerst, Test, dann Switch B. Rückweg: alte Firmware-Partition booten. Info an Pflege-Nachtdienst 3 Tage vorher. Monitoring für die Zeit in den Wartungsmodus gesetzt. Abschluss mit kurzem Bericht.

   ChangeChange-AntragWartungsfensterRückwegStandard-Change
6. 6

   Betrieb mit Kennzahlen belegen und mit Runbooks dokumentieren

   Kompetenz F

   Du misst, wie gut ein Service läuft, etwa Verfügbarkeit, Anzahl Störungen oder Lösungszeit, und berichtest regelmässig. Für wiederkehrende Aufgaben und häufige Alarme schreibst du Runbooks, mit denen auch Kolleg:innen sicher arbeiten können.

   Situation

   Die Heimleitung fragt, ob sich die Pflegedokumentation im letzten halben Jahr verbessert hat.

   Deine Aufgabe

   Erstelle einen Monatsbericht und Runbooks für die häufigsten Alarme.

   Gutes Ergebnis

   Bericht: Verfügbarkeit 99.78 Prozent im 30-Tage-Monat (2 Störungen P1 mit zusammen 96 Minuten Ausfall), mittlere Lösungszeit 48 Min., SLA eingehalten. Runbooks für 'Datenbank-Platte über 90 Prozent', 'Webdienst antwortet nicht' und 'Zertifikat läuft ab', jeweils mit Prüfschritten, Befehlen und Eskalationskontakt.

   KPIMTTRVerfügbarkeitsberechnungRunbookBetriebshandbuch

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Ramon ist im 2. Lehrjahr als Informatiker Plattformentwicklung bei der Sportxpress AG in Dietikon, einem Online-Händler mit 90 Mitarbeitenden. Ausfälle des Webshops bemerkt das IT-Team bisher meistens erst, wenn sich Kundinnen und Kunden in den sozialen Medien beschweren. Ramon soll mit seinem Berufsbildner den Betrieb des Webshops planbar machen.

1. Kapitel 1

   Was ist eigentlich unser Service?

   Ramon zeichnet auf, woraus der Service Webshop besteht: zwei Webserver, eine Datenbank, der Zahlungsanbieter und eine Schnittstelle zum Lager. Mit der Leiterin E-Commerce vereinbart er eine Verfügbarkeit von 99.5 Prozent pro Monat in der Zeit von 6 bis 23 Uhr. Bei einem Totalausfall muss die IT innerhalb von 15 Minuten reagieren. Das alles hält er als Eintrag im Servicekatalog fest.

   Ziel 1

2. Kapitel 2

   Sensoren mit Sinn

   In Zabbix überwacht Ramon nicht nur CPU, RAM und Disks, sondern prüft alle 5 Minuten mit einem Testeinkauf, ob man bis zur Zahlungsseite kommt. In der ersten Woche gibt es 140 Alarme, fast alle wegen kurzer CPU-Spitzen. Ramon ändert den Schwellwert auf 90 Prozent während 10 Minuten. Echte Ausfälle melden sich jetzt per Teams und SMS, Warnungen nur noch im Dashboard.

   Ziel 2

3. Kapitel 3

   Freitag, 19.40 Uhr, der Checkout hängt

   Der Testeinkauf wird rot, und im Vorverkauf zum Black Friday kann niemand mehr bezahlen. Ramon eröffnet ein Ticket mit Priorität 1, informiert den Kundendienst und startet als Workaround den PHP-Dienst neu. Nach 22 Minuten läuft der Shop wieder. Den ganzen Ablauf mit Uhrzeiten hält er im Ticket fest.

   Ziel 3

4. Kapitel 4

   Dreimal ist kein Zufall

   Innerhalb von zwei Wochen hängt der Checkout dreimal, immer kurz nach 19.30 Uhr. In Graylog findet Ramon, dass dann alle PHP-Prozesse belegt sind, und zwar genau, wenn ein Export der Produktbilder startet. Mit der 5-Why-Methode kommt er zum Kern: Ein Kollege hatte den Export auf den Abend verschoben, ohne die Last zu prüfen. Ramon dokumentiert das als Known Error mit dem Neustart als Workaround.

   Ziel 4

5. Kapitel 5

   Geplant statt geflickt

   Ramon schreibt einen Change-Antrag: Der Export läuft neu um 2 Uhr, und die Zahl der PHP-Prozesse steigt nach einer Speicherprüfung von 20 auf 40. Umgesetzt wird am Dienstag um 6 Uhr, mit dokumentiertem Rückweg. Im Monatsbericht zeigt er danach eine Verfügbarkeit von 99.82 Prozent, und die mittlere Behebungszeit ist von 48 auf 19 Minuten gesunken. Für den Pikettdienst schreibt er ein Runbook mit sechs Schritten für den Fall, dass der Checkout hängt.

   Ziel 5Ziel 6

1. 1

   Denken in Services

   ca. 3 Std.

   Du lernst, IT nicht als Sammlung von Servern, sondern als Dienste für Menschen zu sehen.

   • Drei Services deines Lehrbetriebs beschreiben: Nutzen, Benutzergruppen, Komponenten, Betriebszeiten
   • Verfügbarkeiten umrechnen: Wie viele Minuten Ausfall pro Monat erlauben 99, 99.5 und 99.9 Prozent?
   • Ein einfaches SLA für einen Service entwerfen

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Monitoring im Heimlabor

   ca. 5 Std.

   Du installierst ein Monitoring-System und überwachst deine Labor-VMs. PRTG ist bis 100 Sensoren kostenlos, Zabbix und Checkmk Raw sind Open Source.

   • Zabbix oder Checkmk in einem Container oder einer VM installieren
   • Einen Windows- und einen Linux-Server mit Agent einbinden, dazu einen HTTPS-Check auf einen Webdienst
   • Schwellwerte festlegen, Platte künstlich füllen und prüfen, ob der Alarm kommt

   Trainiert Kompetenz B1B2

   Lernziel2

3. 3

   Störungen bearbeiten

   ca. 4 Std.

   Du übst den Ablauf einer Störungsbearbeitung mit einem Ticketsystem.

   • Zammad oder ein anderes Ticketsystem im Labor aufsetzen und Prioritäten definieren
   • Fünf realistische Störungen als Tickets erfassen, priorisieren und lösen
   • Gute und schlechte Ticketeinträge vergleichen: Was braucht die nächste Person?

   Trainiert Kompetenz C1C2

   Lernziel3

4. 4

   Logs lesen und Ursachen finden

   ca. 4 Std.

   Du sammelst Logs zentral und übst, aus wiederkehrenden Fehlern die Ursache herauszuarbeiten.

   • Syslog von Linux und Windows-Ereignisse an Graylog oder einen rsyslog-Server weiterleiten
   • Einen Fehler provozieren (z.B. Dienst startet zu früh) und anhand der Logs analysieren
   • Eine 5-Why-Analyse schriftlich festhalten

   Trainiert Kompetenz D1D2

   Lernziel4

5. 5

   Changes und Wartung

   ca. 3 Std.

   Du planst Wartungsarbeiten so, wie sie im Betrieb ablaufen sollten.

   • Change-Antrag für ein Update deiner Labor-VMs schreiben (Risiko, Ablauf, Test, Rückweg)
   • Wartungsmodus im Monitoring setzen, Update durchführen, Ergebnis dokumentieren
   • Eine Info-Mail an Benutzer:innen für ein Wartungsfenster verfassen

   Trainiert Kompetenz E1E2

   Lernziel5

6. 6

   Berichten und dokumentieren

   ca. 4 Std.

   Du machst die Qualität des Betriebs sichtbar und sicherst Wissen für das Team.

   • Monatsbericht mit Verfügbarkeit, Anzahl Störungen und Lösungszeit aus deinem Labor erstellen
   • Zwei Runbooks für häufige Alarme schreiben und von jemand anderem testen lassen
   • Ein Dashboard in Grafana oder PRTG für die Leitung bauen

   Trainiert Kompetenz F1F2A3

   Lernziel61

ITIL

Sammlung bewährter Praktiken für das IT-Service-Management, international verbreitet.

SLA

Service Level Agreement: Vereinbarung über Qualität und Umfang eines Services, z.B. Verfügbarkeit und Reaktionszeit.

Incident

Ungeplante Unterbrechung oder Qualitätsminderung eines Services.

Problem

Ursache einer oder mehrerer Störungen, die noch nicht bekannt oder behoben ist.

Change

Hinzufügen, Ändern oder Entfernen von etwas, das einen Service beeinflussen kann.

Runbook

Schritt-für-Schritt-Anleitung für eine wiederkehrende Betriebsaufgabe oder einen bestimmten Alarm.

SNMP

Protokoll, mit dem Monitoring-Systeme Zustandsdaten von Netzwerkgeräten und Servern abfragen.

Wartungsfenster

Vereinbarter Zeitraum, in dem geplante Arbeiten mit möglichen Unterbrüchen stattfinden dürfen.

Passende Module