MTTD, MTTR, SLO, budgets d'erreur et burn rate pour l'infrastructure IA

Les métriques SRE transforment la fiabilité de l'IA et de l'infrastructure en quelque chose que les équipes peuvent mesurer et piloter. Le MTTD indique à quelle vitesse les problèmes sont détectés, le MTTR à quelle vitesse le service est rétabli, les SLO fixent la cible de fiabilité, le budget d'erreur chiffre le niveau de non-fiabilité acceptable et le burn rate montre à quel rythme ce budget se consomme.

Pour une infrastructure IA, ces métriques doivent couvrir plus que la disponibilité applicative. Elles peuvent s'appliquer au succès des entraînements, au succès de l'inférence, au débit de Tokens, au temps jusqu'au premier Token, à la disponibilité des accélérateurs, à la reprise après défaillance et aux autres chemins critiques qui conditionnent la capacité à transformer de la puissance de calcul en service stable.

Qu'est-ce que le MTTD ?

Le Mean Time to Detect, ou MTTD, mesure le temps qu'il faut aux outils d'exploitation ou à l'équipe pour détecter un incident après son début.

Une formule simple :

MTTD = Sum of detection delays / Number of incidents

La difficulté est de définir le moment où un incident commence. Pour un événement matériel, ce peut être la première erreur ECC. Pour un incident de service, ce peut être la première requête qui viole l'indicateur de service, et pour un problème de refroidissement, le premier dépassement de seuil. Choisissez une règle par classe d'incident et appliquez-la de façon constante.

Un MTTD bas signifie que les problèmes deviennent visibles rapidement, alors qu'un MTTD élevé signifie que des pannes peuvent affecter les charges de travail trop longtemps avant que quiconque ne s'en aperçoive. La détection automatique peut réduire le MTTD, mais seulement si les alarmes ont un sens. Une avalanche d'alarmes à laquelle personne ne fait confiance peut techniquement détecter le problème en quelques secondes pendant que la réaction humaine reste lente. Il faut donc lire le MTTD avec la qualité des alarmes et la consolidation des incidents.

Qu'est-ce que le MTTR ?

Mean Time to Repair, Recover, Resolve ou Restore s'abrège couramment en MTTR, mais les organisations donnent au deuxième mot des sens différents, alors définissez le vôtre. Pour l'exploitation d'infrastructure, la version la plus utile est souvent le temps de rétablissement du service.

Une formule simple :

MTTR = Sum of restoration durations / Number of incidents

Là encore, définissez les horodatages de début et de fin. Le chronomètre démarre-t-il à la panne ou à la détection ? S'arrête-t-il quand l'équipement est réparé ou quand le service vu par l'utilisateur est rétabli ? Chaque réponse donne une métrique différente.

Pour un incident d'entraînement IA, le service peut être considéré comme rétabli quand le job reprend depuis un checkpoint sur des ressources saines, même si le GPU défaillant est réparé plus tard. C'est souvent une meilleure métrique d'exploitation, parce qu'elle mesure combien de temps le travail productif a été interrompu. Le temps de réparation du matériel peut être suivi à part.

Comment le MTTD et le MTTR s'appliquent-ils aux pannes de GPU ?

Pour une panne de GPU, le MTTD mesure la vitesse à laquelle la plateforme identifie que la carte ou le nœud n'est plus sain. Le MTTR mesure la vitesse à laquelle la charge de travail touchée retrouve un état sain selon le processus de reprise défini.

Une bonne boucle de tolérance aux pannes peut réduire le MTTR si elle sait :

Détecter la carte défectueuse
Cesser d'y planifier de nouvelles tâches
Trouver le job touché
Choisir un checkpoint valide
Allouer des ressources saines de remplacement
Relancer le job
Vérifier qu'il progresse

C'est pour cela que l'intégration entre l'état du matériel et l'ordonnanceur compte. Si l'équipe a besoin de 20 minutes pour savoir quel job utilise la carte, cette recherche de correspondance fait partie du MTTR. Si un checkpoint date de six heures, le service peut être rétabli vite, mais l'entreprise perd quand même six heures de calcul, et ce travail perdu doit être suivi séparément.

