OLA

#informatik/management #GFN/LF06

Ein OLA (Operating Level Agreement / Operational Level Agreement) ist eine interne Vereinbarung zwischen IT-Teams innerhalb einer Organisation, die Service-Level für interne Leistungen definiert.

OLAs unterstützen die Erfüllung von SLAs, indem sie sicherstellen, dass interne Abhängigkeiten klar geregelt sind.

Typische OLAs

  • Netzwerk-Team garantiert Second-Level-Support Reaktionszeit von 2 Stunden
  • Server-Team stellt 99,5% Verfügbarkeit für E-Mail-Server bereit
  • Datenbank-Team bietet Backup-Service innerhalb von 4 Stunden
  • Security-Team überprüft Changes innerhalb von 24 Stunden

OLA vs. SLA vs. UC

Typ Parteien Beschreibung Beispiel
SLA IT ↔ externer Kunden Service Level mit Business/End-User "E-Mail-Service: 99,9% Verfügbarkeit"
OLA IT-Team A ↔ IT-Team B Interne Vereinbarung zwischen IT-Teams "Netzwerk-Team liefert 99,5% für Server-Team"
UC IT ↔ externer Lieferant Vertrag mit externem Dienstleister "Cloud-Provider garantiert 99,99% Uptime"
Hierarchie

Kunden ← SLA → IT-Service
             ↓ (unterstützt durch)
       IT-Team A ← OLA → IT-Team B
             ↓ (nutzt)
       Externer Lieferant ← UC

Zweck und Nutzen

Warum OLAs?

  • Klarheit: Interne Verantwortlichkeiten definieren
  • SLA-Erfüllung: Ohne funktionierende OLAs können SLAs nicht eingehalten werden
  • Messbarkeit: Interne Service-Qualität messen
  • Eskalation: Klare Prozesse bei Problemen
  • Koordination: Abhängigkeiten zwischen Teams managen

Praktisches Szenario

SLA: "E-Mail-Service verfügbar zu 99,9%"

Unterstützende OLAs:

  • Server-Team: "E-Mail-Server läuft zu 99,95%"
  • Netzwerk-Team: "Netzwerk-Verfügbarkeit 99,98%"
  • Storage-Team: "Speicher verfügbar zu 99,99%"

→ Alle OLAs zusammen ermöglichen den SLA

Typische OLA-Inhalte

Was gehört in ein OLA?

  • Service-Beschreibung: Was wird bereitgestellt?
  • Service-Levels: Verfügbarkeit, Performance, Reaktionszeiten
  • Verantwortlichkeiten: Wer macht was? (RACI-Matrix)
  • Support-Zeiten: 24/7 oder Geschäftszeiten?
  • Eskalationsprozess: An wen bei Problemen?
  • Reporting: Wie wird gemessen und berichtet?
  • Review-Prozess: Regelmäßige Überprüfungen

Beispiel-OLA (Auszug):

### OLA: [[Netzwerk]]-Support für Application-Team

**Service**: [[Netzwerk]]-Konnektivität für Produktion
**Verfügbarkeit**: 99,8%
**Reaktionszeit**:
 - Priorität 1: 30 Minuten
 - Priorität 2: 2 Stunden
**Support-Zeiten**: 24/7
**Eskalation**: Bei Nichteinhaltung an IT-Manager
**Review**: Quartalsweise

OLAs im ITIL-Kontext

Service-Level Management

OLAs sind ein zentraler Bestandteil des Service-Level Management-Prozesses:

  1. SLAs definieren - Was versprechen wir [[Kunden]]?
  2. OLAs erstellen - Welche internen Services brauchen wir dafür?
  3. [[UC]]s verhandeln - Welche externen Lieferanten brauchen wir?
  4. Monitoring - Werden alle Levels eingehalten?
  5. Reporting & Review - Kontinuierliche Verbesserung
Service Value Chain

In ITIL 4 unterstützen OLAs die "Deliver & Support"-Aktivität des Service Value System.

Best Practices

Erfolgsfaktoren

  • Realistisch: Keine unrealistischen Versprechen
  • Messbar: Klare Metriken definieren
  • Abgestimmt: Mit allen beteiligten Teams vereinbart
  • Dokumentiert: Schriftlich festgehalten
  • Gelebt: Regelmäßig überprüft und angepasst
  • Automatisiert: Monitoring-Tools für Metriken

Häufige Fehler

  • OLAs existieren nur auf dem Papier
  • Keine regelmäßigen Reviews
  • Unrealistische Service-Levels
  • Fehlende Verantwortlichkeiten
  • Kein Monitoring der OLA-Einhaltung

Monitoring und Reporting

OLA-Metriken

  • Availability: Verfügbarkeit des internen Service
  • Response Time: Reaktionszeit auf Anfragen
  • Resolution Time: Lösungszeit
  • Escalation Rate: Wie oft eskaliert?
  • SLA Impact: Haben OLA-Verletzungen [[SLA]]s gefährdet?

Tools