Zgradite knjigo dokazov o izpadih z umetno inteligenco API, preden strankam obljubite kredite SLA

Ko pride do incidenta pri ponudniku višjega modela, vaše stranke ne sprašujejo le, ali je ponudnik nedeloval. Sprašujejo, ali njihove zahteve niso bile uspešne, kateri ključi in modeli so bili prizadeti, ali se izpad šteje v vaš SLA in kakšen dobropis naj prejmejo. Stran s statusom ponudnika pomaga, vendar sama ne more odgovoriti na vprašanja, specifična za najemnika.

AI API bi moral dokaze o izpadih obravnavati kot prvovrstno knjigo: signali ponudnika, rezultati sintetičnih sond, simptomi na ravni zahteve, okna vpliva najemnika, odločitve o dodelitvi in kreditne prilagoditve. Cilj ni ustvariti lepšo časovnico dogodkov. Cilj je, da so odločitve o izpadih, s katerimi se sooča stranka, razložljive, ponovljive in odporne na previsoke in premajhne kredite.

Kaj strani s statusom ponudnika lahko in česa ne morejo dokazati

Dejstvo: Atlassian Statuspage razkriva javne API končne točke za povzetek, status, komponente, nerazrešene incidente, incidente in načrtovano vzdrževanje. OpenAI in Anthropic objavita JSON končne točke v slogu Statuspage, ki vključujejo podatke o komponentah in dogodkih. Google Oblak dokumentira API-je in nadzorne plošče za zdravje storitev ter prek virov razkriva tudi informacije o javnem zdravju. Ponudniki oblakov objavijo tudi ocene po incidentih za nekatere dogodke.

Ti viri so koristni vložki. Povedo vam lahko, da je ponudnik potrdil incident, na katero širšo komponento je to vplivalo in kdaj se je incident premaknil skozi stanja, kot so preiskovanje, identificiran, spremljanje, razrešen ali posmrtno. Ne zadoščajo za odločanje o dobropisih strank za AI API operacij prodajnega posrednika program.

Strani s stanjem pogosto zaostajajo za dejanskim učinkom na stranke. Opisujejo lahko široko komponento, kot so klepet, odgovori, vdelave, slike ali datoteke, ne da bi se čisto preslikali v vzdevke vašega modela, račune ponudnika, regije, uvedbe, ravni storitev ali sezname dovoljenih najemnikov. Prav tako vam ne morejo povedati, ali zahteve določene stranke niso uspele zaradi degradacije navzgor, omejevanja prehoda, izčrpanega proračuna, neveljavnih vnosov, vedenja časovne omejitve na strani odjemalca ali težave z lokalnim omrežjem.

Priporočilo: status ponudnika uporabite kot en dokazni tok, ne kot sprožilec kredita. Dobropisi bi morali biti odvisni od dokazov o vplivu najemnika in prehoda za usklajevanje, potem ko so na voljo dnevniki zahtev, poravnava uporabe in posodobitve incidentov ponudnika.

Zapis Ledger, ki ga potrebujete

Začnite s trajnim zapisom izpadov, ki lahko predstavlja incidente na ravni ponudnika in vpliv na posameznega najemnika. Zapis mora biti samo za dodajanje ali različico, tako da kasnejše spremembe klasifikacije ne izbrišejo prvotne zaznavne sledi.

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

Čas incidenta ponudnika in čas vpliva na najemnika sta ločeni polji. Ponudnik lahko poroča o obsežnem incidentu od 11.30 do 13.00, vendar en najemnik morda ni bil prizadet, ker so njegovi dovoljeni modeli uporabljali drugega ponudnika. Drugi najemnik je morda opazil napake samo od 11:47 do 12:18, ker ga je usmerjanje premaknilo na nadomestni model. Pri tretjini je morda prišlo do visoke zakasnitve, vendar ni bilo neuspelih zahtev. Te razlike so pomembne, ko krediti postanejo denar.

Zaužijte tri tokove dokazov

1. API-ji statusa ponudnika

Zbirajte podatke o statusu ponudnika po urniku in na zahtevo med incidenti. Shranite neobdelano zgoščeno vrednost koristnega tovora, čas iskanja, identifikatorje komponent ponudnika, stanje dogodka, URL dogodka ali referenco ponudnika in kateri koli besedilni povzetek. Ne prepisujte starih stanj. Če se incident premakne s preiskave na identificiranje na spremljanje, ohranite vsak prehod.

Normalizirajte komponente ponudnika v lastne dimenzije prehoda:

• ponudnik: OpenAI, Anthropic, Azure OpenAI, Google ali drug višji
• površina: klepet, odgovori, vdelave, slike, serija, zvok, realni čas, datoteke, moderiranje
• model ali uvedba: zgornji model, notranji vzdevek ali ime uvedbe v oblaku
• regija: kjer je primerno
• račun ali zbirka poverilnic: račun v skupni rabi, račun, vezan na najemnika, ali poverilnica BYOK
• storitvena raven: ime standardne, prednostne, omogočene, paketne ali notranje stopnje

Kompromis: zaužitje statusa ponudnika je poceni in veljavno za potrditev, vendar je lahko pozno, široko ali nepopolno. Moral bi vzbuditi sum in pomagati pri komunikaciji s strankami, vendar ne bi smel samodejno ustvarjati kreditov.

2. Sintetični kanarčki

Sintetični kanarčki so majhne, nadzorovane zahteve, poslane prek iste prehodne poti kot produkcijski promet. Zajemati morajo kombinacije, ki jih prodajate, ne vseh možnih funkcij ponudnika. Prodajalec lahko na primer izvaja kanarčke za vsakega ponudnika, površino, raven modela in regijo, ki jo uporabljajo plačljivi načrti.

Vsak rezultat kanarčka mora vsebovati:

• canary_id in razpored
• ponudnik, površina, model, regija, zbirka poverilnic in profil poti
• začetni čas, čas prvega bajta, čas dokončanja in prag časovne omejitve
• HTTP status, koda napake ponudnika, koda napake prehoda in število ponovnih poskusov
• centilno vedro zakasnitve, ne le uspešno ali neuspešno
• ID korelacije zahteve in redigirani metapodatki odgovora

Kanarčki naj se izogibajo neobdelanim pozivom strank. Uporabite fiksne, neobčutljive pozive in naj bo preverjanje odgovorov preprosto. Kanarček lahko preveri, ali končna točka sprejema zahteve, so tokovi dokončani in zakasnitev ostaja znotraj praga. Za odločitve o kreditih za izpad mu ni treba presojati kakovosti modela.

Kompromis: kanarčki podajo neodvisne dokaze, preden stranke prijavijo težavo. Prav tako povečajo stroške in lahko porabijo kvoto med stresom ponudnika. Dušite kanarčke med aktivnimi dogodki in se izogibajte agresivnemu ponovnemu vedenju, ki prispeva k obremenitvi navzgor.

3. Pravi simptomi zahteve

Dokazi na ravni zahteve so najmočnejši vir vpliva na najemnika. Vsaka zahteva prehoda bi morala že imeti identifikator najemnika, ključa, uporabnika ali končnega uporabnika, vzdevek modela, pot ponudnika, regijo, status, zakasnitev, uporabo žetona in stanje zaračunavanja. Za poročanje o izpadih dodajte klasifikacijska polja, ki ločujejo zgornje simptome od strank in vzrokov prehoda.

Uporabni razredi simptomov vključujejo:

• provider_5xx: navzgor HTTP 5XX ali enakovredna napaka strežnika ponudnika
• provider_timeout: ni odgovora ponudnika pred časovno omejitvijo prehoda
• provider_429_spike: meja hitrosti navzgor nad normalno izhodiščno vrednost
• stream_abort_upstream: tok ponudnika se je nepričakovano končal
• latency_degraded: dokončana zahteva je presegla prag pravilnika
• gateway_throttle: prehod je zavrnil zahtevo zaradi omejitve najemnika ali politike pravičnosti
• customer_error: neveljavna zahteva, nepodprt model, slabo preverjanje pristnosti ali nepravilno oblikovana vsebina
• budget_exhausted: poraba najemnika ali kreditna omejitev blokirano pošiljanje

Samo prvih pet bi moralo običajno šteti kot simptome izpada in še to šele po dodelitvi. Zvišanje števila 429 navzgor je lahko težava ponudnika, lahko pa ga povzroči tudi en najemnik, ki preseže svojo rezervirano prepustnost. Časovna omejitev je lahko poslabšanje ponudnika, lahko pa jo povzroči tudi prekinitev povezave z odjemalcem ali časovna omejitev na ravni aplikacije, ki je krajša od vaše časovne omejitve prehoda.

Tukaj večmodelni API prehod za ekipe potrebuje disciplinirano modeliranje dogodkov. Odločitev o poti, poskus ponovnega poskusa, nadomestni rezultat, končni odgovor in poravnava zaračunavanja bi morali biti združljivi z ID-jem korelacije.

Ločite Windows za incidente ponudnika od Windows za vpliv najemnika

