SLA Monitoring: %99,9 Uptime Nasıl Takip Edilir ve Raporlanır?

"%99,9 uptime garanti ediyoruz." Çoğu SaaS şirketinin verdiği bir söz. Ancak kaç tanesi bunu gerçekten kanıtlayabilir? SLA monitoring, bu sözü pazarlama metninden ölçülebilir, raporlanabilir bir taahhüde dönüştürür.

Uptime SLA'larını Anlamak

"%99,9 Uptime" Gerçekte Ne Anlama Geliyor?

Rakamlar etkileyici görünür, ancak her "dokuz" arasındaki fark önemlidir:

| SLA | Yıllık Downtime | Aylık Downtime |
|-----|----------------|-----------------|
| %99 | 3 gün, 15 saat | 7 saat, 18 dk |
| %99,5 | 1 gün, 19 saat | 3 saat, 39 dk |
| %99,9 | 8 saat, 46 dk | 43 dk, 50 sn |
| %99,95 | 4 saat, 23 dk | 21 dk, 55 sn |
| %99,99 | 52 dk, 36 sn | 4 dk, 23 sn |

%99,9'da, ayda 44 dakikadan az izin verilen downtime'ınız var. Bu planlı bakım, sürpriz kesintiler ve kısmi degradasyonları içerir. Sıkı bir bütçedir.

SLA vs SLO vs SLI

Bu terimler sıklıkla karıştırılır:

• SLI (Service Level Indicator) — Ölçtüğünüz metrik: uptime yüzdesi, response time, hata oranı.
• SLO (Service Level Objective) — Dahili hedefiniz: "API zamanın %99,95'inde erişilebilir olmalıdır."
• SLA (Service Level Agreement) — Finansal sonuçları olan sözleşmesel taahhüt: "Uptime %99,9'un altına düşerse müşteriler hizmet kredisi alır."

SLO'nuz SLA'nızdan daha sıkı olmalıdır. SLA'nız %99,9 vaat ediyorsa, dahili hedefiniz %99,95 veya daha yüksek olmalıdır. Bu, SLA ihlalleri finansal cezaları tetiklemeden önce size bir tampon sağlar.

Uptime Nasıl Ölçülür?

Temel Formül

```
Uptime % = ((Toplam Dakika - Downtime Dakikası) / Toplam Dakika) × 100
```

30 günlük bir ay için (43.200 dakika):

