SRE suchen

Kapitel 4. Verwendung von Vorfallmetriken zur Verbesserung von SRE im großen Maßstab

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Martin Check, Microsoft

Ganz gleich, ob dein Dienst das nächste Dutzend oder die nächste Milliarde Nutzerinnen und Nutzer aufnehmen soll, früher oder später wirst du dich mit der Frage auseinandersetzen müssen, wie viel du in welche Bereiche investieren solltest, um die Zuverlässigkeit deines Dienstes aufrechtzuerhalten. In diesem Kapitel schauen wir uns anhand einer Fallstudie von Microsoft Azure an, wie man Vorfallskennzahlen nutzen kann, um Investitionen zu konzentrieren. Wir wenden die Erkenntnisse an, die wir bei der Arbeit an der Service-Zuverlässigkeit für eine Vielzahl von Diensten gewonnen haben, von Startups über Unternehmensdienste bis hin zur Cloud-Skala. Azure eignet sich besonders gut als Fallstudie, da die enorme Größe, das Wachstum und die Vielfalt der Produktangebote die typischen Zuverlässigkeitsthemen verstärken. Wir zeigen, wie wir mit Hilfe von Daten und einigen innovativen Techniken diese Themen analysieren und berichten können, um Verbesserungen zu erzielen.

Der Tugendhafte Kreislauf als Retter: Wenn du es nicht misst...

Wie bei jedem Problemmanagement begannen wir damit, uns die Daten anzusehen. Dabei stellte sich jedoch heraus, dass wir Tausende von Datenquellen hatten: Service-Telemetrie, Metriken zum Störungsmanagement, Einsatzmetriken und so weiter und so fort. Wir hatten sogar so viele Datenquellen, dass es schwierig war, zu entscheiden, welche Daten wir in welcher Reihenfolge betrachten sollten, um die Probleme zu lösen. Nachdem wir uns die bewährten Methoden in der Branche angeschaut und uns mit Experten beraten hatten, entschieden wir uns schließlich für das in Abbildung 4-1 dargestellte System, das unsere Verbesserungsbemühungen untermauern sollte: den Tugendzyklus. Der virtuose Zyklus schuf einen Rahmen, mit dem wir feststellen konnten, wie effektiv unsere Überwachung war, indem wir feststellten, wie schnell wir Ausfälle entdeckten, wie gut wir aus Ausfällen lernten, indem wir den Prozess der Ursachenanalyse (RCA) und die Reparaturen maßen, und wie schnell die Fehler behoben wurden. Anhand der Codequalität und der Bereitstellungsgeschwindigkeit konnten wir feststellen, wie schnell wir den gesamten Zyklus durchlaufen haben.

Abbildung 4-1. Der Kreislauf der Tugend

Als SREs wissen wir, dass es auf jede Minute Ausfallzeit ankommt. Deshalb begannen wir damit, die wichtigsten Kennzahlen zu finden, die uns sagten, wie effektiv wir auf Vorfälle reagierten und sie reparierten. Das bedeutete, dass wir zunächst die Kennzahlen definieren mussten, die repräsentativ sind, und uns dann auf Definitionen und Start-/Endzeiten einigen mussten. Im Folgenden werden die von uns ausgewählten Kennzahlen erläutert und warum wir sie für so wichtig halten:

Zeit bis zur Erkennung (TTD)

Die Zeit bis zur Erkennung ist die Zeit zwischen dem Beginn der Einwirkung und dem Zeitpunkt, an dem ein Vorfall für einen Betreiber sichtbar wird. Wir beginnen mit der Zählung, wenn die Auswirkung für den Kunden zum ersten Mal sichtbar wird, auch wenn unsere Überwachung sie nicht entdeckt hat. Das ist oft der Zeitpunkt, an dem das Service-Level Agreement (SLA) verletzt wird.

Ob du es glaubst oder nicht, die TTD ist die wichtigste Kennzahl für Vorfälle, die manuelle Abhilfemaßnahmen erfordern. Diese Kennzahl bestimmt die Qualität und Genauigkeit deiner Überwachung. Wenn du nicht weißt, wie es deinen Kunden geht, kannst du nicht mit der Wiederherstellung beginnen und schon gar nicht die Automatisierung zur Reaktion oder Schadensbegrenzung einschalten. Was vielleicht noch wichtiger ist: Du kannst deinen Kunden nicht vermitteln, dass du das Problem kennst und daran arbeitest. Die Herausforderung bei TTD besteht darin, die Überwachungssensibilität so auszubalancieren, dass du alle Kundenprobleme schnell und genau findest, ohne deine Techniker ständig für Probleme zu unterbrechen, die keine Auswirkungen auf die Kunden haben.

