Build an AI API Outage Evidence Ledger Before You Promise Customer SLA Credits

Když dojde k incidentu u poskytovatele upstream modelu, vaši zákazníci se nejen zeptají, zda byl poskytovatel mimo provoz. Ptají se, zda jejich požadavky selhaly, které klíče a modely byly ovlivněny, zda se výpadek započítává do vaší smlouvy SLA a jaký kredit by měli získat. Stránka stavu poskytovatele pomáhá, ale sama o sobě nedokáže odpovědět na otázky týkající se konkrétních tenantů.

Brána AI API by měla zacházet s důkazy o výpadku jako s prvotřídní účetní knihou: signály poskytovatele, výsledky syntetických testů, symptomy na úrovni požadavků, okna dopadu na nájemce, rozhodnutí o přiřazení a úpravy kreditu. Cílem není vytvořit hezčí časovou osu incidentu. Cílem je zajistit, aby rozhodnutí o výpadku tváří v tvář zákazníkům byla vysvětlitelná, opakovatelná a odolná vůči nadměrnému i nedostatečnému připisování.

Co mohou a nemohou prokázat stránky stavu poskytovatele

Fact: Atlassian Statuspage zpřístupňuje veřejné API koncové body pro shrnutí, stav, komponenty, nevyřešené incidenty, incidenty a plánovanou údržbu. OpenAI a Anthropic publikují koncové body ve stylu Statuspage JSON, které zahrnují data komponent a incidentů. Google Cloud dokumentuje rozhraní Service Health API a řídicí panely a také zpřístupňuje informace o veřejném zdraví prostřednictvím zdrojů. Poskytovatelé cloudu také u některých událostí zveřejňují recenze po incidentu.

Tyto zdroje jsou užitečné vstupy. Mohou vám sdělit, že poskytovatel potvrdil incident, která široká složka byla ovlivněna, a kdy se incident pohyboval ve stavech, jako je vyšetřování, identifikace, monitorování, vyřešení nebo posmrtná smrt. Nestačí k tomu, aby rozhodovali o zákaznických kreditech pro program AI API prodejců.

Stránky stavu často zaostávají za skutečným dopadem na zákazníky. Mohou popisovat širokou komponentu, jako je chat, odpovědi, vložení, obrázky nebo soubory, aniž by se čistě mapovaly na aliasy vašeho modelu, účty poskytovatelů, oblasti, nasazení, úrovně služeb nebo seznamy povolených tenantů. Nedokážou vám také říci, zda požadavky konkrétního zákazníka selhaly z důvodu zhoršení kvality, omezení brány, vyčerpaného rozpočtu, neplatného vstupu, časového limitu na straně klienta nebo problému s místní sítí.

Doporučení: použijte status poskytovatele jako jeden tok důkazů, nikoli jako spouštěč kreditu. Kredity by měly záviset na důkazech o dopadu nájemce a povolení pro odsouhlasení poté, co budou k dispozici protokoly požadavků, vypořádání využití a aktualizace incidentů poskytovatele.

Záznam hlavní knihy, který potřebujete

Začněte trvalým záznamem o výpadku, který může představovat jak incidenty na úrovni poskytovatele, tak dopad specifický pro nájemce. Záznam by měl obsahovat pouze přílohu nebo verzi, aby pozdější změny klasifikace nesmazaly původní detekční stopu.

{
  "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"
}

Doba incidentu poskytovatele a doba dopadu tenanta jsou samostatná pole. Poskytovatel může nahlásit rozsáhlý incident od 11:30 do 13:00, ale jeden nájemce mohl být nedotčen, protože jeho povolené modely využívaly jiného poskytovatele. Jiný nájemce mohl zaznamenat selhání pouze od 11:47 do 12:18, protože ho směrování přesunulo do záložního modelu. Třetí může mít vysokou latenci, ale žádné neúspěšné požadavky. Na těchto rozdílech záleží, když se z kreditů stanou peníze.

Ingest Three Evidence Streams

1. Provider Status APIs

Shromažďujte údaje o stavu poskytovatele podle plánu a na vyžádání během incidentů. Uložte nezpracovaný hash užitečného zatížení, čas načtení, identifikátory komponent poskytovatele, stav incidentu, adresu URL incidentu nebo odkaz na poskytovatele a jakékoli textové shrnutí. Nepřepisujte staré stavy. Pokud se incident přesune od vyšetřování k identifikaci ke sledování, zachovejte každý přechod.

