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

Mit SRE-Kennzahlen können Teams die Zuverlässigkeit von KI und Infrastruktur messen und steuern. MTTD zeigt, wie schnell Probleme erkannt werden, und MTTR, wie schnell der Dienst wiederhergestellt ist. SLOs legen das Zuverlässigkeitsziel fest, Error Budgets beziffern, 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, von denen abhängt, ob aus Rechenleistung ein stabiler Dienst wird.

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

Schwierig ist, den Beginn eines Incidents festzulegen. Bei einem Hardware-Ereignis kann das der erste ECC-Fehler sein, bei einem Service-Incident die erste Anfrage, die den Service-Indikator verletzt, und bei einem Kühlungsproblem die erste Schwellenwertüberschreitung. Legen Sie für jede Incident-Klasse eine Regel fest und wenden Sie sie konsistent an.

Eine niedrige MTTD heißt, dass Probleme schnell sichtbar werden. Bei einer hohen MTTD können Ausfälle Workloads zu lange beeinträchtigen, bevor jemand davon erfährt.

Automatische Erkennung kann die MTTD senken, allerdings nur mit aussagekräftigen Alarmen. Ein Alarmsturm, dem niemand traut, erkennt das Problem technisch vielleicht in Sekunden, und trotzdem reagieren die Menschen langsam. Deshalb gehört die MTTD zusammen mit Alarmqualität und Incident-Konsolidierung betrachtet.

Was ist MTTR?

MTTR steht üblicherweise für Mean Time to Repair, Recover, Resolve oder Restore, und Organisationen verwenden das zweite Wort unterschiedlich. Definieren Sie also Ihre eigene Version. Für den Infrastrukturbetrieb ist die Zeit bis zur Wiederherstellung des Dienstes oft am nützlichsten. Eine einfache Formel lautet:

MTTR = Sum of restoration durations / Number of incidents

Auch hier brauchen Sie klare 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 wieder läuft? Das sind unterschiedliche Kennzahlen.

Bei einem KI-Trainings-Incident kann der Dienst wiederhergestellt sein, sobald der Job aus einem Checkpoint auf funktionsfähigen Ressourcen weiterläuft, auch 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 können Sie separat erfassen.

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 funktioniert. MTTR misst, wie schnell der betroffene Workload nach dem definierten Wiederherstellungsprozess wieder in einen funktionsfähigen Zustand kommt.

Eine gute Fehlertoleranz-Schleife senkt die MTTR, indem sie:

• die defekte Karte erkennt
• keine weiteren Jobs mehr auf ihr einplant
• 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. Ist ein Checkpoint sechs Stunden alt, kann der Dienst zwar schnell wieder laufen, aber das Unternehmen verliert trotzdem sechs Stunden Rechenleistung. Diese verlorene Arbeit sollten Sie separat erfassen.

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

Was ist ein SLO?

Ein Service Level Objective, kurz 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, gemessen an Service-Level-Indikatoren.

Für einen Inferenzdienst kommen etwa diese Indikatoren infrage:

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

Für einen Trainingsdienst eignen sich zum Beispiel:

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

Und für die Infrastruktur selbst:

• 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, an denen Nutzer oder das Geschäft die Zuverlässigkeit tatsächlich spüren.

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

Legen Sie den Dienst, den Indikator, das Ziel, das Messfenster und die Menge der gezählten Ereignisse fest. Ein 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, wichtiger ist die Methode. Zwei Teams können beide ein SLO von 99,9 Prozent angeben und dabei unterschiedliche Anfragen zählen, und dann sagt der Vergleich nichts mehr aus. Halten Sie die Definition deshalb 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 hilft, wenn ein Dienst strikte Latenz braucht und ein anderer nach dem Best-Effort-Prinzip läuft.

Was ist ein Error Budget?

Ein Error Budget ist das Maß an Unzuverlässigkeit, das das SLO im Messfenster erlaubt. Liegt das SLO bei 99,9 Prozent Erfolg, sind die verbleibenden 0,1 Prozent nach dieser Definition das Error Budget. Für ein anfragebasiertes SLO gilt:

Error budget = Total eligible events × Allowed failure fraction

