Ein Service-Level-Review sollte erklären, welche Leistung Nutzer erhalten haben, wie sie zum vereinbarten Ziel passt und was das Team als Nächstes tun sollte. Eine grüne Prozentzahl reicht nicht. Die Zuhörer müssen wissen, was gezählt wurde, welchen Zeitraum die Kennzahl abdeckt und ob eine kleine Nutzergruppe deutlich schlechtere Erfahrungen gemacht hat, als der Gesamtwert vermuten lässt.
Beginnen Sie mit einer hinterfragbaren Aussage: „Der Dienst zum Einreichen von Tickets hat sein Erfolgsquotenziel erreicht. Ein einzelner Vorfall verursachte jedoch den Großteil der Fehler. Wir empfehlen, zunächst diesen Fehlerpfad zu untersuchen, bevor wir das Ziel verschärfen.“ Zeigen Sie danach die Berechnung und den betroffenen Ablauf. Das ist hilfreicher als ein Dashboard-Screenshot mit zwölf unerklärten Zahlen.
Freigegebene Review-Notizen lassen sich mit Presentis Text-zu-Präsentation-Tool in einen bearbeitbaren Foliensatz übertragen. Die Belege kommen aus Ihren Monitoring- und Supportsystemen. Presenti hilft beim Strukturieren und Bearbeiten der Folien; es erfasst keine Service-Telemetrie und entscheidet nicht, ob ein SLO erfüllt wurde.
Dienst, Kennzahl und Zeitraum klar abgrenzen
Begrenzen Sie das Review auf einen Nutzerablauf, den unterstützenden Dienst und das Berichtsfenster. „Zuverlässigkeit der Plattform“ ist zu weit gefasst, wenn die Belege lediglich das Einreichen von Tickets betreffen. Eine erfolgreiche Ticketeinreichung beweist nicht, dass auch Anmeldung, Suche und Benachrichtigungen funktionierten.
Drei Begriffe gehören auf die erste Ergebnisfolie oder in ein kleines Glossar daneben. Die SRE-Erläuterung von Google zu Service-Level-Zielen unterscheidet Messgröße, Ziel und Vereinbarung:
| Begriff | Bedeutung | Darzustellen |
|---|---|---|
| SLI: Service-Level-Indikator | Quantitative Messgröße für das Verhalten eines Dienstes. | Gemessenes Ergebnis und Berechnung. |
| SLO: Service-Level-Ziel | Zielwert für diese Messgröße über einen definierten Zeitraum. | Vereinbarte Schwelle, Geltungsbereich und Zeitfenster. |
| SLA: Service-Level-Vereinbarung | Vereinbarung, die Folgen für die Nichterfüllung ihrer Leistungszusagen vorsieht. | Anwendbare Vereinbarung und deren eigene Messbedingungen, sofern die Vertragserfüllung Gegenstand des Reviews ist. |
Nennen Sie ein internes SLO-Ergebnis nicht einfach „SLA-Erfüllung“, nur weil die Prozentzahlen ähnlich aussehen. Die Vereinbarung kann andere Leistungsgrenzen, Ausschlüsse oder Berechnungszeiträume enthalten. Trennen Sie das operative Ergebnis von der vertraglichen Bewertung. Die Folie allein belegt weder einen Vertragsverstoß noch einen Anspruch auf Gutschrift.
Durchgerechnetes Beispiel: ein Dienst zur Ticketeinreichung
Der folgende Dienst, seine Datensätze und alle Zahlen sind fiktiv. Sie zeigen, wie ein Review aufgebaut werden kann. Es handelt sich weder um Leistungsdaten von Presenti noch um eine Kundenfallstudie.
Eine Supportplattform untersucht, ob Kunden neue Tickets einreichen konnten. Das vereinbarte Erfolgsquoten-SLO beträgt für diesen festen Zeitraum von 28 Tagen 99,90 %. Die folgende Messdefinition gehört neben das Ergebnis, nicht in einen versteckten Anhang.
| Angabe | Definition im Beispiel |
|---|---|
| Nutzerablauf | Ein neues Supportticket einreichen und eine nutzbare Ticket-ID erhalten. |
| Zeitfenster | Vom 1. September, 00:00 UTC (einschließlich), bis zum 29. September, 00:00 UTC (ausschließlich): 28 vollständige Tage. |
| Berücksichtigtes Ereignis | Authentifizierter, korrekt aufgebauter Einreichungsversuch im Produktivbetrieb, der vom Gateway angenommen wurde. Jeder Versuch besitzt eine eigene Request-ID. |
| Gutes Ereignis | Das Ticket wird gespeichert, und der einreichende Client erhält eine nutzbare Ticket-ID. |
| Ausgeschlossener Datenverkehr | Health-Checks, gekennzeichneter Testverkehr und Anfragen, die die vorab vereinbarten Einbeziehungsregeln nicht erfüllen. Diese Regeln standen vor dem Berichtszeitraum fest. |
| Belege | Ein eingefrorener Gateway-Export, über die Request-ID mit Ergebnissen des Ticketdienstes verknüpft; Abfrageversion und Extraktionszeitpunkt werden dem Foliensatz beigefügt. |
| Abdeckungsgrenze | Fehler, die vor Erreichen des Gateways auftreten, werden von diesem SLI nicht erfasst. |
Der Nenner zählt Einreichungsversuche, nicht Kunden. Nach dieser Definition erzeugt ein erneuter Versuch ein weiteres Ereignis. Unternimmt ein Kunde insgesamt zehn Einreichungsversuche, enthält das Review zehn Ereignisse, nicht zehn betroffene Kunden. Behalten Sie diese Unterscheidung sowohl in der Grafikbeschriftung als auch in den Vortragsnotizen bei.
Auch die Abdeckungsgrenze ist wichtig. Eine defekte Anmeldeseite könnte Kunden vom Gateway fernhalten, während dieser SLI weiterhin gut aussieht. Zeigen Sie die Lücke neben dem Ergebnis und verwenden Sie für den umfassenderen Ablauf separate Belege. Verbessern Sie die Prozentzahl nicht, indem Sie fehlgeschlagene Anfragen erst nach Ende des Zeitraums ausschließen.
Die Fehlerbudget-Rechnung zeigen, nicht nur eine Farbe
Die Google-Leitlinien zur SLO-Umsetzung beschreiben ereignisbasierte Indikatoren als gute Ereignisse geteilt durch alle berücksichtigten Ereignisse. Bei einem Prozentziel unter 100 % ergibt die Differenz den zulässigen Anteil schlechter Ereignisse. Für unseren abgeschlossenen Beispielzeitraum lautet die Rechnung:
| Größe | Berechnung | Ergebnis |
|---|---|---|
| Berücksichtigte Versuche | Anzahl der Request-IDs im Geltungsbereich | 2.000.000 |
| Erfolgreiche Versuche | Bestätigte erfolgreiche Ergebnisse | 1.998.600 |
| Fehlgeschlagene Versuche | 2.000.000 − 1.998.600 | 1.400 |
| Gemessene Erfolgsquote | 1.998.600 ÷ 2.000.000 × 100 | 99,93 % |
| Zulässige Fehlversuche | 2.000.000 × (1 − 0,9990) | 2.000 |
| Verbrauchtes Budget | 1.400 ÷ 2.000 × 100 | 70 % |
| Unverbrauchter Spielraum dieses Zeitraums | 2.000 − 1.400 | 600 Versuche |
Das Erfolgsquotenziel wurde erreicht: 99,93 % liegen über 99,90 %. Der Abstand beträgt 0,03 Prozentpunkte. Verbraucht wurden 70 % der zulässigen Fehler, nicht 70 % aller Anfragen.
Beschriften Sie die verbleibenden 600 Versuche sorgfältig. Sie beziehen sich auf den abgeschlossenen Berichtszeitraum und sind keine Erlaubnis, im nächsten Monat 600 Fehler zu verursachen. Ein rollierendes Produktions-SLO benötigt eine eigene Berechnung für das aktuelle Fenster. Ebenso ist ein Ereignisbudget keine Ausfallzeit in Minuten. Eine Minute mit hohem und eine mit geringem Datenverkehr können sehr unterschiedlich viele Fehlversuche beitragen.
Bewahren Sie die ungerundeten Werte in der Quelldatei auf und runden Sie im Foliensatz einheitlich. Liegt ein Ergebnis nahe an der Schwelle, darf Rundung eine Verfehlung nicht wie eine Erfüllung aussehen lassen. Halten Sie Abfrage und Zeitfenster bei der Folie fest, damit jemand anderes das Ergebnis später reproduzieren kann.
Erklären, wen die Fehler betroffen haben
In den fiktiven Daten entfallen 1.200 der 1.400 Fehlversuche auf einen einzelnen Vorfall. Diese 1.200 Versuche lassen sich 140 unterschiedlichen Konto-IDs zuordnen. Der Vorfall verbrauchte damit 60 % des gesamten Fehlerbudgets: 1.200 geteilt durch 2.000. Die übrigen 200 Fehler beanspruchten weitere 10 %.
Daraus ergibt sich eine nützliche Überschrift für die Auswirkungsfolie: „Ein Vorfall verbrauchte den Großteil des Fehlerbudgets und betraf 140 Konten.“ Die Daten rechtfertigen dagegen weder „140 Personen konnten nicht arbeiten“ noch „1.200 Tickets gingen verloren“. Konten können mehrere Nutzer haben; wiederholte Versuche können dasselbe beabsichtigte Ticket betreffen. Die Fehlerzahl sagt zudem nicht, ob ein Ticket schließlich doch angelegt wurde.
Stellen Sie neben der Anzahl den betroffenen Ablauf dar. Im Beispiel erhielten Kunden während des Vorfalls nicht zuverlässig eine Ticketbestätigung. Supportaufzeichnungen können erläutern, was sie danach taten. Leiten Sie aus wenigen Supportgesprächen jedoch keine Aussage über jedes betroffene Konto ab.
Eine kleine Auswirkungsübersicht kann aus drei Zeilen bestehen:
- Beobachtet: 1.200 dem Vorfall zugeordnete Fehlversuche; 140 unterschiedliche Konto-IDs in diesen Datensätzen.
- Noch ungeklärt: Wie viele beabsichtigte Tickets aufgegeben statt später erfolgreich erneut eingereicht wurden.
- Nächster Schritt: Versuche mit der späteren Ticketerstellung abgleichen, bevor eine Abbruchzahl genannt wird.
Deshalb gehören Gesamtergebnis und Nutzerfolgen zusammen. Die Zielerfüllung beantwortet eine Frage; die konzentrierte Störung eines bestimmten Ablaufs eine andere. Keine der beiden sollte die andere verdrängen.
Aus dem Ergebnis eine Entscheidung zur Zuverlässigkeit ableiten
Im Review geht es nicht darum, den höchstmöglichen Zielwert zu wählen. Fragen Sie, welche Maßnahme das beobachtete Problem angeht, welche Belege sie stützen und welche andere Arbeit dafür verschoben würde. Ein Wechsel von 99,90 % auf 99,99 % verbessert den Dienst noch nicht.
Für das Beispiel kann der Serviceverantwortliche folgende Optionen vergleichen:
| Option | Behandeltes Problem | Vor einer weitergehenden Zusage benötigte Belege |
|---|---|---|
| Konzentrierten Fehlerpfad untersuchen | Der Vorfall mit 1.200 Fehlversuchen. | Reproduzierbarer Fehler und ein Vergleichstest möglicher Gegenmaßnahmen; aus zeitlicher Nähe allein keine Ursache ableiten. |
| Messung vor das Gateway erweitern | Die Lücke zwischen Kundenbrowser und aktuellem SLI. | Begrenzter Messvorschlag mit Abdeckung, Datenverarbeitung und Umsetzungsaufwand. |
| SLO sofort verschärfen | Strengere Zuverlässigkeitszusage. | Belege, dass das Ziel zu den Nutzerbedürfnissen passt, und ein vereinbarter Plan für die zusätzliche Zuverlässigkeitsarbeit. |
Die ersten beiden Optionen greifen konkrete Befunde auf. Die dritte braucht eine eigenständige Entscheidung über Erwartungen und Aufwand. Senken Sie das Ziel nicht stillschweigend, damit der Bericht grün wird, und erhöhen Sie es nicht nur, damit eine Folie ambitioniert klingt.
Hat Ihre Organisation bereits eine Fehlerbudget-Richtlinie, nennen Sie die dadurch vorgeschriebene Maßnahme und die Zuständigkeit für Ausnahmen. Gibt es keine, kennzeichnen Sie einen Richtlinienvorschlag ausdrücklich als Vorschlag. Erfinden Sie keinen automatischen Release-Stopp und erwecken Sie nicht den Eindruck, er sei längst vereinbart.
Sechs Folien erstellen, mit denen das Team später weiterarbeiten kann
Der Hauptfoliensatz kann kompakt bleiben, weil die Details im Begleitmaterial stehen. Geben Sie jeder Folie eine Aufgabe:
- Ergebnis und Entscheidung: 99,93 % Erfolg gegenüber 99,90 % Ziel; ein konzentrierter Vorfall; die konkret zu genehmigende Arbeit.
- Messgrenze: Nutzerablauf, Zeitraum, berücksichtigte und gute Ereignisse, Quelle und Abdeckungslücke.
- Budget: Zähler, Nenner, zulässige Fehler und Berechnung des Verbrauchs von 70 %.
- Nutzerfolgen: betroffener Ablauf, 140 beobachtete Konto-IDs und offene Fragen.
- Optionen: konkurrierende Maßnahmen, jeweils benötigte Belege und die dafür zu verschiebende Arbeit.
- Entscheidungsprotokoll: Verantwortlicher, genehmigter Umfang, nächster Review-Termin und dann erwartete Belege.
Bewahren Sie Kennzahlenexporte und Abfragedetails beim Foliensatz auf, kopieren Sie aber keine personenbezogenen Kundendaten in die Folien. Für einen größeren Empfängerkreis eignet sich eine bereinigte Zusammenfassung der Auswirkungen. Wird eine Definitionsänderung vorgeschlagen, zeigen Sie diese als künftige Version. Das aktuelle Ergebnis bleibt an die Definition gebunden, mit der es berechnet wurde.
Ein ausgefülltes Entscheidungsprotokoll der fiktiven Besprechung könnte lauten:
Genehmigt wird eine Untersuchung des Fehlerpfads bei der Ticketbestätigung im Umfang von zwei Engineering-Personentagen unter Verantwortung der Serviceleitung. Zum nächsten Termin werden eine Reproduktion, mögliche Gegenmaßnahmen und Testergebnisse vorgelegt; eine Verringerung künftiger Fehler wird noch nicht behauptet. Das Erfolgs-SLO von 99,90 % bleibt unverändert. Beim nächsten Review wird zusätzlich ein abgegrenzter Vorschlag zur Messung von Einreichungsfehlern vor dem Gateway vorgestellt. Jede Umsetzung über die Untersuchung hinaus benötigt eine separate Kapazitätsentscheidung.
Dieses Protokoll gibt der nächsten Besprechung einen konkreten Ausgangspunkt. Das Team prüft dann Belege aus einer klar definierten Arbeit, statt erneut dieselbe grüne Prozentzahl zu zeigen und dasselbe Versprechen zu wiederholen.
