SLI (Service Level Indicator) misst die tatsächliche Systemleistung als konkrete Kennzahl, SLO (Service Level Objective) definiert das intern angestrebte Ziel für diesen Messwert, und SLA (Service Level Agreement) ist die vertragliche Zusicherung gegenüber einem Kunden oder Nutzer, dass ein bestimmtes Leistungsniveau eingehalten wird. Die drei Begriffe beschreiben eine Hierarchie: Ohne Messung kein Ziel, ohne Ziel kein sinnvoller Vertrag.
Der häufigste Fehler in der Praxis: Unternehmen verhandeln SLAs mit Softwareanbietern, ohne jemals definiert zu haben, welche SLIs sie überhaupt messen und welche SLOs intern gelten. Das Ergebnis ist ein Vertrag, dessen Einhaltung niemand valide prüfen kann.
Die korrekte Logik läuft von unten nach oben:
Ein SLA, das auf keinem definierten SLO basiert, ist ein Dokument ohne operativen Anker.
Ein SLI ist eine präzise, quantifizierbare Messgröße, die den Zustand oder die Leistung eines Systems zu einem bestimmten Zeitpunkt beschreibt. Er ist der Rohstoff aller weiteren Service-Level-Bewertungen.
Typische SLIs in Produktions- und MES-Umgebungen:
| SLI | Messgröße | Relevanz in der Fertigung |
|---|---|---|
| Availability | % der Zeit, in der das System erreichbar ist | Produktionsstillstand bei Ausfall |
| Latency | Antwortzeit in Millisekunden | Verzögerte Maschinendaten, Fehlsteuerungen |
| Error Rate | % fehlgeschlagener Transaktionen | Datenverlust in Qualitätsprotokollen |
| Throughput | Verarbeitete Datenpunkte pro Sekunde | Engpass bei Hochfrequenz-Maschinendaten |
| Data Freshness | Alter des zuletzt geschriebenen Datensatzes | Kritisch für Echtzeit-OEE und Traceability |
SLIs werden nicht geschätzt – sie werden gemessen. Wer keinen Monitoring-Stack betreibt, der SLIs kontinuierlich erfasst, kann weder ein SLO einhalten noch ein SLA prüfen.
Ein SLO ist ein intern definiertes Leistungsziel für einen oder mehrere SLIs, typischerweise über einen festen Messzeitraum. Klassisches Beispiel: „Das MES soll im Monatsdurchschnitt zu 99,9 % verfügbar sein."
SLOs dienen dazu, Betrieb, IT und Fachbereiche auf ein gemeinsames, messbares Ziel auszurichten. Sie sind kein Versprechen nach außen – sie sind die interne Steuerungsgröße.
Praxis-Warnung: Das SLO muss immer strenger sein als das SLA. Wenn das SLA eine Verfügbarkeit von 99,5 % zusichert, sollte das interne SLO bei 99,7 % oder höher liegen – als Puffer, bevor eine Vertragsverletzung eintritt. Unternehmen, die SLO und SLA auf denselben Wert setzen, operieren dauerhaft an der Grenze und haben keinen Handlungsspielraum, bevor das Vertragsniveau gerissen wird.
Ein weiteres Konzept, das in diesem Zusammenhang direkt aus dem Google SRE-Modell stammt und inzwischen auch im Industrie-IT-Umfeld Einzug hält: das Error Budget. Wenn das SLO 99,9 % Verfügbarkeit im Monat definiert, entspricht das einem Error Budget von 0,1 % – also ca. 43 Minuten tolerierter Ausfallzeit pro Monat. Ist dieses Budget aufgebraucht, werden keine riskanten Deployments mehr durchgeführt, bis es sich regeneriert hat. Das macht Risikomanagement operationalisierbar.
Ein SLA ist eine rechtsverbindliche Vereinbarung zwischen Anbieter und Auftraggeber. Es definiert, welche SLOs garantiert werden, wie die Einhaltung gemessen wird, welche Konsequenzen bei Unterschreitung gelten und wie Eskalationswege aussehen.
In Produktionsumgebungen beziehen sich SLAs auf Cloud-MES- oder ERP-Verfügbarkeit, maximale Wiederherstellungszeiten nach Ausfall (RTO), Datenverfügbarkeit und Backup-Aktualität (RPO) sowie Support-Reaktions- und Lösungszeiten nach Störungsklasse.
Kritischer Punkt, der in fast allen SLA-Verhandlungen übersehen wird: Die meisten SLAs definieren Verfügbarkeit als prozentualen Jahresdurchschnitt. 99,9 % Verfügbarkeit klingt nach einem soliden Wert – bedeutet aber bis zu 8,7 Stunden Ausfall pro Jahr, die in einem einzigen Ereignis auftreten können. Wer einen RTO von 2 Stunden für sein MES definiert hat, ist mit einer 99,9%-SLA vertraglich nicht ausreichend abgesichert. Die relevante Klausel ist die maximale Single-Incident-Downtime, nicht die jährliche Gesamtverfügbarkeit.
| Ebene | Begriff | Zweck | Adressat |
|---|---|---|---|
| Messen | SLI | Ist-Zustand quantifizieren | IT-Betrieb, Monitoring |
| Steuern | SLO | Intern angestrebtes Ziel | Betrieb, Produktions-IT, Management |
| Garantieren | SLA | Vertraglich zugesichertes Minimum | Kunde, Auftraggeber, Auditor |
Ein Produktionsbetrieb betreibt ein Cloud-MES. Vereinbart ist eine SLA mit 99,5 % monatlicher Verfügbarkeit. Intern gibt es kein definiertes SLO, kein Monitoring der tatsächlichen Verfügbarkeit als SLI.
Um 02:30 Uhr fällt das System für 3,5 Stunden aus. Die Nachtschicht arbeitet auf Papier weiter, Qualitätsprotokolle werden manuell nachgetragen – mit allen bekannten Risiken für die Audit Readiness. Montagmorgen prüft die IT: 3,5 Stunden von maximal ~3,6 Stunden tolerierter Ausfallzeit im Monat sind in einer Nacht aufgebraucht.
Das Problem: Da kein SLI kontinuierlich gemessen wurde, ist der Nachweis gegenüber dem Anbieter schwierig. Da kein SLO definiert war, hat niemand intern eine Eskalation ausgelöst. Und da das SLA keine Regelung zur Single-Incident-Downtime enthält, ist der Anbieter formal im grünen Bereich.
Das hätte vermieden werden können: SLI-Monitoring mit automatischem Alert ab 30 Minuten Ausfall, ein SLO von 99,8 % als interne Schwelle, und ein SLA mit expliziter Klausel zur maximalen Einzelstörungsdauer.
1. Brauche ich SLOs auch, wenn ich keine externe SLA habe? Ja – gerade dann. SLOs sind primär ein internes Steuerungsinstrument. Wer kein definiertes SLO hat, kann Betriebsstabilität nicht systematisch bewerten und hat keine objektive Grundlage, um auf Verschlechterungen zu reagieren, bevor sie zu Produktionsrisiken werden.
2. Wie granular sollten SLIs in einem MES-Umfeld sein? Mindestens drei SLIs sollten für jedes produktionskritische System definiert sein: Availability (Erreichbarkeit), Latency (Antwortzeit für kritische Operationen wie Auftragsrückmeldung) und Error Rate (fehlgeschlagene Schreibvorgänge in Qualitäts- oder Traceability-Daten). Data Freshness ist ein vierter SLI, der in Echtzeit-Produktionsumgebungen zunehmend an Bedeutung gewinnt.
3. Wer ist im Unternehmen für SLOs verantwortlich? In der klassischen IT-Organisation liegt das beim IT-Betrieb. In Fertigungsunternehmen, in denen OT und IT zusammenwachsen, ist das eine gemeinsame Verantwortung von Produktions-IT und dem Fachbereich – denn nur der Fachbereich kann bewerten, welche Latenz oder Ausfallzeit operativ tolerierbar ist.
4. Was passiert, wenn ein SLA-Wert unterschritten wird? Das hängt vom Vertragstext ab. Üblich sind gestaffelte Gutschriften (Service Credits) auf das Nutzungsentgelt. In kritischen Produktionsumgebungen können darüber hinaus Vertragsstrafen, Sonderkündigungsrechte oder Schadensersatzansprüche vereinbart werden. Wichtig: Gutschriften ersetzen keinen Produktionsschaden – sie sind ein Compliance-Mechanismus, kein Schadensausgleich.
5. Wie hängen SLA/SLO/SLI mit RPO und RTO zusammen? RPO und RTO sind spezifische SLOs für den Disaster-Recovery-Fall: Der RTO ist das SLO für die Wiederherstellungszeit nach einem Ausfall, der RPO ist das SLO für den maximalen Datenverlust. Ein vollständiges Service-Level-Modell für produktionskritische Systeme enthält beides – laufende SLOs für den Normalbetrieb und RPO/RTO als SLOs für den Ausnahmefall.
Ein vollständiges SLI/SLO/SLA-Modell macht die Betriebsqualität digitaler Produktionssysteme zum ersten Mal objektiv vergleichbar, steuerbar und vertraglich durchsetzbar. Wer als Fertigungsunternehmen Cloud-MES oder digitale Plattformlösungen einsetzt, übernimmt damit eine operative Abhängigkeit – und sollte diese Abhängigkeit mit denselben Mitteln steuern, mit denen er auch Maschinenkapazitäten, Lieferzeiten und Qualitätskennzahlen steuert: mit messbaren Zielwerten, klaren Verantwortlichkeiten und definierten Eskalationswegen.