Wie lassen sich SRE-Kennzahlen wie MTTD, MTTR, SLO, Error Budgets und Burn Rate auf KI- und Infrastrukturbetrieb anwenden?

SRE-Kennzahlen machen die Zuverlässigkeit von KI und Infrastruktur zu etwas, das Teams messen und steuern können. MTTD zeigt, wie schnell Probleme erkannt werden, MTTR zeigt, wie schnell der Dienst wiederhergestellt wird, SLOs definieren das Zuverlässigkeitsziel, Error Budgets quantifizieren, wie viel Unzuverlässigkeit akzeptabel ist, und die Burn Rate zeigt, wie schnell dieses Budget verbraucht wird.

Für KI-Infrastruktur müssen diese Kennzahlen mehr abdecken als die Verfügbarkeit einer Anwendung. Sie können sich auf Trainingserfolg, Inferenzerfolg, Token-Durchsatz, Time to First Token, Beschleunigerverfügbarkeit, Fehlerbehebung und andere kritische Pfade beziehen, die die Fähigkeit beeinflussen, Rechenleistung in einen stabilen Dienst zu verwandeln.

Was ist MTTD?

Mean Time to Detect, kurz MTTD, misst, wie lange das Betriebssystem oder das Team braucht, um einen Incident nach seinem Beginn zu erkennen.

Eine einfache Formel lautet:

MTTD = Sum of detection delays / Number of incidents

Der schwierige Teil ist die Definition des Incident-Beginns.

Bei einem Hardware-Ereignis kann der Beginn der erste ECC-Fehler sein.

Bei einem Service-Incident kann es die erste Anfrage sein, die den Service-Indikator verletzt.

Bei einem Kühlungsproblem kann es die erste Schwellenwertüberschreitung sein.

Legen Sie für jede Incident-Klasse eine Regel fest und wenden Sie sie konsistent an.

Eine niedrige MTTD bedeutet, dass Probleme schnell sichtbar werden.

Eine hohe MTTD bedeutet, dass Ausfälle Workloads zu lange beeinträchtigen können, bevor jemand davon erfährt.

Automatische Erkennung kann die MTTD senken, aber nur, wenn die Alarme aussagekräftig sind.

Ein Alarmsturm, dem niemand traut, kann das Problem technisch in Sekunden erkennen, während die menschliche Reaktion trotzdem langsam bleibt.

Deshalb sollte MTTD zusammen mit Alarmqualität und Incident-Konsolidierung betrachtet werden.

Was ist MTTR?

Mean Time to Repair, Recover, Resolve oder Restore wird üblicherweise mit MTTR abgekürzt, aber Organisationen verwenden das zweite Wort unterschiedlich.

Definieren Sie Ihre eigene Version.

Für den Infrastrukturbetrieb ist die nützlichste Version oft die Zeit bis zur Wiederherstellung des Dienstes.

Eine einfache Formel lautet:

MTTR = Sum of restoration durations / Number of incidents

Auch hier gilt: Definieren Sie die Start- und Endzeitstempel.

Beginnt die Uhr beim Ausfall oder bei der Erkennung?

Stoppt sie, wenn das Gerät repariert ist, oder wenn der nutzerseitige Dienst wiederhergestellt ist?

Das sind unterschiedliche Kennzahlen.

Bei einem KI-Trainings-Incident kann der Dienst wiederhergestellt sein, sobald der Job aus einem Checkpoint auf funktionsfähigen Ressourcen fortgesetzt wird, selbst wenn die ausgefallene GPU erst später repariert wird.

Das ist oft die bessere Betriebskennzahl, weil sie misst, wie lange produktive Arbeit unterbrochen war.

Die Reparaturzeit der Hardware kann separat erfasst werden.

Wie gelten MTTD und MTTR bei GPU-Ausfällen?

Bei einem GPU-Ausfall misst MTTD, wie schnell die Plattform erkennt, dass die Karte oder der Knoten nicht mehr funktionsfähig ist.

MTTR misst, wie schnell der betroffene Workload gemäß dem definierten Wiederherstellungsprozess in einen funktionsfähigen Zustand zurückkehrt.

