Azure Brain: Bulutun Sağlığını İzleyen AI Beyni Nedir?
Şöyle bir sahne düşünün: Sabah 03:47 (inanın bana). Bir müşteri Teams üzerinden yazıyor — “Ayşe Bey, West Europe’ta bir tuhaflık var, storage tarafında latency uçtu, sizin panelde bir şey görünmüyor ama…” Sız daha gözünüzü bile tam açmadan, onların uygulama ekibi problemi çoktan fark etmiş oluyor. Bulut sağlayıcısından önce müşteri görüyor. Peki bunu neden söylüyorum? İşte bu, benim 20+ yıllık sistem yönetimi kariyerimde defalarca karşıma çıkan, insanın sınırını bozan senaryolardan biri.
📋 İçindekiler
Azure ekibi buna “the gap” diyor. Yanı bizim ölçtüklerimizle, gerçekten bildiklerimiz arasındaki o boşluk. Ve Mark Russinovich’in geçenlerde duyurduğu Brain, tam da bu boşluğu biraz olsun kapatmak için geliyor. AIOps katmanı mı dersiniz, dijital ikiz mi dersiniz, merkezî sağlık zekâsı mı dersiniz… Ne derseniz deyin — işin özü şu: Azure artık kendi sağlığını izleyen bir yapay zekâ sistemi kullanıyor. Hani kulağa biraz iddialı geliyor ama, açık konuşayım, bu sistem sız fark etmeden bulut deneyimini zaten değiştirmeye başlamış durumda.
Brain aslında ne? Kısaca özetleyeyim
Teknik tanımıyla başlayayım, sonra biraz açarız. Brain, Azure Resource Graph — kendi adıma konuşayım — (ARG) üzerinde çalışan bir AIOps zekâ katmanı; platform telemetrisini, AI/ML modellerini, servis bağımlılıklarını. Müşteri etkisini tek bir sürekli güncellenen görünümde topluyor, yanı servis bazında bakınca da bölge bazında bakınca da tabloyu ayrı ayrı değil, aynı anda görebiliyorsunuz.
Kısa bir not düşeyim buraya.
Bi saniye — Buraya kadar kulağa çok yeni gelmiyor, açık konuşayım (ciddiyim). AIOps lafı Gartner tarafında yıllardır dönüyor, Datadog, Dynatrace, New Relic gibi oyuncular da benzer şeyler söylüyor. Işin asıl farkı ölçekte çıkıyor ortaya (ki bu çoğu kişinin gözünden kaçıyor). 80’den fazla Azure bölgesi, 500’ü aşkın veri merkezî, 800.000 km’yi geçen fiber ve denizaltı kablosu… İşte burada “dijital ikiz” fikri laboratuvar oyunu olmaktan çıkıp bayağı endüstriyel bir probleme dönüşüyor (en azından benim deneyimim böyle)
İşin garibi, Hani bazen sistemler kağıt üstünde aynı görünür ya, işte burada öyle değil. Bir olay çıktığında ilk fark etme süresi kısalıyor, sorun sizin kaynaklarınıza daha işabetli daralıyor. Doğru mühendisin devreye girmesi de hızlanıyor; yanı mesele sadece alarm üretmek değil, alarmın kime gideceğini ve ne kadar işe yarayacağını da toparlamak.
Brain size üç şeyi somut olarak değiştiriyor: bir şey ters gittiğinde size ne kadar hızlı haber verildiği, sorunun sizin kaynaklarınıza ne kadar işabetli daraltıldığı, ve doğru mühendisin ne kadar hızlı devreye girdiği.
Neden ihtiyaç vardı? “Gap” hikâyesi
Aslında, Şimdi işin insan tarafına girelim (ki bu çoğu kişinin gözünden kaçıyor). Yıllardır sahada danışmanlık yapıyorum. Açık konuşayım, kurumsal bir müşteri için en sınır bozucu senaryo şu: Sız kendi uygulamanıza gömülüp hata arıyorsunuz, sonra hop, sorun bulut sağlayıcısında çıkıyor. Evet, baya can sıkıyor.
Durun, bir saniye.
Debugging yaparken üç saat gidiyor, bazen daha da fazla, sonra Twitter’da ya da status sayfasında bir not beliriyor: “We are investigating…” İşte o an insanın içinden “Tamam da bunu biraz önce söyleyemez miydiniz?” demek geliyor. Çünkü boşluk tam burada başlıyor.
Bu boşluğun teknik tarafı aslında basit görünüyor ama pratikte uğraştırıyor. Azure gibi devasa bir sistemde milyonlarca sinyal akıyor; CPU spike var, memory pressure var, network latency uzuyor, DNS resolution süreleri sapıtıyor, control plane hataları geliyor, storage IOPS düşüyor (inanın bana). Tek tek bakınca bunların çoğu gürültü gibi dürüyor. Ama hepsi yan yana gelince bazen tek bir resim çiziyor, işte ML modelinin yakalamaya çalıştığı şey de bu.
Eğer sistem sadece eşik kontrolüne yaslanıyorsa, orada işler çabuk dağılıyor (evet, doğru duydunuz). 2015-2018 arası dönemi düşünün; hyperscale bulut sağlayıcıları da benzer dertleri geleneksel monitöring stack’leriyle çözmeye çalışıyordu (Prometheus benzeri metric toplayıcılar, Grafana dashboard’ları, PagerDuty entegrasyonları falan). Bunlar fena araçlar değil. Ama ölçek büyüyünce “eşik geçti mi?” mantığı yetmiyor; eşiği sıkı tutarsanız alert fatigue başlıyor, gevşetirseniz olay kaçıyor. İkisi de tatsız.
Maalesef.
Türkiye perspektifinden bakınca
Kurumsal müşterilerde sık gördüğüm şey şu: Türkiye’deki büyük kuruluşlar — bankalar, telekomlar, sigorta şirketleri — Azure’a taşınırken en çok SLA yönetimi ve incident süreçlerinde duraksıyor. “Peki sorun çıkarsa biz nereden bileceğiz? Kimi arayacağız?” sorusu teknik olduğu kadar operasyonel de bir soru. Hatta bazen teknikten çok operasyonel diyebilirim.
Brain’in bu tarafı çözmeye başlaması Türkiye’deki finans ve regüle sektörler için önemliydi. Neden derseniz — BDDK’nın outsourcing rehberi de dahil pek çok düzenleyici çerçeve, bulut sağlayıcının hızlı ve işabetli bildirım yapmasını istiyor (yanlış duymadınız). Yanı işin aslı şu: hızlı haber vermek sadece iyi müşteri deneyimi değil, aynı zamanda compliance konusu da oluyor. Biraz sert ama gerçek bu.
Peki neden?
Dijital ikiz mantığı: ARG’nın üstüne inşa
Şimdi teknik tarafa biraz girelim. Azure Resource Graph zaten var, bunu biliyorsunuz. Milyarlarca kaynağı sorgulayabildiğiniz, KQL benzeri dille arayabildiğiniz o servis işte. Brain bunun üstüne oturuyor; yanı sıfırdan bir envanter çıkarmaya çalışmıyor, boşuna da uğraşmıyor. Var olan gerçek zamanlı kaynak grafiğine sağlık ve anlam katmanı ekliyor.
Şöyle söyleyeyim, Bak şimdi, dijital ikiz kavramı endüstriyel IoT tarafından geliyor aslında. Bir uçak motorunun sanal kopyasını yaparsınız, sensörlerden gelen verilerle bunu beslersiniz, sonra “eğer sıcaklık 30 dakika daha böyle giderse ne olur?” diye bakarsınız. Aynı mantık burada da var, ama uçak motoru yerine Azure’un kendisi dürüyor. Servis-bölge-müşteri workload üçgenini modelliyor. Şey, kulağa biraz soyut geliyor olabilir ama işin aslı bu.
Bileşenler ne durumda?
Bir bakayım, aklımdaki şemayı buraya çıkarayım: (buna dikkat edin)
| Katman | Görevi | Örnek çıktı |
|---|---|---|
| Telemetri toplama | Platform sinyalleri, metrikler, loglar | Ham veri havuzu |
| ARG (dijital iskelet) | Kaynak ve bağımlılık grafiği | “Hangi VM hangi vNet’te?” |
| AI/ML modelleri | Anomali tespiti, kök neden | “Bu spike anormal mi?” |
| Aksiyon katmanı | Deployment safeguards: Azure kendi iç deployment’larını yaparken, bir bölgede canary aşamasında anomali görürse otomatik durdurma devreye giriyor. Kısacası Microsoft’un kendi CI/CD akışına gömülü bir “acil dur” düğmesi var; iyi fikir gibi dürüyor, ama tabiî her senaryoda aynı rahatlıkta çalışır mı, orası ayrı konu.Outage declaration: Bir olayın “outage” seviyesine yükseltilip yükseltilmeyeceğine karar verme işi. Bu eskiden neredeyse tamamen insan eliyle yürüyordu, şimdi AI destekli gidiyor; ama buradaki kilit nokta şu, model tek başına hüküm vermiyor, sadece işaret ediyor. (bence en önemlisi)Üçüncüsü bana daha ilginç geliyor. Çünkü bir olayı “outage” ilan etmek, sadece teknik bir etiket değil; PR tarafı var, SLA tarafı var, para tarafı var (evet, bayağı para),. Mesele sandığınızdan daha çetrefilli. Bunu bir modele bırakmak ilk bakışta ürkütücü gelebilir. Ama aslında sistem karar vermiyor — insana “bak buna dikkat et, kalıp outage’a benziyor” diye dürtüyor. Nihai onay hâlâ SRE ekibinde. İşin aslı bu ayrım çok önemli.KQL tarafında pratik: Resource Health’i sorgulamakBrain’in en somut çıktısına biz kullanıcılar Resource Graph üzerinden erişebiliyoruz. Hani işin güzel. Şu: tek tek portal açıp bakmak yerine, küçük bir KQL ile bütün resmî aynı anda görüyorsunuz. Hani ne farkı var diyorsunuz, değil mi? Basit bir sorgu bırakayım, kendi abonelikinizdeki kaynakların sağlık durumunu topluca çekiyor:resources | where type == “microsoft.compute/virtualmachines” | join kind=leftouter ( healthresources | where type == “microsoft.resourcehealth/availabilitystatuses” | project targetResourceId = tolower(tostring(properties.targetResourceId)), availabilityState = tostring(properties.availabilityState), summary = tostring(properties.summary), reportedTime = todatetime(properties.reportedTime) ) on $left.id == $right.targetResourceId | project name, location, availabilityState, summary, reportedTime | order by reportedTime descBu sorguyu Azure Portal > Resource Graph Explorer’da çalıştırabilirsiniz. Ben genelde bunu bir Logic App’e bağlayıp Teams’e bildirım yolluyorum; şey, elle kontrol etmeye göre baya iş görüyor (yanlış duymadınız). EğerAzure IaaS Maliyet Optimizasyonu: Sahadan FinOps Notlarıyazımı okuduysanız, oradaki mantıkla aynı yere çıkıyor gibi düşünün — Resource Graph’i sadece envanter için değil, gözetim için de kullanmak, bazen beklediğinizden daha fazla rahatlık sağlıyor.Evet.Agentic AI: Bir sonraki dalgaAraya gireyim: Russinovich’in yazısındaki en çarpıcı yer bence burası. Brain şu anda daha çok “reaktif zekâ” gibi davranıyor; bir şey oluyor, görüyor, raporluyor. Ama Microsoft’un işaret ettiği yönagentic AI,. Iş sadece tespit etmekte kalmıyor, bazen aksiyon da alıyor.Burada biraz frene basmak lazım. “Otonom aksiyon” kulağa fena gelmiyor, hatta ilk bakışta baya havalı dürüyor ama bulut tarafında sınır çizgisi ince, üstelik yanlış atılan tek bir adımın faturası ağır olabiliyor; mesela bir SRE ajanının hatalı traffic shift kararıyla global bir outage yaratması hiç uzak bir senaryo değil. O yüzden ben agentic AI’ın önce düşük riskli, geri alınabilir işlerde görünmesini beklerim: circuit breaker açma, canary’yi yavaşlatma, belli bir cluster’a trafik yönlendirmeme gibi.Kısa bir not düşeyim buraya.Bu arada bu yönelim sadece Microsoft’ta yok. Google SRE tarafında “toil elimination” yıllardır masada, AWS de Bottlerocket ve otomatik remediation araçlarıyla benzer bir çizgide ilerliyor; ama işin ilginç kısmı şu ki Brain’in avantajı, kurumsal telemetriyi Copilot ekosistemiyle veAgent Framework Orchestration 1.0: Çoklu Ajan Koordinasyonu Yetişkingibi ajan altyapılarıyla aynı çatı altında toplayabilmesi (işte asıl fark burada). Evet, bu birleşim kulağa biraz iddialı geliyor; yine de pratikte elini rahatlatan taraf tam da bu olabilir.Peki bu bize — yanı müşteri tarafına — ne katıyor?Şimdi lafı gevelemeden pratik tarafa gelelim. Küçük bir ekipseniz ya da startup tarafındaysanız, Brain’in getirdiği en somut fayda şu: Resource Health bildirimleri daha nokta atışı olacak, hangi kaynağın etkilendiğini daha net göreceksiniz, Twitter’da “acaba bende mi sorun var” diye doğrulama yapma ihtiyacı da baya azalacak.Büyük kurumsal yapıda işler biraz başka akıyor. Hele bir de regüle bir sektördeyseniz, işin rengi iyice değişiyor; benim önerim şu: (ben de ilk duyduğumda şaşırmıştım)Service Health alerts’ı kurumsal alarm sisteminize entegre edin.Sadece e-posta ile bırakmayın, Action Group üzerinden webhook / ITSM entegrasyonu da koyun; yoksa olay büyüyünce herkes aynı mail kutusuna bakıp dürüyor. (bu kritik)Resource Health tabanlı otomasyon yazın.”Available” dışına düşen kritik VM’ler için Logic App tetikleyin, failover başlatın; hani insan eli değmeden aksiyon alsın, çünkü gece 03:00’te kimse bunu elle kovalamak istemiyor.Kendi observability stack’ınızı Brain’e alternatif değil, tamamlayıcı görün.Datadog / Dynatrace kullanıyorsanız devam edin; Brain platform seviyesini görür, sizin araçlarınız application seviyesini görür, ikisini yan yana koyunca resim biraz daha oturuyor.Post-incident review’lerinizde Azure Status History’i sistematik olarak inceleyin.Brain’in bildirım gecikmelerini ölçün ve Microsoft ekibiyle account manager üzerinden feedback döngüsü kurun; yoksa herkes “bir şeyler olmuş” deyip geçiyor ama kök neden havada kalıyor.💡 Bilgi:Azure Resource Health bildirimleri ücretsizdir amaService Health alertsiçin Action Group yapılandırması gerekir. En sık atlanan detay: aynı Action Group’u birden fazla abonelikte kullanabilmek için Enterprise Agreement seviyesinde tanımlamak. Küçük şirketlerde her subscription’a ayrı ayrı kuruluyor ve bakım kâbusu hâline geliyor.Eleştirel bir not: Her şey güllük gülistanlık mı?Açık konuşayım, hayır. Brain’in vaadi fena değil ama pratikte hâlâ biraz olgunlaşma istiyor; kendi gördüklerim ve topluluktan gelen feedback’ler de bunu söylüyor, yanı işin parıltılı tarafı var ama altını kazıyınca birkaç can sıkıcı detay çıkıyor.Birincisi, bildirım gecikmeleri her zaman istediğimiz kadar hızlı olmuyor. Küresel bir olayda dakikalar önemli, hatta bazen saniyeler bile kıymetli, ama garip şekilde Resource Health “Available” gösterirken sizin uygulama çoktan hata vermiş oluyor; işte burada insanın kaşı kalkıyor.Aslında, İkincisi, kök neden analizi (RCA) raporları hâlâ biraz jenerik kalıyor. “Underlying platform component” gibi ifadeler var ya, açık söyleyeyim sınır bozuyor — daha net açıklamalar için Microsoft’un biraz daha şeffaf davranması gerekiyor gibi geliyor bana.Üçüncüsü, Brain hakkında müşteri olaraksizeözel API veya arayüz henüz yok. Yanı platform içinde çalışan bir zekâdan söz ediyoruz; sız sadece onun dışarı verdiği çıktıları (Resource Health) görüyorsunuz, gerisini pek kurcalayamıyorsunuz. Belki ileride bir “Brain Insights API” gelir, kim bilir? Umarım gelir — itiraf edeyim, beklentimin üstündeydi —Sıkça Sorulan SorularBrain sadece Microsoft içinde mi kullanılıyor, müşteri olarak ben de erişebilir mıyım?İşin garibi, Brain aslında Microsoft’un kendi iç sistemi. Ama çıktıları doğrudan size yansıyor: Azure Resource Health bildirimleri, Service Health uyarıları, outage raporları — bunların hepsi Brain tarafından besleniyor. Yanı size özel ayrı bir portal ya da API yok, ama bence etkisini Azure Portal’da her gün farkında olmadan görüyorsunuz zaten.Bunu biraz açayım.Brain’i devre dışı bırakabilir mıyım, ya da verilerimin işlenmesini istemesem?İlginç olan şu ki, Brain platform telemetrisi kullanıyor — yanı sizin uygulama içeriğinize değil, servis metriklerine bakıyor. Açıkçası kişisel veriniz — ki bu tartışılır — veya iş yükünüzün içeriği bu sisteme girmiyor (ben de ilk duyduğumda şaşırmıştım). Compliance tarafında işe Azure’un standartuyum çerçevesigeçerli.AIOps ile klasik monitöring arasında ne fark var?Şahsen, Geleneksel monitöring eşik bazlı çalışıyor — mesela CPU %80’i geçerse alarm veriyor. AIOps işe farklı: normal davranışı öğreniyor, anomali yakalıyor, olaylar arasında korelasyon kuruyor. Brain milyonlarca sinyali bir arada işleyerek “bu olay şu bölgedeki storage backend sorunuyla bağlantılı olabilir” gibi çıkarımlar yapabiliyor. Bence bu fark, büyük ölçekli ortamlarda gerçekten ciddi bir hamle.Peki neden?Brain, Datadog veya Dynatrace gibi araçlarımın yerini alır mı?Hayır. Brain platform sağlığını izliyor — yanı Microsoft’un sorumluluk alanını. Sizin uygulama katmanınız hâlâ sizin sorumluluğunuzda. Tecrübeme göre tam görünürlük istiyorsanız üçüncü parti APM araçları olmadan olmaz, iki katmanı birleştirmeniz gerekiyor.Brain’den gelen bildirimleri nasıl otomatize edebilirim?Bunu yaşayan biri olarak söyleyeyim, Şöyle bir üçlü var: Azure Monitör Alerts + Service Health alerts + Resource Health alerts (ki bu çoğu kişinin gözünden kaçıyor). Bunları bir Action Group ile birleştirip webhook, Logic App veya Azure Function tetikleyebilirsiniz. Böylece bildirimler otomatik olarak ITSM sisteminize (ServiceNow, Jira gibi) ya da Teams kanalınıza düşüyor. Kurulumu biraz zaman alıyor ama bir kez yapınca çok rahat ediyor (ben de ilk duyduğumda şaşırmıştım) — itiraf edeyim, beklentimin üstündeydi —Kaynaklar ve İleri OkumaBence,Meet Brain: The AI system behind Azure reliability — Mark Russinovich (Azure Blog)Azure Resource Health Overview — Microsoft LearnAzure Resource Graph Documentation — Microsoft LearnBence,Advancing Reliability blog serisi — Azure |
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.
3 comments