Zeit zum Engagieren (TTE)

Das ist die Zeit von der Entdeckung bis zum Einsatz des entsprechenden Technikers. Das kann während des Ereignisses und manchmal auch danach schwierig zu bestimmen sein. Es kann schwierig sein, im Nebel des Krieges einen einzelnen Techniker zu identifizieren, daher ist es in Ordnung, wenn wir uns auf den ersten Techniker am Einsatzort stützen. Diese Kennzahl ist sehr wichtig, um zu sehen, wie effektiv wir in der Lage sind, die Einsatzkräfte zu mobilisieren. Sie berücksichtigt sowohl die Zeit für die Triage (Bestimmung des Schweregrads und der Zuständigkeit) als auch die Zeit für die Eskalation und Mobilisierung der Einsatzkräfte. Es gibt viele Möglichkeiten, dies zu verbessern: Automatisierte Eskalations- und Paging-Systeme, klare Erwartungen an die Rufbereitschaft, Follow-the-Sun-Support-Modelle und sogar eine verbesserte Überwachung können dazu beitragen, dass die Meldung gleich beim ersten Mal an den richtigen Bereitschaftsdiensttechniker geht.

Zeit zum Reparieren (TTF)

Das ist die Zeit, die der Responder braucht, um das Problem zu entschärfen.

Alle diese Kennzahlen zusammen (TTD + TTE + TTF) ergeben die Time to Mitigate (TTM), also die Zeit bis zur Behebung des Ausfalls, wie in Abbildung 4-2 dargestellt.

Abbildung 4-2. Beispiel für eine Aufschlüsselung der Zeit für die Behebung von Ausfällen

Es kann sein, dass ihr unterschiedliche Kennzahlen, Definitionen oder Schwellenwerte habt, aber wichtig ist nur, dass sich eure Gruppe auf eine gemeinsame Taxonomie und gemeinsame Maßnahmen einigt. Die Einigung auf eine Taxonomie ist besonders wichtig, denn wenn es keine Einigung über die Schadensbegrenzung gibt, kann es zu Unterbrechungen kommen, da einige Teams versuchen könnten, sich zurückzuziehen, bevor der Vorfall vollständig geklärt ist. Dies ist nach dem Vorfall besonders wichtig, um eine gemeinsame Taxonomie zu gewährleisten und bei den Besprechungen über Verbesserungsmöglichkeiten zu sprechen.

Metrik-Rückblick: Wenn eine Metrik in den Wald fällt...

Nachdem wir diese Kennzahlen definiert hatten, brachten wir unsere technischen Führungskräfte zusammen, um die wichtigsten Kennzahlen zu betrachten, die wir als entscheidend für den Erfolgskreislauf identifiziert hatten. So konnten wir verfolgen, wie wir vorankommen, Erkenntnisse gewinnen und Aktionspläne für Bereiche erstellen, in denen wir unsere Ziele nicht erreichen. Nachdem wir uns auf Kennzahlen geeinigt hatten, begannen wir mit der Sammlung und Auswertung der Daten für die einzelnen Dienststellen, um festzustellen, wie wir vorankommen, um Bereiche und gemeinsame Themen zu finden, die wir verbessern können, und um die Auswirkungen der von uns vorgenommenen Verbesserungen zu messen. Abbildung 4-3 zeigt ein Beispiel für ein Dashboard zur Messung von Vorfällen und Einsatzkennzahlen. Auf diese Weise konnten wir die Entwicklung der Kennzahlen für unseren Reaktionszyklus auf Vorfälle verfolgen und Verbesserungen entwickeln, so wie wir auch Funktionen in das Produkt einbauen.

Abbildung 4-3. SRE-Metriken Dashboard

Beachte, dass die Kennzahlen zur Reaktion auf Vorfälle, die wir zuvor besprochen haben, hier angezeigt werden: TTD, TTE, TTF und TTM, mit Trends nach Zeiträumen und gemessen an den Zielen, die wir festgelegt und mit den Serviceverantwortlichen vereinbart hatten. Wenn wir feststellten, dass die Daten spärlich waren, eine hohe Variabilität aufwiesen oder große Ausreißer hatten, wendeten wir Perzentile auf die Daten an, um sie ausreichend zu normalisieren. Dann konnten wir uns die Ausreißer ansehen, um sie besser zu verstehen und die Perzentile auf 100 % zu bringen.

