Izgradite AI API knjigu dokaza o prekidu rada prije nego što obećate kupcu SLA kredite

Kad dobavljač uzlaznog modela ima incident, vaši korisnici ne pitaju samo je li pružatelj bio u kvaru. Pitaju jesu li njihovi zahtjevi uspjeli, koji ključevi i modeli su pogođeni, ubraja li se prekid u vaš SLA i koji bi kredit trebali dobiti. Stranica statusa pružatelja usluga pomaže, ali ne može sama odgovoriti na pitanja specifična za stanara.

AI API pristupnik trebao bi tretirati dokaze o prekidu rada kao prvorazrednu knjigu: signali pružatelja usluga, rezultati sintetičke sonde, simptomi na razini zahtjeva, prozori utjecaja stanara, odluke o pripisivanju i kreditne prilagodbe. Cilj nije stvoriti ljepšu vremensku liniju incidenta. Cilj je učiniti odluke o prekidu rada s klijentima objašnjivim, ponovljivim i otpornim na prekomjerno i premalo kreditiranje.

Što stranice statusa pružatelja mogu, a što ne mogu dokazati

Činjenica: Atlassian Statuspage izlaže javne API krajnje točke za sažetak, status, komponente, neriješene incidente, incidente i planirano održavanje. OpenAI i Anthropic objavljuju JSON krajnje točke u stilu stranice statusa koje uključuju podatke o komponentama i incidentima. Google Cloud dokumentira Service Health API-je i nadzorne ploče, a također izlaže informacije o javnom zdravlju putem feedova. Pružatelji usluga u oblaku također objavljuju recenzije nakon incidenta za neke događaje.

Ti su feedovi korisni unosi. Oni vam mogu reći da je pružatelj potvrdio incident, koja je široka komponenta bila pogođena i kada je incident prošao kroz stanja kao što su istraga, identificiran, praćenje, riješen ili postmortalno. Oni nisu dovoljni za odlučivanje o kreditima korisnika za AI API operacije prodavača program.

Stranice statusa često zaostaju za stvarnim učinkom na kupca. Oni mogu opisati široku komponentu kao što su chat, odgovori, ugradnje, slike ili datoteke bez čistog preslikavanja na aliase vašeg modela, račune pružatelja usluga, regije, implementacije, razine usluga ili popise dopuštenih stanara. Također vam ne mogu reći jesu li zahtjevi određenog korisnika uspjeli zbog degradacije uzvodnog toka, prigušenja pristupnika, iscrpljenog proračuna, nevažećeg unosa, ponašanja isteka vremena na strani klijenta ili problema s lokalnom mrežom.

Preporuka: koristite status davatelja kao jedan tok dokaza, a ne kao kreditni okidač. Krediti bi trebali ovisiti o dokazima o utjecaju stanara i prolazu usklađivanja nakon što budu dostupni zapisnici zahtjeva, nagodba korištenja i ažuriranja incidenata pružatelja.

Knjižna knjiga koja vam je potrebna

Počnite s dugotrajnim zapisom o prekidu rada koji može predstavljati incidente na razini pružatelja usluga i učinak specifičan za stanara. Zapis bi trebao biti samo za dodavanje ili verzioniran kako kasnije promjene klasifikacije ne bi izbrisale izvorni trag otkrivanja.

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

Vrijeme incidenta pružatelja i vrijeme utjecaja stanara odvojena su polja. Pružatelj može prijaviti široki incident od 11:30 do 13:00, ali jedan stanar možda nije pogođen jer su njegovi dopušteni modeli koristili drugog pružatelja. Drugi je stanar možda vidio kvarove samo od 11:47 do 12:18 jer ga je usmjeravanje premjestilo na rezervni model. Treći je možda imao veliku latenciju, ali nije imao neuspješne zahtjeve. Te su razlike važne kada krediti postanu novac.

Unos tri toka dokaza

1. API-ji statusa pružatelja usluga

Prikupljajte podatke o statusu pružatelja prema rasporedu i na zahtjev tijekom incidenata. Pohranite neobrađeni hash korisnih podataka, vrijeme dohvaćanja, identifikatore komponenti pružatelja usluga, stanje incidenta, URL incidenta ili referencu pružatelja usluga i bilo koji tekstualni sažetak. Nemojte prepisivati ​​stara stanja. Ako se incident pomakne s istrage na identificiranje na praćenje, sačuvajte svaki prijelaz.

Normalizirajte komponente pružatelja usluga u vlastite dimenzije pristupnika:

