FachgrundlageSprint 6fachsystematische Phase⏱ 4 h
Hier bekommst du die Begriffe und Verfahren, mit denen ein IT-Dienstleister einen Betrieb führt: Services mit SLA, Störungen im Ticketsystem, Überwachung, Aktualisierung und Change-Management.
Sprint 6 · InputBrückenstufe 4
Eure Story: Ihr überwacht den Betrieb, bearbeitet Störungen über einen Helpdesk und führt Updates mit Sicherung und Rückweg durch, bis die Leitung Schulung übernimmt.
Input für eure Storycard. Holt euch die Karte, die eure Storycard gerade braucht. Grundlage für AB 1 bis 8.
Du liest die Abschnitte, ordnest die Begriffe dem Schulungszentrum zu und beantwortest die Prüffragen. Vertiefungen klappst du auf, wenn du sie brauchst.
0 von 8 AB abgehakt AB-Liste öffnen
Der wichtigste Satz auf dieser Seite: Ein Incident wird behoben, ein Problem wird verstanden, ein Change wird geplant. Wer das verwechselt, repariert dieselbe Störung jede Woche neu.
IT-Service-Management und ITIL 4
IT-Service-Management (ITSM) heißt: IT wird als Dienstleistung für die Nutzer geführt, nicht als Sammlung von Geräten. Das verbreitetste Rahmenwerk ist ITIL 4. Es beschreibt Praktiken wie Service Desk, Incident Management, Problem Management, Change Enablement, Monitoring and Event Management und Service Level Management. Die Norm ISO/IEC 20000-1 legt Anforderungen an ein Service-Management-System fest und ist zertifizierbar.
Ein Service ist ein Angebot, das dem Kunden ein Ergebnis ermöglicht, ohne dass er sich um Technik und Risiken kümmern muss. Für die Leitung Schulung ist der Service nicht „srv01“, sondern „Anmeldung und Schulungssoftware an jedem Platz, früh und spät“.
Ein Service Level Agreement (SLA) ist die Vereinbarung über die Qualität des Service: Verfügbarkeit, Servicezeit, Reaktions- und Lösungszeiten, Ansprechpartner, Berichte. Ein SLA ist nur so gut wie seine Messbarkeit: „99,5 %“ ohne Bezugszeitraum und ohne Regel für Wartungsfenster sagt nichts.
Incident, Problem, Service Request, Change
| Begriff (ITIL 4) | Bedeutung | Ziel |
|---|---|---|
| Incident | ungeplante Unterbrechung oder Qualitätsminderung eines Service | Service schnell wiederherstellen, auch mit Umgehung |
| Problem | Ursache oder mögliche Ursache eines oder mehrerer Incidents | Ursache finden, bekannten Fehler dokumentieren, dauerhaft beheben |
| Service Request | Anfrage eines Nutzers nach etwas Vereinbartem, etwa ein neues Konto | nach Standardablauf erfüllen |
| Change | Hinzufügen, Ändern oder Entfernen von etwas, das Services direkt oder indirekt beeinflussen kann | Nutzen ermöglichen, Risiko beherrschen |
Der Service Desk ist die eine Anlaufstelle für alle Meldungen. Er nimmt an, erfasst im Ticketsystem (Helpdesk-System wie Zammad, osTicket, GLPI oder OTOBO), ordnet nach Priorität ein und löst, was mit Standardwissen lösbar ist (1st Level). Was er nicht lösen kann, gibt er an den 2nd Level (Fachteam für Server und Dienste) und dieser bei Bedarf an den 3rd Level (Hersteller, Entwickler). Das ist funktionale Eskalation. Hierarchische Eskalation heißt: Eine Führungskraft wird eingebunden, weil eine Frist reißt oder eine Entscheidung nötig ist.
Die Priorität ergibt sich aus Auswirkung (wie viele Nutzer, welcher Service) und Dringlichkeit (wie schnell wird es schlimm). Zu jeder Priorität gehören eine Reaktionszeit (bis jemand qualifiziert am Ticket arbeitet) und eine Lösungszeit (bis der Service wieder geht). Beide Uhren laufen nur in der vereinbarten Servicezeit, außer für Fälle mit Bereitschaft.
Überwachung der Funktionsfähigkeit und Sicherheit
Ein Monitoring-System wie Checkmk Raw oder Zabbix prüft regelmäßig Hosts (Ist der Rechner erreichbar?) und Dienste (Antwortet DNS? Ist die Platte zu voll? Läuft die Mail-Warteschlange über?). Agenten auf den Servern liefern Messwerte, SNMP oder Ping reichen für Drucker und Gateway. Für jeden Messwert gibt es Schwellen für Warnung und kritisch. Bei Zustandswechsel geht eine Benachrichtigung raus, im Schulungszentrum per Mail über Postfix aus Teil 5.
Gute Schwellen warnen so früh, dass in der Servicezeit Zeit zum Handeln bleibt, und so selten, dass niemand die Mails ungelesen löscht. Ein Zertifikat, das in 30 Tagen abläuft, ist eine Warnung; eines, das morgen abläuft, ist kritisch.
Sicherheitsüberwachung gehört dazu: Häufen sich fehlgeschlagene Anmeldungen an einem Konto oder Platz? Läuft ein Zertifikat ab? Stehen Sicherheitsupdates aus? Samba schreibt Anmeldeereignisse ins Protokoll, wenn die Audit-Protokollierung eingeschaltet ist; Windows schreibt sie ins Sicherheitsprotokoll (Ereignis 4625 für eine fehlgeschlagene Anmeldung).
Aktualisierungsmethoden
Linux-Server: Pakete kommen aus Paketquellen (bei Ubuntu 24.04 etwa noble, noble-updates, noble-security). apt aktualisiert von Hand, unattended-upgrades automatisch; in der Grundeinstellung nur aus der Sicherheitsquelle. Mit apt-mark hold hältst du ein Paket bewusst zurück.
Windows-Clients: Windows Update for Business steuert per Gruppenrichtlinie, wie lange Qualitäts- und Funktionsupdates zurückgestellt werden. So entstehen Ringe ohne eigenen Server. WSUS verteilt Updates von einem eigenen Server mit Freigabe je Computergruppe; Microsoft entwickelt WSUS seit 2024 nicht weiter, unterstützt es aber noch.
Ringe und Staffelung: Ein Update geht nie auf alle Plätze zugleich. Erst ein Testring (Labor, einzelne Plätze), dann ein Pilotring, dann der Rest. Zwischen den Ringen liegt Zeit, in der Fehler auffallen können. Der Patchday von Microsoft ist der zweite Dienstag im Monat.
Ausfallsicher aktualisieren
Vor jedem Change steht die Frage: Wie komme ich zurück? Drei Werkzeuge: Die Sicherung (Backup) liegt getrennt vom System und ist mit einem Restore-Test geprüft. Der Snapshot einer virtuellen Maschine friert ihren Zustand ein und lässt sich in Minuten zurückspielen, liegt aber auf demselben Speicher und ersetzt keine Sicherung. Der Rückweg ist der beschriebene und zeitlich geplante Ablauf, mit dem der alte Zustand wiederhergestellt wird.
Das Wartungsfenster ist die vereinbarte Zeit, in der Ausfälle geplant sind und nicht gegen das SLA zählen. Im Schulungszentrum ist es Sonntag 2 bis 4 Uhr. In das Fenster muss alles passen: Sicherung prüfen, Snapshot, Update, Neustart, Tests und, falls nötig, der Rückweg. Daraus folgt ein spätester Zeitpunkt, an dem die Entscheidung für den Rückweg fallen muss.
Change-Management
Ein Change beginnt mit einem Request for Change (RfC): Was wird geändert, warum, mit welchem Risiko, wann, mit welchem Test und welchem Rückweg? Nicht verwechseln mit den RFCs aus Teil 5, den Request for Comments der IETF.
| Change-Art | Merkmal | Freigabe |
|---|---|---|
| Standard-Change | häufig, geringes Risiko, beschriebener Ablauf | einmal vorab freigegeben, danach ohne Einzelfreigabe |
| normaler Change | geplant, Risiko muss bewertet werden | Freigabe durch die zuständige Change Authority vor der Durchführung |
| Notfall-Change | muss sofort umgesetzt werden, etwa gegen eine ausgenutzte Lücke | beschleunigt, wenige Personen, Dokumentation nachträglich vollständig |
Zum Change gehört die Kommunikation: Wer ist betroffen, wann, was merkt er davon, wen ruft er an, wenn danach etwas nicht geht? Am Ende steht ein Protokoll und, bei Erfolg, das Schließen des Changes mit einem Satz zur Auswertung.
Skalierbarkeit von Systemen
Ein System ist skalierbar, wenn es mit mehr Nutzern, Plätzen oder Daten wachsen kann, ohne dass es neu gebaut werden muss. Vertikal skalieren heißt: einem Server mehr Kerne, Speicher oder Platte geben. Horizontal skalieren heißt: weitere Server danebenstellen, etwa einen zweiten Domänencontroller. Engpässe zeigen sich oft an Stellen, an die niemand denkt: freie Adressen im DHCP-Bereich, Lizenzen je Gerät, Speicherplatz der Ablage, Zahl der Prüfungen im Monitoring.
Verfügbarkeit in Zahlen
Verfügbarkeit = (Betriebszeit − ungeplante Ausfallzeit) / Betriebszeit. Erlaubte Ausfallzeit = (1 − Verfügbarkeit) × Betriebszeit. Entscheidend ist die Betriebszeit: rund um die Uhr oder nur die vereinbarte Servicezeit.
| Verfügbarkeit | erlaubte Ausfallzeit in 30 Tagen rund um die Uhr (43.200 min) |
|---|---|
| 99 % | 432 min = 7 h 12 min |
| 99,9 % | 43,2 min |
| 99,99 % | 4,32 min |
Jede weitere Neun kostet ungefähr eine Größenordnung mehr Aufwand: Redundanz, Bereitschaft, Überwachung.
Snapshot und Domänencontroller
Bei einem einzigen Domänencontroller ist der Snapshot ein brauchbarer Rückweg, alle Änderungen seit dem Snapshot (etwa neue Passwörter) gehen dabei verloren. Sobald es zwei Domänencontroller gibt, darf ein DC nicht einfach auf einen alten Snapshot zurückgesetzt werden: Die Replikation gerät durcheinander (USN-Rollback). Dann führt der Rückweg über eine Sicherung mit samba-tool domain backup oder über das Neuaufnehmen des DC in die Domäne.
Ticket, Ereignis, Alarm
Nicht jedes Ereignis im Monitoring ist ein Incident. Eine Warnung „Platte zu 82 % belegt“ ist ein Ereignis, das einen geplanten Eingriff auslöst. Viele Teams lassen nur kritische Zustände automatisch ein Ticket erzeugen und werten Warnungen einmal am Tag aus.
Die Begriffe dieser Fachgrundlage
| Begriff | Bedeutung | Im Schulungszentrum |
|---|---|---|
| Service | Angebot, das dem Kunden ein Ergebnis ermöglicht | Anmeldung, Schulungssoftware, Druck, Portal an jedem Platz |
| SLA | vereinbarte Servicequalität mit Kennzahlen | 99,5 % im Monat, Servicezeit, Fristen je Priorität |
| Incident | ungeplante Unterbrechung eines Service | Simulator startet in Raum A nicht |
| Problem | Ursache eines oder mehrerer Incidents | DNS auf srv01 fällt wiederholt aus |
| Change | geplante Änderung mit Einfluss auf Services | Sonntagsupdate von srv01 und srv02 |
| Service Desk | eine Anlaufstelle für alle Meldungen | Ticketsystem von Querwind mit Bereitschaftspostfach |
| 1st, 2nd, 3rd Level | Ebenen der funktionalen Eskalation | Service Desk, Fachteam Querwind, Hersteller der Schulungssoftware |
| Monitoring | laufende Prüfung von Hosts und Diensten mit Schwellen | Checkmk Raw oder Zabbix auf srv02 |
| Ring | Gruppe von Systemen, die ein Update zur selben Zeit bekommt | Testring Labor und Trainerbüro |
| Snapshot | eingefrorener Zustand einer VM, schnell zurückspielbar | Snapshot von srv01 vor dem Update |
| Rückweg | geplanter Ablauf zurück zum alten Zustand | Snapshot zurück, Dienst testen, Trainer informieren |
| RfC | Request for Change, Antrag auf eine Änderung | Antrag für das Fenster am Sonntag |
| Skalierung | Wachstum ohne Neubau, vertikal oder horizontal | dritter Schulungsraum mit 17 Plätzen |
Zum Nachlesen
- ITIL 4 Foundation, Kapitel 5 (Praktiken: Incident Management, Problem Management, Change Enablement, Service Desk, Service Level Management, Monitoring and Event Management)
- ISO/IEC 20000-1:2018, Anforderungen an ein Service-Management-System
- BSI IT-Grundschutz-Kompendium, Baustein OPS.1.1.3 Patch- und Änderungsmanagement
- Ubuntu Server Documentation, Kapitel „Automatic updates“ (unattended-upgrades)
- Microsoft Learn: Windows Update for Business, Konfiguration per Gruppenrichtlinie; Ankündigung zur Einstellung der Weiterentwicklung von WSUS (2024)
- Samba Wiki: „Back up and Restoring a Samba AD DC“ und „Setting up Audit Logging“
- Checkmk Handbuch (Hosts, Services, Schwellwerte, Benachrichtigungen) bzw. Zabbix Manual (Hosts, Items, Triggers, Actions)