Agentic Cloud Operations: İçgörüden Eyleme Geçen Bulut Devri
Ne yalan söyleyeyim, Diyelim ki saat 03:42 öldü ve bir alarm birden patladı. Production’da bir microservice latency’si fırlamış, müşteri tarafı da bunu hissetmeye başlamış. Klasik senaryoda ne olur? Nöbetçi mühendis uyanır, — en azından ben öyle düşünüyorum — Grafana’yı açar, log’lara dalar, üç dashboard arasında gidip gelir, sonra yarım saat kadar uğraşıp “ha, deployment’tan gelen bir memory leak varmış” der. Sorunu kapatır, sabah 5 gibi de tekrar uyur.
İşin garibi, Şimdi aynı anı biraz farklı düşünün: alarm çaldığında sistem zaten sinyalleri birleştirmiş, son deployment’la ilişkilendirmiş, iki tane olası kök neden çıkarmış. Bunlardan biri için rollback planını bile hazırlamış oluyor; yanı sizden sadece onay bekliyor. Telefonu açtığınızda iş neredeyse bitmiş gibi dürüyor. Sadece “evet” demeniz yetiyor.
Hmm, bunu nasıl anlatsamdı…
İşte Microsoft’un son dönemde sık sık anlattığı agentic cloud operations tam da bu noktayı hedefliyor. Ben de Azure tarafında yıllardır operasyonel olgunluk projelerinde çalışan biri olarak bu yaklaşım hakkında aklımdan geçenleri, sahada gördüklerimi. Türkiye’deki kurumsal müşteriler için ne ifade ettiğini anlatmak istiyorum. Lafı gevelemeden başlayalım.
Önce şu “agentic” meselesini netleştirelim
“Agentic” kelimesi son bir yılda o kadar çok yerde dolaştı ki, anlamı biraz bulanıklaştı. Açık konuşayım: her LLM çağrısına “agent” diyen bir sektördeyiz. Ama Microsoft’un burada kastettiği şey biraz daha dar ve daha işe yarar bir çerçeve.
Agentic cloud operations dedikleri model şunu söylüyor: AI ajanları kullanıcı niyetine göre yönleniyor, bulut yaşam döngüsünün her aşamasında sürekli bakıyor, yorum yapıyor ve eylemlere yardım ediyor. Yanı sadece “alarm geldi, mail attım” değil. Sinyal geliyor, korelasyon kuruluyor, hipotez çıkıyor, eylem öneriliyor, onay gelirse uygulanıyor ve sonuç da öğreniliyor; döngü kabaca bu.
Microsoft’un Material ile yaptığı son araştırmaya göre kurumların %79’u production ortamında agentic AI deploy etmiş durumda. İlk gördüğümde ben de biraz kaşımı kaldırdım açıkçası —. “deploy etmiş olmak” ile — itiraz edebilirsiniz tabi — “gerçekten iş görüyor olmak” arasında bayağı fark var. Tahmin eder mısınız? Yine de yön belli: artık soru “yapacak mıyız” değil, “bunu nasıl düzgün yapacağız”.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Agentic operasyon, dashboard’a bakıp karar veren mühendis modelinden, kararın büyük kısmını sistemin önerdiği ve mühendisin onayladığı modele geçiştir. Tam otomasyon değil — denetimli otonomi.
Governance kısmı mı? Evet, asıl iş orada başlıyor
Şimdi işin en kolay atlanan yerine gelelim. Çoğu yazı “AI ajanları sizin için sorunları çözecek” deyip geçiyor. Ben tersinden söyleyeceğim: governance katmanını doğru kurmadıysanız bu sistem size yardım etmez; hatta bazen başınıza iş açar.
Düşünün bir kere: bir ajan production ortamında VM restart edebiliyor. Hangi yetkiyle? Hangi politika sınırında? Kim onay verdi? Audit log’da bu olay nasıl görünecek? Denetime girildiğinde bunu nasıl açıklayacaksınız? Sorular uzayıp gidiyor.
Azure tarafında benim önerim hep aynı öldü: ajan eylemleri için ayrı bir identity kullanın, verilen role’leri minimumda tutun ve hepsini Azure Policy ile çerçeveleyin. Bir de Activity Log tarafına özel filtre koyun — “kimin yaptığı belli olmayan” hiçbir hareket ortada kalmasın.
İnsan döngüde kalsın mı? Kalsın ama dozunda
“Human-in-the-loop” kulağa çok düzgün geliyor. Ama pratikte şöyle bir dert var: her şey için onay isterseniz ajanın hızlı olmasının anlamı kalmıyor; hiçbir şey için istemezseniz de riski yönetemiyorsunuz.
Bak şimdi, Sahada en sağlıklı gördüğüm yaklaşım eylemleri risk seviyesine göre ayırmak öldü:
| Risk Seviyesi | Eylem Tipi | Onay Modeli |
|---|---|---|
| Düşük | Log toplama, metric query, dashboard güncelleme | Otomatik — bildirım bile gitmesin |
| Orta | Auto-scale tetikleme, cache flush, non-prod restart | Otomatik + post-action bildirım |
| Yüksek | Prod rollback, kaynak silme, network rule değişikliği | Manuel onay zorunlu |
| Kritik | Veri tabanı schema değişikliği, IAM değişikliği | Çift onay (4-eyes principle) |
Burası basit görünüyor ama uygulaması hiç öyle değil. Çünkü “rollback” bazen düşük riskli olurken bazen şirketin canını sıkabilecek kadar kritik hâle gelebiliyor. Bağlam önemli. İyi tasarlanmış bir agentic sistem bu bağlamı kendi çıkarabiliyor olmalı.
Peki akıl katmanı nerede başlıyor?
Teknik tarafa geçelim biraz. Bir ajanın gerçekten akıllı davranabilmesi için önce iyi görmesi gerekiyor. Cloud ortamı büyüdükçe — hele mikroservisler (en azından benim deneyimim böyle). AI workload’ları da devreye girince — telemetri miktarı insan eliyle takip edilemeyecek kadar artıyor (yanlış duymadınız)
Şimdi gelelim işin can alıcı noktasına.
Azure Monitör, Application Insights, Log Analytics… Bunlar uzun zamandır var zaten. Eskiden mühendis bunlara bakıp manuel korelasyon yapıyordu; şimdi o işi ajan üstleniyor. Üç şeyi özellikle arıyor:
- Anomali tespiti — sadece eşik bazlı değil, davranış değişimini de yakalayabilen yapı
- Çapraz sinyal korelasyonu — trace’i, log satırını ve metric’i birbirine bağlayabilen yapı — bunu es geçmeyin
- Değişiklik tespiti — “son 24 saatte ne değişti?” sorusuna doğal dille cevap verebilen yapı
Şunu fark ettim: Burada küçük bir not düşeyim. Bu konuyla ilgili daha önce Deep Agents + Cosmos DB: Operasyonel Veride Plan-Eylem-Doğrulama yazımda da değinmiştim — ajan tabanlı operasyonel sistemlerin kalbi ham sinyalde değil, anlamlandırılmış sinyalde atıyor. Yanı ajana düz log atmak pek işe yaramıyor; önce embedding katmanı geliyor, sonra semantik index geliyor, sonra prompt geliyor; sıra önemli yanı.
Sinyal geldi diye iş bitmiyor ki…
Tamamdır, sinyaller anlamlandırıldı diyelim. Sonra ne olacak? İşte pek çok ekip tam burada tökezliyor. Insight üretmek başka şeydir; bunu eyleme çevirmek bambaşka şeydir.
Doğrusu, Kapanan döngü (closed-loop) sistemi dediğimiz yapı aslında dört adımdan oluşuyor:
- Gözlem — telemetri ve event’lerin sürekli akışı
- Yorum — ajanın bağlamla birlikte hipotez üretmesi
- Eylem — politika sınırları içinde uygulama yapılması (manuel ya da otomatik)
- Geri besleme — sonucun sisteme dönmesi ve sonraki kararı etkilemesi
Dördüncü adım en zoru gibi dürüyor aslında. “Geri besleme” laf olarak kolay. Pratikte ya sağlam bir RL (reinforcement learning) altyapısı ya da en azından düzgün çalışan bir telemetri-sonuç eşleştirmesi gerektiriyor (inanın bana). Bunu nasıl kurarsınız? Outcome-Driven Learning: OpenEnv ve Foundry ile Kurumsal RL
. Bu yazıda buna değinmiştim; kısa hali şu: ajanın yaptığı her işi bir “outcome metric”e bağlamazsanız sistem öğrenmiyor, sadece reaksiyon veriyor.
Maliyet optimize etmeu artık ayda bir yapılan iş değilmiş gibi davranıyorlar ama öyle değil mi?
Size bir şey söyleyeyim, Zamanında FinOps ekipleri ayda bir otururdu. Kullanım raporlarına bakar, “şu reserved instance’ı alalım”, “şu VM’i küçültelim” derdi geçerdi giderdi. Bu model artık pek yürümüyor gibi; çünkü AI workload’ları geldikten sonra maliyetler haftalık değil bazen saatlik oynuyor.
Agentic modelde optimizasyon arka planda sürekli dönüyor. Ajan bakıyor: hangi kaynak boşta kalmış, hangisi şişmiş, hangi SKU değişimi mantıklı olabilir, hangi region geçişi latency’yi bozabilir mi… Sonra önerisini çıkarıyor. Bazısını otomatik uyguluyor eğer politika izin veriyorsa; bazılarını da size bırakıyor.
Peki Türkiye’deki kurumsal yapı buna nasıl bakıyor?
Aslında, Burası benim en sevdiğim kısım olabilir (ben de ilk duyduğumda şaşırmıştım). Dışarıdaki bloglarda hep aynı hava var: “Herkes agentic’e geçti”, “GenAI çağı başladı”, “geride kalmayın”. Sahada işler öyle pürüzsüz gitmiyor açıkçası.
Türkiye’deki kurumsal müşterilerimde gördüğüm tablo şu öldü: banka ve sigorta gibi regüle sektörlerde governance baskın geliyor doğal olarak. Bir ajanın production’da bağımsız aksiyon almasına onay vermek BDDK ya da SPK açısından ciddi mesele oluyor. Bu yüzden benim önerim çoğu zaman agentic sistemi önce
Sıkça Sorulan Sorular
Agentic cloud operations ile klasik otomasyon arasındaki fark ne?
Klasik otomasyon tamamen kural bazlı çalışıyor —. “X olursa Y yap” mantığı, hepsi önceden yazılmış. Agentic yaklaşım işe bağlamı okuyup kendi kararını veriyor. Mesela aynı sinyal, farklı bir bağlamda bambaşka bir eylemi tetikleyebiliyor. Açıkçası bu esneklik çok işe yarıyor, ama karşılığında tahmin edilebilirlikten biraz feragat ediyorsunuz.
Azure Copilot ile agentic operations aynı şey mi?
Aynı değil, ama aynı aileden sayılır. Aslında Azure Copilot, agentic operations modelinin Azure portalına yansımış hali gibi düşünülebilir. Hani tam anlamıyla agentic bir deneyim istiyorsanız, Copilot tek başına yetmiyor — Logic Apps, Azure Functions, Agent Framework gibi araçları da işin içine katmanız gerekiyor.
Production ortamında ajana ne kadar yetki vermek güvenli?
Garip gelecek ama, Bence burada risk bazlı düşünmek şart. Read-only ve düşük etkili şeyler için — mesela log toplama, metric sorgusu, auto-scale — otomatik onay rahatça verilebilir. Ama veri veya IAM değiştiren işlemlerde mutlaka bir insan onayı olmalı. Tecrübeme göre en sık yapılan hata şu: ajana global admin rolü vermek. Bunu bana kalırsa yapmayın.
FinOps açısından agentic operations bütçeyi nasıl etkiliyor?
İki taraflı bir etki var. Olumlu tarafta: idle kaynakları buluyor, right-sizing önerileri sunuyor, sürekli optimize ediyor — ciddi tasarruf sağlıyor (inanın bana). Olumsuz tarafta işe ajanın kendisi LLM token tüketiyor ve ekstra sorgular üretiyor. Net bakiyeye bakınca genelde pozitife çıkıyor, ama pilot aşamada her iki tarafı da yakından izlemenizi öneririm (en azından benim deneyimim böyle)
Küçük bir ekipsem nereden başlamalıyım?
Bi saniye — Doğrudan Azure Copilot’u portal üzerinden açın ve basit sorularla işe koyulun: “Bu hafta en pahalı kaynağım hangisi?”, “Şu uygulamamda son 24 saatte ne değişti?” gibi. Sonra Azure Advisor önerilerini otomasyona bağlayın. Aslında tam bir framework kurmadan da değer üretmek mümkün — küçük başlamaktan çekinmeyin.
Kaynaklar ve İleri Okuma
Açık konuşayım, From insight to action: The next phase of agentic cloud operations — Azure Blog
Microsoft Copilot in Azure — Resmî Dokümantasyon
Azure Policy: Governance Çerçevesi Dokümantasyonu
Azure Monitör — Observability Platformu Referansı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments