Zum Hauptinhalt springen
Kern•8–14 Stunden

AI Observability, SLO & Runtime Evidence Lab

Baue einen Observability-Vertrag für eine AI-Workload: End-to-End-Traces, risikogeschnittene SLI/SLOs, Qualitäts- und Kostensignale, datenschutzbewusste Telemetrie, autoritative Postconditions und Runtime-Evidence, die den echten Production-Zustand von einem schönen Dashboard unterscheidet.

AI ObservabilityDistributed TracingSLI/SLO DesignRuntime EvidenceCost AttributionPrivacy-aware Telemetry

Szenario

Aufgabe

Ein AI-Service hat grünen Uptime und akzeptable Median-Latenz, aber High-Risk-Tasks verschlechtern sich nach einer Änderung von Model Revision, Retrieval oder Tool Dependency. Das aggregierte Dashboard zeigt dies nicht, während Raw Prompts in Traces ein Datenschutzrisiko erzeugen. Baue einen Observability-Vertrag, der jeden Request mit Behavior Fingerprint, Model-/Retrieval-/Tool-Spans, dem tatsächlichen Business Outcome und den Kosten verknüpft, ohne Telemetrie zu einem weiteren Secret Store zu machen.

Schrittweise Umsetzung

1. Trace als Evidence Graph statt als Log Dump entwerfen

Ergebnis: Eine Aufgabe ist über Model, Retrieval, Tool, Approval und autoritatives Outcome verfolgbar, ohne die Release Identity zu verlieren.

Aufgaben

  • →Correlation/Run ID und Parent-Child-Span-Vertrag definieren
  • →Behavior Fingerprint ohne Secrets ergänzen
  • →Model-/Retrieval-/Tool-/Approval-/Outcome-Spans trennen
  • →Sampled-, Dropped- und Unavailable-Telemetry-Zustände markieren

Prüfungen

  • ✓Der Trace identifiziert die konkrete Model-/Config-Revision
  • ✓Ein fehlender Span wird nicht als Erfolg interpretiert
  • ✓High-cardinality Labels erzeugen keine unkontrollierte Kostenexplosion

2. Datenschutz- und Data-Minimization-Grenze festlegen

Ergebnis: Observability liefert genügend Evidence zur Diagnose, ohne Prompts, PII und Tool Payloads unkontrolliert zu kopieren.

Aufgaben

  • →Metadata, Content und sensitive Felder klassifizieren
  • →Vor dem Export Redaction oder Hashing anwenden
  • →Retention- und Access-Policy definieren
  • →Provider-/Exporter-Pfad als separate Data-Egress-Grenze prüfen

Prüfungen

  • ✓Secrets und Credentials gelangen nicht in Spans
  • ✓Sensitiver Content ist nicht standardmäßig für alle Traces aktiviert
  • ✓Retention und Deletion haben einen Owner und einen überprüfbaren Policy State

3. Risikogeschnittene SLOs und Unit Economics aufbauen

Ergebnis: Das Team sieht neben Uptime auch Qualität, verifiziertes Outcome und Kosten für unterschiedliche Task-Klassen.

Aufgaben

  • →SLIs für Latenz, Availability, Qualität und autoritativen Task Success definieren
  • →Normal-/High-Risk-/No-Answer-/Tool-Write-Slices trennen
  • →Kosten pro erfolgreich verifizierter Aufgabe ergänzen
  • →Error Budget und Blocking Threshold für kritische Slices festlegen

Prüfungen

  • ✓Ein Aggregate Average verbirgt keine Critical-Slice-Regression
  • ✓Ein fehlgeschlagener oder unsicherer Task zählt nicht als erfolgreiches Outcome
  • ✓Jedes SLO hat konkrete Data Source, Window und Owner

4. Runtime-Evidence- und Incident-Drill durchführen

Ergebnis: Ein Alert führt zu einer reproduzierbaren Ursache und der Incident wird zu einem Regression Control.

Aufgaben

  • →Stale Model-/Retrieval-Fingerprint injizieren
  • →Tool Timeout mit unklarem Side Effect simulieren
  • →UNKNOWN → Reconciliation → Verified-Outcome-Pfad prüfen
  • →Failure zu einem Replay-/Regression-Case minimieren und an das Release Gate binden

Prüfungen

  • ✓Ein Runtime Mismatch kann nicht mit PASS enden
  • ✓Retry erfolgt nicht vor Reconciliation eines unklaren Side Effects
  • ✓Der Incident Report enthält Trace/Evidence-Link, Control Change, Owner und Regression Test

Akzeptanzkriterien

  • Ein End-to-End-Trace verknüpft Release Fingerprint, Model-/Retrieval-/Tool-Stufen und autoritatives Outcome
  • Telemetrie besitzt einen Vertrag für Data Minimization, Redaction, Retention und Access
  • SLI/SLOs sind nach Risk-/Task-Slices getrennt und enthalten Kosten pro erfolgreich verifizierter Aufgabe
  • Fehlende oder stale Runtime Evidence endet als UNKNOWN/FAIL und nie als false-green PASS
  • Mindestens ein injizierter Incident wird in einen minimierten Replay und permanenten Regression Case überführt