Ne pripisujete kreditov strankam za ponudnikovo široko trajanje incidenta. Pripišite jim zasluge za del incidenta, ki je vplival na njihov ustrezen promet v skladu z vašim pravilnikom.

Uporabite vsaj pet označevalnikov oken:

• čas zaznavanja: ko je vaš sistem prvič zaznal nenormalno vedenje
• prva prizadeta zahteva: prva primerna zahteva najemnika s simptomom izpada
• čas potrditve ponudnika: ko je zgornji ponudnik objavil ali potrdil incident
• čas ublažitve: ko je vaš prehod uporabil nadomestni učinek, oblikovanje prometa, onemogočanje poti ali drugo ublažitev
• potrditev obnovitve: ko so se kanarčki in realni promet vrnili pod pragove

Okno vpliva na najemnika je mogoče izračunati na najemnika, na ključ, na vzdevek modela in na raven storitve. Na primer:

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

Ta ločitev vas tudi ščiti pred pretiranim kreditiranjem. Če najemnik med incidentom ponudnika ni imel prometa, morda ne bo kredita. Če je najemnik preusmeril samo na neprizadete modele, morda ne bo kredita. Če so bile vse napake neveljavne zahteve ali zavrnitve proračuna, bi moralo to biti navedeno v poročilu o incidentu brez obtoževanja ponudnika.

Določite kreditno politiko pred incidentom

Kreditna politika bi morala biti konfiguracija tabele ali različice, ne pa podporna presoja, improvizirana pod pritiskom. Ni nujno, da je pravilnik popolnoma samodejen, vendar bi moral biti v njem izrecna pravila glede upravičenosti in odobritve.

Vključite ta polja:

• primerni simptomi: ponudnik 5XX, časovna omejitev navzgor, prekinitev toka, resna degradacija zakasnitve ali drugi razredi
• minimalno trajanje: na primer pet zaporednih minut ali mejno število zadevnih zahtev
• prag zakasnitve: fiksni prag, izhodišče percentila ali cilj, specifičen za raven storitve
• izključeni vzroki: napake strank, izčrpanost proračuna, zadrževanje najemnikov, nepravilno oblikovane zahteve, nepodprt model, prekinitve povezave odjemalca
• obravnava ponovitve: ali se uspešne nadomestne zahteve štejejo za neuspešne, slabše ali omilile
• kreditna formula: odstotek prizadete uporabe, fiksna prilagoditev denarnice, dobroimetje po SLA na podlagi načrta ali ročni pregled
• oblast za odobritev: samodejno pod mejo, odobritev poslovanja nad njo, finančna odobritev za velike najemnike
• ravnanje s krediti ponudnika: posredovano, deljeno, zadržano ali obdelano ločeno od kreditov strank
• zadrževanje dokazov: kako dolgo je mogoče poizvedovati o dogodkih, zahtevah, kanarčkih in kreditnih evidencah

Priporočilo: shranite različico kreditne politike na vsako začasno in končno kreditno odločitev. Če pravilnik pozneje spremenite, bi morale zgodovinske odločitve še vedno pojasnjevati, katera pravila so bila takrat uporabljena.

Uskladi pred končnimi krediti

Med incidentom potrebujejo stranke hitre posodobitve stanja. Kreditne odločitve so lahko začasne. Končni prenos kredita bi se moral zgoditi, ko so dnevniki dokončani, zakasnjeni dogodki uporabe poravnani, ponovni poskusi in nadomestne možnosti razvrščeni in so bile pregledane informacije ponudnika po incidentu.

Praktičen potek dela za usklajevanje je videti takole:

1. Ustvarite ali posodobite zapis incidenta iz statusa ponudnika, kanarčkovih opozoril ali zahtevajte pragove simptomov.
2. Zamrznite prizadeti profil poti ali ga označite kot poslabšanega, da se mu lahko nove odločitve o poti izognejo, kjer je to mogoče.
3. Ustvarjanje začasnih oken vpliva na najemnika iz dnevnikov zahtev in kanarčkovih časovnic.
4. Izključite vzroke na strani stranke in prehoda z uporabo pravil za razvrščanje.
5. Združite zapise o uporabi in zaračunavanju, tako da so zadevne zahteve povezane z zapisi o poravnanih stroških in stroških strank.
6. Uporabite različico kreditne politike in ustvarite začasne kreditne vrstice.
7. Preglejte dvoumne primere, zlasti poslabšanje delne zakasnitve in najemnike z visoko vrednostjo.
8. Objavite končne prilagoditve kredita v denarnici ali knjigi računov s povezavami nazaj na zapis incidenta.

