Close

Vorfallmanagement für High-Velocity-Teams

SLA, SLO und SLI: Was sind die Unterschiede?

Eines haben alle Technologieunternehmen gemeinsam – ihre Benutzer.

Ganz gleich, ob es sich um die von Milliarden Menschen im Monat aktiv genutzte Google-Suchmaschine handelt, deren Nutzer kostenlos mit dem Service interagieren, oder um Salesforce mit 3,75 Mio. zahlenden Abonnenten: Die Bereitstellung eines Technologieprodukts bedeutet, dass du Menschen bedienst.

In der von ununterbrochener Verfügbarkeit geprägten Welt von heute haben die Benutzer hohe Erwartungen – sowohl an kostenlose als auch an kostenpflichtige Services. Geschwindigkeit. Verfügbarkeit. Eine zweckmäßige Benutzererfahrung. Die Benutzer von heute erwarten, dass alles hohe Standards erfüllt.

Logo von Looker

Looker stellt seine Services jeden Tag mehr als 200.000 Benutzern zur Verfügung und vertraut dabei auf Opsgenie.

Deshalb ist es für Unternehmen wichtig, SLAs, SLOs und SLIs zu verstehen und zu nutzen. Diese drei Akronyme stehen für die Versprechen gegenüber unseren Benutzern, die internen Ziele zur Einhaltung dieser Versprechen und die nachverfolgbaren Messwerte, die uns zeigen, wie wir abschneiden.

Das Ziel von SLAs, SLOs und SLIs ist es, bei allen – sowohl Anbietern als auch Kunden – für Einigkeit in Sachen Systemleistung zu sorgen. Wie oft werden Systeme verfügbar sein? Wie schnell wird das Team reagieren, wenn das System ausfällt? Was versprichst du in puncto Geschwindigkeit und Funktionalität? Benutzer möchten das wissen. Deswegen benötigst du SLAs, SLOs und SLIs.

Die Unterschiede zwischen SLAs, SLOs und SLIs

SLA: Service Level Agreement

Was ist ein SLA?

Ein SLA (Service Level Agreement) ist eine Vereinbarung zwischen Anbieter und Kunden über messbare Metriken wie Verfügbarkeit, Reaktionsfähigkeit und Verantwortlichkeiten.

Diese Vereinbarungen werden in der Regel von den für Neukunden und Rechtsbelange zuständigen Teams eines Unternehmens verfasst und beinhalten sowohl deine Versprechen gegenüber Kunden als auch die Folgen bei Nichteinhaltung dieser Versprechen. Zu den Folgen gehören in der Regel finanzielle Einbußen, Servicegutschriften oder Lizenzverlängerungen.

Die Herausforderung bei SLAs

Im Fall von SLAs gestalten sich Messung, Berichterstattung und Einhaltung bekanntermaßen schwierig. Diese Vereinbarungen werden oft von Personen verfasst, die sich nicht mit den technologischen Problemen abmühen müssen, und enthalten Versprechen, die für Teams schwer zu messen sind, nicht immer zu den aktuellen und sich ständig weiterentwickelnden Unternehmensprioritäten passen und Kleinigkeiten nicht berücksichtigen.

Ein SLA kann beispielsweise versprechen, dass Teams gemeldete Probleme mit Produkt X innerhalb von 24 Stunden beheben. Doch das SLA enthält keine Angaben dazu, was passiert, wenn der Kunde 24 Stunden benötigt, um Antworten oder Screenshots zu senden, damit dein Team das Problem diagnostizieren kann. Bedeutet dies, dass das 24-Stunden-Fenster des Teams aufgrund der Verzögerungen auf Kundenseite abgelaufen ist? Oder wird die Uhr in Abhängigkeit davon angehalten und gestartet, wann die Kunden antworten? Diese Fragen müssen in SLAs beantwortet werden. Da dies aber oft nicht der Fall ist, gibt es bei IT-Managern mittlerweile eine gewisse Abneigung gegenüber SLAs.

Für viele Experten lässt sich diese Herausforderung in erster Linie dadurch bewältigen, dass die Techniker beim Verfassen der SLAs einbezogen werden. Je mehr die IT- und DevOps-Teams mit den Teams für Rechtsbelange und Geschäftsentwicklung zusammenarbeiten, um praxistaugliche SLAs zu erstellen, umso besser werden SLAs auch wichtige Tatsachen widerspiegeln, z. B. Kunden, die die Behebung ihrer Probleme selbst verzögern.

