Über den Einsatz von Cookies auf dieser Website Unsere Websites benötigen einige Cookies, um ordnungsgemäß zu funktionieren (erforderlich). Darüber hinaus können mit Ihrer Zustimmung weitere Cookies verwendet werden, um die Nutzung der Website zu analysieren, die Benutzerfreundlichkeit zu verbessern und Werbung zu schalten. Weitere Informationen finden Sie in Ihren. Durch den Besuch unserer Website erklären Sie sich mit der Verarbeitung von Informationen einverstanden, wie in der IBMDatenschutzbestimmung beschrieben. Um eine reibungslose Navigation zu ermöglichen, werden Ihre Cookie-Präferenzen über die hier aufgeführten IBM Web-Domains hinweg gemeinsam genutzt.
Startseite
Themen
Service Level Objective
Was ist ein Service Level Objective (SLO)?
Ein Service Level Objective (SLO) ist ein vereinbartes Leistungsziel für einen bestimmten Service über einen definierten Zeitraum. Mit SLOs wird der erwartete Service-Status definiert, und sie helfen Stakeholdern, den Zustand bestimmter Services zu verwalten und Entscheidungen zu optimieren, die Innovation und Zuverlässigkeit in Einklang bringen.1
SLOs werden anhand von Service Level Indicators (SLIs) gemessen, das sind quantitativen Metriken für bestimmte Aspekte des Services. SLOs sind Teil einer umfassenderen Vereinbarung zwischen Service-Anbietern und Kunden –Service Level Agreements (SLAs) –, welche das Maß an Service, das ein Kunde von einem Anbieter erwarten kann, umreißen und Sanktionen für den Fall festlegen, dass die Ziele nicht erreicht werden.
Damit sie sowohl mit den Geschäftsanforderungen als auch mit den Kundenwünschen übereinstimmen, müssen SRE-Teams (Site Reliability Engineering), DevOps, IT und andere relevante Teams die kritischen User Journeys für jede Anwendung kennen: die Interaktionen, mit denen die Endnutzer ihr gewünschtes Ergebnis erreichen können.
Für erfolgreiche SLOs (und damit auch SLAs) ist die interne Beteiligung von entscheidender Bedeutung, und mehrere Interessengruppen sollten an der Festlegung der SLOs beteiligt sein, darunter Produktmanager, DevOps- und Problemmanagement-Teams sowie Infrastrukturingenieure. Externe Kunden werden über Fokusgruppen, Studien, Kundenbeschwerden und soziale Medien in die Diskussion einbezogen.
Die Hauptlogik hinter den SLOs ist, dass die Zuverlässigkeit der Dienste die Zufriedenheit der Nutzer erhöht, was wiederum zu größeren Geschäftsmöglichkeiten führt. Messbare Zuverlässigkeitsziele tragen dazu bei, dass ein Unternehmen ein angenehme und effiziente Nutzererfahrung und angemessene Kosten miteinander vereinbaren kann: Das IT-Budget wird nicht durch Service-Levels belastet, die über das erforderliche oder erwartete Maß hinausgehen.
SLOs sind notwendig, weil sie die Quality of Service (QoS) oder Dienstgüte und die Zuverlässigkeitsziele in konkreten, messbaren und objektiven Begriffen definieren. Sie sind nicht dazu gedacht, das beste Leistungsniveau zu definieren, sondern eine Reihe von bestmöglichen und am wenigsten akzeptablen Leistungsstandards.1
Das Ziel von SLOs wird in 97 Things Every Cloud Engineer Should Know (Link befindet sich außerhalb von ibm.com) von O'Reilly Media treffend zusammengefasst: „Wie kann das Management einen einfachen Weg finden, um die Kompromisse zwischen Zuverlässigkeit, Innovationsgeschwindigkeit und Kosten auf einen Blick zu erkennen? Mit SLOs. Sie schaffen klare Zuverlässigkeitsrichtlinien, die Kompromisse zwischen Cloud-Kosten, Änderungsgeschwindigkeit und externen Risiken ausbalancieren.“
Dieses E-Book räumt mit den Mythen um die Observability (Beobachtbarkeit) auf und legt ihre Rolle in der digitalen Welt dar.
SLOs ist einer von mehreren miteinander verknüpften Begriffen, die mit der Verfolgung und Bewertung der Leistung von Dienstleistungen zu tun haben:
Service Level Indicators (SLI)
Ein SLI (Service-Level-Indikator) bietet ein quantitatives Maß für einen Aspekt eines Dienstes. Es liefert die reellen Zahlen – die Messlatten für die Systemleistung – wie Fehlerraten, Batch-Output oder Anfragelatenz. In der Regel werden die Messwerte zusammengefasst und als Rate, Durchschnitt oder Prozentsatz dargestellt.
Service Level Objective (SLO)
SLOs sind die Zielwerte für diese Messungen (wie z. B. die Sicherstellung einer Antwortzeit von unter 200 Millisekunden), die eingehalten werden müssen, um Service Level Agreements (SLAs) zu erfüllen. Diese Werte werden in der Regel als Prozentsatz über einen bestimmten Zeitraum ausgedrückt.
Service Level Agreement (SLA)
SLAs sind die aus einzelnen SLOs bestehenden Vereinbarungen zwischen Anbietern und Kunden, die ein bestimmtes Maß an Serviceleistungen, Funktionen oder Prozessen garantieren. Sie legen auch die Sanktionen fest, wenn die Vereinbarung nicht eingehalten wird.
Fehlerbudget
Ein Fehlerbudget gehört zu SLOs und definiert die akzeptable Menge an Fehlern, bevor ein Vertragsbruch vorliegt. Mit einem Fehlerbudget lassen sich geplante oder ungeplante Ausfallzeiten des Dienstes, die in der Praxis unvermeidlich sind, berücksichtigen. Das Einplanen von Ausfallzeiten ermöglicht es Ihren Entwicklungsteams, fundierte Entscheidungen in Bezug auf neue Entwicklungen, den Betrieb und die Aktualisierung oder Reparatur installierter Software zu treffen.
Zuverlässigkeit und Reaktionsfähigkeit werden oft mit Zahlen nahe den 100 % gemessen: also 90%, 99%, 99,9% und so weiter. Ein Ziel für die CPU-Verfügbarkeit könnte beispielsweise so dargestellt werden:
Zuverlässigkeitsgrad | Zulässige Unzuverlässigkeit | ||
|
|
| |
pro Jahr | pro Quartal | pro 30 Tagen | |
90 % | 36,5 Tage | 9 Tage | 3 Tage |
95 % | 18,25 Tage | 4,5 Tage | 1,5 Tage |
99 % | 3,65 Tage | 21,6 Stunden | 7,2 Stunden |
99,5 % | 1,83 Tage | 10,8 Stunden | 3,6 Stunden |
99,9 % | 8,76 Stunden | 2,16 Stunden | 43,2 Minuten |
99,95 % | 4,38 Stunden | 1,08 Stunden | 21,6 Minuten |
99.99 % | 52,6 Minuten | 12,96 Minuten | 4,32 Minuten |
99,999 % | 5,26 Minuten | 1,30 Minuten | 26,9 Sekunden |
|
|
| |
Jede Dezimalstelle, die der 100 näher kommt, ist in der Regel mit höheren Kosten und höherer Komplexität verbunden. Für Kunden, ob intern oder extern, ist möglicherweise ein gewisses Maß an Reaktionsfähigkeit wichtig, ab dem sie dann jedoch keinen Unterschied mehr erkennen können. Das Festlegen von SLOs ist teils Wissenschaft, teils Kunst und es geht darum, ein Gleichgewicht zwischen statistischer Perfektion und kosteneffektiven, realistischen Zielen zu finden.
Das Entwicklungs-Team versucht vielleicht, neue Funktionen zu implementieren, während das Betriebs-Team auf Stabilität und Qualität achtet und Änderungen kontrolliert einführt. Da das Unternehmen Produkte oder Dienstleistungen für interne und externe Kunden bereitstellt, ist es wichtig, jede Serviceleistung aus dem Blickwinkel dieser Kunden zu messen.
Die SLOs helfen dabei, Unternehmen im Hinblick auf Zuverlässigkeit zusammenzubringen. Schließlich sollten sich Stakeholder auf ein messbares SLO für den Kunden einigen, das ein effektives Gleichgewicht zwischen Geschwindigkeit und Servicequalität darstellt.
Grundsätzlich sind sie wichtig, weil sie die Zuverlässigkeit und die Einhaltung der Service-Level-Vereinbarungen gewährleisten. Wenn Sie SLAs einhalten, sind Ihre Kunden zufrieden, was wiederum gut für Ihr Unternehmen ist.
SLOs sind nicht nur für externe Kunden wertvoll, sondern bieten auch wertvolle Erkenntnisse für interne Kunden. Mit ihnen können verschiedene Teams, die Leistung von Diensten und Anwendungen messen und feststellen, wie sie verbessert werden können. Dank SLOs können Unternehmen unter anderem:
Probleme bei der Zuverlässigkeit können Ihr Unternehmen Geld kosten. Wenn SLOs richtig eingerichtet sind, können Sie Lücken in der Observability erkennen und aufdecken. Ihr SLO-Setup ist möglicherweise das Einzige, bei dem Sie die Erkenntnisse aus mehreren in Ihrer Organisation verwendeten Überwachungstools zentralisieren können. Durch bessere Observability können Sie bessere Produkte anbieten, die Kundenabwanderung verringern und effizienter arbeiten.
SLOs und SLIs geben Einblick in die Leistung von Diensten und Anwendungen und liefern den Teams ein genaues Maß für Ausfallzeiten und andere potenzielle Probleme. Das ist nützlich für DevOps-, IT- und andere Teams, die bei der Aktualisierung bestehender Produkte und der Veröffentlichung neuer Funktionen ein Gleichgewicht zwischen Innovation und Zuverlässigkeit finden möchten.
Ein gut durchdachtes SLO, das den Zustand Ihres Microservices anhand der Erfahrungen Ihrer Kunden misst, bietet wertvolle Einblicke in die Produktleistung und das Benutzererlebnis.
Sowohl die Festlegung als auch die Nachverfolgung von SLOs tragen dazu bei, dass Teams aus dem gesamten Unternehmen ein gemeinsames Verständnis für einen Dienst und die damit verbundenen Erwartungen entwickeln. Durchdachte SLOs tragen dazu bei, eine Kommunikationskultur zu fördern, in der alle Stakeholder wissen, was sie von einem Service erwarten, und ihre Rolle bei der Erfüllung der SLAs verstehen.
Zusätzlich kann die Erstellung von Berichten und Automatisierungen mit SLOs jedem Mitglied Ihres Teams helfen, Fragen zu Vorfällen schneller zu beantworten. SLOs sind wichtig für Ihre DevOps-, Infrastruktur- und SRE-Teams, können aber auch dazu beitragen, fast jeden Aspekt Ihres Unternehmens zu verändern. Die durch Observability gesammelten Daten können in zugängliche, kontextbezogene und umsetzbare Informationen umgewandelt werden. Diese Erkenntnisse bieten die Transparenz, die Ihre Teams benötigen, um zeitnahe und kosteneffiziente Entscheidungen zu treffen.
Mit eindeutig formulierten Zielen können Unternehmen die SLIs durch Automatisierung überwachen und messen. Auf diese Weise kann sichergestellt werden, dass die Ziele erreicht werden, wobei angestrebt wird, über die Überwachung hinaus zu einer vollständigen Automatisierung der End-to-End-Prozesse zu gelangen.
Ein automatisiertes Überwachungssystem kann dazu beitragen, potenzielle Probleme bereits in der Entstehungsphase zu erkennen, noch bevor die Serviceleistung die in den SLOs festgelegten Ziele verfehlt oder die SLAs verletzt. Nachdem Prozesse, die SLOs erfüllen, etabliert sind, kann eine Automatisierung für eine konsistente Leistung implementiert werden, zum Beispiel durch die Verwendung einer Plattform, die die Ressourcenzuweisung auf der Grundlage des Workload-Bedarfs automatisiert.
Dank SLOs können DevOps-Teams potenzielle Probleme vorausschauend erkennen, bevor sie auftreten. Diese Weitsicht verhindert inakzeptable Ausfallzeiten oder andere Ereignisse, die sich negativ auf den Endbenutzer auswirken oder das Unternehmen Geld kosten könnten.
SLAs basieren oft auf monatlichen Ausfallzeiten oder prozentualen Verfügbarkeitsraten zur Abrechnung. Unter Ausfallzeit versteht man den Zeitraum, in dem ein System seine Hauptfunktion nicht mehr erfüllen kann. Beispielsweise führen Kommunikationsausfälle zu Netzwerkausfallzeiten. Der Verfügbarkeitsstandard in der Branche bleibt hoch und damit auch die Kosten von Ausfallzeiten. Abgesehen von der finanziellen Auswirkung führen nicht eingehaltene SLOs zu Unzufriedenheit bei den Kunden.
Viele Unternehmen etzen auf ein reaktives Incident Management. Wenn Sie jedoch warten, bis ein Vorfall eintritt, dauert es länger, die Probleme in Ihrem System zu entschärfen und zu beheben, was die Mean Time to Repair (MTTR)1 erhöht. Richtig festgelegte SLOs tragen zur Verbesserung der Observability bei und ermöglichen es Unternehmen, im Hinblick auf das Incident Management proaktiver vorzugehen.
Irrelevante Warnmeldungen erhöhen nicht nur die Betriebskosten, sondern können auch zu hohen Burnout-Raten führen. Denn Ingenieure verschwenden Zeit und sind weniger produktiv, wenn sie auf nicht vorhandene Warnmeldungen reagieren. Die größte Herausforderung bei der Warnmeldung besteht darin, das richtige Gleichgewicht zwischen zu vielen und zu wenigen Warnmeldungen zu finden.
Eine relevante Warnung wäre eine, die einen Ingenieur benachrichtigt, wenn die Beeinträchtigung wahrscheinlich zum Verfehlen eines Ziels bezüglich der Zuverlässigkeit führen wird - eine symptombasierte Warnung. So ist es beispielsweise ein ernstes Problem, wenn die Antwortlatenz eines Dienstes in der vergangenen Stunde dazu führt, dass die Latenz-SLO für die ganze Woche nicht eingehalten werden kann.
Fragen Sie Geschäftsleute, welches Ziel sie für ihre Systemverfügbarkeit anstreben, werden viele sagen, dass sie gerne 100 % erreichen würden. Das ist zwar sehr ehrgeizig, aber auch sehr kostspielig und könnte einen Großteil des IT-Budgets auffressen, noch vor dem Erreichen der Ziele. SLOs sind nicht dazu da, um anzugeben, sondern um die Kundenerwartungen zu erfüllen. Denn nur zufriedene Kunden kommen wieder. Verlässlichkeit ist ein Mittel, kein Zweck.
Nur weil eine Leistungskennzahl gemessen werden kann, bedeutet das nicht, dass sie für die Zufriedenheit Ihrer Kunden oder Ihr Endergebnis wichtig ist. Sie Priorisieren. Konzentrieren Sie sich dabei auf die Metriken, die am ehesten auf eine positive Customer Experience hinweisen.
In Foundations of Service Level Management (Link führt zu Seite außerhalb von ibm.com) stellen Rick Sturm und Wayne Morris die folgende Checkliste zum Festlegen realistischer SLOs vor.
SLOs sind:
· Erreichbar
· Wiederholbar
· Messbar
· Verständlich
· Aussagekräftig
· Steuerbar
· Kosteneffizient
- Für beide Seiten akzeptabel
Beachten Sie, dass ihre Liste mit "erreichbar" beginnt. Alles auf eine Karte zu setzen, ist sehr teuer und kann zu einer längeren Betriebszeit führen, als von Ihren Kunden erwartet wird. Hier sind einige wichtige Best Practices, die Ihnen beim Erreichen Ihrer SLO-Ziele helfen können:
Definieren Sie SLOs, die das SLA oder Geschäftsziel unterstützen. Sind 20 SLOs wirklich viermal besser als fünf SLOs? Oder würde dies einfach mehr Arbeit für Ihr IT-Team verursachen und den Kunden verwirren – ohne einen nennenswerten Nutzen? Sie müssen nicht alles bewerten, was messbar ist.
Legen Sie realistische SLO-Ziele fest, anstatt zu viel zu versprechen und dann zu wenig zu liefern, was zu kostspieligen Vertragsstrafen und vielleicht sogar zum Verlust eines Kunden führen kann. Realistisch zu sein, sowohl gegenüber internen Stakeholdern als auch mit Kunden, ermöglicht es jedem, fundierte Entscheidungen zu treffen. Unrealistisch hohe SLO-Ziele verursachen auf lange Sicht nur höhere Kosten.
Indem Sie sich im Vorfeld auf realistische Erwartungen einigen, vermeiden Sie Verwirrung und Konflikte zwischen internen Teams und mit dem Kunden.
Manuelle Berichte zur Erfassung von Metriken können die Korrektur verlangsamen und verhindern möglicherweise eine Ursachenanalyse. Sammeln Sie relevante SLIs, um SLOs automatisch zu bewerten und eine automatische Warnung einzubauen, bevor ein SLO verletzt wird. Geben Sie den von Ihren Mitarbeitern benötigten Kontext für die Problemlösung an, bevor es größer wird.
Weiterführende Lösungen
IBM Instana demokratisiert die Observability, indem es eine Lösung bereitstellt, mit der jeder in den Bereichen DevOps, SRE, Plattform, ITOps und Entwicklung die gewünschten Daten mit dem benötigten Kontext abrufen kann. Die Plattform wurde speziell für cloudnative Zwecke entwickelt und ist technologieunabhängig. Sie liefert automatisch und kontinuierlich hochgenaue Daten mit einer Granularität von einer Sekunde und End-to-End-Traces sowie den Kontext logischer und physischer Abhängigkeiten über mobile, web, Anwendungen und Infrastruktur.
Mit Turbonomic®, der hybriden IBM-Plattform zur Optimierung der Cloud-Kosten können Sie kritische Aktionen kontinuierlich in Echtzeit automatisieren, um Ihren Anwendungen auf jeder Ebene des Stacks proaktiv die effizienteste Nutzung von Rechen-, Speicher- und Netzwerkressourcen zu ermöglichen.
Ressourcen
Erfahren Sie, wie Sie mit Instana® Ihre Service-Level-Ziele erstellen und verwalten können, um die Quality of Service und die Zuverlässigkeitsziele in konkreten, messbaren und objektiven Begriffen zu analysieren.
Erfahren Sie, wie Sie mit Hilfe von Enterprise Observability herausfinden können, wie die Leistung überall und jederzeit ist.
Automatisieren Sie Aufgaben des IT-Betriebs, beschleunigen Sie die Software-Bereitstellung und minimieren Sie IT-Risiken mit Site Reliability Engineering.
Fußnoten
1 „Service Level Objectives“, IBM, 6. September 2023.