“SLA’mız %99.9, bu harika” diyen bir müşteri yönetici ile geçen ay bir toplantıda oturdum. 10 dakika sonra şunu söyledim: “Yılda 8 saat 46 dakika kesinti size harika geliyor mu?” Suratında anlamayan bir bakış oldu. Çoğu kişi bulut SLA rakamlarını bir gurur meselesi olarak görüyor ama aslında operasyonel bir bütçe. Bu yazıda SLA’nın matematiğini, pazarlamanın üstünü örttüğü yerleri ve sahada gerçekten işe yarayan mimari kararları yazıyorum.

“Dokuzlar” ne ifade ediyor?

Yıllık kesinti süresi karşılığı:

• %99.0 → 3 gün 15 saat 39 dakika
• %99.9 → 8 saat 45 dakika (“üç dokuz”)
• %99.95 → 4 saat 22 dakika
• %99.99 → 52 dakika (“dört dokuz”)
• %99.999 → 5 dakika 15 saniye (“beş dokuz”)

Saatlik ciroyu bilen bir e-ticaret için hesap kolay: saat başı 50.000 TL ciro varsa, üç dokuz ile dört dokuz arasındaki fark yılda 400 bin TL’lik potansiyel kayba denk geliyor. Mimari kararı bu rakamı görmeden vermeyin.

SLA gerçekten nedir, ne değildir

SLA bir tazminat mekanizması değil, bir hizmet taahhüdü. İhlal durumunda bulut sağlayıcı o aya ait faturanın belirli yüzdesini kredi olarak iade eder. Azure’da tipik yapı:

• %99-99.9 arası → %10 credit
• %95-99 arası → %25 credit
• %95 altı → %100 credit

Üç kritik noktayı altını çizerek söylüyorum:

1. Credit otomatik gelmez. Destek talebi açıp log/metric kanıtını sunmanız gerekir. Kendim aç, takip et.
2. Credit iş kaybını karşılamaz. 1.000 USD’lık VM’in %25 kredisi = 250 USD. Aynı sürede kesinti size 50.000 USD’lık gelir kaybı yarattıysa, 250 USD sembolik kalır.
3. Planlı bakım SLA’ya sayılmaz. Microsoft önceden bildirdiği bakım pencerelerini SLA dışında tutar. Müşteri yanlış yapılandırması da dahil.

Yani SLA’yı “sigortam var” olarak düşünmek yanlış. “Bu rakamın altında kalırsam hak arayabilirim” olarak düşünmek doğru.

Azure SLA’larını doğru okumak

Aynı hizmetin farklı yapılandırmaları farklı SLA sunar. Bir VM’in tek başına mı, Availability Set’te mi, Availability Zone’da mı olduğuna bakmadan hiçbir SLA taahhüdü veremezsiniz:

• Tek VM, Premium SSD: %99.9
• Availability Set: %99.95
• Availability Zone (farklı zone’larda 2+ instance): %99.99

SQL Database için Business Critical %99.995 (sektör lideri), General Purpose %99.99. AKS uptime SLA açıkça satın alındığında %99.95; free tier’da SLA yok (best-effort). Storage için LRS %99.9, GRS okuma için %99.99. Cosmos DB single-region write ve multi-region write arasında fark var.

Satın alma kararı verirken bir Excel tablosu tutun: hizmet, katman, SLA, aylık maliyet. Yüksek SLA isteyenler için maliyet farkı her zaman değer. Dev ortamı için gereksiz dokuzlara para vermeyin.

Composite SLA — pazarlamanın söylemediği

Uygulamanız tek hizmet değil. Typical web app mimari:

• Azure Front Door — %99.99
• App Service — %99.95
• SQL Database Business Critical — %99.995
• Blob Storage LRS — %99.9

Seri bağlı (biri düşerse sistem düşer) composite SLA:

sla = 0.9999 * 0.9995 * 0.99995 * 0.999
    = 0.99835
    # ≈ %99.835
    # ≈ yılda 14 saat 27 dakika kesinti

Evet, tüm bileşenler çok yüksek görünürken composite yaklaşık %99.84’e düştü. Bu gerçekliğin farkında olmadan mimari kurmak, müşteriye veremeyeceğiniz söz vermek demek.

Redundancy ile SLA’yı nasıl yükseltirsiniz

Aynı bileşeni paralel iki region’da çalıştırıp önüne load balancer koyarsanız:

single = 0.9995  # tek region App Service
parallel = 1 - (1 - single) ** 2
         = 1 - 0.0005 ** 2
         = 0.99999975
         # ≈ beş dokuz

