Zum Inhalt

2. Wartungsverträge und Service Level Agreements

Lernziele

Nach diesem Kapitel können Sie: - Wartungsverträge strukturieren und deren Bestandteile benennen - Service Level Agreements (SLAs) entwerfen und messbare Kennzahlen definieren - Verfügbarkeitsmetriken (RPO, RTO, MTTR) berechnen und interpretieren - Die Beziehung zwischen Wartungsvertrag und SLA verstehen - SLAs an Kundenbedürfnisse anpassen und überwachen

Modul Übersicht

Modul 13 - Kapitel 2 Lesezeit: ~20 Min Quelle: FS-ITB-13-A-laufender Betrieb_V0d .pdf

1. Grundlagen der IT-Betreuung

Nach der Einführung einer IT-Lösung ist die dauerhafte Betreuung und Pflege der Systeme entscheidend für einen stabilen und sicheren Betrieb. Diese Aufgaben werden in der Regel in einem Wartungsvertrag festgelegt.

Bedeutung für den IT-Berater

Ein stabiler Betrieb wird durch rechtssichere Rahmenbedingungen in Form von Wartungsverträgen und Service Level Agreements (SLAs) gewährleistet. Für IT-Berater ist die Gestaltung dieser Verträge ein zentraler Aspekt der Nachbetreuung, da sie:

  • Klare Rahmenbedingungen für beide Parteien schaffen
  • Erwartungen transparent und messbar machen
  • Konflikte im operativen Betrieb vermeiden
  • Die Qualität der IT-Services dauerhaft sichern
  • Die Basis für eine langfristige Partnerschaft bilden

Praxisbeispiel

Ein mittelständisches Unternehmen implementiert ein neues ERP-System. Ohne klaren Wartungsvertrag entsteht nach drei Monaten Unklarheit: Das Unternehmen erwartet 24/7-Support bei Störungen, während der Dienstleister nur Geschäftszeiten-Support in den Aufnahmepreis einplant. Diese Situation führt zu Frustration und erfordert eine nachträgliche Vertragsanpassung, die mit zusätzlichen Kosten und administrativem Aufwand verbunden ist.

2. Der Wartungsvertrag

Ein Wartungsvertrag regelt, welche Leistungen der IT-Dienstleister im laufenden Betrieb erbringt. Er bildet die vertragliche Grundlage für die dauerhafte Zusammenarbeit nach Projektabschluss.

Typische Inhalte eines Wartungsvertrags

2.1 Leistungsumfang

Der Wartungsvertrag definiert präzise, welche Leistungen erbracht werden:

Leistungskategorie Beispiele
Software-Updates Patch-Management, Version-Updates, Security-Fixes
Fehlerbehebung Fehleranalyse, Bugfixing, Hotfixes
Systemüberwachung Monitoring, Health Checks, Präventivmaßnahmen
Benutzerunterstützung User Helpdesk, First-Level Support, Schulungen
Datenbankpflege Backup-Überwachung, Optimierung, Konsistenzprüfungen
Dokumentation Systemdokumentation, Handbücher, Betriebsanleitungen

2.2 Zuständigkeiten

Ein klarer Wartungsvertrag definiert die Verantwortlichkeiten zwischen Dienstleister und Kunde:

flowchart LR
    subgraph "Kunde Verantwortlichkeiten"
        A[Infrastruktur bereitstellen]
        B[Benutzer informieren und schulen]
        C[Zugriffe gewähren]
        D[Backups prüfen]
    end

    subgraph "Dienstleister Verantwortlichkeiten"
        E[Monitoring durchführen]
        F[Updates einspielen]
        G[Support leisten]
        H[Dokumentation pflegen]
    end

    A -.-> E
    B -.-> G
    C -.-> F
    D -.-> H

2.3 Laufzeit und Kündigungsfristen

  • Vertragslaufzeit: Typischerweise 12-36 Monate, oft mit automatischer Verlängerung
  • Kündigungsfrist: Meist 3-6 Monate zum Vertragsende
  • Preisanpassungsklauseln: Regelmäßige Preisanpassungen basierend auf Index oder Inflation
  • Übergangsregelungen: Übergabe von Dokumentationen bei Vertragsende