Bei 1.000.000 berechtigten Anfragen und einem SLO, das 0,1 Prozent Fehlschläge erlaubt:

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

Fehlschläge werden dadurch nicht wünschenswert. Die Organisation bekommt aber eine quantitative Grenze, an der sie Zuverlässigkeit und Änderungsgeschwindigkeit gegeneinander abwägen kann. Ist das Budget gesund, hat das Team Spielraum für das normale Risiko der Softwareauslieferung. Ist es erschöpft, hat Zuverlässigkeitsarbeit Vorrang.

Das zugrunde liegende SRE-Modell arbeitet genau so: Überschreitet das Budget die Schwelle, 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 einem gleichmäßigen Verbrauch über das ganze Fenster. Bei einer Burn Rate von 1 verbraucht der Dienst das Budget im erwarteten Durchschnittstempo und wäre genau am Ende des Zeitraums damit fertig. Über 1 geht das Budget schneller weg, und bei einer sehr hohen Burn Rate kann der Dienst sein Kontingent schnell aufbrauchen, wenn der Zustand anhält.

Nützlich ist die Burn Rate, weil rohe Fehlerzahlen in die Irre führen können. Zehn Fehlschläge in einer Minute können für einen Dienst mit geringem Volumen gravierend sein und für einen Dienst mit sehr hohem Volumen kaum ins Gewicht fallen. Die Burn Rate setzt die Fehlschläge ins Verhältnis zum SLO und zum verbleibenden Budget.

Warum mehrere Burn-Rate-Fenster verwenden?

Mit mehreren Fenstern erkennen Sie sowohl schnelle Incidents als auch eine langsame Verschlechterung der Zuverlässigkeit. Googles SRE Workbook beschreibt Multiwindow-, Multi-Burn-Rate-Alerting als Weg, bedeutsamen SLO-Verbrauch zu erkennen, ohne dass das Alarm-Rauschen ausufert.

Ein kurzes Fenster reagiert empfindlich auf schnelle Fehlschläge, ein längeres bestätigt, dass der Zustand lange genug anhält, um relevant zu sein. Zusätzlich können Sie getrennte Alarmpfade für Fast Burn und Slow Burn definieren. Fast Burn heißt, dass das Budget schnell verschwindet und jemand sofort reagieren muss. Slow Burn heißt, dass sich der Dienst über längere Zeit verschlechtert und geplante Zuverlässigkeitsarbeit nötig sein könnte.

Das zugrunde liegende Betriebsmodell nutzt dasselbe Konzept mit Multiwindow-, Multi-Burn-Rate-Alarmen. Ein Alarm soll dann entstehen, 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 die Verfügbarkeit als auch die Qualität der Auslieferung abbilden. Das zugrunde liegende Material nennt Kennzahlen wie Token-Erfolgsrate, Durchsatz, Time to First Token, Latenz pro Token und Timeout-Rate. Ein Modell-Dienst kann daher mehrere SLOs haben, zum Beispiel für:

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

Fassen Sie nicht alle Indikatoren zu einem zusammengesetzten Wert zusammen, wenn sie unterschiedliche Nutzererfahrungen abbilden. Ein Dienst kann eine exzellente Erfolgsrate und eine schreckliche Latenz haben, und der Nutzer erlebt trotzdem einen schlechten Dienst. Mit getrennten SLOs sehen Sie, woran es liegt.

Wie sollte SRE auf Trainingsdienste angewendet werden?

Bei Training-SRE steht die Zuverlässigkeit des Job-Lebenszyklus im Mittelpunkt. 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, operativ aber teuer. Diese verlorene Rechenleistung sollte sichtbar sein.

Ebenso kann ein Scheduler hochverfügbar sein, während Nutzer stundenlang auf die angeforderte Ressourcenklasse warten. Für die Nutzer zählt, ob sie nutzbare Rechenleistung bekommen, und das sagt die Verfügbarkeit des Scheduler-Prozesses allein nicht aus.

Was ist eine Automatisierungsquote für Fehlerbehebung?

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

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