Normalizujte komponenty poskytovatele do vlastních dimenzí brány:

• poskytovatel: OpenAI, Anthropic, Azure OpenAI, Google nebo jiný upstream
• plocha: chat, odpovědi, vkládání, obrázky, dávka, zvuk, v reálném čase, soubory, moderování
• model nebo nasazení: upstream model, interní alias nebo název cloudového nasazení
• region: kde je to možné
• účet nebo fond pověření: sdílený účet, účet vázaný na klienta nebo pověření BYOK
• úroveň služeb: standardní, prioritní, zajišťovaná, dávková nebo interní název vrstvy

Trade-off: Zpracování stavu poskytovatele je levné a směrodatné pro potvrzení, ale může být pozdní, široké nebo neúplné. Měl by vzbudit podezření a pomoci s komunikací se zákazníky, ale neměl by automaticky generovat kredity.

2. Syntetické Kanárské ostrovy

Syntetické kanárky jsou malé, kontrolované požadavky zasílané stejnou cestou brány jako produkční provoz. Měly by pokrývat kombinace, které prodáváte, ne všechny možné funkce poskytovatele. Prodejce může například provozovat kanárky pro každého poskytovatele, povrch, modelovou úroveň a region, které používají placené plány.

Každý výsledek canary by měl obsahovat:

• canary_id a naplánovat verzi
• poskytovatel, povrch, model, region, fond pověření a profil trasy
• čas zahájení, čas prvního bajtu, čas dokončení a práh časového limitu
• HTTP stav, kód chyby poskytovatele, kód chyby brány a počet opakování
• percentilový segment latence, nejen úspěšné nebo neúspěšné
• ID korelace požadavku a upravená metadata odpovědi

Kanárci by se měli vyhýbat hrubým výzvám zákazníků. Používejte pevné, necitlivé výzvy a udržujte ověřování odpovědí jednoduché. Kanárek může ověřit, že koncový bod přijímá požadavky, streamy jsou dokončeny a latence zůstává v mezích. Nemusí posuzovat kvalitu modelu pro rozhodnutí o výpadku úvěru.

Trade-off: kanárci poskytují nezávislé důkazy dříve, než zákazníci nahlásí problém. Také zvyšují náklady a mohou spotřebovat kvóty během stresu poskytovatele. Během aktivních incidentů přiškrtněte plyn a vyhněte se agresivnímu chování opakování, které přispívá k načítání proti proudu.

3. Příznaky skutečného požadavku

Důkazy na úrovni požadavků jsou nejsilnějším zdrojem dopadu na nájemce. Každý požadavek na bránu by již měl mít tenanta, klíč, identifikátor uživatele nebo koncového uživatele, alias modelu, trasu poskytovatele, oblast, stav, latenci, použití tokenu a stav fakturace. Chcete-li hlásit výpadek, přidejte pole klasifikace, která oddělují příznaky na začátku od příčin zákazníka a brány.

Mezi užitečné třídy symptomů patří:

• provider_5xx: upstream HTTP 5XX nebo ekvivalentní chyba serveru poskytovatele
• provider_timeout: žádná odpověď poskytovatele před vypršením časového limitu brány
• provider_429_spike: horní limit rychlosti nad normální výchozí hodnotou
• stream_abort_upstream: stream poskytovatele skončil neočekávaně
• latency_degraded: dokončený požadavek překročil hranici zásad
• gateway_throttle: brána požadavek zamítla z důvodu omezení nájemců nebo zásad férovosti
• customer_error: neplatný požadavek, nepodporovaný model, špatné ověření nebo chybná datová část
• budget_exhausted: odeslání nájemce nebo kreditního limitu blokováno odeslání

Za příznaky výpadku by se normálně mělo počítat pouze prvních pět, a i to pouze po přiřazení. Nárůst v upstream 429 může být problém poskytovatele, ale může být také způsoben tím, že jeden tenant překročí svou rezervovanou propustnost. Časový limit může být zhoršením poskytovatele, ale může být také způsoben odpojením klienta nebo časovým limitem na úrovni aplikace, který je kratší než časový limit vaší brány.

To je místo, kde multimodelová API brána pro týmy potřebuje disciplinované modelování událostí. Rozhodnutí o trase, pokus o opakování, záložní výsledek, konečná odpověď a vyúčtování fakturace by mělo být možné spojit pomocí ID korelace.

Oddělte Windows incidentu poskytovatele od Windows s dopadem na nájemce