To povezuje obravnavo izpada v poenoteno API zaračunavanje umetne inteligence, namesto da pusti kredite kot ročne opombe v potrdilu za podporo. Prilagoditev mora biti revidirana: kdo jo je odobril, kateri pravilnik je veljal, katere zahteve so bile upravičene in ali je dokončna ali razveljavitvena.

Izpostavite poglede strank in partnerjev API

Stranke potrebujejo jasno razlago incidenta, ne vaše celotne notranje shrambe za sledenje. Nadaljnje platforme, ki preprodajajo ali vdelujejo vaš API, bodo morda prav tako morale prikazati stanje incidenta znotraj svojih portalov. Končna točka partnerja API lahko izpostavi pogled incidenta v obsegu najemnika.

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

Ta pogled naj bo omejen. Vključite ID-je sintetičnih kanarčkov, ID-je korelacije zahtev, prizadete modele, prizadete ključe in končno kreditno stanje. Privzeto se izogibajte neobdelanim pozivom in telesom polnega odgovora. Če stranka potrebuje globlje dokaze, zagotovite nadzorovan izvoz s pregledi redakcije in avtorizacije.

Predloga poročila o incidentu s stranko

Uporabno poročilo o stranki je lahko kratko, če je knjiga popolna. Razlikovati mora potrjena dejstva od operativnih interpretacij.

Dejstva

• Prizadeti ponudnik in površina
• Okno vpliva na najemnika
• Število primernih neuspešnih, pretečenih, prekinjenih ali poslabšanih zahtev
• Prizadeti vzdevki modela, regije in ključi strank
• Uporabljena ublažitev in čas potrditve obnovitve

Gateway Assessment

• Ali so bili simptomi pripisani ponudniku, prehodu, konfiguraciji najemnika ali vedenju zahteve stranke
• Ali je nadomestno usmerjanje zmanjšalo vpliv
• Ali incident dosega prag kreditne politike
• Ali je kredit začasen, odobren, uporabljen ali zavrnjen

Omejitve

• Podrobnosti o incidentu ponudnika se lahko spremenijo po posmrtni objavi
• Pragi poslabšanja zakasnitve so določeni s pravilnikom, niso univerzalni
• Zahteve, izključene zaradi napak strank ali zavrnitev proračuna, se ne štejejo kot vpliv izpada ponudnika

Napovedi in stave za oblikovanje

Napoved: poročanje o izpadih, obrnjeno k strankam, bo postalo običajna značilnost platform prodajnih posrednikov API z umetno inteligenco, zlasti za prodajalce SaaS, ki izpostavljajo funkcije umetne inteligence pod lastno blagovno znamko. Ko se delovne obremenitve umetne inteligence premikajo od eksperimentiranja k proizvodnji, bodo stranke pričakovale enako odgovornost za incidente, kot jo prejmejo od prodajalcev infrastrukture v oblaku.

Predvidevanje: strani s statusom ponudnika bodo ostale potrebne, vendar nezadostne. Več incidentov bo vključevalo delno poslabšanje: skokovite zakasnitve, prekinitve pretakanja, regionalne težave z zmogljivostjo, regresije kakovosti, napake pri klicu orodij ali vedenje kvote, specifične za račun. Ti primeri zahtevajo dokaze na ravni zahteve in najemnika.

Priporočilo: sestavite glavno knjigo, preden obljubite močne kredite SLA. Naknadno opremljanje dokazov o incidentu po spornem izpadu je drago in pogosto neprepričljivo.

Uporabni sklep

Ne dovolite, da strani s statusom ponudnika postanejo vaš edini vir resnice za kredite strank. Zgradite knjigo dokazov o izpadih, ki združuje vire incidentov ponudnika, sintetične kanarčke, simptome zahtev, odločitve o poti, okna vpliva na najemnika, zapise zaračunavanja in končne prilagoditve kredita.

Najmanjša uporabna različica je enostavna: vnesite status ponudnika JSON, zaženite kanarčke majhnega obsega za prodane nivoje modelnih regij, razvrstite neuspešne zahteve glede na vzrok, izračunajte okna vpliva na najemnika in uporabite kreditno politiko z različicami po uskladitvi. To daje podpori, financam, inženiringu in nadaljnjim partnerjem enako bazo dokazov. Prav tako vam omogoča, da razložite incidente brez slepega zrcaljenja strani s stanjem navzgor ali ročnega izdajanja dobropisov dobre volje, kadar koli se stranka pritoži.

Sorodno branje

• poročanje o uporabi in prilagoditvah, usmerjeno k strankam