Zbuduj księgę dowodów przestojów AI API, zanim obiecasz klientowi zwrot SLA

Kiedy dostawca modelu wyższego szczebla ma incydent, Twoi klienci nie tylko pytają, czy dostawca nie działał. Pytają, czy ich żądania nie powiodły się, których kluczy i modeli dotyczyło to, czy przestój wlicza się do umowy SLA i jaki kredyt powinni otrzymać. Strona stanu dostawcy jest pomocna, ale sama nie jest w stanie odpowiedzieć na pytania dotyczące konkretnego dzierżawcy.

Brama AI API powinna traktować dowody przestojów jak najwyższej klasy księgę: sygnały dostawców, wyniki sond syntetycznych, objawy na poziomie żądań, okna wpływu na najemców, decyzje dotyczące atrybucji i korekty kredytu. Celem nie jest stworzenie ładniejszego harmonogramu zdarzeń. Celem jest zapewnienie, aby decyzje o przestojach podejmowane przez klienta były zrozumiałe, powtarzalne i odporne zarówno na nadmierne, jak i niedostateczne kredytowanie.

Co mogą, a czego nie mogą udowodnić strony stanu dostawcy

Fakt: Strona stanu Atlassian udostępnia API publiczne punkty końcowe w celu uzyskania podsumowania, stanu, komponentów, nierozwiązanych incydentów, incydentów i zaplanowanej konserwacji. OpenAI i Anthropic publikują punkty końcowe JSON w stylu strony stanu, które zawierają dane komponentów i incydentów. Google Chmura dokumentuje interfejsy API i pulpity nawigacyjne Service Health, a także udostępnia informacje na temat zdrowia publicznego za pośrednictwem kanałów informacyjnych. Dostawcy usług w chmurze publikują także recenzje niektórych wydarzeń po incydencie.

Te kanały są przydatnymi danymi wejściowymi. Mogą poinformować Cię, że usługodawca potwierdził incydent, którego szerokiego elementu dotyczył oraz kiedy incydent przeszedł przez takie etapy, jak dochodzenie, zidentyfikowanie, monitorowanie, rozwiązanie lub sekcja zwłok. Nie wystarczą, aby zdecydować o kredytach klientów w programie AI API operacji resellerskich.

Strony stanu często nie wywierają rzeczywistego wpływu na klienta. Mogą opisywać szeroki komponent, taki jak czat, odpowiedzi, osadzanie, obrazy lub pliki, bez dokładnego mapowania na aliasy modeli, konta dostawców, regiony, wdrożenia, poziomy usług lub listy dozwolonych dzierżaw. Nie mogą także stwierdzić, czy żądania konkretnego klienta nie powiodły się z powodu degradacji serwera nadrzędnego, ograniczenia przepustowości bramy, wyczerpania budżetu, nieprawidłowych danych wejściowych, przekroczenia limitu czasu po stronie klienta lub problemu z siecią lokalną.

Zalecenie: użyj statusu dostawcy jako jednego strumienia dowodów, a nie jako czynnika uruchamiającego kredyt. Kredyty powinny zależeć od dowodów wpływu najemcy i przebiegu uzgadniania po udostępnieniu dzienników żądań, rozliczeń użytkowania i aktualizacji incydentów dostawcy.

Rekord księgi, którego potrzebujesz

Zacznij od trwałego rejestru przestojów, który może odzwierciedlać zarówno zdarzenia u całego dostawcy, jak i wpływ na dzierżawcę. Rekord powinien być przeznaczony wyłącznie do dołączenia lub wersjonowany, aby późniejsze zmiany klasyfikacji nie zamazały pierwotnego śladu wykrycia.

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

Czas zdarzenia dostawcy i czas wpływu najemcy to oddzielne pola. Dostawca może zgłosić szeroki incydent w godzinach od 11:30 do 13:00, ale jeden najemca mógł nie mieć na to wpływu, ponieważ jego dozwolone modele korzystały z usług innego dostawcy. Inny dzierżawca mógł zauważyć awarie dopiero od 11:47 do 12:18, ponieważ routing przeniósł go do modelu awaryjnego. W trzeciej osobie mogły wystąpić duże opóźnienia, ale nie wystąpiły żadne nieudane żądania. Te różnice mają znaczenie, gdy kredyty stają się pieniędzmi.