2.4 Kostenmodelle

Verschiedene Kostenmodelle für Wartungsverträge haben sich etabliert:

Modell Beschreibung Vor- und Nachteile
Pauschale Fester monatlicher Betrag ✓ Planbar; ✗ Geringe Flexibilität
Zeitabhängig Abrechnung nach tatsächlichem Aufwand ✓ Flexibel; ✗ Nicht planbar
Leistungsabhängig Abrechnung nach erbrachten Leistungen ✓ Fair; ✗ Aufwendige Abrechnung
Hybrid Kombination aus Pauschale und Zeitabhängigkeit ✓ Ausgewogen; ✗ Komplex

Rechtliche Aspekte

Ein professioneller Wartungsvertrag sollte folgende rechtliche Aspekte berücksichtigen:

  • Gewährleistung: Abgrenzung zwischen Wartung und Gewährleistung
  • Haftung: Haftungsbeschränkungen bei Ausfällen oder Datenverlust
  • Versicherung: Haftpflichtversicherung des Dienstleisters
  • Datenschutz: Einhaltung der DSGVO bei Datenzugriffen
  • Subunternehmer: Erlaubnis der Nutzung von Subunternehmern
  • Geheimhaltung: Vertraulichkeitsvereinbarungen

Praxistipp

Lassen Sie Wartungsverträge immer rechtlich prüfen, insbesondere bei kritischen Systemen. Vermeiden Sie vage Formulierungen wie "bester Wissensstand" oder "angemessene Zeiträume". Definieren Sie stattdessen konkrete Zeitangaben, messbare Kriterien und klare Verantwortlichkeiten.

3. Service Level Agreement (SLA)

Ein Service Level Agreement (SLA) ist ein wichtiger Bestandteil eines Wartungsvertrags. Es beschreibt die Qualität und Verbindlichkeit der zu erbringenden Leistungen anhand messbarer Kriterien.

Definition und Zweck

Das SLA definiert das "Wie gut" der Service-Erbringung. Während der Wartungsvertrag festlegt, WAS getan wird, definiert das SLA, WIE GUT und WIE SCHNELL die Leistung erbracht werden muss.

Zweck eines SLA:

  • Transparenz: Klare, messbare Definitionen der Servicequalität
  • Nachvollziehbarkeit: Überprüfbare Kriterien für beide Parteien
  • Verbindlichkeit: Rechtlich relevante Qualitätsvereinbarungen
  • Konfliktvermeidung: Klare Messgrößen reduzieren Streitfälle
  • Stetige Verbesserung: Grundlage für Monitoring und Optimierung

Zentrale SLA-Kennzahlen

3.1 Verfügbarkeit (Availability)

Die Verfügbarkeit ist die wichtigste Kennzahl in den meisten SLAs. Sie wird als Prozentsatz der Zeit angegeben, in der ein System innerhalb der vereinbarten Servicezeiten funktionsfähig ist.

Berechnung:

\[ \text{Verfügbarkeit} = \left(1 - \frac{\text{Ausfallzeit}}{\text{Gesamtzeit}}\right) \times 100\% \]

Typische Verfügbarkeitsstufen:

Verfügbarkeit Ausfallzeit pro Jahr Anwendungsbeispiel
99,9% ~8,8 Stunden Standard-Business-Systeme
99,99% ~52 Minuten Kritische Geschäftssysteme
99,999% ~5 Minuten Hochverfügbare Systeme, Banking
99,9999% ~31 Sekunden Mission-Critical-Systeme

Berechnungsbeispiel

Ein System hat eine vereinbarte Verfügbarkeit von 99,5%. In einem Monat (30 Tage, 720 Stunden) war das System insgesamt 4 Stunden nicht verfügbar.

Verfügbarkeit = (1 - 4/720) × 100% = (1 - 0,0056) × 100% = 99,44%

Das SLA von 99,5% wurde nicht erreicht. Der Dienstleister hat eine Vertragsstrafe oder Gutschrift gemäß SLA-Bestimmungen zu gewähren.

3.2 Reaktionszeit (Response Time)