L'article sur la manière dont une infrastructure IA peut relancer automatiquement les jobs d'entraînement après une panne de GPU ou de serveur détaille cette boucle de reprise.

Qu'est-ce qu'un SLO ?

Un Service Level Objective, ou SLO, est une valeur cible pour un indicateur de niveau de service sur une période définie. Les recommandations SRE de Google traitent les SLO comme des cibles de fiabilité de service fondées sur des indicateurs de niveau de service mesurables.

Pour un service d'inférence, les indicateurs possibles sont :

Taux de succès des requêtes
Taux de succès des Tokens
Latence
Temps jusqu'au premier Token
Débit de Tokens
Taux de timeout

Pour un service d'entraînement, les indicateurs possibles sont :

Succès du démarrage des jobs
Succès de l'achèvement des tâches
Temps d'attente en file
Succès des checkpoints
Temps de reprise
Disponibilité des ressources

Pour l'infrastructure, les indicateurs possibles sont :

Disponibilité des accélérateurs
Disponibilité du réseau
Latence du stockage
Succès du provisionnement
Délai d'intervention pour réparation matérielle

Ne créez pas un SLO pour chaque métrique. Choisissez les indicateurs qui représentent la fiabilité visible par l'utilisateur ou importante pour l'activité.

Comment définir le SLO d'un service d'IA ?

Définissez le service, l'indicateur, la cible, la fenêtre de mesure et la population d'événements. Par exemple :

Service : endpoint d'inférence de production
Indicateur : requêtes réussies / requêtes éligibles
Cible : 99.9 pour cent
Fenêtre : 30 jours glissants
Exclusions : maintenance explicitement définie ou trafic de test non facturable

Le chiffre exact est une décision métier, et la méthode compte davantage. Deux équipes peuvent afficher chacune un SLO de 99.9 pour cent en comptant des requêtes différentes, ce qui rend toute comparaison dénuée de sens. Gardez la définition exportable et versionnée.

Le modèle opérationnel source prévoit aussi des niveaux de service comme Gold, Silver et Bronze, pour que différents modèles aient des seuils différents. Cela peut servir quand un service exige une latence stricte alors qu'un autre fonctionne en best effort.

Qu'est-ce qu'un budget d'erreur ?

Le budget d'erreur est la part de non-fiabilité que le SLO autorise pendant la fenêtre de mesure. Si le SLO est de 99.9 pour cent de succès, le budget d'erreur correspond aux 0.1 pour cent restants selon cette définition.

Pour un SLO fondé sur les requêtes :

Error budget = Total eligible events × Allowed failure fraction

S'il y a 1,000,000 requêtes éligibles et que le SLO autorise 0.1 pour cent d'échecs :

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

Un échec reste indésirable. Le budget donne à l'organisation une limite chiffrée pour arbitrer entre fiabilité et vitesse de changement. Si le budget est sain, l'équipe a de la marge pour le risque normal des livraisons, et s'il est épuisé, le travail de fiabilité doit passer en priorité. Le modèle SRE source applique exactement ce principe : quand le budget franchit le seuil, les mises en production peuvent être gelées jusqu'au remboursement de la dette de fiabilité.

Que signifie le burn rate ?

Le burn rate mesure la vitesse à laquelle le service consomme son budget d'erreur, comparée au rythme qui consommerait ce budget de façon régulière sur toute la fenêtre. Un burn rate de 1 signifie que le service consomme le budget au rythme moyen qui l'épuiserait pile à la fin de la fenêtre. Un burn rate supérieur à 1 signifie que le budget part plus vite, et un burn rate très élevé signifie que le service peut épuiser son allocation rapidement si la situation dure.

Le burn rate est utile parce que les nombres bruts d'erreurs peuvent induire en erreur. Dix échecs en une minute peuvent être graves pour un service à faible volume et négligeables pour un service à très fort volume. Le burn rate rapporte les échecs au SLO et au budget restant.