Przeanalizuj trzy strumienie dowodów

1. Interfejsy API stanu dostawcy

Zbieraj dane o stanie dostawcy zgodnie z harmonogramem i na żądanie podczas incydentów. Przechowuj skrót surowego ładunku, czas pobrania, identyfikatory komponentów dostawcy, stan zdarzenia, adres URL zdarzenia lub odniesienie do dostawcy oraz dowolne podsumowanie tekstowe. Nie nadpisuj starych stanów. Jeśli incydent przejdzie od badania, przez zidentyfikowanie, do monitorowania, zachowaj każde przejście.

Normalizuj komponenty dostawcy do własnych wymiarów bramy:

• dostawca: OpenAI, Anthropic, Azure OpenAI, Google lub inny dostawca
• powierzchnia: czat, odpowiedzi, osadzanie, obrazy, wsad, dźwięk, czas rzeczywisty, pliki, moderacja
• model lub wdrożenie: model nadrzędny, alias wewnętrzny lub nazwa wdrożenia w chmurze
• region: tam, gdzie ma to zastosowanie
• konto lub pula danych uwierzytelniających: konto współdzielone, konto powiązane z dzierżawcą lub dane uwierzytelniające BYOK
• poziom usług: standardowy, priorytetowy, udostępniany, wsadowy lub nazwa warstwy wewnętrznej

Kompromis: pozyskiwanie statusu dostawcy jest tanie i wiarygodne do potwierdzenia, ale może być spóźnione, ogólne lub niekompletne. Powinno wzbudzić podejrzenia i pomóc w komunikacji z klientem, ale nie powinno automatycznie generować kredytów.

2. Kanarki syntetyczne

Syntetyczne kanarki to małe, kontrolowane żądania wysyłane tą samą ścieżką bramy, co ruch produkcyjny. Powinny obejmować sprzedawane przez Ciebie kombinacje, a nie każdą możliwą funkcję dostawcy. Na przykład sprzedawca może oferować kanarki dla każdego dostawcy, powierzchni, poziomu modelu i regionu używanego w planach płatnych.

Każdy wynik dla kanarków powinien zawierać:

• canary_id i wersja harmonogramu
• dostawca, powierzchnia, model, region, pula danych uwierzytelniających i profil trasy
• czas rozpoczęcia, czas pierwszego bajtu, czas zakończenia i próg limitu czasu
• HTTP stan, kod błędu dostawcy, kod błędu bramy i liczba ponownych prób
• Pojemnik percentyla opóźnienia, nie tylko pozytywny lub negatywny
• poproś o identyfikator korelacji i zredagowane metadane odpowiedzi

Kanarki powinny unikać surowych podpowiedzi klientów. Używaj stałych, niewrażliwych podpowiedzi i upraszczaj sprawdzanie odpowiedzi. Kanarek może sprawdzić, czy punkt końcowy akceptuje żądania, strumienie są zakończone, a opóźnienie mieści się w określonym progu. Nie musi oceniać jakości modelu przy podejmowaniu decyzji kredytowych w związku z przestojami.

Kompromis: kanarki przedstawiają niezależne dowody, zanim klienci zgłoszą problem. Zwiększają także koszty i mogą zużywać limit w okresie stresu dostawcy. Dławij kanarki podczas aktywnych zdarzeń i unikaj agresywnego zachowania ponawiania prób, które zwiększa obciążenie w górę strumienia.

3. Objawy prawdziwego żądania

Dowody na poziomie żądania są najsilniejszym źródłem wpływu na najemcę. Każde żądanie bramy powinno już mieć dzierżawę, klucz, identyfikator użytkownika lub użytkownika końcowego, alias modelu, trasę dostawcy, region, stan, opóźnienie, użycie tokenu i stan rozliczeń. Do raportowania przestojów dodaj pola klasyfikacyjne, które oddzielają objawy nadrzędne od przyczyn klientów i bramy.