Surrogat-Metriken

Wenn du dir das SRE-Metriken-Dashboard genau ansiehst, wirst du einige Metriken wie Directly Responsible Individual (DRI) Hops (wie viele Techniker auf Abruf benötigt werden, um einen Vorfall zu lösen) und Autodetection (wie viele Vorfälle durch Überwachung entdeckt werden) bemerken. Dabei handelt es sich um Ersatzmetriken, die mit der übergeordneten Metrik "Zeit bis" zusammenhängen, die spezifischer und umsetzbarer sind als die übergeordneten Metriken, aber für sich genommen keinen Erfolg anzeigen. Wir haben festgestellt, dass die Verwendung von Ersatzmetriken zu schnelleren und dauerhafteren Verbesserungen führt, weil es ein effektiverer Weg ist, den Ingenieuren konkrete Aktionspunkte und Submetriken zu geben, als den Teams nur zu sagen, dass sie "besser arbeiten" und "sich mehr anstrengen" sollen.

Die Untersuchung deiner Daten ist ein guter Weg, um Ersatzmetriken zu finden. Als wir zum Beispiel TTE untersuchten, fanden wir bei Vorfällen mit langen Einsatzzeiten Faktoren, die mit hohen Einsatzzeiten korrelierten oder zu diesen führten, wie zum Beispiel der Einsatz vieler Techniker zur Lösung eines einzigen Vorfalls. Dies kann auf Wissenslücken, Lücken in der Ausrüstung oder auch auf uneinheitliche Erwartungen an den Bereitschaftsdienst zurückzuführen sein. Um dieses Problem zu lösen, haben wir die Submetrik "#DRIs engaged per bridge" eingeführt, die uns zeigt, wie viele DRIs bei einem bestimmten Vorfall im Einsatz sind. Auch wenn weniger DRIs im Einsatz sind, kann dies zu einer langen Reaktionszeit führen, vor allem wenn sie nicht rechtzeitig zusätzliche Ressourcen einsetzen. Zusammen mit der TTD und der TTE ist dies jedoch ein guter Indikator dafür, wie effektiv unsere Überwachungs- und Diagnosemethoden sind, um den Alarm frühzeitig an die richtigen Einsatzkräfte weiterzuleiten.

Als wir daran arbeiteten, die TTD zu verbessern, stellten wir fest, dass sie 10-mal höher war, wenn der Ausfall von unseren Kunden entdeckt wurde, anstatt von der Überwachung erfasst zu werden. Um dies zu messen, haben wir die automatische Erkennungsrate als Ersatzkennzahl für die TTD verwendet. Das bedeutet nicht, dass alle automatisch erkannten Vorfälle eine gute TTD haben, aber die automatische Erkennung ist notwendig, um eine gute TTD zu erhalten. Wie bei Ersatzkennzahlen üblich, ist die automatische Erkennung notwendig, aber nicht ausreichend, um eine erstklassige TTD zu erreichen.

Dies ist keine vollständige Liste von Ersatzmetriken, sondern nur ein paar Beispiele für den Anfang.

Schulden reparieren

Einige der besten Erkenntnisse, die wir bei der Überprüfung der Kennzahlen gewonnen haben, stammen aus der Nachbereitung des Vorfalls. Es gibt bereits eine Menge großartiges Material, daher werde ich nicht näher darauf eingehen, wie man eine gute Nachuntersuchung durchführt (unter "Weitere Lektüre" findest du ein paar Beispiele). Ich werde mich auf das konzentrieren, was für unsere metrischen Überprüfungen am wichtigsten ist: Jedes Mal, wenn wir einen Fehler oder eine Verbesserungsmöglichkeit identifizieren, protokollieren wir ihn und erfassen ihn als Reparatur. Reparaturen sind technische oder verfahrenstechnische Maßnahmen, die entweder verhindern, dass ein Ausfall erneut auftritt, oder die Dauer des Ausfalls verkürzen. In der Regel werden sie in kurzfristige und langfristige Maßnahmen unterteilt. Kurzfristige Reparaturen sollten schnell eingeführt werden (innerhalb einer Woche) und können ein Prozess, ein Skript oder ein Hotfix sein. Langfristige Maßnahmen sind dauerhaftere Korrekturen, wie z. B. gründlichere Codekorrekturen (d. h. Behebung einer Problemklasse im Gegensatz zu einer Instanz eines Problems oder Behebung einer Problemklasse über mehrere Produktlinien hinweg), die Einführung umfassenderer Prozessänderungen (d. h. Erstellung und Durchführung von Schulungen zum Incident Management über mehrere Organisationen hinweg) oder die Entwicklung von Tools wie Chatbots oder automatische Deeskalation/Militarisierung. Reparaturen werden in der Regel in demselben Arbeitsverwaltungssystem erfasst, das du auch für die Erfassung von Produktaufgaben verwendest. Entscheidend ist jedoch, dass sie aufgezeichnet und gemeldet werden und sich vom normalen Produktrückstand unterscheiden lassen.

