1. Warum braucht man überhaupt Metriken und SLO in der ChatGPT‑App
Stellen Sie sich zwei Zustände eines Teams vor.
Im ersten leben alle nach dem Prinzip „scheint zu funktionieren“. Solange sich die Nutzer nicht beim Support beschweren und keine wütenden Tweets schreiben – ist alles okay. Ab und zu schaut jemand in die Logs, scrollt durch eine endlose „Tapete“ aus Zeilen, nickt und schließt den Tab.
Im zweiten hat das Team ein paar einfache Dashboards:
- p95 der Latenz des wichtigsten MCP‑Werkzeugs.
- error‑rate für MCP und für Checkout.
- Verfügbarkeit der Webhooks.
- Conversion bis zur Bezahlung entlang des Funnels.
Und es gibt 3–5 SLO: „95 % der Aufrufe des Werkzeugs recommend_gifts — schneller als 2 Sekunden“, „Fehleranteil der MCP‑Tools < 1 %“, „Verfügbarkeit des Checkouts ≥ 99,5 %“, „Conversion vom Widget bis zur erfolgreichen Zahlung ≥ 10 %“.
In der zweiten Variante können Sie:
- schnell erkennen, dass mit der App etwas nicht stimmt – noch bevor Beschwerden auftauchen;
- die Wirkung jeder Änderung messen (neuer Empfehlungsalgorithmus, SDK‑Migration, neuer Tarif des Providers);
- und zu dem Zeitpunkt, wenn Sie beim Modul über Store und Review ankommen, ehrlich sagen: „Wir haben Qualitätskriterien und wissen, wie gut wir sie erfüllen.“
Wir sprechen über sehr naheliegende Dinge: was p95 ist, warum er besser als der Durchschnitt ist, wie man error‑rate und availability berechnet, welche Metriken für den Commerce‑Teil mit Webhooks wichtig sind und wie man daraus einfache, aber nützliche SLO baut. Das alles schauen wir uns am Beispiel unserer Übungs‑App GiftGenius an — ein Commerce‑Szenario mit MCP‑Empfehlungswerkzeug, Checkout und Zahlungs‑Webhooks.
2. Basis‑Metriken für die ChatGPT‑App: Was genau messen
Latenz: p50/p95/p99 statt „Durchschnitt über alle“
Latenz ist die Zeit vom Beginn einer Operation bis zu ihrem logischen Ende. In unserem Stack gibt es mehrere solcher Operationen:
- Aufruf des MCP‑Werkzeugs recommend_gifts (Geschenkeauswahl);
- Aufruf des Werkzeugs, das einen Checkout‑Intent in der ACP erstellt;
- Verarbeitung des Webhooks über eine erfolgreiche Zahlung.
Wichtig ist zu verstehen, dass wir die Gesamtlatenz, die der Nutzer in ChatGPT sieht, nur teilweise kontrollieren. Einen Anteil hat die Plattform (Modell‑Inference, Netzwerklatenzen bei OpenAI), und einen Anteil haben wir – Tools, Backend, DB, Payment. Für SLI (Service Level Indicator — ein messbarer Qualitätsindikator des Dienstes) bei der Latenz misst man üblicherweise genau unseren Anteil: vom Eintreffen der Anfrage in App/MCP bis zur fertigen Antwort unseres Servers.
Die durchschnittliche Antwortzeit ist hier trügerisch. Wenn 90 % der Anfragen in 100 ms kommen und 10 % in 5 Sekunden, liegt der Durchschnitt bei etwa einer halben Sekunde und die Kurve ist scheinbar „grün“. Aber jeder zehnte Nutzer sieht einen 5‑Sekunden‑Freeze — das UX leidet spürbar.
Daher verwendet man Perzentile: p50 (Median), p95, p99. p95 ist die Grenze, unter die 95 % der Anfragen fallen. Wie SRE‑Guides betonen, lassen Perzentile „Ausreißer sich nicht im Durchschnitt verstecken“ und machen das Leben jener unglücklichen 5–10 % sichtbar, die ständig im Verteilungsschwanz landen.
Am einfachsten denkt man so: p50 sagt, wie es dem „durchschnittlichen“ Nutzer geht, und p95/p99 — wie sehr die Geduldigen leiden, bei denen „irgendetwas ständig bremst“.
Error‑Rate: Anteil der fehlgeschlagenen Anfragen
Error‑rate ist das Verhältnis der Zahl fehlgeschlagener Anfragen zur Gesamtzahl der Anfragen in einem Zeitraum. Hauptquelle der Daten sind üblicherweise entweder strukturierte Logs oder Metriken mit Labels status="success" | "error".
In unserem Stack gibt es mehrere natürliche error‑rate:
- auf Ebene der MCP‑Tools: Anteil der Aufrufe von recommend_gifts, die mit einem Fehler endeten (Exception, HTTP‑5xx eines externen API, Timeout);
- auf Ebene ACP/Checkout: Anteil der fehlgeschlagenen Bestellversuche (API‑Fehler, Payment‑Down);
- auf Ebene des Webhook‑Handlers: Anteil der Webhooks, deren Verarbeitung nicht erfolgreich war.
Ein kniffliger Punkt: In einer ChatGPT‑App gibt es „stille“ Fehler. Zum Beispiel liefert ein MCP‑Tool einen Fehler, das Modell entschuldigt sich und setzt den Dialog fort, ohne den technischen Fehler im Header anzuzeigen. Formal zeigt ChatGPT dem Nutzer eine menschliche Antwort, aber aus Zuverlässigkeitssicht ist Ihr Stack fehlgeschlagen. Deshalb ist es für die error‑rate wichtig, genau die ingenieurmäßigen Status zu zählen und nicht die „endgültige UX‑Antwort von GPT“.
Availability: Verfügbarkeit der Dienste
Availability ist der Prozentsatz der Anfragen, die in einem Zeitraum erfolgreich bedient wurden. Konzeptionell ist das dasselbe wie error‑rate, nur mit umgekehrtem Vorzeichen: „wie viele erfolgreich“ statt „wie viele nicht erfolgreich“. Klassisches Beispiel: availability = successful_requests / total_requests * 100 %.
Auf unseren Stack bezogen:
- Verfügbarkeit des MCP‑Servers: wie viele JSON‑RPC‑Aufrufe von ChatGPT mit einer korrekten Antwort im letzten Stunde endeten;
- Verfügbarkeit des Checkout‑API: welcher Anteil der Aufrufe auf /api/checkout mit HTTP 2xx endete;
- Verfügbarkeit des Webhook‑Endpoints: welcher Anteil eingehender Webhooks vom Payment‑Provider eine korrekte Antwort von uns erhielt (typisch HTTP 200).
Wenn der Zahlungsanbieter in seiner Doku z. B. 99,9 % Verfügbarkeit verspricht, Sie aber 97 % sehen, liegt das Problem höchstwahrscheinlich nicht bei ihm.
Commerce‑Metriken: Conversion und Funnel
GiftGenius ist ein Commerce‑Szenario. Hier ist nicht nur die Technik wichtig (schnelle Antworten, wenige Fehler), sondern auch das Business‑Ergebnis — wie oft Empfehlungen in bezahlte Bestellungen übergehen.
Hier kommt der Conversion‑Funnel ins Spiel:
- Nutzer, denen das Widget angezeigt wurde (view);
- Nutzer, die ein Geschenk ausgewählt haben (selection);
- Nutzer, die „zur Kasse“ gegangen sind (checkout started);
- Nutzer, deren Bestellstatus „bezahlt“ wurde (paid).
Aus diesem Funnel lässt sich die Conversion „vom Widget bis zur Zahlung“ bestimmen; auch das ist ein SLI — ein messbarer Qualitätsindikator des Dienstes. Zum Beispiel: „erfolgreiche Zahlungen / Nutzer, die das Widget an einem Tag gesehen haben = 7 %“. Wenn die Latenz plötzlich steigt oder der Checkout gelegentlich in einen Timeout läuft, beginnt der Funnel an unerwarteten Stellen zu schrumpfen.
Wenn Sie Instant Checkout verwenden
Alle beschriebenen Commerce‑Metriken gelten ebenso für Instant Checkout auf Basis des Agentic Commerce Protocol. In diesem Fall haben Sie statt eines eigenen /api/checkout ein standardisiertes Agentic Checkout API: ChatGPT ruft Ihre REST‑Endpoints auf POST /checkout_sessions, POST /checkout_sessions/{id}, POST /checkout_sessions/{id}/complete (optional — cancel und GET) und erhält jedes Mal von Ihnen den „wahren“ Zustand von Warenkorb und Checkout.
Für die Metriken ändert sich nichts: p95 der Latenz, error-rate und availability berechnen Sie nicht für ein beliebiges /api/checkout, sondern für diese Standard‑Endpoints. SLOs vom Typ „p95 der Checkout‑Latenz < 3 Sekunden, error-rate < 2 %“ gelten dann einfach für die checkout_sessions‑Aufrufe statt für ein Eigenbau‑API.
Eine eigene Welt: Webhook‑Metriken
Webhooks sind asynchrone Ereignisse (z. B. payment_succeeded vom Payment‑Provider), die eine Bestellung durch ihren Lebenszyklus bewegen. Wenn Webhooks schlecht verarbeitet werden, kann die App zwar schön Geschenke empfehlen, aber Bestellungen hängen mit dem Status „Warten auf Zahlung“ oder in einem undefinierten Zustand fest.
Wenn Sie nicht direkt Stripe/den Payment‑Provider integrieren, sondern Instant Checkout nutzen, übernehmen Order‑Events aus dem Agentic Checkout die Rolle der „Payment‑Webhooks“: Ihr Backend sendet Ereignisse wie order.created und order.updated an eine dedizierte Webhook‑URL von OpenAI. Das ist genau dieselbe Klasse von Entitäten: asynchrone Ereignisse, von denen der endgültige Bestellstatus abhängt — nur ist der Adressat nicht Ihr Frontend, sondern ChatGPT.
Entsprechend werden Sie dieselben Metriken — Success Rate, Latenz, error-rate — nicht für Stripe‑Webhooks, sondern für Ihre Order‑Event‑Webhooks in Richtung OpenAI berechnen. In SLO kann man direkt schreiben: „mindestens 99 % der order.*‑Ereignisse werden innerhalb von 7 Tagen zugestellt und erfolgreich verarbeitet, p95 der Verarbeitungsverzögerung < 500 ms“ — und das ist ein korrektes SLI/SLO speziell für Instant Checkout.
Für Webhooks betrachtet man in der Regel:
- Webhook Success Rate — der Anteil der Webhooks, bei denen die Business‑Logik erfolgreich endete (inkl. Retries);
- Webhook Latenz — die Zeit vom Eingang des Webhooks bis zum Ende der Verarbeitung;
- Webhook Error Rate — der Anteil der Fälle, in denen die Verarbeitung des Webhooks mit einem Fehler endete (Validierung fehlgeschlagen, DB nicht verfügbar, Timeout usw.).
Man kann z. B. folgende SLO setzen: „mindestens 99 % der Webhooks werden innerhalb von 7 Tagen erfolgreich verarbeitet“ und „p95 der Webhook‑Verarbeitungszeit < 500 ms“.
3. Wie man Metriken in GiftGenius technisch misst
Von der Theorie zum Code. Wir müssen verstehen, wo wir Messpunkte einbauen, um Daten später zu p95, error‑rate und anderen Metriken zu aggregieren.
Um keinen konkreten Prometheus oder Datadog in die Vorlesung zu ziehen, nehmen wir an, wir haben eine einfache Funktion logMetric oder das Logging von JSON‑Ereignissen. Darauf kann jede Observability‑Lösung die nötigen Grafiken aufbauen.
Latenz des MCP‑Werkzeugs messen
Angenommen, wir haben einen MCP‑Server GiftGenius in TypeScript und das Werkzeug recommend_gifts. Wir umschließen die Business‑Logik mit einem Timer:
// mcp/tools/recommendGifts.ts
import { logMetric } from "../observability/metrics"; // Hilfsfunktion
export async function recommendGiftsTool(input: RecommendInput) {
const startedAt = performance.now(); // Startzeit
try {
const result = await recommendGifts(input); // Geschäftslogik
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "success",
});
return result;
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "error",
error_type: "exception",
});
throw error;
}
}
Hier kann logMetric einfach einen JSON‑Log auf stdout schreiben:
// observability/metrics.ts
export function logMetric(
name: string,
value: number,
labels: Record<string, string | number>
) {
// In der Praxis steht hier ein Prometheus/DataDog‑Client
console.log(
JSON.stringify({
type: "metric",
name,
value,
labels,
timestamp: new Date().toISOString(),
})
);
}
Mit diesem Ansatz erhalten Sie einen Ereignisstrom tool_latency_ms, in dem Sie über die Labels tool und status das p95 nur für erfolgreiche Aufrufe berechnen oder umgekehrt sehen können, wie lange Anfragen dauern, die mit einem Fehler enden.
Error‑Rate berechnen
Ähnlich kann man eine separate Fehlermetrik loggen:
// innerhalb desselben Tool‑Handlers
logMetric("tool_error_total", 1, {
tool: "recommend_gifts",
error_type: "external_api_timeout",
});
Und für erfolgreiche Anfragen:
logMetric("tool_success_total", 1, {
tool: "recommend_gifts",
});
Anschließend bildet man in der Metrik‑Plattform error_rate = tool_error_total / (tool_error_total + tool_success_total) für den Zeitraum. Das wird bereits auf der Seite des Metriksystems aggregiert; in der App ist nur wichtig, die Ereignisse sauber auszugeben.
Wenn man es ganz minimalistisch will, kann man sogar mit Logs ohne eine separate error_total auskommen. Dann wird die error‑rate über das Feld status berechnet.
Metriken für Checkout/ACP
Für den Checkout‑Endpoint in Next.js ist die Logik dieselbe: wir umschließen den Handler mit einem Timer und zählen die Status.
// app/api/checkout/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const body = await req.json();
const result = await createCheckoutSession(body); // Aufruf ACP/Stripe
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "success" });
logMetric("checkout_total", 1, { status: "success" });
return NextResponse.json(result, { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "error" });
logMetric("checkout_total", 1, { status: "error" });
return NextResponse.json(
{ error: "Checkout failed" },
{ status: 500 }
);
}
}
Jetzt kann man das p95 von checkout_latency_ms und die error‑rate über checkout_total betrachten. Auf Basis dieser SLI lassen sich leicht SLO wie „p95 < 3 Sekunden, error‑rate < 2 %“ definieren.
Webhook‑Metriken
Und natürlich Webhooks. Wir haben bereits besprochen, welche Metriken wichtig sind (siehe Abschnitt 2); jetzt schauen wir, wie man sie im Code erfasst. Dort ist nicht nur die Zeit wichtig, sondern auch der Erfolg der Verarbeitung: sonst hat der Nutzer bezahlt, aber die Bestellung wechselt nicht auf „paid“.
// app/api/webhooks/payment/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const payload = await req.text(); // Rohdaten
const sig = req.headers.get("stripe-signature") || "";
const event = verifyStripeSignature(payload, sig); // Validierung
await handlePaymentEvent(event); // Bestellung aktualisieren
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: event.type,
status: "success",
});
logMetric("webhook_total", 1, {
type: event.type,
status: "success",
});
return new NextResponse("ok", { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: "unknown",
status: "error",
});
logMetric("webhook_total", 1, {
type: "unknown",
status: "error",
});
return new NextResponse("error", { status: 500 });
}
}
Auf Basis dieser Ereignisse kann man folgende SLI definieren:
- Webhook Success Rate = success / (success + error);
- p95 von webhook_latency_ms für payment_succeeded.
Und anschließend SLO dafür festschreiben, z. B. „99 % der Webhooks werden innerhalb von 7 Tagen erfolgreich verarbeitet, p95 < 500 ms“.
4. Perzentil‑Statistik: ein wenig tiefer
Wir haben mehrere Male p50/p95/p99 verwendet; schauen wir jetzt etwas formaler, was genau gemeint ist. In der Praxis berechnet das die Metrik‑Plattform, aber es ist nützlich zu verstehen, was dort passiert.
Das Perzentil pX ist der Wert, unter dem X Prozent der Messungen liegen. Sortiert man das Array der Latenzen aufsteigend, liegt p95 irgendwo „im Schwanz“, näher an den Maximalwerten. Im Code (z. B. auf Node, falls Sie lokal mal ein p95 für eine Wertemenge berechnen wollen) kann das etwa so aussehen:
// Einfache Funktion zur Perzentilberechnung
export function percentile(values: number[], p: number): number {
if (values.length === 0) return 0;
const sorted = [...values].sort((a, b) => a - b);
const index = Math.ceil((p / 100) * sorted.length) - 1;
return sorted[Math.max(0, Math.min(index, sorted.length - 1))];
}
Eine solche Funktion kann man in Tests oder in einem kleinen Skript verwenden, das mit Daten spielt und zeigt, wie stark sich p95 vom Durchschnitt unterscheidet. In Produktion übernehmen das Prometheus, Datadog, New Relic und andere „erwachsene“ Tools.
5. SLI, SLO und SLA: in einfachen Worten
Drei Buchstaben, die einschüchternd wirken, aber in Wahrheit sehr einfach sind.
SLI — Service Level Indicator
SLI ist ein konkreter messbarer Indikator, eine Formel. Zum Beispiel:
- p95(Latenz) des Werkzeugs recommend_gifts für die letzten 24 Stunden;
- error‑rate der MCP‑Tools für die letzten 7 Tage;
- Conversion Widget → erfolgreiche Zahlung pro Woche.
SLI ist weder ein Ziel noch ein Versprechen, es ist einfach „das Thermometer“.
SLO — Service Level Objective
SLO ist das Ziel für einen SLI, im Grunde die „Gesundheitsbedingung“ des Dienstes. Zum Beispiel:
- „p95(Latenz recommend_gifts) < 2 Sekunden über ein 7‑Tage‑Fenster“;
- „error‑rate aller MCP‑Tools < 1 % über ein 30‑Tage‑Fenster“;
- „Verfügbarkeit des Checkout‑API ≥ 99,5 % pro Quartal“;
- „Conversion vom Widget bis zur erfolgreichen Zahlung ≥ 15 % pro Monat“.
Gute Praxis: erst den aktuellen Stand messen und das SLO etwas strenger setzen als das, was Sie bereits halten können; sonst wird es entweder zur „Mission Impossible“ oder zu „passt doch so“.
SLA — Service Level Agreement
SLA ist kein internes Ziel, sondern eine externe Vereinbarung mit Nutzern oder Partnern. Im SLA stehen Verpflichtungen (z. B. „99,9 % Uptime“) und Folgen von Verstößen (Kompensation, Strafzahlungen, Verlängerung des Abos usw.). SLO ist oft strenger als SLA, damit es Spielraum für das „Error Budget“ gibt.
Im Rahmen des Übungsprojekts GiftGenius brauchen Sie vermutlich kein SLA, aber die Treppe ist wichtig:
SLI → SLO → SLA
Metrik → Ziel → externes Versprechen
Error Budget (Fehlerbudget)
Das Error budget ist vereinfacht das zulässige Maß an „Nicht‑Perfektion“. Wenn Ihr SLO „Verfügbarkeit 99,9 % über 30 Tage“ lautet, dann sind 0,1 % das Fehlerbudget, das man „verbrauchen“ kann für:
- geplante Releases mit Downtime;
- Experimente;
- unvorhergesehene Incidents.
Wenn das Budget „verbrannt“ ist (z. B. lag die Verfügbarkeit im Monat bei 99,5 %), ist es Zeit, neue Features zu bremsen und Stabilität zu verbessern.
6. Besondere Metriken für GiftGenius: Commerce + Webhooks
Fassen wir alles zusammen und betrachten GiftGenius als Produkt.
Funnel und Conversion
Stellen wir uns einen einfachen Nutzerpfad vor:
flowchart TD A[App mit GiftGenius‑Widget geöffnet] --> B[Empfehlungen erhalten] B --> C[Geschenk ausgewählt] C --> D[„Zur Kasse“ geklickt] D --> E[Erfolgreiche Zahlung]
Für jeden Schritt können wir ein Ereignis loggen:
logMetric("funnel_step_total", 1, {
step: "widget_view",
});
logMetric("funnel_step_total", 1, {
step: "gift_selected",
});
logMetric("funnel_step_total", 1, {
step: "checkout_started",
});
logMetric("funnel_step_total", 1, {
step: "checkout_paid",
});
Danach können wir, ausgehend von der Anzahl der Ereignisse bei widget_view und checkout_paid, die Conversion berechnen: paid / view * 100 %. Und ein SLO setzen: „Conversion ≥ 10 %“. Wenn die Conversion plötzlich auf 3 % fällt, die technischen SLI (latency/error‑rate) aber gut aussehen, liegt es möglicherweise am UX, an der Modell‑Instruktion oder an der Qualität des Produktfeeds – nicht an der Infrastruktur.
Webhook‑Metriken als Teil der Conversion
Wir haben über technische Webhook‑Metriken und ihre Implementierung gesprochen. Jetzt ist wichtig, sie mit der Conversion zu verknüpfen: Für Commerce‑Szenarien sind Webhooks kritisch. Der Nutzer sieht „Zahlung erfolgreich“, aber der finale Bestellstatus hängt davon ab, wie schnell Ihr Backend payment_succeeded annimmt und verarbeitet.
SLI für Webhooks:
- Webhook Success Rate;
- Webhook‑Latenz p95;
- grobe Verfügbarkeit webhook_endpoint_availability.
Wenn die Success Rate bei den Webhooks fällt, verlieren Sie buchstäblich Bestellungen.
7. Einfache Alerts auf Basis der SLO
Ein vollwertiges Alerting‑System ist eher Thema der Ops‑Module, aber wir können schon jetzt die Basis skizzieren.
Die Idee ist, nicht für jeden einzelnen Fehler zu alarmieren, sondern bei einem SLO‑Verstoß. Das nennt man oft symptom‑based alerts — Alerts, die an Symptome einer Degradation gekoppelt sind: Sie interessieren sich nicht für „ein Fehler ist passiert“, sondern für „der Dienst arbeitet systematisch schlechter als zugesagt“.
Typische Beispiele:
- error‑rate der MCP‑Tools in den letzten 5 Minuten > 2 % bei SLO < 1 %;
- p95(Latenz recommend_gifts) in den letzten 10 Minuten > 3 Sekunden bei SLO 2 Sekunden;
- in den letzten 15 Minuten kein einziger erfolgreicher checkout_paid — Verdacht auf Integrationsausfall;
- Webhook Success Rate in den letzten 10 Minuten < 95 %.
Der Alert‑Text sollte menschlich lesbar sein, nicht „Alert: metric 123 > 456“. Beispiel einer „Slack‑Benachrichtigung“ für GiftGenius:
[ALERT][GiftGenius] High error rate on MCP tools:
error_rate = 3.2% (>1% SLO) for last 5 minutes.
Impact: part of users cannot receive gift recommendations.
Actions: check MCP logs and external gift API health.
Solche Nachrichten sind mit SLO verknüpft und helfen dem On‑Call‑Entwickler, das Ausmaß schnell zu verstehen.
8. Mini‑Praxis: SLO für GiftGenius formulieren
Versuchen wir, einen Satz von SLO für unsere App zu formulieren. Das geht sogar auf Papier, ohne ein ausgerolltes Metriksystem.
Beispiel „Start“:
- Für das zentrale MCP‑Werkzeug recommend_gifts:
- SLI: p95(Latenz) erfolgreicher Aufrufe über die letzten 7 Tage.
- SLO: p95(Latenz) < 2 Sekunden.
- Für Fehler der MCP‑Werkzeuge:
- SLI: error‑rate = errors / (errors + successes) über 30 Tage.
- SLO: error‑rate < 1 %.
- Für das Checkout‑API:
- SLI: availability = Anteil HTTP‑2xx an allen Anfragen.
- SLO: availability ≥ 99,5 % pro Monat.
- Für Zahlungs‑Webhooks:
- SLI: Webhook Success Rate.
- SLO: mindestens 99 % erfolgreiche Webhook‑Verarbeitung über 7 Tage; p95 der Verarbeitungszeit < 500 ms.
- Für das Business‑Ergebnis:
- SLI: Conversion Widget → bezahlte Bestellung pro Monat.
- SLO: Conversion ≥ 10–15 % (abhängig von der Nische).
Schon ein solch kleiner Satz liefert ein „Gerüst“ für Entscheidungen: Wenn Sie eine neue Modellversion ausrollen, den Prompt oder den Empfehlungsalgorithmus ändern und sehen, dass p95 und error‑rate innerhalb der SLO bleiben, die Conversion aber steigt — dann war das Experiment wahrscheinlich erfolgreich.
Wenn Sie statt eines eigenen Checkout‑Endpoints Instant Checkout verwenden, sind „Checkout‑API“ faktisch die Aufrufe von Agentic Checkout (/checkout_sessions create/update/complete), und „Zahlungs‑Webhooks“ sind Ihre Order‑Events (order.created, order.updated) in Richtung OpenAI. Metriken und SLO‑Formulierungen bleiben gleich, nur das konkrete Protokoll ändert sich.
9. Typische Fehler beim Arbeiten mit Metriken und SLO
Fehler Nr. 1: nur die durchschnittliche Antwortzeit messen.
Der Durchschnitt ist bequem, aber gefährlich. Er verschleiert leicht den Schwanz aus langsamen Anfragen. In einer ChatGPT‑App ist das kritisch: Selbst wenn die meisten Nutzer schnell bedient werden, fühlen sich regelmäßige 5–10‑Sekunden‑Lags für einen kleinen Prozentsatz wie „die App ist ständig langsam“ an. Verwenden Sie daher für Latenz immer mindestens p50 und p95, nicht nur den Mittelwert.
Fehler Nr. 2: SLI, SLO und SLA im Kopf und in der Dokumentation verwechseln.
Manchmal schreiben Entwickler „unser SLA — p95 < 2 Sekunden“, obwohl das nirgends für externe Nutzer fixiert ist und von keinen Verpflichtungen begleitet wird. In Wirklichkeit ist das ein SLO. Ein SLA ist eine Vereinbarung mit Kunden, in der Folgen von Verstößen geregelt sind. Wenn man alles mischt, ist unklar, was Sie wem wirklich zusagen.
Fehler Nr. 3: keine Verbindung zwischen Alerts und SLO.
Die klassische Falle: Alerts „für jeden Fehler“, für jeden Timeout, für jede Abweichung einer Metrik um 0,01. Am Ende lebt der On‑Call‑Ingenieur in einer Benachrichtigungshölle und ignoriert sie. Viel sinnvoller ist es, bei Verstößen gegen SLO zu alarmieren: wenn die error‑rate deutlich über das Ziel steigt oder p95 „aus dem Band fällt“, dann lohnt es sich, Leute zu wecken.
Fehler Nr. 4: Webhook‑Metriken und asynchrone Teile ignorieren.
Ein eigener, aber bereits bekannter Punkt — das Ignorieren von Webhook‑Metriken und asynchronen Teilen. Viele Teams beobachten nur die HTTP‑Antworten der Haupt‑APIs, aber nicht die Webhooks und Hintergrundverarbeitung. In Commerce‑Szenarien verstecken sich die unangenehmsten Bugs oft genau dort: Zahlung erfolgt, Webhook nicht verarbeitet, Bestellung „steckt fest“. Ohne Metriken zu Success Rate und Latenz für Webhooks kann man lange denken, „es funktioniert alles“, bis die Zahlen in Buchhaltung und Datenbank auseinanderlaufen.
Fehler Nr. 5: unrealistische SLO oder völlige Abwesenheit davon.
Manchmal werden SLO formuliert wie „100 % Uptime“ oder „überhaupt keine Fehler“. In der Praxis ist das unerfüllbar und demotiviert das Team. Die andere Extreme — gar keine SLO zu formulieren und im „wird schon passen“‑Modus zu leben. Der goldene Mittelweg: mit der Messung aktueller SLI starten, ein etwas strengeres, aber erreichbares Ziel setzen und es schrittweise verschärfen, wenn das System reift.
Fehler Nr. 6: Metriken nur für den Haken, ohne Produktbezug.
Kommt auch vor: In der Metrik‑Plattform gibt es viele Grafiken, p95, p99, Dutzende Dashboards, aber niemand kann die einfache Frage beantworten: „Wenn diese Linie hochspringt — was leidet? Der Nutzer? Geld? Reputation?“ Gerade bei LLM‑Produkten ist es wichtig, technische Kennzahlen (latency, error‑rate) mit Business‑Metriken (Conversion, erfolgreiche Zahlungen) zu verknüpfen. Sonst wird Observability zum schönen, aber nutzlosen Fernseher.
GO TO FULL VERSION