Przydatne klasy objawów obejmują:

• provider_5xx: upstream HTTP 5XX lub błąd serwera równoważnego dostawcy
• provider_timeout: brak odpowiedzi dostawcy przed przekroczeniem limitu czasu bramy
• provider_429_spike: limit szybkości przesyłania danych powyżej normalnej wartości bazowej
• stream_abort_upstream: strumień dostawcy zakończył się nieoczekiwanie
• latency_degraded: zakończone żądanie przekroczyło próg zasad
• gateway_throttle: brama odrzuciła żądanie ze względu na limit dzierżawcy lub zasady uczciwości
• customer_error: nieprawidłowe żądanie, nieobsługiwany model, złe uwierzytelnienie lub zniekształcony ładunek
• budget_exhausted: zablokowana wysyłka wydatków najemcy lub limitu kredytu

Tylko pierwszych pięć powinno się zwykle liczyć jako objawy przestoju i nawet wtedy dopiero po przypisaniu. Gwałtowny wzrost liczby wysyłanych sygnałów 429 może być problemem dostawcy, ale może być również spowodowany przekroczeniem przez jednego dzierżawcę zarezerwowanej przepustowości. Przekroczenie limitu czasu może wynikać z degradacji dostawcy, ale może być również spowodowane rozłączeniem klienta lub przekroczeniem limitu czasu na poziomie aplikacji, który jest krótszy niż limit czasu bramy.

W tym miejscu wielomodelowa API brama dla zespołów wymaga zdyscyplinowanego modelowania zdarzeń. Decyzję o trasie, ponowną próbę, wynik zastępczy, ostateczną odpowiedź i rozliczenie płatności należy połączyć według identyfikatora korelacji.

Oddziel okna zdarzeń dostawcy od okien wpływu dzierżawców

Nie przypisuj klientom ogólnego czasu trwania zdarzenia u dostawcy. Przypisz im część zdarzenia, która wpłynęła na ruch kwalifikujący się do nich zgodnie z Twoją polisą.

Użyj co najmniej pięciu znaczników okien:

• czas wykrycia: kiedy system po raz pierwszy wykrył nieprawidłowe zachowanie
• pierwsze żądanie, którego dotyczy problem: pierwsze żądanie kwalifikującej się dzierżawy z objawem przestoju
• czas potwierdzenia dostawcy: kiedy dostawca wyższego szczebla opublikował lub potwierdził zdarzenie
• czas łagodzenia skutków: kiedy brama zastosowała rozwiązanie awaryjne, kształtowanie ruchu, wyłączenie trasy lub inne rozwiązanie łagodzące
• potwierdzenie powrotu do zdrowia: kiedy kanarki i rzeczywisty ruch powrócił poniżej progów

Okno wpływu dzierżawcy można obliczyć dla każdego dzierżawcy, klucza, aliasu modelu i warstwy usług. Na przykład:

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

To oddzielenie chroni również przed nadmiernym kredytowaniem. Jeżeli w czasie zdarzenia u dostawcy najemca nie miał ruchu, kredyt może nie zostać przyznany. Jeśli najemca zostanie przekierowany tylko do modeli, których to nie dotyczy, kredyt może nie zostać przyznany. Jeśli wszystkie niepowodzenia były nieprawidłowymi żądaniami lub odmową budżetu, raport o zdarzeniu powinien to zawierać, bez obwiniania dostawcy.

Określ politykę kredytową przed incydentem

Polityka kredytowa powinna mieć formę tabeli lub konfiguracji opartej na wersjach, a nie oceny pomocniczej improwizowanej pod presją. Polityka nie musi być w pełni automatyczna, ale powinna jasno określać zasady kwalifikowalności i zatwierdzania.

Uwzględnij te pola:

• kwalifikujące się objawy: dostawca 5XX, przekroczenie limitu czasu przesyłania danych, przerwanie strumienia, znaczne pogorszenie opóźnienia lub inne klasy
• minimalny czas trwania: na przykład pięć kolejnych minut lub progowa liczba żądań, których to dotyczy
• próg opóźnienia: stały próg, procentowa wartość bazowa lub cel specyficzny dla warstwy usługi
• wykluczone przyczyny: błędy klientów, wyczerpanie budżetu, ograniczenie dzierżawy, źle sformułowane żądania, nieobsługiwany model, rozłączenia klientów
• ponów próbę: czy udane żądania awaryjne liczą się jako nieudane, pogorszone lub złagodzone
• Formuła kredytu: procent wykorzystania, którego dotyczy problem, stała korekta portfela, kredyt SLA oparty na planie lub weryfikacja ręczna
• organ zatwierdzający: automatycznie poniżej limitu, zatwierdzanie operacji powyżej niego, zatwierdzanie finansów w przypadku dużych najemców
• obsługa kredytów dostawcy: przekazywana, udostępniana, zachowywana lub obsługiwana oddzielnie od kredytów klientów
• przechowywanie dowodów: jak długo można przeglądać historię zdarzeń, wniosków, danych dotyczących kanarek i historii kredytowej

Zalecenie: przechowuj wersję polityki kredytowej przy każdej tymczasowej i ostatecznej decyzji kredytowej. Jeśli później zmienisz zasady, decyzje historyczne powinny nadal wyjaśniać, które zasady były wówczas stosowane.

Uzgodnij przed napisami końcowymi

Podczas zdarzenia klienci potrzebują szybkich aktualizacji statusu. Decyzje kredytowe mogą mieć charakter tymczasowy. Ostateczne zatwierdzenie kredytu powinno nastąpić po skompletowaniu dzienników, ustaleniu opóźnionych zdarzeń użycia, sklasyfikowaniu ponownych prób i przywróceń oraz sprawdzeniu informacji dostawcy po zdarzeniu.

Praktyczny przebieg uzgadniania wygląda następująco:

1. Utwórz lub zaktualizuj rejestr zdarzeń na podstawie statusu dostawcy, alertów Canary lub zażądaj progów objawów.
2. Zablokuj profil trasy, którego to dotyczy, lub oznacz go jako zdegradowany, aby nowe decyzje dotyczące trasy mogły go ominąć, jeśli to możliwe.
3. Generuj tymczasowe okna wpływu najemcy na podstawie dzienników żądań i osi czasu.
4. Wyklucz przyczyny po stronie klienta i bramy za pomocą reguł klasyfikacji.
5. Połącz rejestry użytkowania i rozliczenia, aby żądania, których to dotyczy, zostały powiązane z rejestrami rozliczonych kosztów i opłat klienta.
6. Zastosuj wersję zasad kredytowych i utwórz tymczasowe wiersze kredytowe.
7. Przejrzyj niejednoznaczne przypadki, zwłaszcza częściową degradację opóźnień i najemców o dużej wartości.
8. Opublikuj ostateczne korekty kredytu w portfelu lub księdze faktur z linkami prowadzącymi do rejestru zdarzenia.

To wiąże obsługę przestojów z ujednoliconą sztuczną inteligencją API rozliczeniami zamiast pozostawiania środków w postaci ręcznych notatek w zgłoszeniu pomocy technicznej. Korekta powinna podlegać kontroli: kto ją zatwierdził, jakie zasady zastosowano, które wnioski się kwalifikowały i czy jest ona ostateczna czy odwracalna.

Udostępnij klientom i partnerom API widoki

Klienci potrzebują jasnego wyjaśnienia zdarzenia, a nie całego wewnętrznego magazynu śledzenia. Platformy niższego szczebla, które odsprzedają lub osadzają Twój API, mogą również potrzebować pokazywania statusu zdarzenia w swoich własnych portalach. Punkt końcowy partnera API może udostępniać widok zdarzeń o zasięgu dzierżawcy.

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