Nepřipisujte zákazníkům kredit za široké trvání incidentu poskytovatele. Připište jim zásluhy za tu část incidentu, která ovlivnila jejich způsobilý provoz podle vašich zásad.

Použijte alespoň pět značek oken:

• čas detekce: když váš systém poprvé zjistil abnormální chování
• první dotčená žádost: první oprávněná žádost nájemce s příznakem výpadku
• čas potvrzení poskytovatele: když předřazený poskytovatel incident zveřejnil nebo potvrdil
• doba zmírnění: když vaše brána použila záložní, tvarování provozu, deaktivaci trasy nebo jiné zmírnění
• potvrzení obnovení: když se kanárci a skutečný provoz vrátí pod prahové hodnoty

Okno dopadu tenanta lze vypočítat na tenanta, na klíč, na alias modelu a na úroveň služeb. Například:

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

Toto oddělení vás také chrání před nadměrným kreditováním. Pokud nájemce neměl během incidentu poskytovatele žádný provoz, nemusí mít žádný kredit. Pokud je nájemce nasměrován pouze na nedotčené modely, nemusí existovat žádný kredit. Pokud všechna selhání byly neplatné požadavky nebo zamítnutí rozpočtu, mělo by to být uvedeno ve zprávě o incidentu, aniž by bylo obviňováno poskytovatele.

Definujte úvěrové zásady před incidentem

Úvěrové zásady by měly být tabulkou nebo konfigurací verzí, nikoli podpůrným úsudkem improvizovaným pod tlakem. Tato zásada nemusí být plně automatická, ale měla by jasně stanovit pravidla způsobilosti a schválení.

Zahrňte tato pole:

• způsobilé příznaky: poskytovatel 5XX, upstream timeout, přerušení streamu, závažné snížení latence nebo jiné třídy
• minimální doba trvání: například pět po sobě jdoucích minut nebo limit počtu dotčených požadavků
• práh latence: pevný práh, procentuální výchozí hodnota nebo cíl pro konkrétní úroveň služeb
• vyloučené příčiny: chyby zákazníků, vyčerpání rozpočtu, omezení nájemce, chybně vytvořené požadavky, nepodporovaný model, odpojení klienta
• opakovat ošetření: zda se úspěšné záložní požadavky počítají jako neúspěšné, snížené nebo zmírněné
• úvěrový vzorec: procento ovlivněného využití, pevná úprava peněženky, kredit SLA podle plánu nebo ruční kontrola
• schvalovací pravomoc: automatická pod limitem, schvalování operací nad limitem, finanční schvalování pro velké nájemce
• zpracování kreditu poskytovatele: předáváno, sdíleno, uchováváno nebo zpracováváno odděleně od kreditů zákazníků
• uchovávání důkazů: jak dlouho lze záznamy o incidentech, žádostech, kanárcích a úvěrech zjišťovat

Doporučení: uložit verzi úvěrových zásad při každém předběžném a konečném rozhodnutí o úvěru. Pokud zásady později upravíte, historická rozhodnutí by měla stále vysvětlovat, která pravidla byla v té době uplatňována.

Srovnání před konečnými kredity

Během incidentu zákazníci potřebují rychle aktualizovat stav. Rozhodnutí o úvěru mohou být provizorní. Ke konečnému kreditnímu pasu by mělo dojít po dokončení protokolů, vyřešení událostí zpožděného použití, klasifikaci opakovaných pokusů a záložních řešení a zkontrolování informací poskytovatele po incidentu.

Praktický pracovní postup odsouhlasení vypadá takto:

1. Vytvořte nebo aktualizujte záznam o incidentu ze stavu poskytovatele, výstrah kanárků nebo prahových hodnot příznaků požadavku.
2. Zmrazit dotčený profil trasy nebo jej označit jako degradovaný, aby se mu nová rozhodnutí o trasování mohla vyhnout, kde je to možné.
3. Generujte prozatímní okna dopadu na nájemce z protokolů požadavků a časových os.
4. Vylučte příčiny na straně zákazníka a brány pomocí pravidel klasifikace.
5. Připojte se k záznamům o používání a fakturaci, takže dotčené požadavky jsou svázány s vypořádanými záznamy o nákladech a zákaznických poplatcích.
6. Použijte verzi kreditních zásad a vytvořte prozatímní řádky kreditu.
7. Zkontrolujte nejednoznačné případy, zejména částečné snížení latence a nájemce s vysokou hodnotou.
8. Uveřejněte konečné úpravy kreditu do peněženky nebo knihy faktur s odkazy zpět na záznam incidentu.

