Aller au contenu principal
Avancé•10–16 heures

Exercice de récupération et de réconciliation d’incident IA

Exécutez un exercice de production pour les pannes de fournisseur, les régressions de modèle et les effets de bord incertains : confinement, préservation des preuves, récupération reconcile-first, rollback vers un état connu, failback et conversion de l’incident en régression.

réponse aux incidents IAconfinementréconciliationrollbackfailbackrégression post-incident

Scénario

Tâche

Un workflow IA appelle un modèle externe et des tools, puis la requête se termine par un timeout. On ignore si l’effet de bord du tool a déjà eu lieu. Un retry aveugle peut créer un doublon, tandis qu’un rollback limité au code applicatif ne garantit pas le retour de la configuration model/prompt/retrieval. Exécutez un exercice où l’équipe restaure l’état faisant autorité au lieu de simplement redémarrer le service.

Exécution pas à pas

1. Classer l’incident selon son impact réel

Résultat: Le confinement priorise l’autorité, l’exposition des données et les effets de bord irréversibles plutôt que le volume de l’alerte.

Tâches

  • →Identifier les tâches, utilisateurs, données et actions affectés
  • →Vérifier l’état model/provider/retrieval/tool
  • →Évaluer les effets de bord unknown ou pending
  • →Activer le kill switch ou mode dégradé le plus étroit mais suffisant

Vérifications

  • ✓Le confinement préserve les artefacts forensiques nécessaires
  • ✓Un write path à fort impact peut être arrêté indépendamment des fonctions read-only
  • ✓Un effet de bord inconnu n’est pas marqué failed sans vérification

2. Préserver les preuves et réconcilier l’état faisant autorité

Résultat: L’équipe sait ce qui s’est réellement produit avant tout retry ou compensation.

Tâches

  • →Collecter la correlation/runtime envelope
  • →Rapprocher la requête tool de l’état du system of record
  • →Vérifier l’idempotency key et l’historique des doublons
  • →Classer le résultat comme completed, not completed, pending ou unknown

Vérifications

  • ✓Le retry est bloqué pour pending/unknown jusqu’à la réconciliation
  • ✓Le système faisant autorité prévaut sur le transcript de l’agent
  • ✓Les preuves ne contiennent pas de secrets ou PII inutiles

3. Exécuter rollback, compensation et récupération progressive

Résultat: Le système revient à un comportement known-good et à un état métier cohérent.

Tâches

  • →Restaurer l’enveloppe complète de comportement
  • →Exécuter la compensation uniquement pour les effets de bord confirmés
  • →Lancer les smoke/eval checks
  • →Rouvrir le trafic progressivement avec une période d’observation

Vérifications

  • ✓Le rollback inclut les versions model/prompt/retrieval/tool/policy
  • ✓La compensation est elle-même idempotente ou reconciled
  • ✓Recovery PASS exige des preuves du runtime et de l’état faisant autorité

4. Transformer l’incident en contrôle de régression

Résultat: La même famille de pannes ne dépend plus de la mémoire de l’équipe.

Tâches

  • →Minimiser le reproducteur
  • →Ajouter des checks déterministes ou model-based si nécessaire
  • →Lier le cas à une sévérité bloquante
  • →Mettre à jour runbook, alerte et responsable

Vérifications

  • ✓Le test de régression reproduit le signal de panne original
  • ✓Un cas critique issu de l’incident fait partie du release gate
  • ✓Le postmortem contient un changement de contrôle, pas seulement une consigne de prudence

Critères d’acceptation

  • La carte d’incident fournit un confinement ciblé pour les pannes model/provider/retrieval/tool/write
  • Un effet de bord unknown ou pending passe par une réconciliation faisant autorité avant retry
  • Le rollback restaure l’enveloppe complète de comportement, pas seulement le commit de code
  • La récupération est confirmée par le runtime fingerprint et l’état métier faisant autorité
  • Un incident de production est réduit à un cas de régression permanent avec responsable et sévérité