Durch die Nachverfolgung von Reparaturen können wir betriebliche Schulden in den Standardentwicklungsprozess einbeziehen und sie genauso behandeln wie die Arbeit an Features. Das Diagramm in Abbildung 4-4 ist ein gutes Beispiel dafür, was passiert, wenn wir anfangen, Reparaturen zu verfolgen. In der Regel kommt es zu einem anfänglichen Anstieg der Verschuldung, wenn wir bisher unbekannte oder nicht zielgerichtete Reparaturmaßnahmen aufdecken. Dann passt das Team seine Praktiken an, um die Reparaturverschuldung in den normalen Geschäftsrhythmus einzubinden, und die Reparaturverschuldung sinkt. Die Verfolgung der Reparaturschuld ist wichtig, denn diese Probleme gab es schon immer, aber solange sie nicht verfolgt, gemessen und weitergegeben wurden, konnte das Technikteam keine Maßnahmen ergreifen, um den Service zu verbessern. Zusammen mit dem Fehlerbudget ist dies ein Signal für das Team, wie es die Arbeit an der Servicezuverlässigkeit gegenüber der Arbeit an den Funktionen priorisieren kann.

Abbildung 4-4. Ein Beispiel für ein Reparaturschulddiagramm

Virtuelle Reparaturschuld: Den Geist in der Maschine austreiben

Nicht jeder Film hat ein Hollywood-Ende, und wir stellten fest, dass nicht jeder Dienst die Früchte der strengen Reparaturmaßnahmen sah. In einigen Fällen war die Zuverlässigkeit von Monat zu Monat nicht unbedingt besser, obwohl die Reparaturschuld stabil war. Bei diesen Diensten, bei denen der Reparaturrückstand stabil war, die aber keine Verbesserung der Zuverlässigkeit verzeichneten, waren wir ratlos. Warum verbesserten sie sich nicht, wenn die Reparaturschulden stabil waren und die Dienste offenbar gut besucht wurden? Wir gruben uns tief in die Daten ein, die wir noch nicht ausgewertet hatten, taten unser Bestes, um Sherlock Holmes zu spielen, und fanden eine überraschende Erkenntnis. Einige Dienststellen führten keine gründlichen RCAs durch und hatten daher entweder niedrige RCA-Abschlussquoten oder RCAs ohne genügend Reparaturen. Das bedeutete, dass die Reparaturen nie in den Rückstand gerieten und die Dienststelle nicht die Möglichkeit hatte, sich zu verbessern.

Das brachte eine neue Herausforderung mit sich: Wie können wir die Qualität eines Postmortem messen? Wir müssen nicht nur messen, ob die Probleme behoben wurden, sondern auch, ob sie überhaupt erst entstanden sind. Die meisten Postmortem-Berichte enthalten eine Menge Text, der das Problem und die Maßnahmen zu seiner Behebung beschreibt. Wir könnten sicherlich maschinelles Lernen auf den Text anwenden und versuchen, die Absicht herauszufinden, aber das würde eine erhebliche Investition erfordern und wäre nicht deterministisch.

Die einfachste Lösung lag die ganze Zeit vor uns, und zwar in Form der "Zeit bis"-Metriken, die wir jedem Vorfall und jedem Postmortem zuordnen. Jeder Vorfall, bei dem die Zeit für die Erkennung, den Einsatz oder die Schadensbegrenzung verpasst wurde, sollte einen entsprechenden Reparaturposten haben. Das bedeutete, dass wir eine Taxonomie für den Reparaturprozess brauchten, um die Flaggen für Engagement, Diagnose und Erkennung zuzuordnen, damit wir programmatisch "verpasste Reparaturen" extrahieren konnten. Anhand der verpassten Reparaturen haben wir dann die so genannte "virtuelle Reparaturschuld" gemessen.