Toto spojuje zpracování výpadků se jednotnou AI API fakturací namísto ponechání kreditů jako ručních poznámek na lístku podpory. Úprava by měla být kontrolovatelná: kdo ji schválil, jaké zásady se uplatňovaly, které žádosti byly způsobilé a zda je konečná nebo vratná.

Odhalit zákazníka a partnera API Zobrazení

Zákazníci potřebují jasné vysvětlení incidentu, ne celý váš interní trasovací obchod. Následné platformy, které přeprodávají nebo vkládají vaše API, mohou také potřebovat ukazovat stav incidentu na svých vlastních portálech. Koncový bod partnera API může vystavit zobrazení incidentu v rozsahu tenanta.

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"]
  }
}

Zachovejte rozsah tohoto zobrazení. Zahrňte syntetická ID kanárků, ID korelace požadavků, dotčené modely, dotčené klíče a konečný stav kreditu. Ve výchozím nastavení se vyhněte hrubým výzvám a úplným tělům odpovědí. Pokud zákazník potřebuje hlubší důkazy, poskytněte mu kontrolovaný export s kontrolou redakce a autorizace.

Šablona hlášení o incidentu zákazníka

Pokud je účetní kniha kompletní, může být užitečná zákaznická zpráva krátká. Měl by rozlišovat potvrzená fakta od operativní interpretace.

Fakta

• Dotčený poskytovatel a povrch
• Okno dopadu nájemce
• Počet vhodných neúspěšných, vypršel časový limit, přerušených nebo snížených požadavků
• Aliasy, oblasti a zákaznické klíče dotčeného modelu
• Bylo použito zmírnění a čas potvrzení obnovení

Hodnocení brány

• Zda byly příznaky připsány poskytovateli, bráně, konfiguraci tenanta nebo chování požadavků zákazníka
• Zda záložní směrování snížilo dopad
• Zda incident splňuje limity úvěrových zásad
• Zda je kredit provizorní, schválený, uplatněný nebo zamítnut

Limity

• Podrobnosti o incidentu poskytovatele se mohou po zveřejnění po smrti změnit
• Hranice snížení latence jsou definovány zásadami, nejsou univerzální
• Žádosti vyloučené z důvodu chyb zákazníků nebo zamítnutí rozpočtu se nezapočítávají jako dopad výpadku poskytovatele

Předpovědi a návrhové sázky

Predition: Hlášení výpadků tváří v tvář zákazníkům se stane běžnou funkcí platforem prodejců AI API, zejména pro dodavatele SaaS, kteří vystavují funkce AI pod svou vlastní značkou. Jak se pracovní zátěže umělé inteligence přesouvají od experimentování k produkci, zákazníci budou očekávat stejnou odpovědnost za incidenty, jakou dostávají od dodavatelů cloudové infrastruktury.

Prediction: Stránky stavu poskytovatele zůstanou nezbytné, ale nedostatečné. Více incidentů bude zahrnovat částečné zhoršení: špičky latence, přerušení streamování, problémy s regionální kapacitou, regrese kvality, selhání volání nástrojů nebo chování kvót specifických pro účet. Tyto případy vyžadují důkazy na úrovni požadavku a nájemce.

Doporučení: Než slibujete silné kredity SLA, vytvořte si účetní knihu. Dovybavení důkazů o incidentu po sporném výpadku je nákladné a často neprůkazné.

Aplikovatelný závěr

Nedovolte, aby se stránky stavu poskytovatele staly vaším jediným zdrojem pravdy o kreditech zákazníků. Vytvořte knihu evidence výpadků, která spojí zdroje incidentů poskytovatele, syntetické kanárky, symptomy požadavků, rozhodnutí o trase, okna dopadu na nájemce, fakturační záznamy a konečné úpravy kreditu.

Minimální užitečná verze je přímočará: stav poskytovatele příjmu JSON, provozujte nízkoobjemové kanárky pro prodané úrovně modelových regionů, klasifikujte selhání požadavků podle příčiny, vypočítejte okna dopadu na nájemce a po odsouhlasení použijte verzovanou kreditní politiku. To poskytuje podpoře, financím, inženýrství a následným partnerům stejnou základnu důkazů. Umožňuje vám také vysvětlit incidenty bez slepého zrcadlení upstreamových stavových stránek nebo vydávání manuálních dobropisů, kdykoli si zákazník stěžuje.

Související čtení

• hlášení o používání a úpravách na straně zákazníka