Harika mı? Bekleyin. Load balancer bir bileşen, o da SLA’ya katılır:

effective = 0.9999 * 0.99999975  # Front Door * parallel App Service
          ≈ 0.99989975
          ≈ %99.99

Yani dört dokuz’a ulaştık — beş değil. Her yeni bileşen SLA’yı düşürüyor, redundancy yükseltiyor. Mimari kararı bu matematiği yapmadan verilmemeli.

Pratik mimari desenleri

Multi-region active-active

Traffic Manager veya Front Door ile coğrafi yük dengeleme. Hem trafiği paylaşır hem bir region çökerse sağ kalan trafiği karşılar. DNS TTL ve health probe yapılandırması kritik; 30 saniye altı failover bu şekilde mümkün.

Active-passive with geo-replication

SQL Database auto-failover group ile primary bölge öldüğünde secondary otomatik promote olur. RPO ~5 saniye, RTO ~30 saniye. Veritabanı maliyeti neredeyse 2x ama dört dokuz’a çıkmanın bedeli bu.

Resilience patterns

SLA’nın tamamlayıcısı kod tarafındaki davranış. Retry + exponential backoff + circuit breaker + bulkhead. Polly (.NET), resilience4j (Java), tenacity (Python) — hangi dilde olursan ol, kullan. Geçici ağ hatasında uygulamanın 3 saniye içinde kendini toparlaması ile 3 dakika 5xx fırlatması arasındaki fark kullanıcı için bambaşka.

Error budget kültürü

Google SRE’den gelen pratik: %99.9 SLA hedefi ayda 43.2 dakika kesinti bütçesi. Bu bütçeyi aşmadığın sürece feature deploy edersin; aştığında tüm mühendislik efor’u güvenilirliğe yönlendirilir. İnovasyon ve risk arasında somut denge. Müşteride bu kültürü kurmak 6 ay sürüyor ama sonuç: hem feature velocity korunuyor hem SLA tutturuluyor.

İzleme ve raporlama

“SLA’mız %99.9” demek ile “Son 90 günde %99.87 gerçekleştik” demek arasında okyanus fark var. Azure Monitor + App Insights ile availability test, Log Analytics ile custom uptime sorgusu:

AppServiceHTTPLogs
| where TimeGenerated > ago(30d)
| summarize
    total = count(),
    errors = countif(ScStatus >= 500)
    by bin(TimeGenerated, 1m)
| extend available = iff(errors == 0, 1, 0)
| summarize uptime = avg(available) * 100

Status page (Azure’da üçüncü parti Statuspage.io veya kendi yazdığımız lightweight sayfa) müşteriye transparanlık verir. Planlı bakımları önceden duyurmak güven kazandırır.

Sık Sorulan Sorular

Her zaman en yüksek SLA’yı almalı mıyım?
Hayır. Dev/test ortamı için %99.9 bile gereksiz lüks — oraya tek VM koy, geceleri kapat. Üretim bile her bileşen için dört dokuz gerektirmez; kullanıcıya dokunan kritik yolu (critical path) analiz edin, sadece orayı yükseltin. Non-critical admin panel %99.9’da kalsın.

Planlı bakım SLA’ya dahil değil, ne yapayım?
Multi-region mimari ile bakım zamanı trafiği diğer region’a kaydırırsın. Azure bakımları region bazında yapar, ikisi aynı anda bakımda olmaz. Bu yüzden dört dokuz ve üzeri SLA multi-region olmadan gerçekçi değil.

SLA ihlali için credit nasıl alınır?
Azure portalda destek talebi → billing → SLA credit. Ekinde availability metric, health event timeline. Microsoft kendisi tespit edip otomatik kredi vermez — talep etmezsen vermez. Ayın sonunda uptime raporu çıkarıp ihlal varsa 30 gün içinde talep edin.

Sonuç

SLA bir pazarlama rakamı değil, mimari kararınızı şekillendiren bir matematik. Composite SLA’yı hesaplayın, hangi bileşenin sizi aşağı çektiğini görün, redundancy’i oraya yatırın. Error budget kültürüyle inovasyon ve risk arasında denge kurun. Ve sakın SLA credit’i iş sürekliliği planının yerine koymayın — o bir telafi mekanizması, sigorta değil.

CloudSpark bulut mimarisi danışmanlığı ile yüksek erişilebilirlik, iş sürekliliği ve realistik SLA hedefleri konusunda yanınızdayız.