Utrzymuj zakres tego widoku. Uwzględnij syntetyczne identyfikatory kanarek, identyfikatory korelacji żądań, modele, których dotyczy problem, klucze, których dotyczy problem, oraz ostateczny stan kredytu. Domyślnie unikaj surowych podpowiedzi i pełnych treści odpowiedzi. Jeśli klient potrzebuje głębszych dowodów, zapewnij kontrolowany eksport z kontrolą redakcyjną i autoryzacyjną.

Szablon raportu o zdarzeniu klienta

Przydatny raport o kliencie może być krótki, jeśli księga jest kompletna. Należy odróżnić potwierdzone fakty od interpretacji operacyjnej.

Fakty

• Dotyczy dostawcy i powierzchni
• Okno wpływu na najemcę
• Liczba kwalifikujących się żądań zakończonych niepowodzeniem, przekroczonym limitem czasu, przerwanych lub o pogorszeniu jakości
• Aliasy modeli, regiony i klucze klientów, których to dotyczy
• Zastosowano środki łagodzące i czas potwierdzenia odzyskiwania

Ocena bramy

• Czy objawy zostały przypisane dostawcy, bramie, konfiguracji dzierżawcy czy zachowaniu klienta na żądanie
• Czy routing zastępczy zmniejsza wpływ
• Czy zdarzenie spełnia próg polityki kredytowej
• Czy kredyt jest tymczasowy, zatwierdzony, zastosowany czy odrzucony

Ograniczenia

• Szczegóły zdarzenia u dostawcy mogą ulec zmianie po publikacji pośmiertnej
• Progi degradacji opóźnienia są określone przez zasady, a nie uniwersalne
• Żądania wykluczone z powodu błędów klienta lub odmowy budżetu nie są liczone jako wpływ na przestój dostawcy

Prognozy i zakłady projektowe

Prognoza: zgłaszanie przestojów bezpośrednio do klienta stanie się normalną funkcją platform sprzedawców API AI, szczególnie w przypadku dostawców SaaS, którzy udostępniają funkcje AI pod własną marką. W miarę jak obciążenia sztucznej inteligencji przechodzą z eksperymentów do produkcji, klienci będą oczekiwać takiej samej odpowiedzialności za incydenty, jaką otrzymują od dostawców infrastruktury chmurowej.

Prognoza: strony stanu dostawcy pozostaną konieczne, ale niewystarczające. Więcej incydentów będzie obejmować częściową degradację: skoki opóźnień, przerwy w przesyłaniu strumieniowym, problemy z przepustowością regionalną, regresję jakości, awarie wywołań narzędzi lub zachowanie przydziałów specyficzne dla konta. W takich przypadkach wymagane są dowody na poziomie żądania i na poziomie dzierżawcy.

Zalecenie: utwórz księgę przed obiecaniem wysokich kredytów SLA. Modernizacja dowodów incydentu po spornej awarii jest kosztowna i często niejednoznaczna.

Wnioski, które można zastosować

Nie pozwól, aby strony ze statusem dostawcy stały się Twoim jedynym źródłem prawdy o kredytach klientów. Zbuduj księgę dowodów na przestoje, która będzie łączyć dane o zdarzeniach dostawców, syntetyczne kanarki, objawy żądań, decyzje dotyczące trasy, okna wpływu na najemcę, zapisy rozliczeniowe i ostateczne korekty kredytu.

Minimalna użyteczna wersja jest prosta: pobranie statusu dostawcy JSON, uruchamianie małych ilości kanarków dla sprzedawanych warstw w regionie modelu, klasyfikowanie niepowodzeń żądań według przyczyny, obliczanie okien wpływu na najemcę i stosowanie wersjonowanych zasad kredytowych po uzgodnieniu. Dzięki temu partnerzy zajmujący się wsparciem, finansami, inżynierią i dalszymi działaniami mają tę samą bazę danych. Umożliwia także wyjaśnianie incydentów bez ślepego powielania stron stanu na początku źródła lub ręcznego przyznawania wartości firmy za każdym razem, gdy klient złoży skargę.

Powiązana lektura

• raporty dotyczące użytkowania i dostosowań skierowane do klienta