Bir AI agent ya da otomasyonun 7/24 çalışması, yalnızca sürecin ayakta kalması değildir. Harici API yavaşladığında, görev kuyruğu büyüdüğünde, aynı işlem tekrarlandığında veya kimlik bilgisi sızdığından şüphelenildiğinde sistemin güvenli biçimde yavaşlaması, durması ve geri dönmesi gerekir. Bunun için kısa, uygulanabilir ve düzenli test edilen bir AI Agent Hosting olay müdahale runbook’u hazırlanmalıdır.

AI agent olayı neden klasik sunucu alarmından farklıdır?

Klasik bir web servisinde hata çoğu zaman HTTP durum kodu, yanıt süresi veya kaynak kullanımıyla görünür. Bir agent ise teknik olarak çalışmaya devam ederken yanlış aracı çağırabilir, aynı işi defalarca kuyruğa alabilir, harici servisin kota sınırına takılabilir ya da eksik bağlamla hatalı çıktı üretebilir. Bu nedenle yalnızca CPU, RAM ve process durumuna bakmak yeterli değildir.

Runbook; altyapı sinyallerini iş sonucu sinyalleriyle birleştirmelidir. Kuyruk yaşı, başarısız görev oranı, tekrar deneme sayısı, araç çağrısı süresi, maliyet eğilimi ve insan onayı bekleyen işlem sayısı aynı olay görünümünde değerlendirilmelidir. “Process açık” ile “iş doğru ilerliyor” birbirinden ayrı sağlık koşullarıdır.

Runbook başlamadan önce: sahiplik ve etki sınırı

Her production otomasyonu için bir teknik sahip, bir iş sahibi ve gerektiğinde karar verecek yedek kişi belirleyin. Teknik sahip servis, log ve kuyruk davranışını; iş sahibi ise yanlış veya gecikmiş çıktının müşteri ve operasyon etkisini değerlendirir. Mesai dışı durumda kimin aranacağı belirsizse en iyi gözlem paneli bile müdahaleyi hızlandıramaz.

• Agent’ın okuyabildiği ve yazabildiği sistemleri listeleyin.
• Otomatik gerçekleştirebildiği geri döndürülemez eylemleri işaretleyin.
• Günlük normal görev hacmi ve kabul edilebilir kuyruk yaşını kaydedin.
• Harici API, veritabanı, webhook ve mesajlaşma bağımlılıklarını belirtin.
• İnsan onayı olmadan çalışabilecek adımlara açık sınır koyun.

Senaryo 1: görev kuyruğu büyüyor

Kuyruk büyümesi her zaman daha fazla worker eklenmesi gerektiği anlamına gelmez. Önce giriş hızı, işleme hızı ve en eski görevin yaşı birlikte incelenmelidir. Tek bir problemli görev sonsuz retry döngüsüne girmiş olabilir; harici API gecikmiş olabilir veya downstream veritabanı kilitlenmiş olabilir. Worker sayısını körlemesine artırmak, bağımlı sistemi daha fazla baskı altında bırakabilir.

1. Yeni görev kabulünü tamamen kapatmadan önce oran sınırlaması uygulayın.
2. En sık hata veren görev tipini ve son başarılı örneği ayırın.
3. Retry politikasındaki maksimum deneme, backoff ve jitter değerlerini kontrol edin.
4. Tekrarlanması riskli işleri dead-letter kuyruğuna taşıyın; otomatik yeniden oynatmayın.
5. Kapasite artışı gerekiyorsa önce bağımlı servis limitlerini doğrulayın.

Senaryo 2: harici API hatası veya kota sorunu

AI modelleri, arama servisleri, CRM’ler ve mesajlaşma API’leri geçici olarak hata verebilir. Runbook, zaman aşımı ile kalıcı yetki hatasını ayırmalıdır. Zaman aşımı kontrollü retry ile ele alınabilir; geçersiz anahtar veya yetki kaybı ise retry edilirse yalnızca kuyruğu ve maliyeti büyütür. HTTP kodu, sağlayıcı hata sınıfı ve çağrı kimliği loglanmalı; ancak token ve hassas payload loglara yazılmamalıdır.

Degrade mod tanımlayın: Agent veri yazmak yerine taslak üretebilir, dış sisteme gönderimi durdurabilir veya yalnızca düşük riskli görevleri sürdürebilir. Kullanıcıya belirsiz bir başarı mesajı vermek yerine işlemin beklemeye alındığını açıkça belirtmek daha güvenlidir.

Senaryo 3: tekrar eden veya yan etkili işlem

