Avancé•12–18 heures

Observabilité de production pour un système d’IA

Construisez le monitoring et un workflow d’incident pour une charge IA avec des preuves sur la latence, le coût, la qualité, le fallback et le rollback.

SLOtracingsuivi des coûtssignaux de qualitéréponse aux incidentsfallbacks

Scénario

Tâche

Une fonctionnalité IA dépend d’un modèle externe et d’un retrieval interne. L’équipe doit détecter la dégradation de la latence, du coût, du taux d’erreur et de la qualité des réponses avant les utilisateurs.

Exécution pas à pas

1. Définir les signaux

Résultat: L’état opérationnel de la fonctionnalité IA est mesurable sur toute la pipeline.

Tâches

→Ajouter la latence et le taux d’erreur
→Mesurer l’usage des tokens et le coût
→Ajouter les signaux de retrieval et de qualité
→Corréler par request ID

Vérifications

✓Un trace end-to-end existe
✓Les PII et prompts n’entrent pas dans les logs sans politique explicite

2. Construire le SLO

Résultat: L’équipe dispose de limites explicites pour la dégradation acceptable.

Tâches

→Définir un SLO de disponibilité
→Ajouter un SLO de latence
→Définir un proxy de qualité
→Calculer l’error budget

Vérifications

✓Les alertes sont liées à l’impact utilisateur
✓Une erreur transitoire unique ne déclenche pas d’alerte

3. Ajouter le control plane

Résultat: Le système peut passer en mode dégradé en sécurité.

Tâches

→Ajouter des rate limits
→Configurer un modèle de fallback
→Ajouter le backpressure de file
→Implémenter un kill switch

Vérifications

✓Le fallback est testé
✓Le kill switch ne nécessite pas un nouveau déploiement

4. Réaliser un exercice d’incident

Résultat: La récupération est appuyée par des preuves.

Tâches

→Simuler une panne du fournisseur
→Simuler un pic de coût
→Vérifier le rollback
→Créer un postmortem

Vérifications

✓La timeline est reconstructible depuis la télémétrie
✓La récupération correspond au runbook

Critères d’acceptation

Une observabilité end-to-end existe
Le SLO et l’error budget sont enregistrés
Le coût et la qualité ont des alertes
Le fallback et le kill switch sont testés
L’exercice d’incident se termine par un postmortem

Grille d’évaluation

Comment le résultat est évalué

Score de réussite: 75/100 · Distinction: 92/100

Couverture de télémétrie

Les couches modèle, retrieval et application disposent d’une visibilité end-to-end.

25 points

Insuffisant

Seuls les logs applicatifs existent.

Compétent

Latency, erreurs, coût et qualité sont corrélés.

Solide

Le distributed tracing et une politique de redaction sont en place.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README avec les décisions
✓ Sortie des tests ou preuve runtime
✓ Carte des traces et métriques

SLO et alertes

Les alertes reflètent l’impact utilisateur et l’error budget.

25 points

Insuffisant

Les alertes sont bruyantes ou sans SLO.

Compétent

Les SLO et seuils sont définis.

Solide

Les alertes burn-rate et les signaux de capacité sont automatisés.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README avec les décisions
✓ Sortie des tests ou preuve runtime
✓ Document SLO et exemples d’alertes

Fallback et control plane

Rate limits, fallback, backpressure et kill switch sont vérifiés.

25 points

Insuffisant

Il n’existe pas de degraded mode sûr.

Compétent

Le fallback et le kill switch fonctionnent.

Solide

Le routing automatique et une politique de rollback sont en place.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README avec les décisions
✓ Sortie des tests ou preuve runtime
✓ Test de fallback

Préparation aux incidents

Un failure drill comprend timeline, recovery et postmortem.

25 points

Insuffisant

Le runbook reste déclaratif.

Compétent

Le drill a été mené avec des preuves.

Solide

La récupération est automatisée et testée régulièrement.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README avec les décisions
✓ Sortie des tests ou preuve runtime
✓ Rapport d’incident