Die Reaktionszeit ist die Zeitspanne zwischen der Meldung einer Störung und dem Beginn der Bearbeitung durch den Dienstleister.

Typische Reaktionszeiten nach Priorität:

Priorität Beschreibung Reaktionszeit
P1 - Kritisch Kompletter Systemausfall, Produktionsstop ≤ 15 Minuten
P2 - Hoch Wesentliche Funktionsbeeinträchtigung ≤ 1 Stunde
P3 - Mittel Teilweise Funktionsbeeinträchtigung ≤ 4 Stunden
P4 - Niedrig Geringe Beeinträchtigung oder Frage ≤ 1 Arbeitstag

Wichtig

Die Reaktionszeit unterscheidet sich von der Wiederherstellungszeit. Die Reaktionszeit gibt an, WANN mit der Bearbeitung begonnen wird, nicht wann das Problem gelöst ist.

3.3 Wiederherstellungszeit (Recovery Time / Resolution Time)

Die Wiederherstellungszeit ist die Zeitspanne von der Meldung bis zur vollständigen Behebung der Störung.

Beispiel-Definition:

  • P1 - Kritisch: ≤ 4 Stunden
  • P2 - Hoch: ≤ 8 Stunden
  • P3 - Mittel: ≤ 24 Stunden
  • P4 - Niedrig: ≤ 3 Arbeitstage

3.4 Weitere wichtige SLA-Kennzahlen

Kennzahl Definition Beispiel
MTTR Mean Time To Repair; durchschnittliche Wiederherstellungszeit 2,5 Stunden
MTBF Mean Time Between Failures; durchschnittliche Zeit zwischen Ausfällen 720 Stunden
Servicezeit Zeiten, in denen Services verfügbar sein müssen Mo-Fr, 08:00-18:00
Lösungsrate Prozentsatz der Tickets, die beim ersten Kontakt gelöst wurden 85% First Contact Resolution
Zufriedenheit Kundenzufriedenheit mit Support (z.B. CSAT-Score) ≥ 4,2/5,0

Verfügbarkeitsmetriken im Detail

RPO - Recovery Point Objective

Das Recovery Point Objective (RPO) gibt an, wie viel Daten maximal verloren gehen dürfen, wenn ein System ausfällt. Es wird als Zeitspanne angegeben.

Beispiele:

RPO Erklärung Anwendungsbeispiel
0 Sekunden Kein Datenverlust tolerierbar Finanztransaktionen, Echtzeit-Systeme
15 Minuten Daten der letzten 15 Minuten können verloren gehen ERP-Systeme mit regelmäßigen Backups
1 Stunde Daten der letzten Stunde können verloren gehen E-Mail-Systeme
24 Stunden Daten des letzten Tages können verloren gehen Dokumentenarchiv

RPO vs. RTO

RPO (Recovery Point Objective) bezieht sich auf die Datenmenge (Zeitspanne), die maximal verloren gehen darf. RTO (Recovery Time Objective) bezieht sich auf die Dauer, die maximal für die Wiederherstellung in Kauf genommen wird.

RTO - Recovery Time Objective

Das Recovery Time Objective (RTO) gibt an, wie lange ein System maximal ausfallen darf, ohne dass ein inakzeptabler Schaden für das Unternehmen entsteht.

Bestimmung des RTO:

flowchart TD
    A[Business Impact Analyse] --> B{Kritikalität des Systems}
    B -->|Hoch| C[RTO: < 4 Stunden]
    B -->|Mittel| D[RTO: 4 - 24 Stunden]
    B -->|Niedrig| E[RTO: 24 - 72 Stunden]

    C --> F[High Availability<br/>Replikation, Failover]
    D --> G[Standard Recovery<br/>Backups, Restore]
    E --> H[Manual Recovery<br/>kein 24/7-Support]

    style C fill:#ff6b6b
    style D fill:#ffd93d
    style E fill:#6bcb77

MTTR - Mean Time To Repair

Der Mean Time To Repair (MTTR) ist eine Kennzahl für die durchschnittliche Zeit, die benötigt wird, um einen Ausfall zu beheben.

Berechnung:

\[ \text{MTTR} = \frac{\text{Summe aller Wiederherstellungszeiten}}{\text{Anzahl der Ausfälle}} \]

Beispiel:

  • Ausfall 1: 2 Stunden
  • Ausfall 2: 3 Stunden
  • Ausfall 3: 4 Stunden
  • Ausfall 4: 1 Stunde

MTTR = (2 + 3 + 4 + 1) / 4 = 2,5 Stunden

Ein niedriger MTTR ist positiv, da dies auf effektive Notfallmaßnahmen hindeutet.

MTBF - Mean Time Between Failures

Der Mean Time Between Failures (MTBF) gibt an, wie lange im Durchschnitt zwischen zwei Ausfällen eines Systems vergeht. Je höher der MTBF, desto zuverlässiger das System.

Berechnung:

\[ \text{MTBF} = \frac{\text{Gesamtbetriebszeit}}{\text{Anzahl der Ausfälle}} \]

Beispiel:

Ein System war im Jahr (8.760 Stunden) insgesamt 12 Mal ausgefallen.

MTBF = 8.760 / 12 = 730 Stunden

Das System durchschnittlich alle 730 Stunden (ca. 30 Tage) ausfallen.

Struktur eines professionellen SLA

Ein umfassendes SLA sollte folgende Kapitel enthalten:

1. Allgemeine Bestimmungen

  • Geltungsbereich
  • Vertragspartner
  • Laufzeit und Kündigung
  • Änderungsverfahren

2. Definition der Services

  • Beschreibung der Services
  • Servicezeiten
  • Ausgeschlossene Zeiten (Wartungsfenster)

3. Service Levels

  • Verfügbarkeitsanforderungen
  • Reaktionszeiten nach Priorität
  • Wiederherstellungszeiten
  • Qualität der Services

4. Messung und Berichterstattung

  • Messmethoden
  • Berichtszeitraum
  • Berichtsformat
  • Bestätigungsprozess

5. Konsequenzen bei Nichteinhaltung

  • Service Credits (Gutschriften)
  • Vertragsstrafen
  • Sonderkündigungsrechte
  • Schadensersatzansprüche

6. Management- und Eskalationsverfahren

  • Regelmäßige Service Reviews
  • Eskalationsstufen
  • Kontaktinformationen

Typische SLA-Struktur mit Prioritäten

graph TB
    subgraph "SLA-Struktur"
        A[Service Level Agreement]

        subgraph "Prioritäten"
            B[P1 - Kritisch]
            C[P2 - Hoch]
            D[P3 - Mittel]
            E[P4 - Niedrig]
        end

        subgraph "Kriterien"
            F[Verfügbarkeit]
            G[Reaktionszeit]
            H[Wiederherstellungszeit]
            I[SLA-Verletzung]
        end

        B --> F1[99,9%]
        B --> G1[≤ 15 Min]
        B --> H1[≤ 4 Std]
        B --> I1[30% Gutschrift/Monat]

        C --> F2[99,5%]
        C --> G2[≤ 1 Std]
        C --> H2[≤ 8 Std]
        C --> I2[15% Gutschrift/Monat]

        D --> F3[99,0%]
        D --> G3[≤ 4 Std]
        D --> H3[≤ 24 Std]
        D --> I3[5% Gutschrift/Monat]

        E --> F4[95,0%]
        E --> G4[≤ 1 AT]
        E --> H4[≤ 3 AT]
        E --> I4[Keine Gutschrift]
    end

    style B fill:#ff6b6b
    style C fill:#ffd93d
    style D fill:#6bcb77
    style E fill:#4ecdc4

4. Beziehung zwischen Wartungsvertrag und SLA

Wartungsvertrag und SLA bilden zusammen die Grundlage für eine verlässliche und planbare IT-Betreuung.

Aspekt Wartungsvertrag SLA
Fokus Was wird geleistet? Wie gut wird geleistet?
Inhalt Leistungen, Zuständigkeiten, Kosten Messbare Kriterien, Kennzahlen
Charakter Vertragliche Rahmenbedingung Detaillierte Qualitätsdefinition
Verbindlichkeit Rechtlich bindend Teil des Vertrags, rechtlich bindend
Änderung Eher statisch Häufige Anpassungen

