# Yapay Zeka Ajan Ornekleri DevOps: Uretimde Gercek Durumlar

URL: https://upstreamapi.com/tr/journal/yapay-zeka-ajan-ornekleri-devops
Type: blog
Locale: tr
Published: 2026-07-14
Updated: 2026-07-16

---

> Platform muhendislerine yonelik yapay zeka ajan ornekleri: rollback ajanlar, kok neden triaj, Kubernetes tani ve runbook yurututculeri. Hangilerini uretime almaya deger?

## Yapay Zeka Ajan Ornekleri DevOps Ortamlarinda: Uretimde Hangi Ajanlar Calisir?

Yapay zeka ajan ornekleri DevOps ortamlarinda arayin, bulacaginiz her kaynak, bir urun katalogu gibi gorunuyor: sohbet robotlari, satis asistanlari, Insan Kaynaklari otomasyonu. Ancak platform muhendisinin sorduğu gercek sorusu cok başka: yapay zeka ajan ornekleri dagitim boru hattinda nasil gercekten uygulanir ve calisir? Açik ve duruss cevap: pazarlama sunumlarindan cok daha dar, cok daha az gorkemli ve cok daha teknik. Uretimde calisan yapay zeka ajan ornekleri DevOps'te dort temel kategoriye ayrilir: otomatik geri alma ajanlari, kok neden triaj ajanlari, bulut ve Kubernetes tani ajanlari, ve runbook yurume otomasyon sistemleri. Geri kalanin hepsi, pazarlamasi daha iyi olan basit chatbot'tur.

Bu bulguları, halka açık vaka çalışmalarından, satıcı post-mortem raporlarından ve kendi SLO-gated dağıtım deneyimlerimizden derledik. Hiçbiri uçtan uca tam otonom değildir. Hepsi dar kapsamlı, tam denetlenebilir ve tek bir belirli işe yönelik olarak tasarlanmıştır. Yanlış problem için yanlış kategorideki ajanı seçmek, hem parametre tuning zamanını hem de operasyonel başarısızlık riskini artırır.

## Dagitim Boru Hattinda Yapay Zeka Ajan Olmak Tam Olarak Neyi Anlamina Geliyor?

Bir anomali işaretleyen dashboard, ajan değildir. Metrik eşiğini aşan bir Slack uyarısı da ajan değildir, sadece daha iyi yazılmış bir cron işidir. Platform takımları için gerçek olan ayrım: bir ajan birden fazla sistem arasında bir eylem dizisi planlar, bulduğu veri sonuçlarına göre bu planı dinamik olarak uyarlar ve bir insan her adımı onaylayan müdahale etmeden yürütür. Bu tanım önemlidir, çünkü bir çok "yapay zeka DevOps" aracı bu tanımı karşılamaz.

Bu kritere göre değerlendirildiğinde, çoğu yapay zeka DevOps aracı hala destekleyici ve yardımcı, gerçek ajan değildir. Bu araçlar bilgiyi daha hızlı ortaya çıkarırlar, bu iyidir fakat operasyonel karar vermez. Aşağıdaki dört kategori, tanımlı bir patlama yarıçapı içinde gerçekten karar alıp hareket etmenin sınırını geçer.

## Geri Alma Ajanı: İnsan Fark Etmeden Otomatik Dağıtım Geri Alma

Bu, kendi geliştirdiğimiz ve yoğun şekilde test ettiğimiz kategoridir. Ajan, bir dağıtım sırasında SLO yanma oranını izler ve bütçe eşiğini aştığında, insan bir dashboard açıp durum görmeden dağıtımı otomatik olarak geri alır. Karar yok, 3 sabah saat yarısı Slack tartışması yok "bu geri almaya yeterince ciddi mi?" sorusu. Eşik değeri, adrenalin-içermez bir ortamda, gün ışığında önceden belirlenir ve sistem yapılandırılması sırasında yazılı kurala dönüştürülür.

Minimal bir versiyonu şöyle görünür:

`type RolloutState = {
  errorBudgetBurn: number;
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14;
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}`Bu karar tamamı. Ajan kısmı bunun etrafında yer alır: gözlemlenebilirlik yığınından canlı hata oranı ve gecikme metriklerini çekme, SLO'ya karşı karşılaştırma, dağıtım API'si aracılığıyla geri alma işlemini yürütme, olay kanalına ne tetiklediğini ve neler gördüğünü açıklayan yapılandırılmış not yazma. Bu deseni, günde 40 civarında dağıtım yapan bir Seri C fintech operasyonunda üretimde gördük. Yanma tespitinden geriye alınmaya kadar geçen ortalama süre: 90 saniyenin altında. Takımın kendi manuel tepki zamanı (altı aylık post-mortem analizlerine göre): 11 dakika. Başka bir deyişle, otomatik ajan bu takım için yapıyı altı kat hızlandırdı.

Dağıtım frekansınız çok düşükse ve zaten insan her dağıtımı canlı olarak izliyorsa bu deseni uygulamaya gerek yoktur.

![Bir monitörün yakından görüntüsü, soyut metrik grafikler gösteriyor, bir araştırma sırasında ajan tarafından ilişkilendirilen gözlemlenebilirlik verilerini temsil ediyor](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-07/03d611-inline1.webp)

## Kok Neden Triaj Ajanı: Uyarıdan Slack Konusmasina Dakikalar Icinde

Bu kategori, arkasında şu anda en çok halka açık veriye ve kanıta sahip olanıdır, çünkü satması ve ölçmesi diğerlerinden daha kolaydır. AWS'nin DevOps Ajanı, bir CloudWatch uyarısı veya PagerDuty sayfası tarafından tetiklenir, neden hakkında bir başlangıç hipotezi oluşturur, logları ve izlemeleri sorgulayarak hipotezini test eder, anomaliyi son dağıtım zaman damgalarına karşı ilişkilendirir ve Slack'e bulgularını gönderir. AWS, belgelenen dağıtımlarında yüzde 75'e kadar daha düşük MTTR (ortalama onarım süresi) bildiriyor ve Western Governors University vaka çalışması, çözüm süresinin iki saatten 28 dakikaya indiğini net olarak belirtiyor ([kaynak](https://aws.amazon.com/blogs/devops/leverage-agentic-ai-for-autonomous-incident-response-with-aws-devops-agent/)).

Önemli olan yüzde sayısı değildir, denetim izi mekanizması budur: ajan tarafından alınan her mantıksal adım, ajan'ın kendisinin değiştiremediği veya silip atamadığı bir geçmiş kaydında tutulur. Bu bir lüks değil, teknik zorunluluktur. Ajan, dağıtım geçmişinizi hata artışınızla ilişkilendirip "muhtemelen checkout servisi değişikliği" desede, sonraki soruşturmada yanlış olduğunda tam olarak nasıl oraya ulaştığını yeniden oluşturabilmeniz mutlak şarttır. Hiçbir ajan tam doğru değildir.

Aynı kalıbı farklı ürün ve araç adlarıyla görmüşüz: Wild Moose bir dakikadan kısa kök nedeni vaat ediyor, HolmesGPT bulut uyarılarını aynı tespit, ilişkilendir, açıkla döngüsüyle tanılıyor. Problem her yerde aynı şekil ve yapıda: uyarı tetiklenir, ajan telemetri okur, ajan neden önerir, insan doğrular veya geçersiz kılar. Cycle time bu sırası içinde minimize edilir.

Takımınız haftada birden fazla sayfalanıyorsa ve post-mortem raporları "neden bulması çok uzun sürdü" temasını tekrarlıyorsa, kurma ve öğrenme maliyeti çok çabucak geri döner. Envanteriniz mimarı büyük değişiklik kadar nadirse veya eğitim verileri için yapılan yatırım pahalıysa uygulamayı bir sonraki döneme erteleyebilirsiniz.

## Kubernetes Tanı Ajanı: Dar Kapsamlı ve Daha Guvenli Tasarim

Kubernetes ortamında hata ayıklaması, çoğu ajan ve otomasyon aracının başladığı yerdir. Bunun sebebi kubectl çıktısının LLM'in özet oluşturma ve açıklamalar yapmak için ideal olan yapılandırılmış ve yoğun metindir. k8s-GPT bir kümesini tarar ve hataları açık dille açıklar: pod neden CrashLoopBackOff durumunda takılı, PVC neden bağlanmıyor, servis neden uç noktası yok. Hareket etmiyor, sadece açıklama yapıyor. Bu kasıtlı kapsam sınırlaması budur ve tasarım felsefesi.

Sonraki seviye ve gelişmiş sürüm, Guardian tarzı ajanlar tarafından temsil edilir: sorunu tespit eder, kök nedeni bulur, kümeye doğrudan itmek ve hemen uygulamak yerine bir PR açar. Bu bir ek adım, canlı değişiklik kodu uygulaması yerine PR inceleme süreci. "Yararlı otomasyon" ile "geçen Salı'nın kesinti olayının nedeni" arasındaki tüm fark bu tek adımdır. PR incelenir, tartışılır ve onaylanır. Doğrudan kubectl uygulaması ajanından incelenmez ve üretim güvenliği sağlanır.

Dokümantasyon katmanı ve runbook'lar burada çoğu mühendisinin tahmin ettiğinden çok daha önemlidir. Ajan bir hata açıkladığında veya düzeltme PR açtığında, dolaylı olarak takip ettiği runbook ve prosedür ya takımınızın başında yaşıyor ya da sorgulanabilir bir yapay zeka katmanı olan bir docs-as-code aracında yaşıyor. Runbook'ları böyle modern araçlarda saklayan takımlar, altı ay sonra "neden bunu yaptık, bu en iyi yöntem mi" konuşmasını daha az görmüş. Ajan çıktısı, zamanla modası geçmiş belgeleri daha hızlı ortaya çıkarır ve güvenlik açıklarını gösterir.

![3 sabah saat yarısında bir laptop uyarısını kontrol eden uyarıdaki mühendis, olay yanıtı ajanının engellemeyi amaçladığı senaryo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-07/b0774c-inline2.webp)

## Runbook Yurutcu: Bir Ajana Uretim Ortamini Dokunmasini Verme

Bu kategori, insanların sık sık "tam otonom SRE ajanı" dediğinde kastettiği şeydir ve aynı zamanda en ince, en az doğrulanmış kanıt tabanı olan kategoridir. Ajan, bellek sızıntısını tespit eder, düşük trafikli bir zaman penceresinde dağıtılmış yeniden başlatma tetikler, hizmetin sağlıklı geri gelişini doğrular, döngüyü kapatır ve hiç kimseyi sayfalamaz. Çok adımlı runbook'lar, yazım hatası veya atlanmış adım riski olmadan ve otomatik kontrol mekanizmalarıyla yürütülür.

Çalışıyor, evet, ancak oyun kitabı dar, belirli ve patlama yarıçapı küçükse. Stateless bir servisi tanımlı düşük trafikli pencerede yeniden başlatmak makuldür. Bir veritabanı failover işlemi gündüz iş saatleri içinde bile riskli ve çok dikkatli yaklaşılması gereken bir harekettir. Veri kaybı potansiyeli ile yaşamak istemeyen hiçbir işletme tam otonom veritabanı operasyonlarını uygulamaz.

Kendi gözlemimiz ve müşteri deneyimleri: müşterileri AI Pilot'u progressive rollout'lara teli, düşük-risk eylemleriyle başla. Failover değil restart. Veritabanı şema değişiklikleri değil canary yüzde geri alma. Ajanın hata oranı, düşük-riskli eylemlerde bu yapıyı kanıtlayıncaya kadar ve güven sağlayıncaya kadar, yüksek-riskli olanlar için zamanı yavaş yavaş ve kademeli uzat. Zaman hafta değil ay ölçüsünde ölçün. Bu kademeli yaklaşım, gözlemlenebilirlik altyapısının ve takım içgüdüsünün beraber gelişmesini sağlar.

## Genel Amaçlı Ajanlar da Piyasada Gorunuyor, Yanlis Sekil

"Yapay zeka ajan ornekleri" arayıp ops bağlamı dışında kalırsanız, çok başka bir kategori bulursunuz: sanal tarayıcı, terminal ve dosya sistemi arasında açık uçlu görevleri planlayan ve yürüten genel amaçlı ajanlar. Bu ajanlar insanların yaptığı birçok bilişsel görev için eğitilmiştir.

Manus sanal bilgisayar içinde çalışır, bitmiş teslimatlar geri bildirir. Araştırma ve çok adımlı web görevlerinde yetkin. Üretim dağıtım kararı ve otomasyonu için ise hatalı araç seçimi budur. Çünkü değer önerisi genişlik ve çok amaçlılığa dayanır, neredeyse her şey, yeterli adımlar ve zaman sonrasında yapılabilir. Rollback kararı ve SLO otomasyonu ise zıt gerektirir: hızlı, dar, tahmin edilebilir ve sonucundan emin.

Lindy ops'a bitişik konumda oturur: kodsuz iş akışları, gelen kutusu triaj, toplantı planlaması, tekrarlayan takipler. Uyarıda olan dönüşü ve destekleyici işler için faydalı, sabah 6'de elle devir yeniden zamanlamak istemez. Ancak gerçek ve kritik olay yanıtı için işe yaramaz. Genspark'ın kodsuz Super Ajanı ile aynı hikaye, göz at, ara, oluştur ama SLO bütçesinin ve canary yüzdenin hiçbir kavramı ve kontrolü yok.

Bu araçlar ve platformlar kötü değildir. Farklı problem kategorileri için uygun şekilde inşa edildi. Gördüğümüz yaygın hata: dar ops ve DevOps sorunu karşı genel amaçlı ajan değerlendirmek, başarısız olması beklenen sonuç, etkilenmez olmak, "yapay zeka ajanları altyapı otomasyonu için henüz hazır değil" sonucuna gelmektir. Bu yanlış kategori, yanlış araç, yanlış sonuç çıkartmak demektir.

## Bu Ajanlar Nereye ve Ne Zaman Basarisiz Oluyor?

Kök nedeni yüzde 94 doğru tanımlayan ajanlar bir kez 17 kez yanlışlanır ve hatalıdır. Yanlış cevap genellikle güvenli ve spesifik seslidir, uyarıdaki mühendisiyi 20 dakika yanlış servise tutar. Dağıtım zaman damgası korelasyonu gerçek bir sinyaldir, bunu reddetmez. Ama kanıt değildir. Emin olmak için eğitilmiş ajan, tesadüfi korelasyon ve gerçek, kausal neden hakkında eşit sesli, eşit güvenle konuşur ve ikisini ayıramaz.

İkinci başarısızlık kategorisi ve modu: ajan yayılımı ve kontrol kaybı. Triaj, tanı ve rollback ajanları çalışır sonra, ajanları izlemek zorunlu bir gereklilik olur. Erken 2026 dağıtımları net şekilde gösteriyor: en büyük operasyonel kazanç MTTR sayısı değil, ajan katmanı için gözlemlenebilirlik ve telemetri sisteminin kurulması. Sessizce tetiklemeyi durduran bir ajan, hiç ajan olmaktan çok daha tehlikelidir. Hiç kimse yokluğunu, kaldırmasını ve inaktiflendirmesini fark etmez ve bu sessizlik felaket olabilir.

![Ajan'ların izlediği altyapı katmanını temsil eden, raf satırlarıyla dolu karanlık bir sunucu odası koridoru](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-07/474040-inline3.webp)

## Ajana Dagitimunizi Teli Misiniz, Yoksa Cikisi Beklemeli Misiniz?

Takımınız ayda birkaçtan fazla sayfalanıyorsa ve post-mortem raporları farklı servislerle aynı nedeni tekrarlıyorsa, triaj ajanı kendisini hızlıca kanıtlar ve değer gösterir. Çoğunlukla "ne değişti" aşamasını kısaltarak. Dağıtım hacminiz, bir insan her dağıtımı canlı izleyemez kadarsa, SLO-gated rollback ajanı üç sabah saat yarısı kararını tamamen kaldırır. Amaç budur: uyarıdaki mühendis düşünmez ve hesap yapmaz 3 sabah, gün ışığında yapılandırılan bir düğme basar, o kadar.

Hiçbiri doğru ve uygulanabilir değilse, SLO'ları doğru tanımlamayı ve ölçmeyi gerçekleştir. Gürültülü, tanımlanmamış, muğlak bütçeler üzerinde oturan ajan, bir insan daha hızlı hatalı kararlar otomatikleştirir. Ajan zor kısım değildir. Tam olarak "hareket etmek için yeterince kötü" ne tam olarak anlamına geldiğini, net sayılarla, 3 sabah adrenalin olmadan, önceden bilmek çok zor kısım.

## FAQ

### Uretim ortaminda hangi yapay zeka ajan ornekleri gercekten calisir?

Dort kategori: SLO yanma oranina dayali geri alma ajanlari, CloudWatch uyarılarını loglarla ilişkilendiren triaj ajanları, Kubernetes hataları açıklayan tanı ajanları ve low-risk runbook'ları yürüten otomasyon. Hepsi dar kapsamlı ve tam denetlenebilir.

### AWS DevOps Ajanı MTTR'ı nasıl yüzde 75 düşürüyor?

Uyarı tetiklendiğinde, AWS ajanı hipotez oluşturur, logları sorgular, son dağıtımla ilişkilendirir ve Slack'e bulgu gönderir. Kök neden bulma aşaması saatlerden dakikalara düşer, ama her adım denetim izi gerektirir ve güvenlik için kaydedilir.

### Manus ve Lindy gibi genel ajanlar DevOps için neden yanlış?

Genel ajanlar genişliğe tasarlanmış, neredeyse her şey yapabilen. Rollback ve SLO kararları tersine gerekir: dar, hızlı, tahmin edilebilir ve deterministik. Yanlış kategori, yanlış sorun, yanlış araç seçimi.

### Ajanları neden izlemek kritik?

Sessizce tetiklemeyi durduran ajan, hiç olmaktan çok daha tehlikelidir. Hiç kimse yokluğunu fark etmez. Erken 2026 dağıtımları gösteriyor: en büyük operasyonel kazanç ajan katmanı için gözlemlenebilirlik ve telemetri.

### Runbook yürütücüsü ile başlamak güvenli midir?

Stateless bir servisi tanımlı düşük trafikli pencerede yeniden başlatmak güvenlidir. Veritabanı failover'ı ve şema değişiklikleri değildir. Düşük-risk eylemlerle başla, sonra yüksek-risk otomasyon zamanıyla kademeli ilerle.

### Kök nedeni yüzde 94 doğru tanımlayan ajan yeterince güvenilir midir?

Hayır. Yüzde 94 doğruluk, 17 uyarıdan birinin yanlış olacağı anlamı. Denetim izi gereklidir, ama ajanın yanlış olabileceği akılda tutulmalı ve insan kontrol süreci olmalı.