Bir webhook iki kez gelebilir, worker yanıtı kaydetmeden kapanabilir veya zaman aşımı yaşanan çağrı karşı tarafta başarıyla tamamlanmış olabilir. Bu nedenle ödeme, kayıt güncelleme, e-posta gönderimi ya da ticket açma gibi yan etkili işlemler idempotency anahtarıyla korunmalıdır. Olay sırasında ilk soru “istek tekrar gönderilebilir mi?” değil, “karşı tarafta gerçekleştiğini nasıl doğrularız?” olmalıdır.

• Her iş için benzersiz olay ve işlem kimliği üretin.
• Başlamadan önce ve tamamlandıktan sonra durum kaydı tutun.
• Aynı kimlikle ikinci yazmayı engelleyin.
• Belirsiz durumda hedef sistemi okuyarak sonucu doğrulayın.
• Toplu yeniden oynatma için insan onayı ve örneklem kontrolü isteyin.

Senaryo 4: kimlik bilgisi riski ve güvenli durdurma

Token’ın logda göründüğü, beklenmeyen konumdan çağrı yapıldığı veya agent’ın yetki sınırını aştığı şüphesinde öncelik yalnızca servisi yeniden başlatmak değildir. Etkilenen credential devre dışı bırakılmalı, yeni anahtar farklı bir güvenli kanaldan dağıtılmalı ve eski anahtarla yapılan işlemler incelenmelidir. Anahtar döndürme prosedürü daha önce test edilmediyse müdahale sırasında gereksiz kesinti oluşabilir.

Güvenli durdurma; yeni görev kabulünü kesmek, çalışan işleri belirli bir sürede tamamlamak, tamamlanamayanları görünür duruma taşımak ve yazma yetkilerini geçici olarak azaltmak anlamına gelir. Process’i aniden öldürmek, yarım kalmış işlem ve tekrar riskini artırabilir. Kill switch’in neyi durdurduğu ve neyi çalışır bıraktığı dokümante edilmelidir.

İlk 15 dakikalık müdahale akışı

1. Doğrula: Alarmın gerçek olduğunu iki bağımsız sinyalle kontrol edin.
2. Sınıflandır: Veri kaybı, yetkisiz işlem, müşteri etkisi ve maliyet artışı ihtimalini belirleyin.
3. Sınırla: Riskli görev tipini, tenant’ı veya entegrasyonu izole edin; tüm sistemi gereksiz yere kapatmayın.
4. Koru: Log, kuyruk durumu, deployment sürümü ve son başarılı işlem kimliklerini saklayın.
5. İletişim kur: Teknik ve iş sahibine etki, alınan önlem ve bir sonraki güncelleme zamanını bildirin.
6. Geri dön: Bilinen son güvenli sürüme veya degrade moda geçin.

Olay sonrası kanıt ve iyileştirme

Olay kapatma ölçütü yalnızca alarmın susması değildir. Kuyruk normale dönmeli, belirsiz işlemler hedef sistemden doğrulanmalı, müşteri etkisi listelenmeli ve geçici değişiklikler kalıcı konfigürasyona dönüştürülmelidir. Kısa bir zaman çizelgesi; ilk sinyal, sınırlama, geri dönüş ve tam düzelme anlarını içermelidir.

Ardından alarm eşiği, retry politikası, yetki kapsamı veya deployment kontrolü için en az bir ölçülebilir iyileştirme seçin. Runbook’u masa başında okumak yerine üç ayda bir kontrollü tatbikatla deneyin. Kuyruk durdurma, credential rotation ve dead-letter replay adımları tatbikatta çalışmıyorsa gerçek olayda güvenilir değildir.

Production’a çıkmadan önce kontrol listesi

• Teknik sahip, iş sahibi ve eskalasyon kişisi belli.
• Kuyruk yaşı, hata oranı, retry ve maliyet sinyalleri izleniyor.
• Yan etkili işlemler idempotency ile korunuyor.
• Token ve hassas payload loglardan maskeleniyor.
• Degrade mod ve kill switch kapsamı test edildi.
• Dead-letter kuyruğu insan onayı olmadan toplu oynatılmıyor.
• Credential rotation adımı dokümante ve denenmiş.
• Olay sonrası dış sistem okuma/doğrulama adımı mevcut.

7/24 çalışan agent, bot ve otomasyonlar için sunucu seçiminin yanında izleme, kontrollü durdurma ve olay müdahale modeli de değerlendirilmelidir. Narweb’in AI Agent Hosting yaklaşımını inceleyebilir; mevcut iş akışınızın çalışma modeli için teknik gereksinimleri paylaşabilirsiniz.