Eine gute Fehlertoleranz-Schleife kann die MTTR senken, indem sie:

Die defekte Karte erkennt
Die Neuzuweisung an sie stoppt
Den betroffenen Job findet
Einen gültigen Checkpoint auswählt
Funktionsfähige Ersatzressourcen zuweist
Den Job neu startet
Den Fortschritt validiert

Deshalb sind Hardware-Health und Scheduler-Integration wichtig.

Wenn das Team 20 Minuten braucht, um herauszufinden, welcher Job die Karte nutzt, wird dieser Zuordnungsschritt Teil der MTTR.

Wenn ein Checkpoint sechs Stunden alt ist, kann der Dienst schnell wiederhergestellt werden, aber das Unternehmen verliert trotzdem sechs Stunden Rechenleistung.

Diese verlorene Arbeit sollte separat erfasst werden.

Der Artikel darüber, wie KI-Infrastruktur Trainingsjobs nach einem GPU- oder Serverausfall automatisch wiederherstellen kann, behandelt diese Wiederherstellungsschleife im Detail.

Was ist ein SLO?

Ein Service Level Objective, oder SLO, ist ein Zielwert für einen Service-Level-Indikator über einen definierten Zeitraum.

Googles SRE-Leitfaden behandelt SLOs als Ziele für die Zuverlässigkeit eines Dienstes, basierend auf messbaren Service-Level-Indikatoren.

Für einen Inferenzdienst kommen unter anderem folgende Indikatoren infrage:

Erfolgsrate der Anfragen
Token-Erfolgsrate
Latenz
Time to First Token
Token-Durchsatz
Timeout-Rate

Für einen Trainingsdienst kommen unter anderem folgende Indikatoren infrage:

Erfolgreicher Job-Start
Erfolgreicher Task-Abschluss
Wartezeit in der Queue
Erfolgreicher Checkpoint
Wiederherstellungszeit
Ressourcenverfügbarkeit

Für Infrastruktur kommen unter anderem folgende Indikatoren infrage:

Beschleunigerverfügbarkeit
Netzwerkverfügbarkeit
Storage-Latenz
Erfolgreiche Bereitstellung
Reaktionszeit bei Hardware-Reparaturen

Erstellen Sie nicht für jede Kennzahl ein SLO.

Wählen Sie die Indikatoren, die nutzersichtbare oder geschäftlich wichtige Zuverlässigkeit widerspiegeln.

Wie sollte ein SLO für einen KI-Dienst definiert werden?

Definieren Sie den Dienst, den Indikator, das Ziel, das Messfenster und die Population der Ereignisse.

Zum Beispiel:

Dienst: Produktions-Inferenz-Endpunkt
Indikator: erfolgreiche Anfragen / berechtigte Anfragen
Ziel: 99,9 Prozent
Fenster: rollierende 30 Tage
Ausschlüsse: explizit definierte Wartungsarbeiten oder nicht abrechenbarer Testverkehr

Die genaue Zahl ist eine geschäftliche Entscheidung.

Die Methode ist der wichtige Teil.

Zwei Teams können beide ein SLO von 99,9 Prozent beanspruchen, während sie unterschiedliche Anfragen zählen.

Das macht den Vergleich bedeutungslos.

Halten Sie die Definition exportierbar und versioniert.

Das zugrunde liegende Betriebsmodell unterstützt außerdem Service-Tiers wie Gold, Silber und Bronze, sodass unterschiedliche Modelle unterschiedliche Schwellenwerte haben können.

Das kann nützlich sein, wenn ein Dienst strikte Latenz erfordert, während ein anderer nach dem Best-Effort-Prinzip arbeitet.

Was ist ein Error Budget?

Ein Error Budget ist das Maß an Unzuverlässigkeit, das das SLO während des Messfensters erlaubt.

Wenn das SLO bei 99,9 Prozent Erfolg liegt, ist das Error Budget die verbleibenden 0,1 Prozent unter dieser Definition.

Für ein anfragebasiertes SLO:

Error budget = Total eligible events × Allowed failure fraction

