Bulut hizmetleri kullanırken hizmet sağlayıcınızın size verdiği en önemli taahhüt Servis Seviye Anlaşmasıdır (SLA – Service Level Agreement). SLA, hangi hizmetin ne düzeyde erişilebilirlik, performans ve destek garantisi sunduğunu tanımlayan yasal bağlayıcılığı olan bir sözleşmedir. Bulut ortamına taşındığınızda altyapının fiziksel kontrolü sizde olmadığı için, SLA’lar hizmet kalitesinin garantisi haline gelir.

SLA Nedir ve Neden Önemlidir?

SLA, hizmet sağlayıcı ile müşteri arasında hizmet kalitesi beklentilerini resmileştiren bir anlaşmadır. Bulut bilişim bağlamında SLA genellikle yüzdelik bir erişilebilirlik değeri ile ifade edilir: yüzde 99,9 (üç dokuz), yüzde 99,95, yüzde 99,99 (dört dokuz) gibi. Bu rakamlar arasındaki fark küçük görünse de gerçek etkileri büyüktür.

Yüzde 99,9 SLA yılda yaklaşık 8 saat 46 dakika plansız kesintiye karşılık gelir. Yüzde 99,95 ise yılda yaklaşık 4 saat 23 dakika. Yüzde 99,99 SLA yılda yalnızca 52 dakika kesintiye izin verir. Kritik iş uygulamaları için bu farklar ciddi iş etkisi yaratabilir. Örneğin bir e-ticaret platformunda saatlik ciro 50.000 TL ise, yüzde 99,9 ile yüzde 99,99 arasındaki fark yılda yaklaşık 400.000 TL’lik potansiyel kayba karşılık gelir.

SLA Bileşenleri

Bir bulut SLA’sı birkaç temel bileşenden oluşur. Birincisi erişilebilirlik (availability) garantisidir ve yukarıda bahsettiğimiz yüzdelik değerlerle ifade edilir. İkincisi performans metrikleridir: gecikme süresi (latency), aktarım hızı (throughput) ve işlem kapasitesi (transactions per second) gibi değerler belirli bir eşiğin altında taahhüt edilir. Üçüncüsü destek seviyesi ve yanıt süreleridir: kritik bir sorun için ne kadar sürede ilk yanıt geleceği, ne kadar sürede çözüm sunulacağı garanti edilir.

Dördüncü ve sıklıkla gözden kaçan bileşen SLA kapsamı ve istisnalarıdır. Hangi hizmetlerin SLA kapsamında olduğu, planlı bakımların (scheduled maintenance) SLA hesabına dahil edilip edilmediği, müşteri kaynaklı sorunların SLA ihlali sayılıp sayılmadığı gibi detaylar dikkatle okunmalıdır. Örneğin Azure’da bir VM tek instance olarak çalıştırılıyorsa SLA farklıdır, Availability Set’te çalıştırılıyorsa farklıdır, Availability Zone’da çalıştırılıyorsa çok daha yüksek bir SLA geçerlidir.

Azure SLA Örnekleri

Azure hizmetlerinin SLA değerleri hizmete ve yapılandırmaya göre değişir. Azure Virtual Machines Availability Zone’da dağıtıldığında yüzde 99,99, Availability Set’te yüzde 99,95, tekil VM’de ise Premium SSD kullanımına bağlı olarak yüzde 99,9 SLA sunar. Azure SQL Database Business Critical katmanında yüzde 99,995 SLA ile sektörün en yüksek değerlerinden birini sunar. Azure Kubernetes Service (AKS) için SLA açıkça etkinleştirildiğinde yüzde 99,95 garanti edilir ve bu ücretli bir ek özelliktir. Azure Blob Storage LRS (Locally Redundant Storage) için yüzde 99,9, GRS (Geo-Redundant Storage) için yüzde 99,99 okuma erişimi SLA’sı geçerlidir.

Önemli bir nokta: Azure’da farklı katmanlardaki hizmetler farklı SLA değerleri sunar. Bir Azure Functions Consumption planı ile Premium planı aynı SLA’ya sahip değildir. Azure Cosmos DB’nin single-region yazma erişimi ile multi-region yazma erişimi farklı SLA’larla taahhüt edilir. Üst katman hizmet genellikle daha yüksek SLA sunar ancak maliyeti de artar.

Bileşik SLA Hesaplama

Gerçek dünya uygulamaları birden fazla Azure hizmetinden oluşur ve uygulamanızın toplam SLA’sı bu hizmetlerin SLA’larının çarpımıyla hesaplanır. Buna bileşik SLA (composite SLA) denir. Örneğin uygulamanız Azure App Service (yüzde 99,95) ve Azure SQL Database (yüzde 99,99) kullanıyorsa, bileşik SLA şöyledir: 0,9995 çarpı 0,9999 eşittir 0,9994 yani yaklaşık yüzde 99,94. Her eklenen bileşen toplam SLA’yı biraz düşürür.

Bu durum mimari tasarımda önemli kararları etkiler. Üç bileşenli bir uygulamada her bileşen yüzde 99,9 SLA sunsa bile bileşik SLA yaklaşık yüzde 99,7’ye düşer. Bu, yılda yaklaşık 26 saat kesintiye karşılık gelir. Bileşik SLA’yı yükseltmek için birkaç strateji uygulanabilir: yedekli (redundant) bileşenler ekleyerek paralel SLA hesaplaması yapılır, bağımlılıklar azaltılarak bileşen sayısı minimize edilir ya da daha yüksek SLA sunan hizmet katmanları tercih edilir.

SLA İhlali ve Kredi Mekanizması

Bulut sağlayıcı SLA’yı karşılayamadığında müşteriye servis kredisi verir. Bu kredi genellikle aylık fatura üzerinden indirim olarak uygulanır. Azure’da SLA ihlali durumunda tipik kredi yapısı şöyledir: erişilebilirlik yüzde 99-99,9 arasında kaldığında yüzde 10 kredi, yüzde 95-99 arasında yüzde 25 kredi, yüzde 95’in altına düştüğünde yüzde 100 kredi verilir.

Ancak burada iki önemli nokta vardır. Birincisi, kredi otomatik uygulanmaz; müşterinin destek talebi açarak kredi talep etmesi gerekir ve SLA ihlalini kanıtlayan loglar veya metrikler sunması beklenir. İkincisi, kredi miktarı genellikle o hizmetin aylık maliyesinin belirli bir yüzdesiyle sınırlıdır ve iş kaybını karşılamaz. Dolayısıyla SLA kredisi bir tazminat değil, sembolik bir telafi mekanizmasıdır. Gerçek iş kaybınızı karşılamak için iş sürekliliği planlaması ve uygun sigorta mekanizmaları düşünülmelidir.

SLA Odaklı Mimari Tasarım

Yüksek SLA hedefleyen mimari tasarımda uygulanabilecek stratejiler şunlardır. Multi-region dağıtım ile bir bölge tamamen çöktüğünde diğer bölge trafiği devralır. Azure Traffic Manager veya Azure Front Door ile coğrafi yük dengeleme yapılır. Veritabanı katmanında aktif geo-replikasyon ile ikincil bölgede okuma kopyası tutulur ve birincil bölge arızalandığında otomatik failover devreye girer.

Asynchronous tasarım desenleri de SLA’yı artırır. Bir bileşen geçici olarak erişilemez olduğunda isteklerin kuyrukta beklemesi (queue-based load leveling), yeniden deneme mantığı (retry) ve devre kesici (circuit breaker) desenleri uygulamanın dayanıklılığını artırır. Azure SDK’ları bu desenleri yerleşik olarak destekler; örneğin Azure Storage SDK otomatik retry mekanizmasıyla geçici ağ hatalarını sessizce yönetir.

SLA İzleme ve Raporlama

Kendi uygulamanızın SLA değerini izlemek ve raporlamak için Azure Monitor, Application Insights ve Log Analytics kullanılır. Uptime kontrolü, yanıt süresi izleme ve hata oranı takibi ile gerçek zamanlı SLA durumunuzu görebilirsiniz. Aylık SLA raporları oluşturarak trend analizi yapabilir ve SLA hedeflerinize ne kadar yakın olduğunuzu ölçebilirsiniz. Statuspage veya benzeri araçlarla müşterilerinize anlık servis durumu gösterebilir, planlı bakımları önceden duyurabilirsiniz.

SLA Hesaplama Örnekleri

Birleşik SLA hesaplamasını somut bir örnekle gösterelim. Tipik bir web uygulaması mimarisinde App Service (%99.95), Azure SQL Database (%99.99) ve Azure Blob Storage (%99.9) kullanılsın. Seri bağlı bileşenler için birleşik SLA = 0.9995 × 0.9999 × 0.999 = %99.84’tür. Bu yıllık yaklaşık 14 saat kesinti demektir. İş gereksiniminiz %99.99 ise mimariyi yeniden düşünmeniz gerekir.

Yüksek erişilebilirlik için bileşenleri paralel (redundant) yapılandırın. Aynı App Service’i iki bölgede çalıştırırsanız tek bir bileşenin SLA’ı 1 – (1-0.9995)^2 = %99.999975 olur. Front Door veya Traffic Manager ile bölgeler arası yük dengeleme yaparak birleşik SLA’yı dramatik biçimde artırabilirsiniz. Ancak unutmayın: yük dengeleyicinin kendisi de bir bileşendir ve SLA hesabına dahil edilmelidir.

SLA İhlali Durumunda Ne Olur?

Microsoft, SLA ihlali durumunda hizmet kredisi sunar. Aylık uptime yüzdesine göre fatura indirimi uygulanır. Tipik olarak %99-99.9 arasında %25, %95-99 arasında %50 ve %95 altında %100 kredi verilir. Ancak kredi otomatik olarak uygulanmaz, müşterinin destek talebi oluşturarak kredi talep etmesi gerekir. SLA hesabında yalnızca Microsoft kaynaklı kesintiler sayılır; müşterinin yanlış yapılandırması veya bakım pencereleri hariç tutulur.

Pratik SLA Yönetimi

SLA yönetimi yalnızca bir sayıyı izlemek değildir, operasyonel bir kültürdür. Error budget kavramını benimseyin: %99.9 SLA hedefi ayda 43.2 dakika kesintiye izin verir. Bu süreyi aşmadığınız sürece yeni özellik deploy’ları yapabilirsiniz; aştığınızda ise tüm geliştirme effort’u güvenilirlik iyileştirmelerine yönlendirilir. Bu yaklaşım Google’ın SRE pratiğinden gelir ve risk ile inovasyon arasında somut bir denge kurar. Status page ile kullanıcılarınıza kesinti bilgilerini transparan biçimde iletin. Azure Resource Health ve Service Health alertlerini yapılandırarak sorunlardan erken haberdar olun.

Sonuç

SLA, bulut bilişimde hizmet kalitesinin ölçülebilir ve hesap verilebilir olmasını sağlayan temel mekanizmadır. Doğru SLA değerlerini anlamak, bileşik SLA hesaplamak, yüksek erişilebilirlik için mimari kararlar almak ve SLA ihlallerinde hakklarınızı bilmek bulut stratejinizin ayrılmaz parçasıdır.

Cloudspark bulut danışmanlığı hizmetlerimizle iş sürekliliği planlaması ve yüksek erişilebilirlik mimarisi konusunda yanınızdayız.