Vereinbarungen zum Servicelevel - SLA, SLO, SLI

Die Erwartung der Menschen in unserer Always-on-Welt, sowohl an kostenlose als auch an kostenpflichtige Dienste ist hoch. Die Benutzerbasis erwartet das Geschwindigkeit, Nützlichkeit, UX einem hohen Standard entspricht.

Warum Servicelevel-Vereinbarungen?

Aufgrund der Erwartungen der Benutzerbasis ist es wichtig, dass Unternehmen SLAs, SLOs und SLIs verstehen und pflegen - drei Abkürzungen, die die Versprechen darstellen, die wir unseren Benutzern geben. Es sind interne Ziele, die uns helfen, diese Versprechen basierend auf nachvollziehbaren Messungen zu halten und uns zeigen wo wir stehen.

Das Ziel aller drei Vereinbarungen ist es, alle – Anbieter und Kunden gleichermaßen – in Bezug auf die Systemleistung auf die gleiche Seite zu bringen. Wie oft werden Ihre Systeme verfügbar sein? Wie schnell wird Ihr Team reagieren, wenn das System ausfällt? Welche Versprechungen machen Sie in Bezug auf Geschwindigkeit und Funktionalität? Benutzer wollen es wissen – und deshalb brauchen Sie SLAs, SLOs und SLIs.

SLA: Service Level Agreements

Was ist ein SLA?

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

Diese Vereinbarungen werden in der Regel von den neuen Geschäfts- und Rechtsteams eines Unternehmens erstellt und stellen die Versprechen dar, die Sie Kunden machen – und die Konsequenzen, wenn Sie diese Versprechen nicht einhalten. Zu den Folgen gehören in der Regel Geldstrafen, Servicegutschriften oder Lizenzverlängerungen.

Herausforderung von SLAs

SLAs sind notorisch schwer zu messen, zu melden und zu erfüllen. Diese Vereinbarungen – im Allgemeinen von Leuten geschrieben, die selbst nicht in den Tech-Gräben stehen – machen oft Versprechungen, die für Teams schwer zu messen sind, nicht immer mit aktuellen und sich ständig weiterentwickelnden Geschäftsprioritäten übereinstimmen und keine Nuancen berücksichtigen.

Beispielsweise kann ein SLA versprechen, dass Teams gemeldete Probleme mit Produkt X innerhalb von 24 Stunden lösen. Aber das gleiche SLA legt nicht fest, was passiert, wenn der Client 24 Stunden braucht, um Antworten oder Screenshots zu senden, um Ihrem Team bei der Diagnose des Problems zu helfen. Bedeutet dies, dass das 24-Stunden-Fenster des Teams durch Client-Verlangsamungen aufgezehrt wurde, oder beginnt und stoppt die Uhr basierend auf der Antwort des Clients? SLAs müssen diese Fragen beantworten, tun dies aber oft nicht – eine Tatsache, die ihnen gegenüber bei IT-Managern viel Feindseligkeit hervorgerufen hat.

Für viele Experten lautet die Antwort auf diese Herausforderung in erster Linie, dass die Technik in die Erstellung von SLAs einbezogen werden sollte. Je mehr IT und DevOps mit der Rechtsabteilung und der Geschäftsentwicklung zusammenarbeiten, um SLAs zu entwickeln, die sich auf reale Szenarien beziehen, desto mehr SLAs werden beginnen, wichtige Realitäten widerzuspiegeln, wie z. B. Kunden, die ihre eigene Problemlösung verzögern.

Wer braucht ein SLA?

Ein SLA ist eine Vereinbarung zwischen einem Anbieter und einem zahlenden Kunden. Es ist unwahrscheinlich, dass Unternehmen, die Benutzern einen kostenlosen Dienst anbieten, ein SLA für diese kostenlosen Benutzer wünschen oder benötigen.

SLO: Service Level Objectives

Was ist ein SLO?

