Erstellen Sie ein AI API-Ausfallnachweisbuch, bevor Sie Kunden SLA-Gutschriften versprechen

Wenn bei einem Upstream-Modellanbieter ein Vorfall auftritt, fragen Ihre Kunden nicht nur, ob der Anbieter ausgefallen ist. Sie fragen, ob ihre Anfragen fehlgeschlagen sind, welche Schlüssel und Modelle betroffen waren, ob der Ausfall auf Ihr SLA angerechnet wird und welche Gutschrift sie erhalten sollten. Eine Anbieterstatusseite hilft, kann diese mandantenspezifischen Fragen jedoch nicht alleine beantworten.

Ein KI-API-Gateway sollte Ausfallnachweise wie ein erstklassiges Hauptbuch behandeln: Anbietersignale, Ergebnisse synthetischer Untersuchungen, Symptome auf Anfrageebene, Fenster für Mieterauswirkungen, Zuordnungsentscheidungen und Kreditanpassungen. Das Ziel besteht nicht darin, einen schöneren Zeitplan für den Vorfall zu erstellen. Das Ziel besteht darin, kundenorientierte Ausfallentscheidungen erklärbar, wiederholbar und resistent gegen Über- und Unterkreditierung zu machen.

Was Anbieterstatusseiten beweisen können und was nicht

Fakt: Atlassian Statuspage stellt öffentliche API Endpunkte für Zusammenfassung, Status, Komponenten, ungelöste Vorfälle, Vorfälle und geplante Wartung bereit. OpenAI und Anthropic veröffentlichen Endpunkte im Statuspage-Stil JSON, die Komponenten- und Vorfalldaten enthalten. Google Cloud dokumentiert Service Health APIs und Dashboards und stellt über Feeds auch Informationen zur öffentlichen Gesundheit bereit. Cloud-Anbieter veröffentlichen für einige Ereignisse auch Post-Incident-Reviews.

Diese Feeds sind nützliche Eingaben. Sie können Ihnen mitteilen, dass ein Anbieter einen Vorfall bestätigt hat, welche umfassende Komponente betroffen war und wann der Vorfall Status wie „Untersuchung“, „Identifiziert“, „Überwachung“, „Behoben“ oder „Post-Mortem“ durchlaufen hat. Sie reichen nicht aus, um über die Kundengutschriften für ein AI API Reseller Operations-Programm zu entscheiden.

Statusseiten bleiben oft hinter der tatsächlichen Wirkung auf den Kunden zurück. Sie beschreiben möglicherweise eine umfassende Komponente wie Chat, Antworten, Einbettungen, Bilder oder Dateien, ohne dass sie eindeutig Ihren Modellaliasen, Anbieterkonten, Regionen, Bereitstellungen, Serviceebenen oder Mandantenzulassungslisten zugeordnet werden können. Sie können Ihnen auch nicht sagen, ob die Anfragen eines bestimmten Kunden aufgrund von Upstream-Verschlechterung, Gateway-Drosselung, erschöpftem Budget, ungültiger Eingabe, clientseitigem Timeout-Verhalten oder einem lokalen Netzwerkproblem fehlgeschlagen sind.

Empfehlung: Verwenden Sie den Anbieterstatus als einen Beweisstrom, nicht als Kreditauslöser. Gutschriften sollten von Nachweisen über die Auswirkungen auf den Mandanten und einem Abgleichsdurchlauf abhängen, nachdem Anforderungsprotokolle, Nutzungsabrechnungen und Aktualisierungen von Anbietervorfällen verfügbar sind.

Der Ledger-Datensatz, den Sie brauchen

Beginnen Sie mit einem dauerhaften Ausfalldatensatz, der sowohl anbieterweite Vorfälle als auch mandantenspezifische Auswirkungen darstellen kann. Der Datensatz sollte nur angehängt oder versioniert sein, damit spätere Klassifizierungsänderungen den ursprünglichen Erkennungspfad nicht löschen.

{
  "incident_id": "inc_2026_05_29_openai_azure_eastus_latency",
  "provider": "azure_openai",
  "provider_account_id": "acct_prod_shared_01",
  "surface": "chat_completions",
  "model_or_deployment": "gpt-4o-prod-eastus",
  "region": "eastus",
  "source_signals": ["provider_status", "synthetic_canary", "request_symptoms"],
  "confidence": "confirmed",
  "provider_started_at": "2026-05-29T11:42:00Z",
  "provider_acknowledged_at": "2026-05-29T12:05:00Z",
  "detected_at": "2026-05-29T11:45:11Z",
  "mitigated_at": "2026-05-29T12:31:44Z",
  "recovered_at": "2026-05-29T12:48:00Z",
  "affected_tenant_ids": ["ten_123", "ten_456"],
  "linked_request_ids": ["req_a", "req_b", "req_c"],
  "credit_policy_version": "sla_2026_04",
  "credit_status": "pending_reconciliation"
}

Die Vorfallzeit des Anbieters und die Auswirkungszeit des Mandanten sind separate Felder. Ein Anbieter kann zwischen 11:30 und 13:00 Uhr einen groß angelegten Vorfall melden, ein Mieter war jedoch möglicherweise nicht betroffen, da seine zugelassenen Modelle einen anderen Anbieter nutzten. Bei einem anderen Mieter sind die Ausfälle möglicherweise nur von 11:47 bis 12:18 Uhr aufgetreten, weil das Routing ihn auf ein Fallback-Modell umgestellt hat. Bei einem Drittel kam es möglicherweise zu einer hohen Latenz, aber zu keinen fehlgeschlagenen Anfragen. Diese Unterschiede sind wichtig, wenn Credits zu Geld werden.

Drei Beweisströme aufnehmen

1. Anbieterstatus-APIs

Erfassen Sie Anbieterstatusdaten nach einem Zeitplan und bei Bedarf bei Vorfällen. Speichern Sie den Roh-Payload-Hash, die Abrufzeit, die Provider-Komponenten-IDs, den Vorfallstatus, die Vorfall-URL oder die Provider-Referenz sowie eine beliebige Textzusammenfassung. Überschreiben Sie keine alten Zustände. Wenn ein Vorfall von der Untersuchung über die Identifizierung zur Überwachung übergeht, behalten Sie jeden Übergang bei.

Anbieterkomponenten in Ihre eigenen Gateway-Dimensionen normalisieren:

• Anbieter: OpenAI, Anthropic, Azure OpenAI, Google oder ein anderer Upstream
• Oberfläche: Chat, Antworten, Einbettungen, Bilder, Batch, Audio, Echtzeit, Dateien, Moderation
• Modell oder Bereitstellung: Upstream-Modell, interner Alias oder Cloud-Bereitstellungsname
• Region: sofern zutreffend
• Konto oder Anmeldeinformationspool: gemeinsames Konto, mandantengebundenes Konto oder BYOK-Anmeldeinformationen
• Dienstebene: Standard, Priorität, bereitgestellt, Batch oder Name der internen Ebene

Kompromiss: Die Erfassung des Anbieterstatus ist kostengünstig und maßgeblich für die Bestätigung, kann jedoch verspätet, umfassend oder unvollständig sein. Es soll Verdacht erregen und bei der Kundenkommunikation helfen, aber nicht automatisch Credits generieren.

2. Synthetische Kanarienvögel

Synthetische Canaries sind kleine, kontrollierte Anfragen, die über denselben Gateway-Pfad wie der Produktionsverkehr gesendet werden. Sie sollten die von Ihnen verkauften Kombinationen abdecken, nicht alle möglichen Anbieterfunktionen. Ein Wiederverkäufer könnte beispielsweise Canaries für jeden Anbieter, jede Oberfläche, jede Modellstufe und jede Region ausführen, die von kostenpflichtigen Plänen verwendet werden.

Jedes Canary-Ergebnis sollte Folgendes enthalten:

• canary_id und Zeitplanversion
• Anbieter, Oberfläche, Modell, Region, Anmeldeinformationspool und Routenprofil
• Startzeit, Zeit des ersten Bytes, Abschlusszeit und Timeout-Schwellenwert
• HTTP Status, Provider-Fehlercode, Gateway-Fehlercode und Anzahl der Wiederholungsversuche
• Latenzperzentil-Bucket, nicht nur bestanden oder nicht bestanden
• Korrelations-ID und redigierte Antwortmetadaten anfordern

Kanarienvögel sollten rohe Kundenaufforderungen vermeiden. Verwenden Sie feste, nicht sensible Eingabeaufforderungen und halten Sie die Antwortvalidierung einfach. Ein Canary kann überprüfen, ob der Endpunkt Anfragen akzeptiert, Streams abgeschlossen sind und die Latenz innerhalb eines Schwellenwerts bleibt. Für Entscheidungen zur Ausfallgutschrift muss die Modellqualität nicht beurteilt werden.

Kompromiss: Kanarienvögel liefern unabhängige Beweise, bevor Kunden ein Problem melden. Außerdem erhöhen sie die Kosten und können bei Anbieterstress Kontingente verbrauchen. Drosseln Sie Canaries bei aktiven Vorfällen und vermeiden Sie aggressives Wiederholungsverhalten, das zur Upstream-Last beiträgt.

3. Echte Anforderungssymptome

Beweise auf Anfrageebene sind die stärkste Quelle für die Auswirkungen auf Mandanten. Jede Gateway-Anfrage sollte bereits über Mandant, Schlüssel, Benutzer- oder Endbenutzer-ID, Modellalias, Anbieterroute, Region, Status, Latenz, Token-Nutzung und Abrechnungsstatus verfügen. Fügen Sie für Ausfallberichte Klassifizierungsfelder hinzu, die Upstream-Symptome von Kunden- und Gateway-Ursachen trennen.

Nützliche Symptomklassen sind:

• provider_5xx: Upstream HTTP 5XX oder gleichwertiger Anbieterserverfehler
• provider_timeout: Keine Provider-Antwort vor Gateway-Timeout
• provider_429_spike: Upstream-Ratenbegrenzung über normaler Basislinie
• stream_abort_upstream: Anbieter-Stream wurde unerwartet beendet
• latency_degraded: Die abgeschlossene Anfrage hat den Richtlinienschwellenwert überschritten
• gateway_throttle: Gateway hat die Anfrage aufgrund einer Mandantenbeschränkung oder einer Fairness-Richtlinie abgelehnt
• customer_error: ungültige Anfrage, nicht unterstütztes Modell, schlechte Authentifizierung oder fehlerhafte Nutzlast
• budget_exhausted: Mieterausgaben oder Kreditlimit blockiert Versand

Nur die ersten fünf sollten normalerweise als Ausfallsymptome gelten, und selbst dann nur nach Zuordnung. Ein Anstieg der Upstream-429-Verbindungen kann ein Anbieterproblem sein, kann aber auch dadurch verursacht werden, dass ein Mandant seinen reservierten Durchsatz überschreitet. Eine Zeitüberschreitung kann auf eine Verschlechterung des Providers zurückzuführen sein, kann aber auch durch eine Client-Verbindungstrennung oder eine Zeitüberschreitung auf Anwendungsebene verursacht werden, die kürzer als die Zeitüberschreitung Ihres Gateways ist.

Hier benötigt ein Multimodell-APIGateway für Teams eine disziplinierte Ereignismodellierung. Die Routenentscheidung, der Wiederholungsversuch, das Fallback-Ergebnis, die endgültige Antwort und die Abrechnung sollten über die Korrelations-ID verknüpfbar sein.

Trennung der Provider-Vorfallsfenster von den Mandantenauswirkungsfenstern

Schreiben Sie den Kunden nicht die breite Vorfalldauer des Anbieters zu. Schreiben Sie ihnen den Teil des Vorfalls zu, der sich auf ihren berechtigten Datenverkehr gemäß Ihrer Richtlinie ausgewirkt hat.

