Zum Hauptinhalt springen
Fortgeschritten•10–16 Stunden

AI Incident Recovery & Reconciliation Drill

Führe einen Production Drill für Provider-Ausfälle, Modellregressionen und unklare Side Effects durch: Containment, Evidence Preservation, Reconcile-first Recovery, Known-good Rollback, Failback und Incident-to-Regression.

AI Incident ResponseContainmentReconciliationRollbackFailbackPost-Incident Regression

Szenario

Aufgabe

Ein AI-Workflow ruft ein externes Modell und Tools auf, danach endet der Request mit einem Timeout. Es ist unklar, ob der Tool-Side-Effect bereits eingetreten ist. Ein blinder Retry kann ein Duplikat erzeugen, und ein Rollback nur des Application Codes garantiert nicht die Wiederherstellung der Model-, Prompt- oder Retrieval-Konfiguration. Führe einen Drill durch, in dem das Team den autoritativen Zustand wiederherstellt, statt lediglich den Service neu zu starten.

Schrittweise Umsetzung

1. Incident nach tatsächlichem Impact klassifizieren

Ergebnis: Containment priorisiert Authority, Data Exposure und irreversible Side Effects statt der Lautstärke eines Alerts.

Aufgaben

  • →Betroffene Tasks, Nutzer, Daten und Actions bestimmen
  • →Model-/Provider-/Retrieval-/Tool-State prüfen
  • →Unknown oder Pending Side Effects bewerten
  • →Den engsten ausreichenden Kill Switch oder Degraded Mode aktivieren

Prüfungen

  • ✓Containment erhält notwendige Forensic Artifacts
  • ✓Ein High-impact Write Path kann unabhängig von Read-only Functions gestoppt werden
  • ✓Ein unbekannter Side Effect wird ohne Verifikation nicht als fehlgeschlagen markiert

2. Evidence sichern und autoritativen Zustand reconciliieren

Ergebnis: Das Team weiß vor jedem Retry oder jeder Compensation, was tatsächlich passiert ist.

Aufgaben

  • →Correlation- und Runtime-Envelope erfassen
  • →Tool Request mit dem System-of-record-State abgleichen
  • →Idempotency Key und Duplicate History prüfen
  • →Outcome als completed, not completed, pending oder unknown klassifizieren

Prüfungen

  • ✓Retry bleibt für pending/unknown bis zur Reconciliation gesperrt
  • ✓Das autoritative System hat Vorrang vor dem Agent Transcript
  • ✓Evidence enthält keine unnötigen Secrets oder PII

3. Rollback, Compensation und stufenweise Recovery ausführen

Ergebnis: Das System kehrt zu Known-good Behavior und einem konsistenten Business State zurück.

Aufgaben

  • →Das vollständige Behavior Envelope zurückrollen
  • →Compensation nur für bestätigte Side Effects ausführen
  • →Smoke- und Eval-Checks durchführen
  • →Traffic stufenweise mit Hold Period wieder öffnen

Prüfungen

  • ✓Rollback umfasst Model-, Prompt-, Retrieval-, Tool- und Policy-Versionen
  • ✓Compensation ist selbst idempotent oder reconciled
  • ✓Recovery PASS erfordert Runtime- und Authoritative-state-Evidence

4. Incident in einen Regression Control umwandeln

Ergebnis: Dieselbe Failure Family hängt nicht mehr vom Gedächtnis des Teams ab.

Aufgaben

  • →Reproducer minimieren
  • →Bei Bedarf deterministische oder modellbasierte Checks ergänzen
  • →Case an eine blockierende Severity binden
  • →Runbook, Alert und Owner aktualisieren

Prüfungen

  • ✓Der Regressionstest reproduziert das ursprüngliche Failure Signal
  • ✓Ein kritischer incident-derived Case ist Teil des Release Gates
  • ✓Das Postmortem enthält eine Control-Änderung statt nur den Hinweis, vorsichtiger zu sein

Akzeptanzkriterien

  • Die Incident Map bietet scoped Containment für Model-/Provider-/Retrieval-/Tool-/Write-Fehler
  • Ein unknown oder pending Side Effect wird vor Retry autoritativ reconciled
  • Rollback stellt das vollständige Behavior Envelope statt nur des Code Commits wieder her
  • Recovery wird durch Runtime Fingerprint und autoritativen Business State bestätigt
  • Ein Production Incident wird zu einem permanenten Regression Case mit Owner und Severity minimiert