Müşteriye SLA Kredisi Sözü Vermeden Önce Bir Yapay Zeka API Kesinti Kanıt Defteri Oluşturun

Bir yukarı akış model sağlayıcısında bir olay yaşandığında, müşterileriniz yalnızca sağlayıcının kapalı olup olmadığını sormaz. İsteklerinin başarısız olup olmadığını, hangi anahtarların ve modellerin etkilendiğini, kesintinin SLA'nıza dahil edilip edilmediğini ve hangi krediyi almaları gerektiğini sorarlar. Sağlayıcı durum sayfası yardımcı olur ancak kiracıya özgü bu soruları tek başına yanıtlayamaz.

Bir AI API ağ geçidi, kesinti kanıtlarını birinci sınıf bir defter gibi ele almalıdır: sağlayıcı sinyalleri, sentetik araştırma sonuçları, istek düzeyindeki belirtiler, kiracı etki pencereleri, ilişkilendirme kararları ve kredi ayarlamaları. Amaç daha güzel bir olay zaman çizelgesi oluşturmak değil. Amaç, müşteriye yönelik kesinti kararlarını açıklanabilir, tekrarlanabilir ve hem aşırı kredilendirmeye hem de yetersiz kredilendirmeye karşı dayanıklı hale getirmektir.

Sağlayıcı Durum Sayfalarının Neleri Kanıtlayabileceğini ve Kanıtlayamayacağını

Gerçek: Atlassian Durum Sayfası özet, durum, bileşenler, çözülmemiş olaylar, olaylar ve planlı bakım için genel API uç noktalarını açığa çıkarır. OpenAI ve Anthropic, bileşen ve olay verilerini içeren Durum Sayfası stili JSON uç noktalarını yayınlar. Google Bulut, Hizmet Durumu API'lerini ve kontrol panellerini belgelendirir ve ayrıca feed'ler aracılığıyla kamu sağlığı bilgilerini açığa çıkarır. Bulut sağlayıcıları ayrıca bazı etkinlikler için olay sonrası incelemeler de yayınlar.

Bu yayınlar yararlı girdilerdir. Size bir sağlayıcının bir olayı kabul ettiğini, hangi geniş bileşenin etkilendiğini ve olayın soruşturma, tespit etme, izleme, çözümleme veya ölüm sonrası gibi durumlardan ne zaman geçtiğini söyleyebilirler. AI API bayi işlemleri programı için müşteri kredilerine karar vermek için bunlar yeterli değildir.

Durum sayfaları genellikle gerçek müşteri etkisinde gecikme yaşıyor. Model takma adlarınız, sağlayıcı hesaplarınız, bölgeleriniz, dağıtımlarınız, hizmet katmanlarınız veya kiracı izin verilenler listelerinizle net bir şekilde eşlemeden sohbet, yanıtlar, yerleştirmeler, resimler veya dosyalar gibi geniş bir bileşeni tanımlayabilirler. Ayrıca belirli bir müşterinin isteklerinin yukarı akış bozulması, ağ geçidi kısıtlaması, tükenen bütçe, geçersiz giriş, istemci tarafı zaman aşımı davranışı veya yerel ağ sorunu nedeniyle başarısız olup olmadığını söyleyemezler.

Öneri: Sağlayıcı durumunu kredi tetikleyicisi olarak değil, tek bir kanıt akışı olarak kullanın. Krediler, kiracı etkisi kanıtlarına ve istek günlükleri, kullanım anlaşması ve sağlayıcı olay güncellemeleri mevcut olduktan sonra mutabakat geçişine bağlı olmalıdır.

İhtiyacınız Olan Defter Kaydı

Hem sağlayıcı çapındaki olayları hem de kiracıya özel etkiyi temsil edebilecek dayanıklı bir kesinti kaydıyla başlayın. Daha sonraki sınıflandırma değişikliklerinin orijinal tespit izini silmemesi için kaydın yalnızca eklemeli veya sürümlü olması gerekir.

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

Sağlayıcı olay süresi ve kiracı etki süresi ayrı alanlardır. Bir sağlayıcı 11:30 ile 13:00 arasında geniş bir olayı bildirebilir, ancak bir kiracı, izin verilen modellerde başka bir sağlayıcı kullanıldığı için bundan etkilenmemiş olabilir. Başka bir kiracı, yönlendirmenin onu bir geri dönüş modeline taşıdığı için yalnızca 11:47 ile 12:18 arasında hatalar görmüş olabilir. Üçüncüsü yüksek gecikme yaşamış olabilir ancak hiçbir başarısız istek yaşanmamıştır. Krediler paraya dönüştüğünde bu farklılıklar önemlidir.

Üç Kanıt Akışını Besleyin

1. Sağlayıcı Durumu API'leri

Sağlayıcı durum verilerini belirli bir programa göre ve olaylar sırasında isteğe bağlı olarak toplayın. Ham yük karmasını, alma zamanını, sağlayıcı bileşen tanımlayıcılarını, olay durumunu, olay URL'sini veya sağlayıcı referansını ve herhangi bir metin özetini saklayın. Eski durumların üzerine yazmayın. Bir olay araştırma aşamasından tespit aşamasına ve ardından izlemeye geçerse her geçişi koruyun.

Sağlayıcı bileşenlerini kendi ağ geçidi boyutlarınıza göre normalleştirin:

• sağlayıcı: OpenAI, Anthropic, Azure OpenAI, Google veya başka bir yukarı akış
• yüzey: sohbet, yanıtlar, yerleştirmeler, resimler, toplu iş, ses, gerçek zamanlı, dosyalar, denetleme
• model veya dağıtım: yukarı akış modeli, dahili takma ad veya bulut dağıtım adı
• bölge: uygun olduğu yerde
• hesap veya kimlik bilgisi havuzu: paylaşılan hesap, kiracıya bağlı hesap veya BYOK kimlik bilgisi
• hizmet katmanı: standart, öncelikli, temel hazırlığı yapılan, toplu veya dahili katman adı

Ödünleşme: Sağlayıcı durumu alımı ucuzdur ve onay açısından yetkilidir, ancak geç, kapsamlı veya eksik olabilir. Şüphe uyandırmalı ve müşteri iletişimine yardımcı olmalıdır ancak otomatik olarak kredi oluşturmamalıdır.

2. Sentetik Kanaryalar

Sentetik kanaryalar, üretim trafiğiyle aynı ağ geçidi yolu üzerinden gönderilen küçük, kontrollü isteklerdir. Olası her sağlayıcı özelliğini değil, sattığınız kombinasyonları kapsamalıdırlar. Örneğin bir bayi, ücretli planların kullandığı her sağlayıcı, yüzey, model katmanı ve bölge için kanaryalar çalıştırabilir.

Her kanarya sonucu şunları içermelidir:

• canary_id ve sürüm
'i planla
• sağlayıcı, yüzey, model, bölge, kimlik bilgisi havuzu ve rota profili
• başlangıç zamanı, ilk bayt zamanı, tamamlanma süresi ve zaman aşımı eşiği
• HTTP durumu, sağlayıcı hata kodu, ağ geçidi hata kodu ve yeniden deneme sayısı
• gecikme yüzdelik dilimi grubu, yalnızca başarılı veya başarısız değil
• istek korelasyon kimliği ve düzeltilmiş yanıt meta verileri

Kanaryalar ham müşteri istemlerinden kaçınmalıdır. Sabit, hassas olmayan istemler kullanın ve yanıt doğrulamayı basit tutun. Bir kanarya uç noktanın istekleri kabul ettiğini, akışların tamamlandığını ve gecikmenin belirli bir eşik dahilinde kaldığını doğrulayabilir. Kesinti kredisi kararları için model kalitesini değerlendirmeye gerek yoktur.

Ödünleşme: kanaryalar, müşteriler bir sorun bildirmeden önce bağımsız kanıtlar sunar. Ayrıca maliyet eklerler ve sağlayıcı stresi sırasında kota tüketebilirler. Etkin olaylar sırasında kanaryaları kısın ve yukarı akış yüküne katkıda bulunan agresif yeniden deneme davranışından kaçının.

3. Gerçek İstek Belirtileri

İstek düzeyindeki kanıtlar, kiracı etkisine ilişkin en güçlü kaynaktır. Her ağ geçidi isteğinde halihazırda kiracı, anahtar, kullanıcı veya son kullanıcı tanımlayıcısı, model takma adı, sağlayıcı rotası, bölge, durum, gecikme, belirteç kullanımı ve faturalama durumu bulunmalıdır. Kesinti raporlaması için, yukarı yöndeki belirtileri müşteri ve ağ geçidi nedenlerinden ayıran sınıflandırma alanları ekleyin.

Yararlı belirti sınıfları şunları içerir:

• provider_5xx: yukarı akış HTTP 5XX veya eşdeğer sağlayıcı sunucusu hatası
• provider_timeout: ağ geçidi zaman aşımından önce sağlayıcıdan yanıt alınamıyor
• provider_429_spike: yukarı akış hız sınırı normal taban çizgisinin üzerinde
• stream_abort_upstream: sağlayıcı akışı beklenmedik bir şekilde sona erdi
• latency_degraded: tamamlanan istek politika eşiğini aştı
• gateway_throttle: ağ geçidi, kiracı sınırı veya adalet politikası nedeniyle isteği reddetti
• customer_error: geçersiz istek, desteklenmeyen model, hatalı kimlik doğrulama veya hatalı biçimlendirilmiş veri yükü
• budget_exhausted: kiracı harcaması veya kredi limiti gönderimi engellendi

Normalde yalnızca ilk beşi kesinti belirtisi olarak sayılmalıdır, o zaman bile yalnızca ilişkilendirmeden sonra. Yukarı akış 429'lardaki ani artış bir sağlayıcı sorunu olabilir, ancak aynı zamanda bir kiracının ayrılmış verimi aşmasından da kaynaklanabilir. Zaman aşımı, sağlayıcının bozulmasından kaynaklanabileceği gibi istemci bağlantısının kesilmesinden veya ağ geçidi zaman aşımınızdan daha kısa olan uygulama düzeyindeki bir zaman aşımından da kaynaklanabilir.

Bu, ekipler için çok modelli API ağ geçidinin disiplinli etkinlik modellemesine ihtiyaç duyduğu yerdir. Rota kararı, yeniden deneme girişimi, geri dönüş sonucu, son yanıt ve faturalandırma anlaşması, korelasyon kimliğiyle birleştirilebilir olmalıdır.

Sağlayıcı Olay Pencerelerini Kiracı Etki Pencerelerinden Ayırın

Sağlayıcının geniş olay süresi için müşterilere kredi vermeyin. Politikanız kapsamında olayın uygun trafiği etkileyen kısmı için onlara kredi verin.

En az beş pencere işaretçisi kullanın:

• tespit süresi: sisteminizin anormal davranışı ilk algıladığı zaman
• ilk etkilenen istek: kesinti belirtisi olan ilk uygun kiracı isteği
• sağlayıcı onay zamanı: yukarı akış sağlayıcının olayı yayınladığı veya onayladığı zaman
• hafifletme süresi: ağ geçidinizin geri dönüş, trafik şekillendirme, rotayı devre dışı bırakma veya başka bir hafifletme uyguladığı zaman
• kurtarma onayı: kanaryalar ve gerçek trafik eşik değerlerin altına döndüğünde

Kiracı etki penceresi kiracı başına, anahtar başına, model takma adı başına ve hizmet katmanı başına hesaplanabilir. Örneğin:

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

Bu ayırma aynı zamanda sizi aşırı kredi vermekten de korur. Sağlayıcı olayı sırasında kiracının trafiği yoksa, kredi olmayabilir. Kiracı yalnızca etkilenmeyen modellere yönlendirilirse kredi verilmeyebilir. Tüm başarısızlıklar geçersiz istekler veya bütçe reddiyse olay raporunda sağlayıcıyı suçlamadan bu durum belirtilmelidir.

Kredi Politikasını Olaydan Önce Tanımlayın

Kredi politikası, baskı altında doğaçlama bir destek kararı değil, tablo veya sürümlü bir yapılandırma olmalıdır. Politikanın tamamen otomatik olması gerekmez ancak uygunluk ve onay kurallarını açıkça belirtmelidir.

Şu alanları ekleyin:

• uygun belirtiler: sağlayıcı 5XX, yukarı akış zaman aşımı, akışın iptal edilmesi, ciddi gecikme bozulması veya diğer sınıflar
• minimum süre: örneğin, art arda beş dakika veya etkilenen isteklerin eşik sayısı
• gecikme eşiği: sabit eşik, yüzdelik taban çizgisi veya hizmet katmanına özel hedef
• hariç tutulan nedenler: müşteri hataları, bütçe tükenmesi, kiracı kısıtlaması, hatalı biçimlendirilmiş istekler, desteklenmeyen model, istemci bağlantısının kesilmesi
• yeniden deneme işlemi: başarılı geri dönüş isteklerinin başarısız, bozulmuş veya hafifletilmiş olarak sayılıp sayılmayacağı
• kredi formülü: etkilenen kullanım yüzdesi, sabit cüzdan düzenlemesi, plana dayalı HDS kredisi veya manuel inceleme
• onay yetkisi: bir limitin altında otomatik, limitin üzerinde operasyon onayı, büyük kiracılar için finans onayı
• sağlayıcı kredisi yönetimi: müşteri kredilerinden ayrı olarak aktarılır, paylaşılır, saklanır veya işlenir
• kanıt saklama: olay, talep, kanarya ve kredi kayıtlarının ne kadar süreyle sorgulanabilir kalacağı

Öneri: Her geçici ve nihai kredi kararında kredi politikası sürümünü saklayın. Politikayı daha sonra revize ederseniz, geçmiş kararlarda o sırada hangi kuralların uygulandığı hala açıklanmalıdır.

Son Kredilerden Önce Uzlaştırma

Bir olay sırasında müşterilerin durum güncellemelerine hızlı bir şekilde ihtiyacı vardır. Kredi kararları geçici olabilir. Nihai kredi geçişi, günlükler tamamlandıktan, gecikmeli kullanım olayları çözüldükten, yeniden denemeler ve yedekler sınıflandırıldıktan ve sağlayıcının olay sonrası bilgileri incelendikten sonra gerçekleştirilmelidir.

Pratik bir mutabakat iş akışı şuna benzer:

1. Sağlayıcı durumu, kanarya uyarıları veya istek belirti eşiklerinden olay kaydını oluşturun veya güncelleyin.
2. Yeni yönlendirme kararlarının mümkün olduğu yerde bundan kaçınabilmesi için etkilenen rota profilini dondurun veya bozulmuş olarak işaretleyin.
3. İstek günlüklerinden ve canary zaman çizelgelerinden geçici kiracı etki pencereleri oluşturun.
4. Sınıflandırma kurallarını kullanarak müşteri tarafı ve ağ geçidi tarafı nedenlerini hariç tutun.
5. Etkilenen isteklerin belirlenen maliyet ve müşteri ücret kayıtlarına bağlanması için kullanım ve faturalandırma kayıtlarını birleştirin.
6. Kredi politikası sürümünü uygulayın ve geçici kredi satırları oluşturun.
7. Belirsiz durumları, özellikle de kısmi gecikme azalmasını ve yüksek değerli kiracıları inceleyin.
8. Son kredi ayarlamalarını, olay kaydına giden bağlantılarla birlikte cüzdan veya fatura defterine gönderin.

Bu, kredileri destek bildiriminde manuel notlar olarak bırakmak yerine kesinti yönetimini birleşik AI API faturalandırma ile ilişkilendirir. Düzenleme denetlenebilir olmalıdır: Kim onayladı, hangi politika uygulandı, hangi isteklerin uygun olduğu ve nihai mi yoksa geri alınabilir mi olduğu.

Müşteri ve İş Ortağının API Görünümünü Açığa Çıkarın

Müşterilerin dahili izleme deponuzun tamamına değil, net bir olay açıklamasına ihtiyacı vardır. API numaranızı yeniden satan veya yerleştiren alt platformların da olay durumunu kendi portallarında göstermesi gerekebilir. İş Ortağı API uç noktası, kiracı kapsamlı bir olay görünümünü açığa çıkarabilir.

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

