AI agent hosting neden “sadece sunucu” değildir?

AI agent, bot, otomasyon işçisi veya LLM destekli arka plan servisi çalıştıran ekipler için hosting ihtiyacı klasik web sitesi barındırmadan farklıdır. Burada trafik yalnızca ziyaretçiden gelmez; webhook, zamanlanmış görev, API çağrısı, kuyruk, dosya işleme ve üçüncü parti servis limitleri de altyapıyı etkiler. Bu yüzden doğru soru “kaç CPU/RAM alalım?” değil, “iş yükünü nasıl izleyelim, güvene alalım ve maliyeti nasıl kontrol edelim?” olmalıdır.

Narweb’in AI Agent Hosting yaklaşımında amaç; agent süreçlerini production ortamına uygun çalıştırmak, beklenmeyen kaynak tüketimini fark etmek ve güvenlik sınırlarını baştan tanımlamaktır.

İzleme: agent çalışıyor mu, doğru mu çalışıyor?

İlk izleme seviyesi uptime değildir. Bir agent servisi ayakta görünebilir ama kuyruk tüketmiyor, webhook yanıtlamıyor veya sürekli retry döngüsüne giriyor olabilir. Bu nedenle uygulama sağlık kontrolü, worker sayısı, kuyruk bekleme süresi, hata oranı, cron tetiklenme zamanı ve dış API yanıt süreleri ayrı ayrı takip edilmelidir.

Özellikle küçük ekiplerde en pratik model; sistem metrikleri, uygulama logları ve iş mantığına ait sayaçları tek bakım panosunda toplamaktır. “Son başarılı görev zamanı”, “başarısız görev oranı” ve “işlenen kayıt sayısı” gibi metrikler CPU grafiğinden daha erken uyarı verir.

Güvenlik: erişim anahtarlarını ve agent yetkilerini ayırın

AI agent servisleri çoğu zaman veritabanı, dosya deposu, CRM, e-posta veya harici API anahtarlarına erişir. Tek bir ortam değişkeni sızıntısı bütün sistemi riske atmamalıdır. Production ortamında ayrı kullanıcılar, minimum yetki, IP/port kısıtları, düzenli secret rotasyonu ve loglarda hassas veri maskeleme temel standart olmalıdır.

Agent’ların internetten gelen webhookları işlediği senaryolarda rate limit, imza doğrulama, request boyutu sınırı ve hata durumunda güvenli retry stratejisi gerekir. Aksi halde düşük bütçeli bir otomasyon, saldırı veya hatalı entegrasyon yüzünden gereksiz maliyet üretebilir.

Maliyet kontrolü: kaynak, token ve dış servis tüketimini birlikte düşünün

AI agent maliyeti yalnızca VDS veya cloud sunucu faturası değildir. CPU/RAM, disk, outbound trafik, model/API tüketimi, log saklama, object storage, backup ve monitoring maliyetleri beraber hesaplanmalıdır. Özellikle sürekli retry yapan işler hem altyapı hem API tarafında görünmeyen maliyet doğurur.

B2B ekipleri için iyi bir başlangıç modeli; görev başına maliyet, günlük maksimum çalışma limiti, kuyruk büyüme alarmı ve beklenmeyen trafik için manuel durdurma prosedürüdür. Böylece sistem büyüdükçe hangi işi optimize etmek gerektiği görünür olur.

Production checklist

• Health-check endpoint’i ve son başarılı görev zamanı takip ediliyor mu?
• Worker, cron, queue ve webhook logları ayrı etiketleniyor mu?
• Secret’lar minimum yetkiyle ve ayrı kullanıcılarla tanımlandı mı?
• Backup, restore ve object storage retention planı test edildi mi?
• Beklenmeyen maliyet artışı için alarm ve durdurma prosedürü var mı?

Narweb ile nasıl başlanır?

AI agent, otomasyon veya bot iş yükünüzü test ortamından production’a taşımadan önce mimari, izleme, yedek ve güvenlik sınırlarını birlikte netleştirmek için AI Agent Hosting sayfasını inceleyebilir veya Narweb ile iletişime geçebilirsiniz.

Küçük ekipler için önerilen mimari yaklaşım

Başlangıç aşamasında karmaşık bir platform kurmak yerine sınırları net bir production modeli tercih edilmelidir. Webhook girişi, worker süreci, kuyruk, veritabanı, dosya alanı ve log/monitoring katmanı ayrı düşünülürse hem güvenlik hem maliyet daha kolay yönetilir. Tek makinede başlanacaksa bile servislerin systemd veya container düzeyinde ayrı izlenmesi, deployment sonrası rollback adımının yazılması ve backup hedefinin uygulama sunucusundan ayrılması gerekir.

Yoğunlaşma başladığında yatay ölçekleme kararı metrikle verilmelidir. CPU yüksek diye node büyütmek yerine hangi job’un beklediği, hangi dış API’nin yavaşladığı ve hangi retry döngüsünün maliyet ürettiği görülmelidir. Bu yaklaşım gereksiz paket büyütmeyi engeller.

Satın alma ve teknik değerlendirme soruları

• Agent kaç farklı dış servise bağlanıyor ve her biri için rate limit var mı?
• Görevler gerçek zamanlı mı, kuyrukla gecikmeli çalışabilir mi?
• Hata durumunda aynı isteğin kaç kez denenmesine izin verilecek?
• Kritik secret’lar kimde, nasıl rotasyon yapılacak?
• Başarılı/başarısız görev raporu satış veya destek ekibine nasıl ulaşacak?

Bu sorular cevaplandığında Narweb tarafında doğru VDS/cloud boyutu, izleme kapsamı ve bakım modeli daha hızlı netleşir. Amaç en büyük sunucuyu almak değil, kesinti ve sürpriz maliyet riskini baştan azaltmaktır.

Örnek operasyon akışı

Bir müşteri destek agent’ı düşünelim: web formundan gelen talebi sınıflandırıyor, CRM kaydı açıyor, gerekiyorsa dosya özetliyor ve ekibe bildirim gönderiyor. Bu akışta her adım ayrı başarısızlık üretebilir. Form çalışırken CRM API limiti dolabilir; dosya işleme başarılıyken bildirim kuyruğu takılabilir; model yanıtı dönerken sonuç veritabanına yazılamayabilir. Bu yüzden tek bir “servis ayakta” metriği yeterli değildir.

Production ortamında her iş için benzersiz işlem kimliği, retry sayısı, hata nedeni ve son durum tutulmalıdır. Loglar yalnızca geliştirici için değil, satış ve destek ekibinin müşteri sorusuna hızlı cevap verebilmesi için de anlamlı olmalıdır. Özellikle ücretli API kullanan agent’larda başarısız retry sınırı ve günlük kota alarmı yoksa maliyet kontrolü zayıflar.

Ne zaman büyütmeli, ne zaman optimize etmeli?

Sunucu kaynağı yetersiz görünüyorsa önce darboğaz sınıflandırılmalıdır: CPU mu, bellek mi, disk I/O mu, dış API gecikmesi mi, yoksa verimsiz job tasarımı mı? Dış API yavaşken daha büyük sunucu almak sorunu çözmez. Aynı şekilde bellek sızıntısı olan bir worker için sınırsız kaynak ayırmak, problemi sadece fatura kalemine taşır.

Narweb ile yapılacak teknik değerlendirmede bu metrikler üzerinden ölçekleme kararı alınabilir. Başlangıçta tek VDS üzerinde güvenli bir kurulum yeterliyken, büyüme aşamasında ayrı worker node, managed backup, object storage ve daha kapsamlı DevOps bakım modeli gerekebilir.