Zum Hauptinhalt springen
Kern•8–12 Stunden

Labor für AI-Serving-Release-Envelopes

Erstelle einen gesteuerten Release-Vertrag für eine AI-Runtime: exakter Model-/Konfigurations-Fingerprint, Readiness-Checks, begrenzte Retries, Canary, Rollback und Runtime-Verifikation statt der Annahme, grünes CI bedeute bereits Production Truth.

AI ServingRelease EnvelopesRuntime-VerifikationCanary RolloutRollbackReliability Engineering

Szenario

Aufgabe

Das Team ändert Modell, Prompt, Retrieval-Index oder Tool-Konfiguration und erhält grünes CI. In Production kann trotzdem eine andere Modellrevision, ein veralteter Prompt, ein unvollständiger Index oder alte Tool-Scopes laufen. Erstelle ein Release Envelope, das den verifizierten Kandidaten an die tatsächliche Runtime bindet und beweist, dass Canary und Production exakt die getestete Konfiguration ausführen.

Schrittweise Umsetzung

1. Release Unit breiter als einen Git-Commit definieren

Ergebnis: Das Team kann die tatsächlich geprüfte Verhaltenskonfiguration eindeutig benennen.

Aufgaben

  • →Code-/Model-/Prompt-/Retrieval-/Tool-/Policy-/Dependency-Fingerprint erfassen
  • →Immutable oder auflösbare Versionskennungen festhalten
  • →Owner für jede mutable Komponente bestimmen
  • →Mehrdeutige Aliase in Production-Evidence ohne aufgelöste Version verbieten

Prüfungen

  • ✓Ein freigegebenes Envelope entspricht einer reproduzierbaren Konfiguration
  • ✓Eine Änderung von Model Alias oder Retrieval-Index ändert den Fingerprint
  • ✓Secrets gelangen nicht in das Evidence-Artefakt

2. Readiness- und Failure-Vertrag bauen

Ergebnis: Die Runtime nimmt keinen Traffic an, solange eine kritische Dependency oder ein Policy-State nicht bereit ist.

Aufgaben

  • →Liveness und Readiness trennen
  • →Timeout, Cancellation und begrenzte Retries festlegen
  • →Health für Provider/Retrieval/Tools ergänzen
  • →Degraded Modes und Stop-Bedingungen definieren

Prüfungen

  • ✓Readiness-Fehler wird nicht durch Liveness-Erfolg verdeckt
  • ✓Retry-Budget erzeugt keinen Retry Storm
  • ✓Degraded Mode erweitert weder Authority noch Data Scope

3. Staged Rollout durchführen

Ergebnis: Der Kandidat erhält begrenzte Production-Exposition vor vollständiger Promotion.

Aufgaben

  • →Shadow oder Replay einsetzen, wo möglich
  • →Canary-Kohorte definieren
  • →Quality-/Reliability-/Cost-Signale mit Baseline vergleichen
  • →Explizites Promote/Hold/Rollback-Verdikt festhalten

Prüfungen

  • ✓Kritische Safety- oder Authority-Regression blockiert Promotion unabhängig vom Gesamtscore
  • ✓Canary hat ein zum Risk Class passendes Observation Window
  • ✓Rollback-Ziel ist vor Rollout verifiziert

4. Runtime Truth nachweisen

Ergebnis: Production-Status wird durch Runtime-Evidence bestätigt, nicht durch das Ende der Pipeline.

Aufgaben

  • →Tatsächlichen Runtime-Fingerprint lesen
  • →Mit dem freigegebenen Envelope vergleichen
  • →Stale Model-/Prompt-/Index-Mismatch simulieren
  • →Deployment-Verification-Artefakt speichern

Prüfungen

  • ✓Mismatch endet mit FAIL oder UNKNOWN, nie PASS
  • ✓CI PASS ersetzt keine Deploy-Verifikation
  • ✓Auch Rollback wird durch den tatsächlichen Runtime-Fingerprint bestätigt

Akzeptanzkriterien

  • Das Release Envelope versioniert Code, Modell, Prompt, Retrieval, Tools, Policies, Dependencies und Eval-Datensatz
  • Readiness prüft kritische AI-Dependencies und besitzt begrenzte Timeout-/Retry-/Cancellation-Regeln
  • Canary hat explizite Promote/Hold/Rollback-Kriterien und ein Known-Good-Rollback-Ziel
  • Production-Verifikation vergleicht den tatsächlichen Runtime-Fingerprint maschinell mit dem freigegebenen Envelope
  • Eine veraltete oder abweichende Runtime-Konfiguration kann keinen PASS erhalten