Wenn es 1.000.000 berechtigte Anfragen gibt und das SLO 0,1 Prozent Fehlschläge erlaubt:

1,000,000 × 0.001 = 1,000 allowed failed requests

Das bedeutet nicht, dass Fehlschläge wünschenswert sind.

Es gibt der Organisation eine quantitative Grenze, um Zuverlässigkeit und Änderungsgeschwindigkeit gegeneinander abzuwägen.

Wenn das Budget gesund ist, hat das Team Spielraum für das normale Risiko der Softwareauslieferung.

Wenn das Budget erschöpft ist, sollte Zuverlässigkeitsarbeit Priorität haben.

Das zugrunde liegende SRE-Modell nutzt genau dieses Prinzip: Wenn das Budget die Schwelle überschreitet, kann die Release-Aktivität eingefroren werden, bis die Zuverlässigkeitsschuld abgebaut ist.

Was bedeutet Burn Rate?

Die Burn Rate misst, wie schnell der Dienst sein Error Budget verbraucht, verglichen mit der Rate, die das Budget gleichmäßig über das gesamte Fenster verbrauchen würde.

Eine Burn Rate von 1 bedeutet, dass der Dienst das Budget im erwarteten Durchschnittstempo verbraucht, das es genau am Ende des Zeitraums aufzehren würde.

Eine Burn Rate über 1 bedeutet, dass das Budget schneller verbraucht wird.

Eine sehr hohe Burn Rate bedeutet, dass der Dienst sein Kontingent schnell aufbrauchen kann, wenn der Zustand anhält.

Die Burn Rate ist nützlich, weil rohe Fehlerzahlen irreführend sein können.

Zehn Fehlschläge in einer Minute können für einen Dienst mit geringem Volumen gravierend sein.

Dieselben zehn Fehlschläge können für einen Dienst mit sehr hohem Volumen vernachlässigbar sein.

Die Burn Rate setzt die Fehlschläge in Relation zum SLO und zum verbleibenden Budget.

Warum mehrere Burn-Rate-Fenster verwenden?

Mehrere Fenster helfen dabei, sowohl schnelle Incidents als auch langsame Zuverlässigkeitsverschlechterung zu erkennen.

Googles SRE Workbook beschreibt Multiwindow-, Multi-Burn-Rate-Alerting als eine Möglichkeit, bedeutsamen SLO-Verbrauch zu erkennen und gleichzeitig Alarm-Rauschen unter Kontrolle zu halten.

Ein kurzes Fenster ist empfindlich gegenüber schnellen Fehlschlägen.

Ein längeres Fenster bestätigt, dass der Zustand anhaltend genug ist, um relevant zu sein.

Sie können außerdem separate Fast-Burn- und Slow-Burn-Alarmpfade definieren.

Fast Burn bedeutet, dass das Budget schnell verschwindet und eine dringende Reaktion erfordert.

Slow Burn bedeutet, dass sich der Dienst über einen längeren Zeitraum verschlechtert und geplante Zuverlässigkeitsarbeit nötig sein könnte.

Das zugrunde liegende Betriebsmodell nutzt dasselbe Konzept mit Multiwindow-, Multi-Burn-Rate-Alarmen.

Das Ziel ist nicht, mehr Alarme zu erzeugen.

Es geht darum, Alarme zu erzeugen, wenn das Zuverlässigkeitsziel tatsächlich gefährdet ist.

Wie sollten SLOs auf Token-Dienste angewendet werden?

Token-Dienste können Indikatoren verwenden, die sowohl Verfügbarkeit als auch Qualität der Auslieferung widerspiegeln.

Das zugrunde liegende Material listet Kennzahlen wie Token-Erfolgsrate, Durchsatz, Time to First Token, Latenz pro Token und Timeout-Rate auf.

Ein Modell-Dienst kann daher mehrere SLOs haben.

Zum Beispiel:

Erfolgsrate der Anfragen
Erfolgreiche Token-Generierung
Time to First Token
Kontinuität des Streamings
Gesamtlatenz
Timeout-Rate