Dabei müssen Sie festlegen, was „berechtigt“ heißt. Hochriskante Incidents sollten nicht als Automatisierungsfehler zählen, wenn die Richtlinie bewusst eine menschliche Freigabe verlangt.

Das zugrunde liegende SRE-Modell teilt Incidents nach Risikostufe ein. Bekannte, vorübergehende Ereignisse können sich selbst erholen, bei Incidents mit kontrolliertem Risiko laufen genehmigte Skripte mit Rollback, und risikobehaftete Änderungen brauchen eine Workflow-Freigabe und eine Canary-Ausführung. Dadurch wird die Quote aussagekräftig, denn sie misst Automatisierung innerhalb des genehmigten Rahmens.

Was ist Toil-Reduktion?

Toil-Reduktion misst, wie viel repetitive manuelle Betriebsarbeit wegfällt oder kürzer wird. 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

Ob Menschen eine Arbeit mögen, ist dabei kein Maßstab für Toil. Manche manuelle Arbeit ist wertvoll, weil sie Urteilsvermögen erfordert. Automatisiert werden sollten die repetitiven, vorhersehbaren Aktionen, damit sich Ingenieure auf Diagnose, Kapazität, Zuverlässigkeit und Verbesserungen konzentrieren können.

Messen Sie die tatsächlich eingesparte Zeit. Sonst wird „Automatisierung“ schnell zu einer Feature-Zählung ohne operativen Nutzen.

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

Ein Post-Incident-Review sollte aus einzelnen Fehlschlägen Änderungen am Zuverlässigkeitssystem machen. Festgehalten werden sollten:

• 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

War die MTTD schlecht, verbessern Sie die Erkennung. War die MTTR schlecht, 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 Erkenntnissen profitieren.

Wie beeinflussen Error Budgets Release-Entscheidungen?

Error Budgets liefern ein messbares Release-Gate. Liegt der Dienst komfortabel innerhalb seines SLO und ist noch Budget übrig, laufen Releases gemäß Richtlinie normal weiter. Ist das Budget fast erschöpft, können risikoreiche Änderungen verlangsamt werden, und ist es ganz verbraucht, kann das Team nicht essenzielle Releases einfrieren und Zuverlässigkeitsarbeit vorziehen.

Damit stützt sich die Diskussion auf Evidenz statt auf Meinungen. Produktteams sehen die Zuverlässigkeitsbeschränkung, Betriebsteams können den Verbrauchstrend zeigen, und das Management sieht das prognostizierte Erschöpfungsdatum. Darin liegt der Wert eines Error Budgets für das Management.

Wie unterstützt AIOps SRE?

AIOps kann die MTTD senken, indem es Fehlschläge schneller erkennt und korreliert, und die MTTR, indem es wahrscheinliche Ursachen identifiziert und genehmigte Abhilfemaßnahmen vorschlägt oder ausführt. Ob diese Verbesserungen real sind, zeigt aber erst der Messrahmen von SRE.

Wenn ein AIOps-System eine schnellere Diagnose behauptet, vergleichen Sie die MTTD vorher und nachher. Kommt automatisierte Wiederherstellung dazu, vergleichen Sie MTTR und Wiederholungsrate. Verbessert sich die Alarmkorrelation, vergleichen Sie die Arbeitslast der Bediener und das Volumen falscher Incidents. Und wenn die Zuverlässigkeit sinkt, während die Automatisierung zunimmt, funktioniert die Automatisierung nicht.

Wie beides zusammenhängt, beschreibt der Artikel wie AIOps Alarm-Rauschen reduziert, Grundursachen identifiziert und die geschäftlichen Auswirkungen bestimmt.

Was sollte ein SRE-Dashboard zeigen?

Ein nützliches SRE-Dashboard zeigt Zuverlässigkeitsleistung, Budgetstatus, Incident-Risiko und operativen Aufwand. Mindestens gehören dazu:

• 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 und nicht mit 100 Kennzahlen. Definieren Sie für jeden ein oder zwei SLOs, messen Sie MTTD und MTTR, legen Sie ein 30-Tage-Error-Budget an und prüfen Sie jeden Incident, der einen bedeutenden Teil davon verbraucht. Sobald Sie den Definitionen vertrauen, erweitern Sie das System.