• provider: OpenAI, Anthropic, Azure OpenAI, Google ili neki drugi uzvodni
• površina: chat, odgovori, ugradnje, slike, serija, zvuk, stvarno vrijeme, datoteke, moderiranje
• model ili implementacija: uzvodni model, interni alias ili naziv implementacije u oblaku
• regija: gdje je primjenjivo
• račun ili skup vjerodajnica: zajednički račun, račun vezan za stanara ili BYOK vjerodajnica
• razina usluge: standardna, prioritetna, osigurana, skupna ili interna razina naziva

Kompromis: unos statusa davatelja je jeftin i mjerodavan za potvrdu, ali može biti kasno, široko ili nepotpuno. Trebao bi izazvati sumnju i pomoći u komunikaciji s klijentima, ali ne bi trebao automatski generirati kredite.

2. Sintetički kanarinci

Sintetički kanarinci su mali, kontrolirani zahtjevi koji se šalju kroz isti pristupni put kao i proizvodni promet. Oni bi trebali pokrivati ​​kombinacije koje prodajete, a ne svaku moguću značajku pružatelja usluga. Na primjer, preprodavač može pokrenuti Canary za svakog pružatelja, površinu, razinu modela i regiju koju koriste plaćeni planovi.

Svaki rezultat kanarinca trebao bi uključivati:

• canary_id i raspored verzija
• pružatelj, površina, model, regija, skup vjerodajnica i profil rute
• vrijeme početka, vrijeme prvog bajta, vrijeme završetka i prag isteka vremena
• HTTP status, šifra pogreške pružatelja usluga, šifra pogreške pristupnika i broj ponovnih pokušaja
• centil kašnjenja, ne samo prolaz ili pad
• ID korelacije zahtjeva i redigirani metapodaci odgovora

Kanarinci bi trebali izbjegavati sirove korisničke upute. Koristite fiksne, neosjetljive upite i neka provjera valjanosti odgovora bude jednostavna. Kanarinac može provjeriti prihvaća li krajnja točka zahtjeve, dovršava li strujanje i ostaje li latencija unutar praga. Ne treba ocjenjivati kvalitetu modela za odluke o kreditu za ispad.

Kompromis: kanarinci daju neovisne dokaze prije nego što kupci prijave problem. Oni također dodaju troškove i mogu potrošiti kvotu tijekom stresa pružatelja. Prigušite kanarince tijekom aktivnih incidenata i izbjegavajte agresivno ponašanje pri ponovnom pokušaju koje doprinosi opterećenju uzvodno.

3. Simptomi stvarnog zahtjeva

Dokaz na razini zahtjeva najjači je izvor utjecaja na stanara. Svaki pristupni zahtjev već bi trebao imati zakupca, ključ, identifikator korisnika ili krajnjeg korisnika, alias modela, rutu pružatelja, regiju, status, latenciju, upotrebu tokena i stanje naplate. Za izvješćivanje o prekidu rada, dodajte polja klasifikacije koja odvajaju uzvodne simptome od uzroka korisnika i pristupnika.

Korisne klase simptoma uključuju:

• provider_5xx: uzvodno HTTP 5XX ili ekvivalentna greška poslužitelja pružatelja usluga
• provider_timeout: nema odgovora davatelja usluga prije isteka vremena pristupnika
• provider_429_spike: uzvodno ograničenje brzine iznad normalne osnovne vrijednosti
• stream_abort_upstream: stream davatelja neočekivano je završio
• latency_degraded: dovršeni zahtjev premašio je prag pravila
• gateway_throttle: pristupnik je odbio zahtjev zbog ograničenja zakupca ili pravila pravednosti
• customer_error: nevažeći zahtjev, nepodržani model, loša provjera autentičnosti ili neispravan korisni sadržaj
• budget_exhausted: potrošnja stanara ili kreditno ograničenje blokirano slanje

Samo prvih pet treba se normalno računati kao simptomi ispada, pa čak i tada samo nakon pripisivanja. Skok u uzvodnim 429 može biti problem pružatelja, ali može biti uzrokovan i time što jedan stanar premašuje svoju rezerviranu propusnost. Istekanje vremena može biti degradacija pružatelja usluga, ali također može biti uzrokovano prekidom veze s klijentom ili istekom vremena na razini aplikacije koje je kraće od vremena čekanja vašeg pristupnika.

Ovdje višemodelni API pristupnik za timove treba disciplinirano modeliranje događaja. Odluka o ruti, pokušaj ponovnog pokušaja, rezervni rezultat, konačni odgovor i obračun naplate trebali bi se pridružiti ID-om korelacije.

Odvojite Provider Incident Windows od Tenant Impact Windows

Nemojte pripisivati klijentima dugotrajnost incidenta pružatelja usluge. Pripišite im zasluge za dio incidenta koji je utjecao na njihov prihvatljiv promet prema vašoj politici.

