Fortgeschritten•12–18 Stunden

Production Observability für ein AI-System

Baue Monitoring und einen Incident-Workflow für eine AI-Workload mit Evidenz zu Latenz, Kosten, Qualität, Fallback und Rollback.

SLOTracingKostenmonitoringQualitätssignaleIncident ResponseFallbacks

Szenario

Aufgabe

Eine AI-Funktion nutzt ein externes Modell und internes Retrieval. Das Team muss Verschlechterungen bei Latenz, Kosten, Fehlerrate und Antwortqualität erkennen, bevor Nutzer sie bemerken.

Schrittweise Umsetzung

1. Signale definieren

Ergebnis: Der Betriebszustand der AI-Funktion ist über die gesamte Pipeline messbar.

Aufgaben

→Latenz und Fehlerrate erfassen
→Token- und Kostenverbrauch messen
→Retrieval- und Qualitätssignale ergänzen
→Über Request ID korrelieren

Prüfungen

✓Ein End-to-End-Trace existiert
✓PII und Prompts gelangen nicht ohne explizite Policy in Logs

2. SLO aufbauen

Ergebnis: Das Team hat explizite Grenzen für akzeptable Degradation.

Aufgaben

→Availability SLO definieren
→Latency SLO ergänzen
→Quality Proxy definieren
→Error Budget berechnen

Prüfungen

✓Alerts sind an User Impact gebunden
✓Ein einzelner transienter Fehler löst keinen Alert aus

3. Control Plane ergänzen

Ergebnis: Das System kann sicher in einen Degraded Mode wechseln.

Aufgaben

→Rate Limits ergänzen
→Fallback-Modell konfigurieren
→Queue Backpressure ergänzen
→Kill Switch implementieren

Prüfungen

✓Fallback wird getestet
✓Der Kill Switch benötigt kein neues Deployment

4. Incident Drill durchführen

Ergebnis: Recovery ist durch Evidenz belegt.

Aufgaben

→Provider-Ausfall simulieren
→Cost Spike simulieren
→Rollback prüfen
→Postmortem erstellen

Prüfungen

✓Die Timeline ist aus Telemetrie rekonstruierbar
✓Recovery entspricht dem Runbook

Akzeptanzkriterien

End-to-End Observability ist vorhanden
SLO und Error Budget sind dokumentiert
Kosten und Qualität besitzen Alerts
Fallback und Kill Switch sind getestet
Der Incident Drill endet mit einem Postmortem

Bewertungsraster

Wie das Ergebnis bewertet wird

Bestehensgrenze: 75/100 · Auszeichnung: 92/100

Telemetry-Abdeckung

Model-, Retrieval- und Application-Layer verfügen über End-to-End-Sichtbarkeit.

25 Punkte

Unzureichend

Es gibt nur Application Logs.

Kompetent

Latency, Errors, Cost und Quality werden korreliert.

Stark

Distributed Tracing und eine Redaction Policy sind umgesetzt.

Erforderliche Nachweise

✓ Link zu Code oder Artefakt
✓ README mit Entscheidungen
✓ Testausgabe oder Runtime-Evidenz
✓ Trace- und Metrics-Map

SLO und Alerts

Alerts spiegeln User Impact und Error Budget wider.

25 Punkte

Unzureichend

Alerts sind verrauscht oder ohne SLO.

Kompetent

SLOs und Schwellenwerte sind festgelegt.

Stark

Burn-Rate Alerts und Capacity Signals sind automatisiert.

Erforderliche Nachweise

✓ Link zu Code oder Artefakt
✓ README mit Entscheidungen
✓ Testausgabe oder Runtime-Evidenz
✓ SLO-Dokument und Alert-Beispiele

Fallback und Control Plane

Rate Limits, Fallback, Backpressure und Kill Switch sind verifiziert.

25 Punkte

Unzureichend

Es gibt keinen sicheren Degraded Mode.

Kompetent

Fallback und Kill Switch funktionieren.

Stark

Automatisches Routing und eine Rollback Policy sind umgesetzt.

Erforderliche Nachweise

✓ Link zu Code oder Artefakt
✓ README mit Entscheidungen
✓ Testausgabe oder Runtime-Evidenz
✓ Fallback-Test

Incident Readiness

Ein Failure Drill enthält Timeline, Recovery und Postmortem.

25 Punkte

Unzureichend

Das Runbook ist nur deklarativ.

Kompetent

Der Drill wurde mit Evidenz abgeschlossen.

Stark

Recovery ist automatisiert und wird regelmäßig getestet.

Erforderliche Nachweise

✓ Link zu Code oder Artefakt
✓ README mit Entscheidungen
✓ Testausgabe oder Runtime-Evidenz
✓ Incident Report