Yapay Zekâ Sağlayıcısı Kesintisinde İş Sürekliliği

Yapay zekâ sağlayıcısı kesintisi neden ayrı bir plan gerektirir?

Klasik altyapıda yedek çoğu zaman aynı yazılımın başka bir kopyasıdır. Yapay zekâda ise yedek model aynı girdiye farklı yanıt verir. İstemlerin ayarlanması, güvenlik süzgeçlerinin yeniden sınanması ve veri koruma koşullarının ayrıca onaylanması gerekir. Hazırlık, ikinci bir adres tanımlamaktan çok davranış sürekliliğini planlamaktır.

Büyük sağlayıcılar da kesinti yaşar. OpenAI'ın yayımladığı olay raporuna göre 11 Aralık 2024'te PST saatiyle 15.16 ile 19.38 arasında tüm OpenAI hizmetleri ciddi bozulma ya da tam erişilemezlik yaşadı. Neden, filoya yeni bir telemetri hizmeti dağıtan iç bir değişiklikti. Kubernetes API sunucuları aşırı yüklendi ve büyük kümelerin çoğunda denetim düzlemi çöktü. Olay bir güvenlik ihlali değildi, ama müşteriler açısından sonuç aynıydı: yaklaşık dört saat boyunca model yoktu.

Kesinti farklı biçimlerde gelir: tam erişilemezlik, uzayan yanıt süresi, artan hata oranı, sıkılaşan hız limitleri ya da kullanımdan kaldırılan bir model. Kısmi bozulma çoğu zaman tam kesintiden daha zordur, çünkü sistem çalışıyor görünür ama kalitesi düşer.

Bağımlılık haritası nasıl çıkarılır?

Harita, hangi iş sürecinin hangi uygulamaya, hangi modele ve hangi dış bileşene dayandığını gösterir. Harita olmadan kesintinin etkisi tahmin edilemez.

Gizli bağımlılıklara bakın. Ekipler ana modeli bilir, ama gömme modelini, içerik denetim hizmetini, kimlik sağlayıcısını ve ağ geçidinin kendisini unutur. Kesinti bu küçük bileşenlerden de başlayabilir.

Yedek sağlayıcı ve model nasıl hazırlanır?

Microsoft'un Foundry yüksek erişilebilirlik belgesi, platformun kendiliğinden otomatik yük devretme ya da felaket kurtarma sağlamadığını açıkça yazar. Global Standard ve Data Zone dağıtımları çıkarımı izin verilen kapsam içinde yönlendirebilir, ama bu, uygulama düzeyinde bölgeler arası geçişin yerini tutmaz. Önerilen düzen, farklı bölgelerde iki kaynak ve önlerinde yük dengeleme ile devre kesici desenini destekleyen bir üretken yapay zekâ ağ geçididir. Ağ geçidinin kendisi de bölgesel kesintiye karşı birden fazla bölgede çalıştırılmalıdır.

Aynı mantık sağlayıcılar arası yedek için de geçerlidir. Ağ geçidi modelleri soyutlar, uygulama kodu değişmeden geçiş yapılır. Ancak soyutlama davranış farkını ortadan kaldırmaz.

1. Ağ geçidinde sağlayıcı ve bölge geçişini yapılandırmayla yapılabilir kılın.
2. Her yedek model için istemleri ve çıktı biçimini test edin.
3. Güvenlik ve kalite değerlendirme kümesini yedek modelde de çalıştırın.
4. Yedeğin veri işleme bölgesini ve sözleşme koşullarını ana sağlayıcı kadar titizlikle onaylayın.
5. Geçiş kararını kimin, hangi ölçütle vereceğini yazın.
6. Yedeğe düzenli olarak gerçek trafik gönderin, böylece çalıştığını bilirsiniz.

Dördüncü adım sık atlanır. Kesinti sırasında kişisel veri, sözleşmesi ve bölgesi onaylanmamış bir hizmete akabilir. Ağ geçidi mimarisinin ayrıntıları için LLM gateway yazısına, sağlayıcı sözleşmesinde aranacak maddeler için yapay zekâ sözleşme maddeleri yazısına bakın.

Yeniden deneme ve devre kesici nasıl ayarlanır?