Wer benötigt ein SLA?

Ein SLA ist eine Vereinbarung zwischen einem Anbieter und einem zahlenden Kunden. Unternehmen, die Benutzern einen Service kostenlos zur Verfügung stellen, wollen oder benötigen wahrscheinlich kein SLA für diese Benutzer.

SLO: Service Level Objective

Was ist ein SLO?

Ein SLO (Service Level Objective) ist eine Vereinbarung innerhalb eines SLA über bestimmte Metriken wie die Verfügbarkeit oder Reaktionszeit. Wenn also ein SLA die formelle Vereinbarung zwischen dir und deinem Kunden ist, dann sind SLOs die einzelnen Versprechen gegenüber dem Kunden. SLOs bestimmen die Kundenerwartungen und teilen den IT- und DevOps-Teams mit, was sie erreichen und woran sie sich messen müssen.

Die Herausforderungen bei SLOs

Die Abneigung gegenüber SLOs ist geringer als gegenüber SLAs, sie können aber genauso viele Probleme verursachen, wenn sie vage, übermäßig kompliziert oder unmöglich zu messen sind. Einfachheit und Klarheit sind unerlässlich, um SLOs zu erstellen, mit denen die Techniker im Unternehmen gut zurechtkommen. Nur die wichtigsten Metriken sollten in die SLOs aufgenommen werden. Außerdem sollten die Ziele immer in einfacher Sprache abgefasst sein, und wie bei den SLAs sollten Probleme wie Verzögerungen auf Kundenseite berücksichtigt werden.

Wer benötigt SLOs?

SLAs sind nur für zahlende Kunden relevant, doch SLOs können bei kostenpflichtiger und kostenloser Nutzung hilfreich sein, sowohl bei internen als auch bei externen Kunden.

Interne Systeme wie CRM-Systeme, Kundendaten-Repositorys und das Intranet können genauso wichtig sein wie Systeme für externe Benutzer. SLOs für diese internen Systeme tragen in bedeutendem Maße dazu bei, dass Unternehmensziele erreicht werden und interne Teams ihre eigenen kundenorientierten Ziele erreichen können.

SLI: Service Level Indicator

Was ist ein SLI?

Mit einem SLI (Service Level Indicator) wird die Compliance mit einem SLO (Service Level Objective) gemessen. Wenn in dem SLA also beispielsweise angegeben ist, dass deine Systeme 99,95 % der Zeit verfügbar sein werden, ist dein SLO wahrscheinlich eine Verfügbarkeit von 99,95 % und dein SLI ist die Messung deiner tatsächlichen Verfügbarkeit. Diese beträgt vielleicht 99,96 %. Vielleicht aber auch 99,99 %. Um Compliance mit deinem SLA zu erreichen, muss der SLI die Versprechen im SLA erfüllen oder übertreffen.

Die Herausforderungen bei SLIs

Wie bei SLOs besteht die Herausforderung bei SLIs darin, sie einfach zu halten, die richtigen Metriken zur Nachverfolgung zu wählen und der IT die Arbeit nicht übermäßig zu erschweren, indem zu viele Metriken nachverfolgt werden sollen, die für Kunden eigentlich keine Rolle spielen.

Erstellung detaillierter Disaster-Recovery-Pläne

Was wirst du bei einem Ausfall tun? Wenn du die Antwort auf diese Frage noch nicht kennst, lautet die Standardantwort "Wertvolle Zeit verschwenden, um herauszufinden, was zu tun ist".

Je besser dein Incident-Response-Plan, umso schneller und effektiver werden deine Teams Vorfälle bewältigen können. Deshalb sollte der erste Schritt eines neuen Programms für das Vorfallmanagement immer den Prozessen und der Planung gewidmet sein.

Wer benötigt SLIs?

Jedes Unternehmen, das seine Leistung im Hinblick auf SLOs misst, benötigt SLIs für diese Messungen. Ohne SLIs können Unternehmen SLOs nicht wirklich implementieren.

SLAs: Versprechen gegenüber Kunden SLOs: interne Ziele SLIs: Wie haben wir abgeschnitten?

Best Practices rund um SLAs, SLOs und SLIs

Kundenerwartungen als Basis für SLAs