Best Practice

Das SLA sollte als Anlage zum Wartungsvertrag geführt werden. Dies ermöglicht bei Änderungen (z. B. neue Kennzahlen, andere Prioritäten) eine flexible Anpassung des SLA ohne den gesamten Wartungsvertrag neu zu verhandeln.

5. SLA-Design und Implementierung

Schritt 1: Analyse der Anforderungen

Bevor ein SLA erstellt wird, müssen die Anforderungen des Kunden analysiert werden:

Fragen zur Analyse:

  • Wie kritisch ist das System für den Geschäftsbetrieb?
  • Welche Verfügbarkeit wird benötigt?
  • Welche Auswirkungen hat ein Ausfall auf das Business?
  • Welche Budgets stehen zur Verfügung?
  • Welche SLAs erhalten Wettbewerber?
  • Welche Servicezeiten werden benötigt (24/7, 5 Tage/Woche)?

Schritt 2: Definition der Kennzahlen

Basierend auf der Analyse werden die Kennzahlen definiert:

Strategie:

  1. Realistische Kennzahlen: Keine unrealistischen Ziele, die nicht eingehalten werden können
  2. Messbare Kennzahlen: Alle Kennzahlen müssen objektiv messbar sein
  3. Klare Definitionen: Eindeutige Definitionen, was "gemessen" wird
  4. Abgestufte Kennzahlen: Unterschiedliche Kennzahlen für verschiedene Prioritäten

Schritt 3: Dokumentation

Alle Kennzahlen und Verfahren werden schriftlich dokumentiert:

Wichtige Aspekte:

  • Definition der Messmethoden
  • Festlegung der Berichtszeitpunkte (z. B. monatlich)
  • Definition des Berichtsformats
  • Beschreibung des Bestätigungsprozesses

Schritt 4: Monitoring und Berichterstattung

Nach Implementierung muss das SLA regelmäßig überwacht werden:

Monitoring-Systeme:

  • Verfügbarkeitsüberwachung (z. B. Pingdom, Uptime Robot)
  • Ticket-Systeme für Support (z. B. Jira Service Desk, Zendesk)
  • Performance-Monitoring (z. B. Zabbix, Prometheus)
  • Reporting-Dashboards (z. B. Grafana, Power BI)

Schritt 5: Regelmäßige Überprüfung (SLA-Reviews)

SLAs sollten regelmäßig überprüft werden (typischerweise halbjährlich):

Checkliste für SLA-Reviews:

  • Werden die SLAs eingehalten?
  • Sind die Kennzahlen noch angemessen?
  • Gibt es neue Anforderungen oder veränderte Bedingungen?
  • Muss das SLA angepasst werden?

SLA-Review-Beispiel

Ein SLA-Review zeigt, dass die Verfügbarkeit eines kritischen Systems in den letzten 6 Monaten bei 99,6% lag, während das SLA 99,9% vorsieht. Analyse: Die Nichterreichung liegt an geplanten Wartungsfenstern, die nicht als Wartungszeit deklariert wurden. Anpassung: Geplante Wartungen werden in das SLA als "ausgeschlossene Zeiten" aufgenommen. Das angepasste SLA definiert nun: "Verfügbarkeit von 99,9% außerhalb der geplanten Wartungsfenster (jeweils 2 Stunden am ersten Samstag im Monat, 02:00-04:00 Uhr)."

6. Service Credits und Konsequenzen bei SLA-Verletzung

Die meisten SLAs enthalten sogenannte "Service Credits" (Gutschriften) als Konsequenz bei Nichteinhaltung der definierten Kennzahlen.

Service Credits definieren

Service Credits sind Gutschriften auf die monatliche Wartungsgebühr, die dem Kunden gewährt werden, wenn das SLA nicht eingehalten wurde.

Typische Service Credit-Struktur:

Verfügbarkeit (Ziel: 99,5%) Service Credit
99,4% - 99,5% 5% der monatlichen Gebühr
99,3% - 99,4% 10% der monatlichen Gebühr
99,0% - 99,3% 20% der monatlichen Gebühr
< 99,0% 30% der monatlichen Gebühr

