Failover, altyapıda tartışmasız iyi bir şey. Birinci aday cevap vermezse ikinciye geçersin, kullanıcı kesinti görmez. Aday zincirini uzatmak dayanıklılığı artırır.
Uyumluluk yolunda bu mantık tersine dönüyor.
Sorunun şekli
Bir kural yazdığınızı düşünün: TCKN tespit edilen istekler yalnızca Türkiye bölgesindeki modele gitsin. Kuralı yazdınız, uygulamaya aldınız, denetim raporunuzda bölge dağılımı temiz görünüyor.
Sonra bir gün birinci aday 30 saniye boyunca hata veriyor.
Yedekleme zinciri açıksa ne olur? İstek ikinci adaya düşer. İkinci aday yurt dışındaki bir sağlayıcıysa, o 30 saniye boyunca regüle veri bölge dışına çıkar. Kimse fark etmez, çünkü sistem tam olarak tasarlandığı gibi davranmıştır: birinci aday başarısız oldu, ikinciye geçildi, kullanıcı kesinti görmedi.
Denetim raporunda bu 30 saniye bir satır olarak görünür. O satırı açıklamak zorundasınız.
Sessizlik, asıl problem
Bu senaryoda kötü olan şey verinin dışarı çıkması değil — kötü olan, dışarı çıkmasının başarı olarak kaydedilmesi. Failover mekanizması bir hata durumunu ele aldı ve çözdü. Log'larda hata yok. Uyarı yok. Metriklerde bir sıçrama bile yok, çünkü istek başarıyla tamamlandı.
Uyumluluk ihlalleri en pahalı hâllerini tam olarak burada alıyor: sistemin normal çalışması olarak görünen ihlaller.
Modelion'da nasıl çözülüyor
Yerleşim kısıtı doğuran bir kural, aynı zamanda yedekleme zincirini kapatıyor:
then:
effect: route
route:
candidates: [gpt-4o-mini]
fallbackToOriginal: false # ← bu satır
fallbackToOriginal: false şu demek: bu kural kazandığında aday listesi kuralın verdiği listeden ibarettir. Combo'da tanımlı başka adaylar varsa değerlendirilmez.
Aday kalmazsa ne olur? Gateway 503 döner.
"Servis durursa ne olacak" sorusu
Bu, kamu ve fintech görüşmelerinde her seferinde çıkan soru. Cevabı şu: evet, servis durur. Ve bu bilinçli bir tercih.
Fail-open davranışı — yani hata durumunda izin vermek — uyumluluk sınırını hiçbir koşulda genişletmemeli. Bir kesinti pahalıdır, ölçülebilir ve açıklanabilir. Yanlış yargı alanına gitmiş regüle veri ise pahalı olmakla kalmıyor; ne zaman, kaç istek, hangi veri sorularının cevabını da vermeniz gerekiyor.
Bu riski azaltmanın doğru yolu yedekleme zincirini açmak değil — bölge içinde birden fazla aday tanımlamak. Aynı bölgede iki farklı model, ya da kendi vLLM kümeniz artı barındırılan bir model. Zincir yine var, ama zincirin tamamı uyumluluk sınırının içinde.
Politika bunu neden bilebiliyor
Circuit breaker'ın pod-yerel olduğu ve routing katmanının içinde yaşadığı bir mimaride, politika sağlayıcı sağlığını göremez. Görmediği için de "bu sağlayıcı bozuk ama bu istek KVKK kapsamında, yine de yurt dışına gitmesin" diyemez.
Sağlık bilgisi input.runtime üzerinden politikaya enjekte edildiğinde bu mümkün oluyor. Politika artık iki şeyi birlikte biliyor: sağlayıcının durumu ve isteğin regülasyon bağlamı. Kararı ikisine bakarak veriyor.
Bir ayrıntı önemli: sağlayıcıların hepsi bozuksa baypas yapılmıyor. Fail-open, kısıtı genişletmenin gerekçesi olamaz.