Deine Kundenvereinbarung sollte komplett auf dem basieren, was für den Kunden wichtig ist. Schlussendlich kann die Bewältigung eines Vorfalls 10 verschiedene Komponenten umfassen. Doch aus Sicht des Kunden zählt nur, dass das System wie erwartet funktioniert.

Dieser Tatsache solltest du in deinen SLAs und SLOs Rechnung tragen. Erschwere die Dinge nicht, indem du zu sehr ins Detail gehst und individuelle Versprechen für jede dieser 10 Komponenten gibst. Beschränke dich bei deinen Versprechen auf die übergeordnete, benutzerorientierte Funktionalität. Das sorgt für zufriedenere, weniger verwirrte Kunden und erleichtert den für die Einhaltung der SLA-Versprechen verantwortlichen IT-Experten den Alltag.

SLAs in einfacher Sprache

Kunden bitten nicht immer um Klarstellungen, daher werden komplizierte Formulierungen im SLA später wahrscheinlich unangenehme Missverständnisse nach sich ziehen. Je einfacher SLAs abgefasst sind, umso unwahrscheinlicher sind nachfolgende Kundenkonflikte.

Bei SLOs ist weniger mehr

Nicht jede Metrik ist für den Erfolg der Kunden entscheidend, daher sollte auch nicht jede Metrik ein SLO sein. Beschränke dich auf so wenige SLOs wie möglich und konzentriere dich auf diejenigen, die für die Kunden am wichtigsten sind.

Nicht jede nachverfolgbare Metrik sollte ein SLI sein

Das Nachverfolgen der Leistung im Hinblick auf 10 Komponenten für jedes der 10 SLOs kann sehr schnell umständlich werden. Stattdessen solltest du strategisch vorgehen und die Metriken auswählen, die für deine wesentlichen SLOs von Bedeutung sind. Dann kannst du dich darauf konzentrieren, diese effektiv nachzuverfolgen.

Einbeziehung von Faktoren, über die das IT-Team keine Kontrolle hat

Was passiert, wenn der Kunde den Lösungsprozess verlangsamt? Wenn du diesbezüglich keine klaren Angaben im SLA machst, wird von deinem Team eventuell Unmögliches erwartet, nämlich dass es Kundenprobleme ohne Kundenbeteiligung lösen soll.

Festlegung eines Fehlerbudgets

Spielraum für Fehler schützt nicht nur das Unternehmen vor SLA-Verstößen und schweren Folgen, sondern ermöglicht auch Agilität – damit das Team schnell Änderungen vornehmen und innovative neue Lösungen ausprobieren kann, die vielleicht fehlschlagen.

Google empfiehlt sogar die Verwendung von nicht aufgebrauchtem Fehlerbudget für geplante Ausfallzeiten, die dir helfen können, ungeahnte Probleme zu identifizieren (z. B. Services, die Server nicht richtig nutzen) und die Erwartungen deiner Kunden angemessen zu erfüllen.

Keine überhöhten Ziele

Nur weil dein Team vielleicht eine Verfügbarkeit von 99,99 % aufrechterhalten kann, sollten 99,99 % noch lange nicht dein SLO-Wert sein. Es ist immer besser, weniger zu versprechen und die Erwartungen zu übertreffen. Das gilt insbesondere für agile Teams, die früh und oft bereitstellen möchten und ein Fehlerbudget benötigen, um dieses schnelle Tempo beizubehalten.

Was sind die Auswirkungen auf SRE-Teams?

Für diejenigen, die das Modell von Google anwenden und mit SRE-Teams (Site Reliability Engineering) eine Verbindung zwischen Entwicklung und Operations schaffen, sind SLAs, SLOs und SLIs für den Erfolg unabdingbar. SLAs helfen Teams beim Definieren von Grenzen und Fehlerbudgets. SLOs helfen bei der Aufgabenpriorisierung. Und anhand von SLIs können SRE-Teams sehen, wann sie Bereitstellungen stoppen müssen, um das Fehlerbudget nicht zu belasten – und wann sie die Zügel locker lassen können.

Behalte mit Jira Service Management den Überblick über SLAs, um Anfragen basierend auf Prioritäten zu lösen, und verwende automatisierte Eskalationsregeln, um die richtigen Teammitglieder zu benachrichtigen und SLA-Verstöße zu verhindern.