Hatalar aynı değildir ve aynı biçimde ele alınmamalıdır. Anthropic API belgesine göre 429 hız limitine ya da kullanım kademesinin aylık harcama tavanına ulaşıldığını, 500 sağlayıcı içi beklenmeyen bir hatayı, 529 ise API'nin genel yük nedeniyle geçici olarak aşırı yüklendiğini gösterir. Resmî SDK geçici hataları üstel bekleme ile varsayılan olarak iki kez yeniden dener ve varsa retry-after başlığına uyar. Harcama tavanından gelen ve retry-after taşımayan 429 ise erişim açılana kadar başarısız olmaya devam eder. Organizasyon ya da çalışma alanı için kendi koyduğunuz harcama limitine ulaşıldığında ise API 400 invalid_request_error döndürür. Bu hata da yeniden denenmez.

• Geçici hatalarda üstel bekleme ve rastgele sapma (jitter) kullanın.
• retry-after başlığına uyun.
• Harcama tavanı, harcama limiti ve yetki hatalarını yeniden denemeyin, uyarıya çevirin.
• Toplam deneme süresine üst sınır koyun, kullanıcıyı sonsuz beklemede bırakmayın.

Devre kesici, art arda hata alındığında çağrıları bir süre durdurur, yedeğe yönlendirir ve belirli aralıklarla deneme isteğiyle ana hizmetin dönüp dönmediğini yoklar. Kesintide her istemcinin art arda yeniden denemesi sağlayıcıyı daha da yükler ve token maliyetini artırır. Devre kesici bu yükü keser.

Bozulmuş çalışma düzeni nasıl tasarlanır?

Bozulmuş çalışma düzeni, hizmetin sınırlı ama güvenli bir yetenekle sürmesidir. Basamaklı bir örnek:

1. Sistem aynı sağlayıcının başka bölgesine ya da yedek modele geçer.
2. Asistan yalnız onaylı yanıtlar ve arama sonuçlarıyla cevap verir.
3. Karmaşık talepler insan temsilciye ya da kuyruğa yönlendirilir.
4. Yapay zekâ özelliği kapanır ve klasik arayüze dönülür.

Kritik ilke şudur: kesinti güvenlik kontrollerini gevşetmemelidir. İçerik süzgeci ya da denetim modeli çalışmıyorsa riskli işlemler durdurulur. "Süzgeç yanıt vermiyor, o halde geçirelim" mantığı kurulmaz. Ajanlı işlemlerde yetki kademeli daraltılır. Bu kademelerin tetikleyici ve yetki tablosu ajan durdurma merdiveni yazısında yer alır.

Kullanıcıya ne olduğunu sade bir dille söyleyin: "Şu an otomatik yanıt veremiyoruz, talebiniz alındı." Hata mesajında sağlayıcı adı ya da iç yapı bilgisi vermeyin.

Önbellek ve kuyruk nasıl kullanılır?

Önbellek, sık sorulan sorulara verilmiş onaylı yanıtları saklar ve kesintide sunar. Riski, yanlış kişiye ait ya da güncelliğini yitirmiş yanıt vermektir. Kişisel veri içeren yanıtları ortak önbelleğe koymayın, her kayda geçerlilik süresi verin. Benzer sorulara aynı yanıtı döndüren anlamsal önbelleklerin kötüye kullanımı için semantik önbellek zehirlenmesi yazısına bakın.

Kuyruk, işlenemeyen talepleri biriktirir ve hizmet dönünce işler. Kuyruğa üst sınır, öncelik sırası ve zaman aşımı koyun. Hizmet döndüğünde birikmiş işleri kademeli bırakın, yoksa ani yük yeni bir kesinti yaratır. Ajan işlemlerinde kuyrukta bekleyen eski bir komut sonradan çalıştığında yanlış sonuç doğurabilir. Bu yüzden kuyruktaki işlemleri yeniden doğrulayın, gerekiyorsa insan onayına gönderin.

Hizmet düzeyi sözleşmesinde neye bakılmalı?

Sözleşme riski devreder ama ortadan kaldırmaz. Tazmin çoğu zaman hizmet kredisiyle sınırlıdır ve gerçek iş kaybını karşılamaz. İncelenecek maddeler:

• Erişilebilirlik taahhüdü hangi bileşeni kapsıyor: model, API, kimlik doğrulama, konsol?
• Ölçüm yöntemi nedir ve ölçümü kim yapıyor?
• Planlı ve bildirimsiz bakım nasıl sayılıyor?
• Kesinti bildirimi hangi kanaldan, ne kadar sürede geliyor?
• Tazminin biçimi ve üst sınırı nedir?
• Model kullanımdan kaldırma ne kadar önceden bildiriliyor?
• Çıkışta veri iadesi ve silme hakları neler?