Pourquoi utiliser plusieurs fenêtres de burn rate ?

Plusieurs fenêtres permettent de détecter à la fois les incidents rapides et la dégradation lente de la fiabilité. Le SRE Workbook de Google décrit l'alerting multi-fenêtres et multi-burn-rate comme un moyen de détecter une consommation significative du SLO tout en maîtrisant le bruit des alertes.

Une fenêtre courte réagit aux pannes rapides, et une fenêtre plus longue confirme que la situation dure assez pour compter. Vous pouvez aussi définir des chemins d'alerte distincts pour la consommation rapide et la consommation lente. Une consommation rapide signifie que le budget fond vite et demande une réaction urgente. Une consommation lente signifie que le service se dégrade sur une période plus longue et peut nécessiter un travail de fiabilité planifié.

Le modèle opérationnel source reprend ce concept avec des alertes multi-fenêtres et multi-burn-rate. L'objectif est de ne déclencher d'alerte que lorsque l'objectif de fiabilité est réellement menacé.

Comment appliquer les SLO aux services de Tokens ?

Les services de Tokens peuvent utiliser des indicateurs qui reflètent à la fois la disponibilité et la qualité de livraison. Le matériau source cite des mesures comme le taux de succès des Tokens, le débit, le temps jusqu'au premier Token, la latence par Token et le taux de timeout, si bien qu'un service de modèle peut avoir plusieurs SLO. Par exemple :

Taux de succès des requêtes
Succès de la génération de Tokens
Temps jusqu'au premier Token
Continuité du streaming
Latence globale
Taux de timeout

Ne regroupez pas tous les indicateurs dans un score composite s'ils représentent des expériences utilisateur différentes. Un service peut avoir un excellent taux de succès et une latence désastreuse, et l'utilisateur voit quand même un mauvais service. Des SLO séparés rendent le mode de défaillance visible.

Comment appliquer le SRE aux services d'entraînement ?

Le SRE de l'entraînement doit se concentrer sur la fiabilité du cycle de vie des jobs. Indicateurs utiles :

Délai d'admission dans la file
Succès du démarrage des jobs
Succès de l'achèvement des jobs
Succès des checkpoints
Succès des reprises
Calcul moyen perdu après une panne
Disponibilité des ressources
Taux de pannes répétées

Un job d'entraînement qui échoue au bout de 18 heures et repart d'un checkpoint vieux de 17 heures est techniquement rétabli, mais coûteux en exploitation, et ce calcul perdu doit être visible. De même, un ordonnanceur peut être hautement disponible pendant que les utilisateurs attendent des heures la classe de ressources demandée. La fiabilité du service couvre toute l'expérience d'obtention d'un calcul utile, au-delà de la disponibilité du processus de l'ordonnanceur.

Qu'est-ce que le taux de remédiation automatique ?

Le taux de remédiation automatique mesure la part des incidents éligibles résolus par des actions automatisées approuvées, sans exécution manuelle. Une définition simple :

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

Définissez « éligible ». Les incidents à haut risque ne doivent pas compter comme des échecs d'automatisation si la politique exige volontairement une approbation humaine.

Le modèle SRE source classe les incidents par niveau de risque. Les événements transitoires connus peuvent se rétablir seuls, les incidents à risque maîtrisé peuvent lancer des scripts approuvés avec retour arrière, et les changements porteurs de risque exigent une approbation par workflow et une exécution en canary. Le taux d'automatisation a alors un sens, parce qu'il mesure l'automatisation à l'intérieur du périmètre approuvé.

Qu'est-ce que la réduction du toil ?

La réduction du toil mesure la quantité de travail d'exploitation manuel et répétitif supprimée ou raccourcie. Indicateurs possibles :

Interventions manuelles par incident
Minutes d'opérateur par incident
Nombre d'actions répétées automatisées
Ordres de travail terminés sans exécution manuelle de commande
Temps passé en inspection de routine
Récurrence des incidents répétés