Verwenden Sie mindestens fünf Fenstermarkierungen:

• Erkennungszeitpunkt: Als Ihr System zum ersten Mal ungewöhnliches Verhalten erkannte
• erste betroffene Anfrage: erste berechtigte Mieteranfrage mit einem Ausfallsymptom
• Bestätigungszeit des Anbieters: wann der Upstream-Anbieter den Vorfall veröffentlicht oder bestätigt hat
• Abhilfezeit: Wenn Ihr Gateway Fallback, Traffic Shaping, Routendeaktivierung oder eine andere Abhilfemaßnahme angewendet hat
• Wiederherstellungsbestätigung: wenn Canaries und realer Datenverkehr wieder unter die Schwellenwerte fielen

Das Mandantenauswirkungsfenster kann pro Mandant, pro Schlüssel, pro Modellalias und pro Dienstebene berechnet werden. Zum Beispiel:

tenant_id: ten_123
model_alias: support-fast
eligible_requests: 842
failed_provider_requests: 96
degraded_latency_requests: 211
first_affected_at: 2026-05-29T11:47:08Z
last_affected_at: 2026-05-29T12:22:31Z
mitigation_applied_at: 2026-05-29T12:04:19Z
credit_status: provisional

Diese Trennung schützt Sie auch vor einer Überkreditierung. Wenn ein Mieter während des Anbietervorfalls keinen Verkehr hatte, besteht möglicherweise keine Gutschrift. Wenn ein Mieter nur an nicht betroffene Modelle weitergeleitet wird, kann es sein, dass es keine Gutschrift gibt. Wenn es sich bei allen Fehlern um ungültige Anfragen oder Budgetverweigerungen handelte, sollte dies im Vorfallbericht angegeben werden, ohne dem Anbieter die Schuld zu geben.

Kreditrichtlinien vor dem Vorfall definieren

Kreditrichtlinien sollten eine tabellarische oder versionierte Konfiguration sein und kein unter Druck improvisiertes Support-Urteil. Die Richtlinie muss nicht vollständig automatisch sein, sie sollte jedoch Berechtigungs- und Genehmigungsregeln explizit machen.

Fügen Sie diese Felder ein:

• Zulässige Symptome: Anbieter 5XX, Upstream-Timeout, Stream-Abbruch, schwere Latenzverschlechterung oder andere Klassen
• Mindestdauer: zum Beispiel fünf aufeinanderfolgende Minuten oder eine bestimmte Anzahl betroffener Anfragen
• Latenzschwellenwert: fester Schwellenwert, Perzentil-Basislinie oder dienstebenenspezifisches Ziel
• ausgeschlossene Ursachen: Kundenfehler, Budgetausschöpfung, Mandantendrosselung, fehlerhafte Anfragen, nicht unterstütztes Modell, Client-Verbindungsabbrüche
• Wiederholungsbehandlung: Ob erfolgreiche Fallback-Anfragen als fehlgeschlagen, herabgestuft oder entschärft gelten
• Guthabenformel: Prozentsatz der betroffenen Nutzung, feste Wallet-Anpassung, planbasiertes SLA-Guthaben oder manuelle Überprüfung
• Genehmigungsbehörde: automatisch unterhalb einer Grenze, Betriebsgenehmigung darüber, Finanzierungsgenehmigung für Großmieter
• Verwaltung von Anbieterkrediten: weitergegeben, geteilt, einbehalten oder getrennt von Kundenkrediten behandelt
• Beweisaufbewahrung: Wie lange bleiben Vorfall-, Anfrage-, Canary- und Kreditdatensätze abfragbar?

Empfehlung: Speichern Sie die Version der Kreditrichtlinie bei jeder vorläufigen und endgültigen Kreditentscheidung. Wenn Sie die Richtlinie später überarbeiten, sollten historische Entscheidungen immer noch erklären, welche Regeln zu diesem Zeitpunkt angewendet wurden.