Koristite najmanje pet oznaka prozora:

• vrijeme otkrivanja: kada je vaš sustav prvi put otkrio abnormalno ponašanje
• prvi zahvaćeni zahtjev: prvi kvalificirani zahtjev stanara sa simptomom ispada
• vrijeme potvrde pružatelja: kada je prethodni pružatelj objavio ili potvrdio incident
• vrijeme ublažavanja: kada je vaš pristupnik primijenio zamjenu, oblikovanje prometa, onemogućavanje rute ili drugo ublažavanje
• potvrda oporavka: kada su se kanarinci i stvarni promet vratili ispod pragova

Prozor utjecaja zakupca može se izračunati po zakupcu, po ključu, po aliasu modela i po razini usluge. Na primjer:

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

Ovo odvajanje također vas štiti od prekomjernog kreditiranja. Ako stanar nije imao prometa tijekom incidenta s pružateljem, možda neće biti kredita. Ako je stanar preusmjerio samo na nepromijenjene modele, možda neće biti kredita. Ako su svi neuspjesi bili nevažeći zahtjevi ili odbijanja proračuna, to bi trebalo biti navedeno u izvješću o incidentu bez okrivljavanja pružatelja usluga.

Definirajte kreditnu politiku prije incidenta

Kreditna politika trebala bi biti konfiguracija tablice ili verzije, a ne prosudba podrške improvizirana pod pritiskom. Pravila ne moraju biti potpuno automatizirana, ali bi trebala biti eksplicitna pravila prihvatljivosti i odobrenja.

Uključite ova polja:

• prihvatljivi simptomi: pružatelj 5XX, vremensko ograničenje uzlaznog toka, prekid toka, ozbiljno smanjenje latencije ili druge klase
• minimalno trajanje: na primjer, pet uzastopnih minuta ili prag broja zahvaćenih zahtjeva
• prag kašnjenja: fiksni prag, postotna osnovna vrijednost ili cilj specifičan za razinu usluge
• isključeni uzroci: pogreške korisnika, iscrpljenost proračuna, ograničenje zakupca, neispravni zahtjevi, nepodržani model, prekid veze s klijentom
• ponovni pokušaj obrade: računaju li se uspješni zamjenski zahtjevi kao neuspjeli, smanjeni ili ublaženi
• kreditna formula: postotak pogođene upotrebe, fiksna prilagodba novčanika, SLA kredit temeljen na planu ili ručni pregled
• ovlaštenje odobrenja: automatsko ispod granice, odobrenje operacija iznad nje, odobrenje financija za velike stanare
• postupanje s kreditima davatelja usluga: proslijeđeno, dijeljeno, zadržano ili obrađeno odvojeno od kredita korisnika
• zadržavanje dokaza: koliko dugo podaci o incidentu, zahtjevu, kanarincu i kreditnoj sposobnosti ostaju podložni upitu

Preporuka: pohranite verziju kreditne politike na svaku privremenu i konačnu odluku o kreditu. Ako kasnije revidirate pravilo, povijesne odluke bi i dalje trebale objašnjavati koja su pravila primijenjena u to vrijeme.

Usklađivanje prije konačnih bodova

Tijekom incidenta kupci trebaju brzo ažuriranje statusa. Odluke o kreditu mogu biti privremene. Konačna kreditna propusnica trebala bi se dogoditi nakon što se dovrše zapisnici, riješe odgođeni događaji upotrebe, klasificiraju ponovni pokušaji i zamjene i pregledaju informacije pružatelja nakon incidenta.

Praktični radni tijek usklađivanja izgleda ovako:

1. Stvorite ili ažurirajte zapis incidenta iz statusa pružatelja usluga, upozorenja Canary ili zahtjevajte pragove simptoma.
2. Zamrznite zahvaćeni profil rute ili ga označite kao degradiran tako da ga nove odluke o usmjeravanju mogu izbjeći gdje je to moguće.
3. Generirajte privremene prozore utjecaja stanara iz zapisa zahtjeva i vremenskih okvira Canary.
4. Isključite uzroke na strani korisnika i pristupnika pomoću pravila klasifikacije.
5. Pridružite evidenciju o korištenju i naplati tako da se zahvaćeni zahtjevi povežu s podmirenim troškovima i evidencijom o naplati korisnika.
6. Primijenite verziju kreditne politike i izradite privremene kreditne retke.
7. Pregledajte dvosmislene slučajeve, posebno djelomičnu degradaciju latencije i stanare visoke vrijednosti.
8. Objavite konačna usklađenja kredita u novčanik ili knjigu faktura s vezama natrag na evidenciju događaja.

Ovo povezuje rukovanje prekidima s objedinjenom AI API naplatom umjesto ostavljanja kredita kao ručnih bilješki u tiketu za podršku. Prilagodba bi se trebala moći provjeriti: tko ju je odobrio, koja je politika primijenjena, koji su zahtjevi bili prihvatljivi i je li konačna ili poništiva.

Izlaganje kupaca i partnera API Pogledi

Kupci trebaju jasno objašnjenje incidenta, a ne cijelo interno skladište praćenja. Nizvodne platforme koje preprodaju ili ugrađuju vaš API možda će također morati prikazati status incidenta unutar svojih portala. Krajnja točka partnera API može izložiti prikaz incidenta s opsegom stanara.

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

Držite ovaj pregled ograničenim. Uključite sintetičke ID-ove Canary-a, ID-ove korelacije zahtjeva, zahvaćene modele, zahvaćene ključeve i konačno kreditno stanje. Izbjegavajte neobrađene upite i potpuna tijela odgovora prema zadanim postavkama. Ako kupac treba dublje dokaze, osigurajte kontrolirani izvoz s redigiranjem i provjerama autorizacije.

Predložak izvješća o incidentu korisnika

Korisno korisničko izvješće može biti kratko ako je knjiga potpuna. Trebao bi razlikovati potvrđene činjenice od operativnog tumačenja.

Činjenice

• Ponuđač i površina zahvaćena
• Prozor utjecaja stanara
• Broj prihvatljivih neuspjelih zahtjeva, isteklo je vrijeme, prekinutih ili degradiranih zahtjeva
• Pogođeni aliasi modela, regije i korisnički ključevi
• Primijenjeno ublažavanje i vrijeme potvrde oporavka

Gateway Assessment

• Jesu li simptomi pripisani pružatelju, pristupniku, konfiguraciji zakupca ili ponašanju zahtjeva korisnika
• Je li rezervno usmjeravanje smanjilo utjecaj
• Zadovoljava li incident prag kreditne politike
• Je li kredit privremen, odobren, primijenjen ili odbijen

Ograničenja

• Pojedinosti o incidentu pružatelja mogu se promijeniti nakon obdukcije
• Pragovi degradacije latencije definirani su pravilima, a ne univerzalni
• Zahtjevi isključeni zbog pogrešaka korisnika ili odbijanja proračuna ne računaju se kao utjecaj ispada pružatelja usluga

Predviđanja i oklade na dizajn

Predviđanje: izvješćivanje o prekidu rada prema korisnicima postat će normalna značajka AI API platformi preprodavača, posebno za SaaS dobavljače koji izlažu AI značajke pod svojim vlastitim brendom. Kako se radna opterećenja umjetne inteligencije pomiču s eksperimentiranja na proizvodnju, korisnici će očekivati istu odgovornost za incidente koju dobivaju od dobavljača infrastrukture u oblaku.

Predviđanje: stranice statusa pružatelja ostat će potrebne, ali nedovoljne. Više incidenata uključivat će djelomičnu degradaciju: skokove latencije, prekide strujanja, regionalne probleme s kapacitetom, regresije kvalitete, neuspjehe poziva alata ili ponašanje kvote specifično za račun. Ti slučajevi zahtijevaju dokaze na razini zahtjeva i na razini stanara.

Preporuka: izgradite glavnu knjigu prije nego obećate jake SLA kredite. Dodatno opremanje dokaza o incidentu nakon spornog prekida skupo je i često neuvjerljivo.

Zaključak koji se može poduzeti

Ne dopustite da stranice statusa pružatelja usluga postanu vaš jedini izvor istine za korisničke kredite. Izgradite knjigu dokaza o prekidu rada koja objedinjuje podatke o incidentima dobavljača, sintetičke kanarince, simptome zahtjeva, odluke o ruti, prozore utjecaja zakupca, zapise o naplati i konačne kreditne prilagodbe.

Minimalna korisna verzija je jednostavna: unos statusa pružatelja JSON, pokretanje malih količina za prodane razine modelske regije, klasificiranje neuspjeha zahtjeva prema uzroku, izračunavanje prozora utjecaja zakupca i primjena verzionirane kreditne politike nakon usklađivanja. To daje podršci, financijama, inženjeringu i nizvodnim partnerima istu bazu dokaza. Također vam omogućuje objašnjavanje incidenata bez slijepog zrcaljenja uzlaznih statusnih stranica ili izdavanja ručnih kredita dobre volje kad god se korisnik žali.

Povezano čitanje

• korisnička izvješća o korištenju i prilagodbi