Le toil désigne plus que « le travail que les gens n'aiment pas ». Une partie du travail manuel a de la valeur parce qu'elle demande du jugement. Le but est d'automatiser les actions répétitives et prévisibles pour que les ingénieurs se consacrent au diagnostic, à la capacité, à la fiabilité et à l'amélioration. Mesurez le temps réellement gagné, sinon « l'automatisation » peut devenir un simple décompte de fonctionnalités sans bénéfice opérationnel.

Comment relier les revues d'incident aux métriques SRE ?

La revue post-incident doit transformer des pannes isolées en changements du système de fiabilité. Elle doit conserver :

Chronologie
Cause racine
Facteurs contributifs
Écart de détection
Écart de reprise
Ampleur de l'impact sur le service
Volume de calcul perdu
Impact sur le SLO
Consommation du budget d'erreur
Actions d'amélioration
Responsable
Échéance

Si le MTTD était mauvais, améliorez la détection. Si le MTTR était mauvais, améliorez les runbooks, la répartition des responsabilités, les checkpoints ou l'automatisation. Si la même panne continue de consommer le budget d'erreur, corrigez le problème de fiabilité sous-jacent au lieu d'améliorer seulement le processus de réponse. La revue doit alimenter la base de connaissances pour que les incidents futurs profitent de ce qui a été appris.

Comment les budgets d'erreur influencent-ils les décisions de mise en production ?

Les budgets d'erreur fournissent un critère mesurable pour autoriser une mise en production. Si le service tient largement son SLO et qu'il reste du budget, les mises en production normales peuvent continuer selon la politique. Si le budget est presque épuisé, on peut ralentir les changements à haut risque, et une fois qu'il est épuisé, l'équipe peut geler les mises en production non essentielles et donner la priorité au travail de fiabilité.

La discussion passe ainsi de l'opinion aux preuves. Les équipes produit voient la contrainte de fiabilité, les équipes d'exploitation montrent la tendance de consommation et la direction voit la date d'épuisement prévue. C'est là que le budget d'erreur justifie sa place comme outil de gestion.

Comment l'AIOps aide-t-il le SRE ?

L'AIOps peut réduire le MTTD en détectant et en corrélant les pannes plus vite, et réduire le MTTR en identifiant les causes probables et en recommandant ou en exécutant une remédiation approuvée. Le SRE fournit le cadre de mesure qui indique si ces améliorations sont réelles.

Si un système AIOps promet un diagnostic plus rapide, comparez le MTTD avant et après. Si vous ajoutez une reprise automatisée, comparez le MTTR et la récurrence. Si la corrélation des alarmes s'améliore, comparez la charge des opérateurs et le volume de faux incidents. Si la fiabilité se dégrade pendant que l'automatisation augmente, l'automatisation a échoué.

La relation entre les deux est traitée dans comment l'AIOps réduit le bruit des alarmes, identifie les causes racines et évalue l'impact métier.

Que doit afficher un tableau de bord SRE ?

Un tableau de bord SRE utile doit montrer la performance en fiabilité, l'état du budget, le risque d'incident et l'effort d'exploitation. Au minimum :

MTTD
MTTR
Atteinte du SLO
Budget d'erreur restant
Burn rate
Date prévue d'épuisement du budget
Nombre d'incidents
Niveau de risque
Taux de remédiation automatique
Tendance du toil
Incidents répétés
Avancement des actions post-incident

Sensaka est un exemple de plateforme qui applique ces mesures de l'infrastructure jusqu'aux services de Tokens.

Si je devais introduire le SRE dans une infrastructure IA, je commencerais par trois services critiques plutôt que par 100 métriques. Définissez un ou deux SLO pour chacun, mesurez le MTTD et le MTTR, créez un budget d'erreur sur 30 jours et analysez chaque incident qui en consomme une part significative. Une fois que les définitions inspirent confiance, étendez le système.