Sağlayıcı yüksek bir erişilebilirlik vaat etse bile kritik süreciniz bu orana dayanamıyorsa, sözleşme ötesi önlem almak zorundasınız. Kendi barındırma seçeneği sağlayıcı bağımlılığını azaltır ama donanım, kapasite planlaması, yama ve nöbet yükünü kuruma taşır. Birçok kurum için dengeli bir seçenek, kritik işlevlerde açık ağırlıklı bir modeli yedek olarak hazır tutmak ve ana yükü yönetilen hizmette bırakmaktır.

Tatbikat ve izleme nasıl yürütülür?

Denenmemiş plan çalışıp çalışmadığını bilemez. Masa başı bir senaryoyla başlayın: ana sağlayıcı dört saat yanıt vermiyor, kim neyi ne zaman yapıyor? Senaryo kurgusu için yapay zekâ olay tatbikatı yazısı kullanılabilir. Ardından test ortamında ana sağlayıcıya erişimi gerçekten kapatın ve devre kesicinin, yedeğin ve kullanıcı mesajlarının nasıl davrandığını gözleyin.

İzlenecek sinyaller şunlardır: yanıt süresi, hata türlerine göre hata oranı, zaman aşımı sayısı, yedeğe geçiş sayısı, kuyruk uzunluğu ve maliyet. Sağlayıcının durum sayfasını izleyin ama yalnız ona güvenmeyin. Kendi ölçümünüz sorunu çoğu zaman daha erken gösterir.

Sık Sorulan Sorular

Yedek model sağlayıcısı her zaman gerekli mi?

Hayır, ama kesintiyi kaldıramayan işlevler için gereklidir. Önce hangi özelliklerin durması kabul edilemez, hangilerinin ertelenebilir olduğunu belirleyin. Ertelenebilir işlevlerde bozulmuş çalışma düzeni ve kuyruk yeterli olabilir. Yedek kullanıyorsanız istemleri, güvenlik süzgeçlerini ve veri koruma koşullarını yedek modelde önceden test edin. Denenmemiş yedek, kesinti anında işe yaramaz.

Bozulmuş çalışma düzeni ne demektir?

Hizmetin tamamen durmak yerine sınırlı yetenekle sürmesidir. Asistan yalnız onaylı hazır yanıtlar verir, karmaşık talepleri insana devreder ya da işleri kuyruğa alır. Bu düzende güvenlik kontrolleri gevşemez. Denetim modeli ya da içerik süzgeci çalışmıyorsa riskli işlemler durdurulur, sistem güvenli tarafta kalacak biçimde kapanır.

429 ve 529 hataları aynı şekilde mi ele alınır?

Hayır. Anthropic API'sinde 429 hız limitini ya da kullanım kademesinin aylık harcama tavanını, 529 ise API'nin genel yük nedeniyle geçici olarak aşırı yüklendiğini gösterir. Hız limitinde retry-after başlığına uyarak beklemek doğrudur. Retry-after taşımayan tavan kaynaklı 429 ve kendi koyduğunuz harcama limitinden gelen 400 ise yeniden denenmez, uyarıya çevrilir.

Hizmet düzeyi sözleşmesinde nelere bakılmalı?

Taahhüdün hangi bileşeni kapsadığına, nasıl ölçüldüğüne, planlı bakımın nasıl sayıldığına, kesinti bildiriminin hangi kanaldan geldiğine ve tazminin biçimi ile üst sınırına bakın. Model kullanımdan kaldırma bildirimi ve çıkışta veri iadesi de sözleşmede yer almalıdır. Tazmin çoğu zaman hizmet kredisiyle sınırlıdır ve gerçek iş kaybını karşılamaz. Sözleşme riski devreder, ortadan kaldırmaz.

Kaynaklar

• OpenAI Status: 11 Aralık 2024 olay raporu
• Microsoft Learn: High availability and resiliency for Microsoft Foundry
• Microsoft Learn: Understanding deployment types in Microsoft Foundry Models
• Claude Platform Docs: API errors
• Azure Architecture Center: Circuit Breaker pattern

İlgili Yazılar

• LLM Gateway Nedir? LLM Firewall ve Runtime Protection ile Farkı
• Yapay Zekâ Sözleşme Maddeleri: Güvenlik Kontrol Listesi
• Yapay Zekâ Olay Tatbikatı: Masa Başı Senaryolar
• LLM Güvenliğinde Build vs Buy: Kendi Guardrail'ini Yazmak mı, Hazır Çözüm mü? Gerçek mühendislik verisiyle 2026 karar rehberi