Beispiel: Service Credit-Berechnung

Situation:

  • Monatliche Wartungsgebühr: 2.500 €
  • Vereinbarte Verfügbarkeit: 99,5%
  • Tatsächliche Verfügbarkeit: 99,2%

Berechnung:

  • Verletzung um 0,3% (99,5% - 99,2% = 0,3%)
  • Dies fällt in die Kategorie "99,0% - 99,3%" = 20% Service Credit
  • Service Credit = 2.500 € × 20% = 500 €

Ergebnis: Der Kunde erhält eine Gutschrift von 500 € für den betreffenden Monat.

Andere Konsequenzen bei SLA-Verletzung

Neben Service Credits können weitere Konsequenzen vereinbart werden:

Konsequenz Beschreibung
Vertragsstrafen Zusätzliche Strafzahlungen bei grober Verletzung
Sonderkündigungsrecht Recht zur außerordentlichen Kündigung bei wiederholter Verletzung
Rückerstattung Rückzahlung bereits bezahlter Gebühren
Verbesserte SLAs Herabsetzung der Kennzahlen ohne Preisanpassung

Wichtig

Service Credits sollten nicht als Einnahmequelle für Kunden betrachtet werden. Ihr Zweck ist es, Anreize für die Einhaltung der SLAs zu schaffen. Übermäßige Strafen können dazu führen, dass Anbieter unangemessene Preise verlangen oder kritische Services gar nicht mehr anbieten.

7. Praxisbeispiel: SLA-Design für ein ERP-System

Ausgangssituation

Ein mittelständisches Unternehmen mit 200 Mitarbeitern führt ein ERP-System ein. Das Unternehmen benötigt eine 24/7-Verfügbarkeit für Produktionssteuerung, kann aber keine extrem hohen Kosten für IT-Services ausgeben.

SLA-Design

Service Verfügbarkeit Reaktionszeit Wiederherstellungszeit Wartungsgebühr/Monat
ERP-System 99,5% P1: ≤ 2 Std.
P2: ≤ 4 Std.
P3: ≤ 8 Std.
P4: ≤ 1 AT		 P1: ≤ 6 Std.
P2: ≤ 12 Std.
P3: ≤ 24 Std.
P4: ≤ 3 AT		 3.500 €
Datenbank-Server 99,7% P1: ≤ 1 Std.
P2: ≤ 2 Std.		 P1: ≤ 4 Std.
P2: ≤ 8 Std.		 Inbegriffen
Backup-Service 100% (RPO: 15 Min)
99,9% (RTO: 8 Std)		 P1: ≤ 30 Min P1: ≤ 8 Std Inbegriffen
User Helpdesk 95% (Erreichbarkeit) P1: ≤ 15 Min
P2: ≤ 30 Min		 P1: ≤ 2 Std.
P2: ≤ 4 Std.		 800 €

Wartungsfenster

Geplante Wartungen werden in definierten Wartungsfenstern durchgeführt:

  • Täglich: 02:00 - 03:00 Uhr (nicht kritische Wartungen)
  • Wöchentlich: Samstag, 02:00 - 06:00 Uhr (größere Updates)
  • Quartalsweise: Erster Sonntag im Quartal, 02:00 - 10:00 Uhr (große Updates)

Zeiten in diesen Fenstern sind von der Verfügbarkeitsberechnung ausgenommen.

Service Credits

Bei Nichteinhaltung der Verfügbarkeit:

Verfügbarkeit (Ziel: 99,5%) Service Credit
99,4% - 99,5% 5% der monatlichen Gebühr
99,3% - 99,4% 10% der monatlichen Gebühr
99,0% - 99,3% 20% der monatlichen Gebühr
98,5% - 99,0% 30% der monatlichen Gebühr
< 98,5% 50% der monatlichen Gebühr

Überwachung und Berichterstattung

  • Monitoring: Kontinuierliches Monitoring mit automatischer Benachrichtigung bei Ausfällen
  • Reporting: Monatlicher Bericht mit Verfügbarkeit, Reaktionszeiten und Ticket-Statistiken
  • Service Review: Halbjährliches Meeting zur Überprüfung und Anpassung der SLAs