• 20 dakika downtime = %99,954 uptime
• 44 dakika downtime = %99,898 uptime (%99,9'da SLA ihlali)
• 120 dakika downtime = %99,722 uptime

Downtime Olarak Ne Sayılır?

Burada nüanslar devreye girer. SLA'nız açıkça tanımlamalıdır:

Genellikle downtime sayılır:

• Tam hizmet kullanılamazlığı (5xx hataları, timeout'lar)
• Ciddi performans düşüşü (response time'lar normalin 10 katından fazla)
• Kullanıcı erişimini engelleyen authentication arızaları
• Veri kaybı veya bozulma olayları

Genellikle hariç tutulur:

• Planlanmış bakım pencereleri (önceden bildirimle)
• Mücbir sebepler (doğal afetler, büyük internet kesintileri)
• Müşterinin neden olduğu sorunlar (yanlış yapılandırılmış API çağrıları)
• Kontrolünüz dışındaki üçüncü taraf bağımlılıkları

Bu tanımları SLA'nızda belgeleyin. Belirsizlik kimseye fayda sağlamaz.

SLA Uyumluluğu İçin Monitoring

Uptime'ı SLA amaçlı doğru şekilde takip etmek için:

Sık kontrol edin: 1 dakika veya 30 saniyelik kontrol aralıkları size hassas downtime ölçümleri verir. 5 dakikalık bir aralık, downtime ölçümlerinizin yalnızca ±5 dakika doğruluğunda olduğu anlamına gelir — aylık bütçeniz 44 dakika olduğunda bu önemlidir.

Birden fazla konumdan izleyin: Yalnızca Avrupalı kullanıcıları etkileyen bir kesinti yine de bir kesintidir. Çok bölgeli monitoring, yerelleşmiş sorunları yakalamanızı sağlar.

Bileşen düzeyinde uptime takip edin: SLA'nız genel hizmeti kapsayabilir, ancak bileşen başına uptime takibi zayıf halkaları belirlemenize yardımcı olur.

Bakım pencerelerini hariç tutun: SLA'nız planlanmış bakıma izin veriyorsa, monitoring aracınızın bakım pencerelerini desteklediğinden emin olun, böylece bu süreler uptime'ınıza karşı sayılmaz.

SLA Raporu Oluşturma

Temel Metrikler

Her SLA raporu şunları içermelidir:

1. Genel uptime yüzdesi — Ana başlık rakamı.
2. Incident sayısı — Hizmetin kaç kez çöktüğü.
3. Toplam downtime — Toplam kullanılamazlık dakikaları/saatleri.
4. Ortalama Tespit Süresi (MTTD) — Her sorunu ne kadar hızlı fark ettiniz.
5. Ortalama Kurtarma Süresi (MTTR) — Her sorunun ne kadar hızlı çözüldüğü.
6. En uzun tek incident — Raporlama dönemindeki en kötü kesintiniz.
7. Trend karşılaştırması — Bu dönemin önceki dönemlerle karşılaştırması.

Raporlama Sıklığı

• Aylık: Çoğu SLA anlaşması için standart. Yukarıdaki metriklerin yanı sıra zaman damgaları ve açıklamalarla birlikte incident listesi dahil edin.
• Üç aylık: İş değerlendirmesi formatı. Trendleri, iyileştirme girişimlerini ve altyapı yatırım planlarını dahil edin.
• Yıllık: Liderlik ve kurumsal müşteriler için stratejik genel bakış. Yıldan yıla karşılaştırmaları ve güvenilirlik yol haritasını dahil edin.

Yüksek Uptime'ı Koruma Stratejileri

Error Budget Yönetimi

Google'ın SRE çerçevesinden gelen "error budget" konsepti güçlüdür. Error budget'ınız %100 ile SLO hedefiniz arasındaki farktır.

30 gün üzerinden %99,9 SLO için error budget'ınız 43 dakikadır.

Bütçe dahilindeyken hızlı hareket edebilirsiniz — sık deploy edin, deney yapın ve hesaplanmış riskler alın. Bütçeniz azaldığında yavaşlayın — kritik olmayan deployment'ları dondurun, testleri artırın ve güvenilirliğe odaklanın.

Doğru Alanlara Yatırım Yapın

Tüm uptime iyileştirmeleri eşit değildir. Odaklanın:

1. Tek hata noktalarını ortadan kaldırmak — Replikası olmayan database, failover'ı olmayan sunucu, yedeği olmayan DNS sağlayıcısı.
2. Deployment riskini azaltmak — Blue-green deployment'lar, canary release'ler ve otomatik rollback'ler, deployment kaynaklı kesintileri önler.
3. Tespit hızını artırmak — Daha hızlı tespit, daha kısa kesintiler anlamına gelir.
4. Kurtarmayı otomatikleştirmek — Başarısız süreçleri yeniden başlatan, trafiği yeniden yönlendiren ve kaynakları otomatik olarak ölçeklendiren kendini iyileştiren sistemler.

Şeffaflık İçin Status Page Kullanın

Halka açık bir status page doğrudan uptime'ı iyileştirmez, ancak müşterilerin güvenilirliğinizi algılama şeklini dönüştürür:

• Incident'lar sırasında proaktif iletişim güven oluşturur
• Incident geçmişi geçmiş performansınızı gösterir
• Abone bildirimleri müşterileri bilgilendirir
• Şeffaflık destek talebi hacmini azaltır

Sonuç

SLA monitoring sadece sözleşmesel uyumluluk hakkında değildir — güvenilirlik kültürü oluşturmakla ilgilidir. Uptime'ı titizlikle ölçtüğünüzde, şeffaf bir şekilde takip ettiğinizde ve error budget'ınızı bilinçli olarak yönettiğinizde, hizmetinizi sürekli olarak iyileştiren bir geri bildirim döngüsü oluşturursunuz.

Net uptime hedefleri tanımlayarak, hassas monitoring kurarak ve dürüstçe raporlayarak başlayın. Rakamlar takip edecektir.

SLA'nızı hassasiyetle takip edin. Ücretsiz monitoring başlatın — detaylı uptime raporları, incident takibi ve status page'ler dahil.