Ein SLO (Service Level Objective) ist eine Vereinbarung innerhalb eines SLA über eine bestimmte Metrik wie Verfügbarkeit oder Reaktionszeit. Wenn das SLA also die formelle Vereinbarung zwischen Ihnen und Ihrem Kunden ist, sind SLOs die individuellen Versprechen, die Sie diesem Kunden geben. SLOs setzen Kundenerwartungen und sagen IT- und DevOps-Teams, welche Ziele sie erreichen und an denen sie sich messen müssen.

Herausforderungen von SLOs

SLOs werden weniger gehasst als SLAs, aber sie können genauso viele Probleme verursachen, wenn sie vage, übermäßig kompliziert oder unmöglich zu messen sind. Der Schlüssel zu SLOs, die Ihre Ingenieure nicht dazu bringen, sich die Haare zu raufen, ist Einfachheit und Klarheit. Nur die wichtigsten Metriken sollten sich für den SLO-Status qualifizieren, die Ziele sollten in einfacher Sprache formuliert sein und, wie bei SLAs, sollten sie immer Probleme wie Verzögerungen auf Client-Seite berücksichtigen.

Wer braucht SLOs?

Wo SLAs nur für zahlende Kunden relevant sind, können SLOs sowohl für bezahlte als auch für unbezahlte Konten sowie für interne und externe Kunden nützlich sein.

Interne Systeme wie CRMs, Kundendatenspeicher und Intranet können genauso wichtig sein wie externe Systeme. SLOs für diese internen Systeme zu haben, ist nicht nur wichtig, um die Geschäftsziele zu erreichen, sondern es internen Teams zu ermöglichen, ihre eigenen kundenorientierten Ziele zu erreichen.

SLI: Service Level Indicators

Was ist ein SLI?

Ein SLI (Service Level Indicator) misst die Einhaltung eines SLO (Service Level Objective). Wenn Ihr SLA beispielsweise angibt, dass Ihre Systeme zu 99,95 % der Zeit verfügbar sein werden, entspricht Ihr SLO wahrscheinlich einer Betriebszeit von 99,95 % und Ihr SLI ist die tatsächliche Messung Ihrer Betriebszeit. Vielleicht sind es 99,96 %. Vielleicht 99,99 %. Um Ihr SLA einzuhalten, muss der SLI die in diesem Dokument gemachten Zusagen erfüllen oder übertreffen.

Herausforderungen von SLIs

Wie bei SLOs besteht die Herausforderung bei SLIs darin, sie einfach zu halten, die richtigen zu verfolgenden Metriken auszuwählen und die Arbeit der IT nicht zu verkomplizieren, indem zu viele Metriken verfolgt werden, die für Kunden eigentlich nicht wichtig sind.

Erstellen Sie einen detaillierten Notfallwiederherstellungsplan:

• Was werden Sie tun, wenn Ausfallzeiten auftreten?
• Wenn Sie die Antwort auf diese Frage noch nicht kennen, lautet die Standardantwort „Kostbare Zeit damit verschwenden, herauszufinden, was zu tun ist“.

Je besser Ihr Plan zur Reaktion auf Vorfälle ist, desto schneller und effektiver werden Ihre Teams Vorfälle bearbeiten. Aus diesem Grund sollte der erste Schritt jedes neuen Incident-Management-Programms der Prozess und die Planung sein.

Wer braucht SLIs?

Jedes Unternehmen, das seine Leistung anhand von SLOs misst, benötigt SLIs, um diese Messungen durchführen zu können. SLOs sind ohne SLIs nicht wirklich möglich.

• SLAs: Versprechen an Kunden.
• SLOs: interne Ziele.
• SLIs: wie haben wir abgeschnitten?

Best Practices für SLA, SLO und SLI

Jeder Teil Ihrer Kundenvereinbarung sollte darauf ausgerichtet sein, was für den Kunden wichtig ist. Auf der Rückseite kann ein Vorfall bedeuten, dass 10 verschiedene Komponenten angesprochen werden. Aber aus Sicht des Kunden zählt nur, dass das System wie erwartet funktioniert.

Ihre SLAs und SLOs sollten diese Realität widerspiegeln. Machen Sie die Dinge nicht zu kompliziert.