Abgleich vor dem Abspann

Während eines Vorfalls benötigen Kunden schnelle Statusaktualisierungen. Kreditentscheidungen können vorläufig sein. Die endgültige Gutschrift sollte erfolgen, nachdem die Protokolle vollständig sind, verzögerte Nutzungsereignisse behoben sind, Wiederholungsversuche und Fallbacks klassifiziert wurden und die Anbieterinformationen nach dem Vorfall überprüft wurden.

Ein praktischer Abstimmungsworkflow sieht so aus:

1. Erstellen oder aktualisieren Sie den Vorfalldatensatz anhand des Anbieterstatus, von Canary-Warnungen oder Anforderungssymptomschwellenwerten.
2. Das betroffene Routenprofil einfrieren oder als beeinträchtigt markieren, damit neue Routing-Entscheidungen es nach Möglichkeit vermeiden können.
3. Generieren Sie vorläufige Mandantenauswirkungsfenster aus Anforderungsprotokollen und Canary-Zeitplänen.
4. Kundenseitige und Gateway-seitige Ursachen mithilfe von Klassifizierungsregeln ausschließen.
5. Nutzungs- und Abrechnungsdatensätze zusammenführen, damit betroffene Anfragen mit den abgerechneten Kosten- und Kundengebührendatensätzen verknüpft werden.
6. Wenden Sie die Version der Kreditrichtlinie an und erstellen Sie vorläufige Kreditzeilen.
7. Überprüfen Sie mehrdeutige Fälle, insbesondere teilweise Verschlechterung der Latenz und hochwertige Mandanten.
8. Veröffentlichen Sie endgültige Kreditanpassungen im Wallet- oder Rechnungsbuch mit Links zurück zum Vorfalldatensatz.

Dies bindet die Ausfallabwicklung in die unified AI APIAbrechnung ein, anstatt Gutschriften als manuelle Notizen in einem Support-Ticket zu hinterlassen. Die Anpassung sollte überprüfbar sein: Wer hat sie genehmigt, welche Richtlinie galt, welche Anträge waren berechtigt und ob sie endgültig oder rückgängig gemacht werden kann.

Kunden und Partner offenlegen API Aufrufe

Kunden benötigen eine klare Erklärung des Vorfalls, nicht Ihren gesamten internen Trace-Speicher. Nachgelagerte Plattformen, die Ihr API weiterverkaufen oder einbetten, müssen möglicherweise auch den Vorfallstatus in ihren eigenen Portalen anzeigen. Ein Partner-Endpunkt API kann eine mandantenbezogene Vorfallansicht verfügbar machen.

GET /partner/incidents/{incident_id}/tenant-impact?tenant_id=ten_123

{
  "incident_id": "inc_2026_05_29_openai_azure_eastus_latency",
  "status": "final",
  "summary": "Elevated upstream latency and intermittent failures affected selected chat requests.",
  "affected_windows": [
    {
      "model_alias": "support-fast",
      "first_affected_at": "2026-05-29T11:47:08Z",
      "last_affected_at": "2026-05-29T12:22:31Z",
      "eligible_failed_requests": 96,
      "eligible_degraded_requests": 211
    }
  ],
  "affected_keys": ["key_live_abc"],
  "credit_status": "applied",
  "credit_adjustment_id": "adj_789",
  "evidence": {
    "canary_ids": ["canary_chat_eastus_01"],
    "sample_request_ids": ["req_a", "req_b"]
  }
}

Behalten Sie den Gültigkeitsbereich dieser Ansicht bei. Geben Sie synthetische Canary-IDs, Anforderungskorrelations-IDs, betroffene Modelle, betroffene Schlüssel und den endgültigen Kreditstatus an. Vermeiden Sie standardmäßig rohe Eingabeaufforderungen und vollständige Antworttexte. Wenn ein Kunde tiefergehende Beweise benötigt, stellen Sie einen kontrollierten Export mit Schwärzungs- und Autorisierungsprüfungen bereit.