Fassen Sie nicht alle Indikatoren in einem zusammengesetzten Wert zusammen, wenn sie unterschiedliche Nutzererfahrungen abbilden.

Ein Dienst kann eine exzellente Erfolgsrate und eine schreckliche Latenz haben.

Der Nutzer erlebt trotzdem einen schlechten Dienst.

Getrennte SLOs machen den Fehlermodus sichtbar.

Wie sollte SRE auf Trainingsdienste angewendet werden?

Training-SRE sollte sich auf die Zuverlässigkeit des Job-Lebenszyklus konzentrieren.

Nützliche Indikatoren sind unter anderem:

Zulassungszeit in der Queue
Erfolgreicher Job-Start
Erfolgreicher Job-Abschluss
Erfolgreicher Checkpoint
Erfolgreiche Wiederherstellung
Durchschnittlich verlorene Rechenleistung nach einem Ausfall
Ressourcenverfügbarkeit
Rate wiederholter Fehlschläge

Ein Trainingsjob, der nach 18 Stunden ausfällt und von einem 17 Stunden alten Checkpoint neu startet, ist technisch wiederhergestellt, aber operativ teuer.

Diese verlorene Rechenleistung sollte sichtbar sein.

Ebenso kann ein Scheduler hochverfügbar sein, während Nutzer stundenlang auf die angeforderte Ressourcenklasse warten.

Zuverlässigkeit des Dienstes bedeutet die Erfahrung, nutzbare Rechenleistung zu erhalten, nicht einfach die Verfügbarkeit des Scheduler-Prozesses.

Was ist eine Automatisierungsquote für Fehlerbehebung?

Die Automatisierungsquote für Fehlerbehebung (Automatic-Remediation Ratio) misst den Anteil berechtigter Incidents, die durch genehmigte automatisierte Maßnahmen ohne manuelle Ausführung gelöst wurden.

Eine einfache Definition lautet:

Automatic-remediation ratio = Automatically resolved eligible incidents / Total eligible incidents

Definieren Sie „berechtigt“.

Hochriskante Incidents sollten nicht als Automatisierungsfehler gezählt werden, wenn die Richtlinie bewusst eine menschliche Freigabe verlangt.

Das zugrunde liegende SRE-Modell unterteilt Incidents nach Risikostufe.

Bekannte, vorübergehende Ereignisse können sich selbst erholen.

Incidents mit kontrolliertem Risiko können genehmigte Skripte mit Rollback ausführen.

Risikobehaftete Änderungen erfordern eine Workflow-Freigabe und eine Canary-Ausführung.

Das macht die Automatisierungsquote aussagekräftig, weil sie Automatisierung innerhalb des genehmigten Rahmens misst.

Was ist Toil-Reduktion?

Toil-Reduktion misst, wie viel repetitive manuelle Betriebsarbeit entfernt oder verkürzt wurde.

Mögliche Indikatoren sind:

Manuelle Eingriffe pro Incident
Bediener-Minuten pro Incident
Anzahl automatisierter, zuvor wiederholter Aktionen
Ohne manuelle Befehlsausführung abgeschlossene Arbeitsaufträge
Für Routineinspektionen aufgewendete Zeit
Wiederkehrende Incident-Häufigkeit

Toil ist nicht einfach „Arbeit, die Menschen nicht mögen“.

Manche manuelle Arbeit ist wertvoll, weil sie Urteilsvermögen erfordert.

Das Ziel ist, repetitive, vorhersehbare Aktionen zu automatisieren, damit sich Ingenieure auf Diagnose, Kapazität, Zuverlässigkeit und Verbesserung konzentrieren können.

Messen Sie die tatsächlich eingesparte Zeit.

Andernfalls kann „Automatisierung“ zu einer reinen Feature-Zählung ohne operativen Nutzen werden.

Wie sollten Incident-Reviews mit SRE-Kennzahlen verknüpft werden?

Ein Post-Incident-Review sollte einzelne Fehlschläge in Änderungen am Zuverlässigkeitssystem verwandeln.

Das Review sollte Folgendes festhalten:

Zeitachse
Grundursache
Beitragende Faktoren
Erkennungslücke
Wiederherstellungslücke
Ausmaß der Serviceauswirkung
Ausmaß der verlorenen Rechenleistung
Auswirkung auf das SLO
Verbrauch des Error Budgets
Verbesserungsmaßnahmen
Verantwortlicher
Fälligkeitsdatum

Wenn die MTTD schlecht war, verbessern Sie die Erkennung.

Wenn die MTTR schlecht war, verbessern Sie Runbooks, Zuständigkeiten, Checkpoints oder Automatisierung.

Wenn derselbe Fehler immer wieder das Error Budget verbraucht, beheben Sie das zugrunde liegende Zuverlässigkeitsproblem, statt nur den Reaktionsprozess zu verbessern.

Das Review sollte in die Wissensdatenbank einfließen, damit künftige Incidents von den gewonnenen Erkenntnissen profitieren.

Wie beeinflussen Error Budgets Release-Entscheidungen?

Error Budgets bieten ein messbares Release-Gate.

Wenn der Dienst komfortabel innerhalb seines SLO liegt und noch Budget übrig hat, kann die normale Release-Aktivität gemäß Richtlinie fortgesetzt werden.

Wenn das Budget fast erschöpft ist, können risikoreiche Änderungen verlangsamt werden.

Wenn das Budget erschöpft ist, kann das Team nicht essenzielle Releases einfrieren und Zuverlässigkeitsarbeit priorisieren.

Das verwandelt die Diskussion von Meinung in Evidenz.

Produktteams können die Zuverlässigkeitsbeschränkung sehen.

Betriebsteams können den Verbrauchstrend zeigen.

Das Management kann das prognostizierte Erschöpfungsdatum sehen.

Das ist der Managementwert eines Error Budgets.

Wie unterstützt AIOps SRE?

AIOps kann die MTTD senken, indem es Fehlschläge schneller erkennt und korreliert, und es kann die MTTR senken, indem es wahrscheinliche Ursachen identifiziert und genehmigte Abhilfemaßnahmen vorschlägt oder ausführt.

Aber SRE liefert den Messrahmen, der zeigt, ob diese Verbesserungen real sind.

Wenn ein AIOps-System eine schnellere Diagnose behauptet, vergleichen Sie die MTTD vorher und nachher.

Wenn automatisierte Wiederherstellung hinzugefügt wird, vergleichen Sie MTTR und Wiederholungsrate.

Wenn sich die Alarmkorrelation verbessert, vergleichen Sie die Arbeitslast der Bediener und das Volumen falscher Incidents.

Wenn sich die Zuverlässigkeit verschlechtert, während die Automatisierung zunimmt, ist die Automatisierung nicht erfolgreich.

Die Beziehung zwischen beiden wird in wie AIOps Alarm-Rauschen reduziert, Grundursachen identifiziert und die geschäftlichen Auswirkungen bestimmt behandelt.

Was sollte ein SRE-Dashboard zeigen?

Ein nützliches SRE-Dashboard sollte Zuverlässigkeitsleistung, Budgetstatus, Incident-Risiko und operativen Aufwand zeigen.

Mindestens:

MTTD
MTTR
SLO-Erfüllung
Verbleibendes Error Budget
Burn Rate
Prognostizierte Budgeterschöpfung
Incident-Anzahl
Risikostufe
Automatisierungsquote für Fehlerbehebung
Toil-Trend
Wiederkehrende Incidents
Status der Post-Incident-Maßnahmen

Ein Plattformbeispiel, das diese Kennzahlen von der Infrastruktur bis zu den Token-Diensten anwendet, ist Sensaka.

Wenn ich SRE in KI-Infrastruktur einführen würde, würde ich mit drei kritischen Diensten beginnen, nicht mit 100 Kennzahlen. Definieren Sie ein oder zwei SLOs für jeden, messen Sie MTTD und MTTR, erstellen Sie ein 30-Tage-Error-Budget und überprüfen Sie jeden Incident, der einen bedeutenden Anteil davon verbraucht. Sobald die Definitionen vertrauenswürdig sind, erweitern Sie das System.