Die Visualisierung der virtuellen Reparaturschuld wurde zu einem mächtigen Werkzeug, um Verbesserungen voranzutreiben. Wie in Abbildung 4-5 zu sehen ist, lässt die graue Linie, die den Reparaturrückstand darstellt, den Anschein erwecken, dass das Team mit dem Rückstand Schritt hält, aber wenn du die gestrichelte rote Linie hinzufügst, die für die verpassten Reparaturen steht, werden die dunklen Reparaturposten, die den virtuellen Rückstand bilden, deutlich sichtbar. Virtuelle Schulden sind besonders wichtig, weil sie den Bestand an Reparaturen darstellen, die nie protokolliert wurden und dem Betrieb auf Dauer schaden werden. Wenn es virtuelle Schulden gibt, werden sich die spezifischen TTD- und TTM-Fehler immer wieder wiederholen, bis sie erfasst und behoben werden.

Abbildung 4-5. Diagramm der virtuellen Reparaturschuld

Real-Time Dashboards: Das Brot und die Butter von SRE

Der vielleicht wichtigste Teil der Überprüfung von Kennzahlen ist die Darstellung der Kennzahlen und Erkenntnisse in Echtzeit-Dashboards. Ein monatlicher oder sogar wöchentlicher Blick auf die Daten hilft nicht, Veränderungen schnell genug voranzutreiben. Jede Dienststelle, jede Komponente muss in Echtzeit sehen können, wo sie zu tun hat, wo sie gut arbeitet und wo sie sich verbessern kann. Das bedeutet, dass Dashboards erstellt werden müssen, die nach Dienststelle, nach Manager und sogar bis zum einzelnen Ingenieur, der für die Arbeit verantwortlich ist, aufgeschlüsselt werden können.

Learnings: TL;DR

Wenn du alles aus diesem Kapitel in einem Satz zusammenfassen willst, dann ist es dieser: Miss alles, sei unermüdlich neugierig und hab keine Angst, dich schmutzig zu machen und in deinen Daten zu wühlen, um die richtigen Maßnahmen zu finden. Um diese Erkenntnisse zu gewinnen, mussten wir in vielen Fällen eine ganze Reihe von Daten von Hand kuratieren, aber nachdem wir verstanden hatten, welche Kennzahlen wichtig waren, konnten wir sie instrumentieren und automatisieren und dazu beitragen, dass die Kennzahlen, die zur Verbesserung der Dienste beitragen, sichtbar wurden.

Weitere Lektüre

Tadellose Postmortale:

• "Tadellose PostMortems und eine gerechte Kultur": John Allspaw, Etsy

• "Postmortem-Aktionspunkte: Die Arbeit planen und den Plan umsetzen": Sue Lueder und Betsy Beyer, Google

• Jenseits von Schuldzuweisungen - aus Misserfolgen und Erfolgen lernen: Dave Zwieback

Daten nutzen, um betriebliche Erkenntnisse zu gewinnen:

• "Verbesserung der Betriebsabläufe durch Datenanalyse": Parviz Deyhim und Arti Garg, Datapipe

• "Vorfallsanalyse": Sue Lueder, Google

• "Den Erfolg des Incident Managements bei Atlassian messen": Gerry Millar, Atlassian

• "PDA: Ein Werkzeug zur automatisierten Problemermittlung": Hai Huang, Raymond Jennings III, Yaoping Ruan, Ramendra Sahoo, Sambit Sahu, und Anees Shaikh, IBM T.J. Watson Research Center

Mitwirkende Bio

Martin Check ist ein Site Reliability Engineering Manager im Microsoft Azure-Team. Seit 14 Jahren arbeitet er bei Microsoft an großen Diensten in verschiedenen Funktionen, darunter Service-Design und -Implementierung, Krisenreaktion, Problemmanagement und sogar die Leitung von Teams bei der DevOps/SRE-Umstellung. Derzeit arbeitet Martin als SRE-Manager für globale SRE-Teams, wo er weiterhin Dateneinblicke nutzt, um SRE-Verbesserungen voranzutreiben.