Eskiden Disaster Recovery, yani DR konuşurken senaryolar genelde belliydi: Database ya da bir region erişilemez olursa ne yapacağız? Son backup nerede, servisi geri getirmek ne kadar sürecek?
Ama artık kritik iş akışlarının içine yeni bir dependency girdi: AI.
Burada Cursor veya Claude sorun yaşadığında kod yazamamaktan bahsetmiyorum. O tarafı oldukça kolay handle edebiliriz. Asıl problem, deploy süreci ya da sistemin kendisi doğrudan LLM’e bağlandığında başlıyor. Çünkü o noktada LLM artık sadece işleri hızlandıran veya iyileştiren bir araç değil; database ya da storage gibi sistemin bir parçası haline geliyor.
⚠️ Üstelik bir LLM arızası sadece servis sağlayıcının API’sinin 500 dönmesi demek değil.
Servis sağlayıcı rate limit’i değiştirebilir, kullandığımız modeli kaldırabilir veya modelin yeni versiyonu farklı çıktılar üretmeye başlayabilir. Daha kötüsü, API tamamen erişilebilir olabilir ve cevaplar da ilk bakışta geçerli görünebilir; ama modelin kalitesi veya davranışı, kurduğumuz akışa artık güvenemeyeceğimiz kadar değişmiş olabilir.
Dependency de sadece model ve servis sağlayıcıyla sınırlı değil. Modelin etrafında kurduğumuz diğer katmanlar da bunun bir parçası: Agent’lar, vector database, prompt’lar ve context oluşturmak için kullandığımız veriler. Bunların hepsi aynı zincirin içinde.
Bu yüzden AI tabanlı sistemlerde DR, ikinci bir servis sağlayıcıdan alınmış bir API key bulundurmakla bitmemeli.
Alternatif model, ana modelle aynı context window’a, JSON formatına, tool calling özelliklerine veya kaliteye sahip olmayabilir. Bir modelde iyi çalışan prompt, başka bir modelde aynı sonucu vermeyebilir. Model davranışındaki küçük bir değişiklik bile Agent’ın yanlış tool’u seçmesine veya sonraki sistemin işleyemeyeceği bir çıktı üretmesine neden olabilir.
Eskiden DR senaryolarını nasıl dokümante edip test ediyorsak, bugün de LLM kullandığımız her bölüm için aynısını yapmamız gerekiyor. Bir kesinti olduğunda her parçanın nasıl davranacağını ve sistemi tekrar normale döndürmenin ne kadar süreceğini önceden bilmeliyiz.