Vorlage für Kundenvorfallsberichte

Ein nützlicher Kundenbericht kann kurz sein, wenn das Hauptbuch vollständig ist. Es sollte bestätigte Fakten von operativen Interpretationen unterscheiden.

Fakten

• Anbieter und Oberfläche betroffen
• Mandantenauswirkungsfenster
• Anzahl der berechtigten fehlgeschlagenen, abgelaufenen, abgebrochenen oder beeinträchtigten Anfragen
• Betroffene Modellaliase, Regionen und Kundenschlüssel
• Angewandte Schadensbegrenzung und Bestätigungszeit für die Wiederherstellung

Gateway-Bewertung

• Ob die Symptome auf den Anbieter, das Gateway, die Mandantenkonfiguration oder das Kundenanfrageverhalten zurückzuführen sind
• Ob Fallback-Routing die Auswirkungen reduziert
• Ob der Vorfall den Schwellenwert der Kreditrichtlinie erreicht
• Ob der Kredit vorläufig, genehmigt, beantragt oder abgelehnt ist

Limits

• Details zu Anbietervorfällen können sich nach der Post-Mortem-Veröffentlichung ändern
• Schwellenwerte für die Latenzverschlechterung sind richtliniendefiniert und nicht universell
• Anfragen, die aufgrund von Kundenfehlern oder Budgetablehnungen ausgeschlossen wurden, werden nicht als Auswirkung von Anbieterausfällen gezählt

Vorhersagen und Design-Wetten

Vorhersage: Die kundenorientierte Ausfallberichterstattung wird zu einem normalen Merkmal von KI-API Reseller-Plattformen werden, insbesondere für SaaS-Anbieter, die KI-Funktionen unter ihrer eigenen Marke anbieten. Da KI-Arbeitslasten vom Experimentieren zur Produktion übergehen, erwarten Kunden die gleiche Verantwortung für Vorfälle, die sie von Cloud-Infrastrukturanbietern erhalten.

Vorhersage: Anbieterstatusseiten werden weiterhin notwendig, aber unzureichend sein. Bei weiteren Vorfällen kommt es zu einer teilweisen Verschlechterung: Latenzspitzen, Streaming-Unterbrechungen, regionale Kapazitätsprobleme, Qualitätsrückgänge, Fehler bei Tool-Aufrufen oder kontospezifisches Kontingentverhalten. In diesen Fällen sind Nachweise auf Anfrage- und Mandantenebene erforderlich.

Empfehlung: Erstellen Sie das Hauptbuch, bevor Sie starke SLA-Gutschriften versprechen. Das Nachrüsten von Vorfallbeweisen nach einem umstrittenen Ausfall ist teuer und oft nicht schlüssig.

Umsetzbare Schlussfolgerung

Lassen Sie nicht zu, dass die Anbieterstatusseiten Ihre einzige Informationsquelle für Kundengutschriften werden. Erstellen Sie ein Ausfallnachweis-Ledger, das Anbieter-Vorfall-Feeds, synthetische Canaries, Anforderungssymptome, Routenentscheidungen, Mieter-Auswirkungsfenster, Abrechnungsdatensätze und endgültige Kreditanpassungen zusammenführt.

Die minimal nützliche Version ist einfach: Anbieterstatus JSON erfassen, Canaries mit geringem Volumen für verkaufte Modellregionen ausführen, Anforderungsfehler nach Ursache klassifizieren, Mandantenauswirkungsfenster berechnen und nach dem Abgleich eine versionierte Kreditrichtlinie anwenden. Dadurch verfügen Support-, Finanz-, Technik- und nachgelagerte Partner über die gleiche Faktenbasis. Außerdem können Sie damit Vorfälle erklären, ohne blind Upstream-Statusseiten zu spiegeln oder manuelle Kulanzgutschriften auszustellen, wann immer sich ein Kunde beschwert.

Verwandte Lektüre

• Kundenorientierte Nutzungs- und Anpassungsberichte