Bu görünümün kapsamını koruyun. Sentetik kanarya kimliklerini, istek korelasyon kimliklerini, etkilenen modelleri, etkilenen anahtarları ve son kredi durumunu ekleyin. Varsayılan olarak ham istemlerden ve tam yanıt gövdelerinden kaçının. Müşterinin daha derin kanıtlara ihtiyacı varsa düzenleme ve yetkilendirme kontrolleriyle kontrollü bir dışa aktarma sağlayın.

Müşteri Olay Raporu Şablonu

Defter tamamlandıysa faydalı bir müşteri raporu kısa olabilir. Doğrulanmış gerçekleri operasyonel yorumdan ayırmalıdır.

Gerçekler

• Sağlayıcı ve etkilenen yüzey
• Kiracı etki aralığı
• Uygun, başarısız olan, zaman aşımına uğrayan, iptal edilen veya kalitesi düşürülen isteklerin sayısı
• Etkilenen model takma adları, bölgeler ve müşteri anahtarları
• Azaltma uygulandı ve kurtarma onay süresi

Ağ Geçidi Değerlendirmesi

• Belirtilerin sağlayıcıyla mı, ağ geçidiyle mi, kiracı yapılandırmasıyla mı yoksa müşteri isteği davranışıyla mı ilişkilendirildiği
• Yedek yönlendirmenin etkiyi azaltıp azaltmadığı
• Olayın kredi politikası eşiğini karşılayıp karşılamadığı
• Kredinin geçici mi, onaylı mı, uygulanmış mı yoksa reddedilmiş mi olduğu

Sınırlar

• Sağlayıcı olay ayrıntıları ölüm sonrası yayınlandıktan sonra değişebilir
• Gecikme azalması eşikleri evrensel değil, politikayla tanımlanır
• Müşteri hataları veya bütçe reddi nedeniyle hariç tutulan istekler, sağlayıcı kesintisi etkisi olarak sayılmaz

Tahminler ve Tasarım Bahisleri

Tahmin: müşteriye yönelik kesinti raporlaması, özellikle AI özelliklerini kendi markaları altında sunan SaaS satıcıları için, AI API bayi platformlarının normal bir özelliği haline gelecektir. Yapay zeka iş yükleri denemeden üretime geçtikçe müşteriler, bulut altyapısı tedarikçilerinden aldıkları olay sorumluluğunun aynısını bekleyecek.

Tahmin: sağlayıcı durum sayfaları gerekli ancak yetersiz kalacak. Daha fazla olay kısmi bozulmayı içerecektir: gecikme artışları, akış kesintileri, bölgesel kapasite sorunları, kalite gerilemeleri, araç çağrısı hataları veya hesaba özgü kota davranışı. Bu durumlar, istek düzeyinde ve kiracı düzeyinde kanıt gerektirir.

Öneri: Güçlü HDS kredileri vaat etmeden önce defteri oluşturun. Tartışmalı bir kesintiden sonra olay kanıtlarını yenilemek pahalıdır ve çoğu zaman sonuçsuz kalır.

Uygulanabilir Sonuç

Sağlayıcı durum sayfalarının müşteri kredileri için tek gerçek kaynağınız olmasına izin vermeyin. Sağlayıcı olay akışlarını, sentetik kanaryaları, istek belirtilerini, rota kararlarını, kiracı etki pencerelerini, faturalandırma kayıtlarını ve son kredi ayarlamalarını birleştiren bir kesinti kanıt defteri oluşturun.

Minimum kullanışlı sürüm basittir: alma sağlayıcı durumu JSON, satılan model bölgesi katmanları için düşük hacimli kanaryalar çalıştırın, istek hatalarını nedene göre sınıflandırın, kiracı etki pencerelerini hesaplayın ve mutabakat sonrasında sürümlendirilmiş bir kredi politikası uygulayın. Bu, destek, finans, mühendislik ve alt ortaklara aynı kanıt tabanını sağlar. Ayrıca, yukarı akış durum sayfalarını körü körüne yansıtmadan veya bir müşteri şikayet ettiğinde manuel iyi niyet kredileri vermeden olayları açıklamanıza da olanak tanır.

İlgili okuma

• müşteriye yönelik kullanım ve düzenleme raporları