Bulut projelerinde yüksek erişilebilirlik ve iş sürekliliği çoğu zaman projenin ilk gününde konuşulur; ancak maliyet, zaman baskısı ve uygulamanın bir an önce devreye alınması gibi nedenlerle detaylar sonraya bırakılır. Sonrasında ise çalışan bir yapıyı kesintisiz biçimde daha dayanıklı hale getirmek, sıfırdan tasarlamaktan çok daha zor ve maliyetli olabilir.
Microsoft’un public preview olarak kullanıma sunduğu Resiliency Agent in Azure Copilot, tam olarak bu noktaya odaklanıyor. Azure Copilot içerisinde yer alan bu özel ajan, Azure iş yüklerinin dayanıklılığını doğal dil kullanarak tasarlamamıza, değerlendirmemize ve geliştirmemize yardımcı oluyor.
Buradaki önemli nokta şu: Resiliency Agent sadece genel tavsiyeler veren bir sohbet botu değil. Mimariyi anlamaya, kaynakların mevcut yapılandırmasını değerlendirmeye, dayanıklılık eksiklerini göstermeye ve uygulanabilir Bicep şablonları ya da iyileştirme scriptleri üretmeye çalışıyor.
Resiliency Agent ne işe yarıyor?
Azure üzerinde dayanıklı bir mimari kurmak yalnızca birden fazla sanal makine çalıştırmaktan ibaret değil. Kullanılan Azure bölgesinin Availability Zone desteği, sanal makinelerin ve disklerin yerleşimi, veritabanının yedeklilik modeli, storage hesabının replikasyon seçeneği, yük dengeleme katmanı ve uygulamanın bileşenleri arasındaki bağımlılıklar birlikte ele alınmalı.
Üstelik her Azure servisi aynı yöntemle dayanıklı hale getirilemiyor. Bazı servislerde mevcut kaynak üzerinde yapılandırma değişikliği yapılabilirken, bazı kaynakların yeniden oluşturulması veya taşınması gerekiyor. Bu da maliyet, kesinti süresi ve operasyonel risk anlamına geliyor.
Resiliency Agent, bu karmaşıklığı daha yönetilebilir hale getirmeyi amaçlıyor. Doğal dilde tarif ettiğimiz bir uygulamayı analiz edebiliyor, mevcut kaynakların zone dayanıklılığını kontrol edebiliyor, ön koşulları ve engelleri belirleyebiliyor ve izlenebilecek iyileştirme yolunu sunabiliyor.
Microsoft bu yetenekleri iki ana başlık altında topluyor: Start Resilient ve Get Resilient.
Start Resilient: Dayanıklılığı en baştan tasarlamak
Start Resilient, henüz kurulmamış veya modernize edilmekte olan uygulamalar için tasarlanmış. Uygulamanın bileşenlerini doğal dilde anlattığımızda ajan mimariyi analiz ediyor, gerektiğinde bölge ve yapılandırma tercihleri hakkında ek sorular soruyor ve dayanıklılık önerileri hazırlıyor.
Örneğin şu şekilde bir talepte bulunabiliyoruz:
Bir sanal makine, PostgreSQL veritabanı ve load balancer kullanan bir uygulama kuracağım. Zone dayanıklılığı olan bir mimari tasarlamama yardımcı ol.
Ajan bu tarif üzerinden topolojiyi değerlendiriyor ve kaynaklara özel öneriler içeren bir dayanıklılık raporu oluşturuyor. Daha da önemlisi, önerilen yapılandırmaların etkin olduğu, dağıtıma hazır modüler Bicep dosyaları üretebiliyor. Bunlar main.bicep, parametre dosyası ve kaynaklara ayrılmış Bicep modüllerini içerebiliyor.
Bence Start Resilient’ın asıl değeri burada ortaya çıkıyor. Dayanıklılık, uygulama devreye alındıktan sonra yapılacak bir düzeltme çalışması olmaktan çıkıp dağıtımın varsayılan bir parçasına dönüşüyor. Elbette üretilen mimari ve kod uzman kontrolünden geçirilmeden doğrudan üretim ortamına uygulanmamalı; ancak tasarım ve ilk şablon oluşturma süresini ciddi biçimde kısaltabilecek bir yaklaşım sunuyor.
Get Resilient: Mevcut Azure ortamını değerlendirmek
Gerçek hayatta kurumların büyük bölümü sıfırdan başlamıyor. Azure üzerinde çalışan, zaman içinde büyümüş ve farklı ekipler tarafından yönetilmiş iş yükleri bulunuyor. Get Resilient, mevcut ortamların dayanıklılık seviyesini anlamaya ve açıkları sistematik biçimde kapatmaya odaklanıyor.
Ajan, tek bir kaynağın veya bir uygulamayı oluşturan kaynak grubunun zone dayanıklılığını kontrol edebiliyor. Burada Azure Service Groups kullanılarak aynı uygulamaya ait kaynaklar mantıksal bir yapı altında toplanabiliyor. Böylece değerlendirme yalnızca tek tek kaynaklar üzerinden değil, uygulama bütünlüğü açısından yapılabiliyor.
Get Resilient ile şu tür sorular sorulabiliyor:
- Sanal makinem zone dayanıklılığına sahip mi?
- Storage hesabımı zone-redundant hale getirmek için ne yapmalıyım?
- Service Group içindeki kaynakların dayanıklılık durumu nedir?
- Veritabanında zone redundancy özelliğini açmadan önce hangi ön koşulları sağlamalıyım?
- Tespit edilen eksikleri gidermek için PowerShell, Azure CLI veya Bicep scriptleri üretir misin?
Ajan yalnızca sorunu göstermekle kalmıyor; gerekli izinleri, bölgesel kısıtlamaları ve yapılandırma bağımlılıklarını da belirlemeye çalışıyor. Ayrıca değişikliğin mevcut kaynak üzerinde yapılıp yapılamayacağını veya yeniden dağıtım gerektirip gerektirmediğini açıklıyor.
Bu ayrım son derece önemli. Örneğin desteklenen bazı servislerde zone dayanıklılığı mevcut kaynak üzerinde etkinleştirilebilirken, sanal makineler gibi bazı kaynaklar yeniden dağıtım gerektirebilir. Resiliency Agent, doğrudan değişiklik yapabildiği senaryolar ile yalnızca yönlendirme ve script sunduğu senaryoları birbirinden ayırıyor. Böylece uygulanacak değişikliğin olası maliyet ve kesinti etkisi daha baştan görülebiliyor.
Service Groups ve dayanıklılık hedefleri
Kurumsal ortamlarda kaynak bazlı değerlendirme tek başına yeterli değildir. Bir uygulama; sanal makinelerden, veritabanlarından, storage hesaplarından, ağ bileşenlerinden ve farklı PaaS servislerinden oluşabilir. Bu bileşenlerden yalnızca birinin dayanıklı olmaması, uygulamanın tamamı için tek hata noktası yaratabilir.
Resiliency Agent, Service Groups üzerinden aynı uygulamaya ait kaynakların mantıksal olarak gruplanmasına yardımcı oluyor. Ardından bu grup için zone dayanıklılığı hedefi tanımlanabiliyor, uyumluluk durumu kontrol edilebiliyor ve değişikliklerden sonra değerlendirme yenilenebiliyor. Gerekli durumlarda belirli kaynaklar hedef dışında da bırakılabiliyor.
Bu yaklaşım, dayanıklılık çalışmalarını tek seferlik bir kontrol listesi yerine izlenebilir bir yönetişim sürecine dönüştürme potansiyeli taşıyor.
Hangi çıktıları üretebiliyor?
Resiliency Agent’ın güçlü taraflarından biri, önerileri uygulanabilir çıktılara dönüştürmesi. Mevcut yetenekleri kapsamında:
- Dayanıklılık değerlendirme raporları,
- Kaynağa ve mimariye özel öneriler,
- Dağıtıma hazır modüler Bicep şablonları,
- PowerShell ve Azure CLI scriptleri,
- Mevcut kaynağı dönüştürme veya yeniden dağıtma adımları,
- Ön koşul ve engel analizleri,
- Gösterge niteliğinde maliyet etkisi
sunabiliyor. Get Resilient tarafında ARM ve Terraform dahil farklı çıktı formatlarıyla script üretimi de destekleniyor. Buna karşılık, sıfırdan mimari oluşturan Start Resilient akışındaki şablon üretimi bugün için ağırlıklı olarak Bicep odaklı.
Bugünkü sınırları neler?
Ürünün henüz preview aşamasında olduğunu unutmamak gerekiyor. Mevcut sürüm ağırlıklı olarak zonal resiliency, yani aynı Azure bölgesi içindeki Availability Zone arızalarına karşı dayanıklılık senaryolarına odaklanıyor.
Bu nedenle Resiliency Agent’ı bugün itibarıyla eksiksiz bir felaket kurtarma çözümü veya tüm iş sürekliliği sürecini tek başına yöneten bir platform olarak konumlandırmak doğru olmaz. Bölgeler arası dayanıklılık, uçtan uca felaket kurtarma planı, uygulama seviyesindeki RTO ve RPO gereksinimleri, veri tutarlılığı ve operasyonel prosedürler ayrıca ele alınmaya devam edilmeli.
Ayrıca yapay zeka tarafından üretilen mimari önerileri ve Infrastructure as Code çıktıları; kurum standartları, güvenlik gereksinimleri, maliyet modeli ve uygulama bağımlılıkları açısından mutlaka uzmanlar tarafından doğrulanmalı.
Nasıl kullanılır?
Azure Portal üzerinden Resiliency genel bakış sayfasına gidildikten sonra sağ üst bölümdeki Copilot simgesi seçiliyor. Açılan ajan listesinden Resiliency tercih edildiğinde önerilen başlangıç komutlarıyla veya doğal dilde yazılan özel bir taleple çalışmaya başlanabiliyor.
Ajan konuşma bağlamını koruduğu için süreç tek bir soru-cevap ile sınırlı değil. Önce Service Group oluşturup kaynakları eklemek, ardından dayanıklılık hedefi belirlemek, mevcut durumu kontrol etmek ve son olarak eksikleri giderecek scriptleri istemek mümkün.
Ben nasıl değerlendiriyorum?
Azure Copilot Resiliency Agent’ın en değerli yönü, dayanıklılık konusunu farklı ekranlara, dokümanlara ve ham sinyallere dağılmış bir çalışma olmaktan çıkarıp yönlendirmeli bir sürece dönüştürmesi.
Yeni projelerde doğru mimariyi daha baştan kurmak, mevcut projelerde ise hangi kaynağın neden risk oluşturduğunu ve bu riskin nasıl giderilebileceğini görmek önemli bir zaman kazancı sağlayabilir. Özellikle yüzlerce veya binlerce kaynağın bulunduğu ortamlarda, uygulama bileşenlerini Service Groups altında değerlendirerek hedef ve uyumluluk takibi yapmak kurumsal yönetişim açısından da dikkate değer.
Ancak bu araç mimari uzmanlığın yerini almıyor; aksine uzmanın daha hızlı analiz yapmasını ve uygulanabilir çıktıya daha kısa sürede ulaşmasını sağlayan bir yardımcı olarak konumlanıyor. Benim gözümde doğru yaklaşım da tam olarak bu: Yapay zekayı kararın sahibi değil, doğru karara ulaşmayı hızlandıran teknik bir ekip arkadaşı olarak kullanmak.
Resiliency Agent şu anda public preview aşamasında. Azure üzerinde yeni uygulama tasarlayan veya mevcut iş yüklerinin Availability Zone dayanıklılığını geliştirmek isteyen ekiplerin, kontrollü bir test ortamında deneyerek kendi senaryoları üzerinden değerlendirmesinde fayda görüyorum.
Daha fazla bilgi için Microsoft’un Azure Copilot Resiliency Agent dokümantasyonunu inceleyebilirsiniz.