Ergebnis nach 12 Monaten Betrieb

Monat Verfügbarkeit SLA-Erfüllung Service Credit
1 99,6% ✓ 0 €
2 99,4% ✗ 175 € (5% von 3.500 €)
3 99,5% ✓ 0 €
4 99,2% ✗ 700 € (20% von 3.500 €)
5 99,7% ✓ 0 €
6 99,5% ✓ 0 €
7 99,3% ✗ 350 € (10% von 3.500 €)
8 99,6% ✓ 0 €
9 99,5% ✓ 0 €
10 99,4% ✗ 175 € (5% von 3.500 €)
11 99,8% ✓ 0 €
12 99,5% ✓ 0 €

Gesamt: 8 von 12 Monaten SLA erfüllt (66,7%); Service Credits: 1.400 €

Analyse: Die Verletzungen lagen an ungeplanten Ausfällen, die durch Hardwareschäden verursacht wurden. Anpassung: Im Jahr 2 wurde ein redundanter Server eingeführt, um die Verfügbarkeit zu erhöhen.

Schlüsselbegriffe

Begriff Definition
Wartungsvertrag Vertragliche Vereinbarung über die Betreuung und Pflege von IT-Systemen
SLA Service Level Agreement; Vereinbarung über messbare Servicequalität
Verfügbarkeit Prozentsatz der Zeit, in der ein System funktionsfähig ist
Reaktionszeit Zeit von der Meldung bis zum Beginn der Bearbeitung
Wiederherstellungszeit Zeit von der Meldung bis zur vollständigen Problemlösung
RPO Recovery Point Objective; Maximal tolerierbarer Datenverlust in Zeiteinheiten
RTO Recovery Time Objective; Maximal tolerierbare Ausfallzeit
MTTR Mean Time To Repair; Durchschnittliche Wiederherstellungszeit
MTBF Mean Time Between Failures; Durchschnittliche Zeit zwischen Ausfällen
Service Credits Gutschriften bei SLA-Verletzung als finanzielle Konsequenz
Servicezeit Zeiten, in denen ein Service verfügbar sein muss
Priorisierung Einteilung von Störungen nach Dringlichkeit (P1-P4)

Verständnisfragen

Frage 1: SLA-Kennzahlen unterscheiden

Ein Kunde beschwert sich, dass ein kritischer Ausfall gestern Abend um 22:30 Uhr nicht rechtzeitig behoben wurde. Der Dienstleister argumentiert, dass er innerhalb der vereinbarten Zeit reagiert hat. Welche SLA-Kennzahlen sind hier relevant und wie könnten sie definiert sein?

Lösung: Hier sind zwei SLA-Kennzahlen relevant: 1. Reaktionszeit: Die Zeit von der Meldung bis zum Beginn der Bearbeitung. Wenn z. B. die Störung um 22:30 Uhr gemeldet wurde und der Dienstleister um 22:35 Uhr mit der Bearbeitung begann, beträgt die Reaktionszeit 5 Minuten. 2. Wiederherstellungszeit: Die Zeit von der Meldung bis zur vollständigen Problemlösung. Wenn das Problem z. B. erst um 02:00 Uhr gelöst war, beträgt die Wiederherstellungszeit 3,5 Stunden.

Bei einem kritischen Ausfall (Priorität P1) könnte das SLA z. B. eine Reaktionszeit von ≤ 15 Minuten und eine Wiederherstellungszeit von ≤ 4 Stunden vorsehen. Beide Zeiten müssten dann geprüft werden.

Frage 2: Verfügbarkeit berechnen

Ein System hat eine vereinbarte Verfügbarkeit von 99,9%. In einem Monat (30 Tage = 720 Stunden) war das System an zwei Tagen jeweils für 2 Stunden nicht verfügbar. Wurde das SLA eingehalten? Berechnen Sie die tatsächliche Verfügbarkeit und nennen Sie die maximal tolerierbare Ausfallzeit für 99,9%.

Lösung: Berechnung der tatsächlichen Verfügbarkeit: * Gesamtausfallzeit: 2 × 2 Stunden = 4 Stunden * Verfügbarkeit = (1 - 4/720) × 100% = (1 - 0,0056) × 100% = 99,44%

Berechnung der maximal tolerierbaren Ausfallzeit für 99,9%: * Verfügbarkeit = 99,9% bedeutet 0,1% Ausfallzeit * Maximale Ausfallzeit = 720 Stunden × 0,001 = 0,72 Stunden = 43,2 Minuten

Ergebnis: Das SLA von 99,9% wurde nicht erreicht. Die tatsächliche Verfügbarkeit von 99,44% liegt unter dem Ziel, und die Ausfallzeit von 4 Stunden überschreitet die maximal tolerierbare Zeit von 43,2 Minuten deutlich.

Frage 3: RPO vs. RTO

Ein Unternehmen legt für sein wichtiges ERP-System ein RPO von 15 Minuten und ein RTO von 4 Stunden fest. Ein Hardware-Ausfall tritt um 14:00 Uhr auf. Das letzte Backup wurde um 13:30 Uhr erstellt, und das System wird um 17:30 Uhr wiederhergestellt. Wurden die RPO- und RTO-Vorgaben eingehalten?

Lösung: RPO-Prüfung (Recovery Point Objective - maximaler Datenverlust): * Ausfallzeit: 14:00 Uhr * Letztes Backup: 13:30 Uhr * Datenverlust: 14:00 - 13:30 = 30 Minuten * Vorgabe RPO: 15 Minuten * RPO-Ergebnis: ✗ NICHT eingehalten (30 Minuten > 15 Minuten)

RTO-Prüfung (Recovery Time Objective - maximale Wiederherstellungszeit): * Ausfallzeit: 14:00 Uhr * Wiederherstellung: 17:30 Uhr * Wiederherstellungszeit: 17:30 - 14:00 = 3,5 Stunden * Vorgabe RTO: 4 Stunden * RTO-Ergebnis: ✓ Eingehalten (3,5 Stunden < 4 Stunden)

Fazit: Das RTO wurde eingehalten, aber das RPO wurde überschritten. Das Unternehmen verlor 30 Minuten Daten, obwohl nur maximal 15 Minuten toleriert waren. Maßnahmen: Einführung häufigerer Backups oder einer Replikationslösung.

Frage 4: MTTR und MTBF interpretieren

Ein Server im Jahr hatte folgende Ausfälle mit folgenden Wiederherstellungszeiten: * Ausfall 1: 4 Stunden * Ausfall 2: 6 Stunden * Ausfall 3: 2 Stunden * Ausfall 4: 3 Stunden

Der Server war im Jahr (8.760 Stunden) insgesamt 850 Stunden in Wartung. Berechnen Sie MTTR und MTBF und interpretieren Sie die Werte.

Lösung: MTTR (Mean Time To Repair - Durchschnittliche Wiederherstellungszeit): * Summe aller Wiederherstellungszeiten: 4 + 6 + 2 + 3 = 15 Stunden * Anzahl der Ausfälle: 4 * MTTR = 15 / 4 = 3,75 Stunden

MTBF (Mean Time Between Failures - Durchschnittliche Zeit zwischen Ausfällen): * Gesamtbetriebszeit: 8.760 Stunden - 850 Stunden Wartung = 7.910 Stunden * Anzahl der Ausfälle: 4 * MTBF = 7.910 / 4 = 1.977,5 Stunden ≈ 82 Tage

Interpretation: * MTTR von 3,75 Stunden: Wenn ein Ausfall auftritt, dauert es durchschnittlich 3,75 Stunden, bis der Server wieder verfügbar ist. Dies könnte optimiert werden (z. B. durch bessere Dokumentation, redundante Hardware). * MTBF von 1.977,5 Stunden (ca. 82 Tage): Im Durchschnitt fällt der Server etwa alle 82 Tage aus. Dies deutet auf eine eher mäßige Zuverlässigkeit hin. Maßnahmen zur Verbesserung könnten sein: Hardware-Erneuerung, proaktive Wartung, Monitoring.