SLO, SLI ve Error Budget: Servis Güvenilirliğini Yönetmek

Bir servisin "iyi çalıştığını" ekip içinde herkes farklı tanımlayabilir. Geliştirici için bu, deploy'un sorunsuz geçmesi olabilir; ürün ekibi için kullanıcı şikayetinin azalması; operasyon içinse gece pager'ının çalmaması. SRE pratiğinin gücü burada ortaya çıkar: güvenilirliği sezgisel değil, ölçülebilir bir sözleşmeye dönüştürür.

Bu sözleşmenin üç temel parçası vardır: SLI, SLO ve error budget.

Kavramlar Netleşsin

• SLI (Service Level Indicator): Ölçtüğün metrik.
• SLO (Service Level Objective): Hedeflediğin seviye.
• SLA (Service Level Agreement): Müşteriyle yapılan resmi taahhüt.

Örnek:

• SLI: "Başarılı HTTP yanıt oranı"
• SLO: "30 gün içinde %99.9 başarı"

Neden SLO?

SLO yalnızca teknik KPI değildir; ürün hızı ile sistem kalitesi arasındaki denge aracıdır. Çok agresif özellik geliştirme, incident riskini artırır. Çok konservatif davranmak da inovasyonu yavaşlatır. Error budget bu dengeyi rakama çevirir.

30 günlük hedef: %99.9 availability
Toplam hata payı: %0.1

30 gün = 43,200 dakika
Hata bütçesi = 43.2 dakika / 30 gün

Bu şu anlama gelir: Ay boyunca toplam 43.2 dakikayı aşan "kullanıcı etkili kesinti" yaşarsan bütçe biter. Bütçe bittiyse yeni riskli release'ler durdurulur, öncelik stabilizasyon olur.

SLI Seçerken Altın Kural

Sadece altyapı metrikleri yeterli değildir. CPU düşük olabilir ama kullanıcı checkout yapamıyorsa sistem başarısızdır. Bu yüzden SLI mümkün olduğunca kullanıcıya yakın seçilmelidir.

İyi SLI örnekleri:

• API success rate (2xx/3xx oranı)
• P95 latency (özellikle kritik endpoint)
• Checkout completion rate
• Mesaj teslim süresi (event-driven sistemlerde)

Kötü SLI örnekleri:

• Ortalama CPU
• Pod sayısı
• Sadece teknik log sayacı, kullanıcı etkisi olmayan metrikler

Multi-Window, Multi-Burn-Rate Alarm

Sadece tek pencerede alarm üretmek geç veya gürültülü olabilir. Daha iyi yaklaşım:

Kısa pencere (5m) + yüksek burn rate  -> kritik alarm
Uzun pencere (1h/6h) + orta burn rate -> uyarı

Burn rate, error budget'in ne hızla tüketildiğini gösterir. 10x burn rate, normalden 10 kat hızlı bütçe yakıyorsun demektir. Böylece "şu an küçük görünen sorun" birkaç saatte ay hedefini bitirebilir, erken yakalarsın.

Ekip Karar Mekanizmasına Bağlama

SLO raporunu dashboard'a koymak yetmez; release sürecine bağlamak gerekir:

1. Error budget sağlıklıysa feature rollout devam.
2. Bütçe hızlı tükeniyorsa rollout yüzdesi düşürülür.
3. Bütçe bittiyse güvenilirlik sprint'i zorunlu olur.

Bu kural politikası önceden tanımlanırsa kriz anında tartışma azalır. Karar kişi bazlı değil veri bazlı verilir.

Pratik Uygulama Planı

Hafta 1:

• En kritik 2 kullanıcı akışını seç (ör. login, ödeme).
• Bu akışlar için ölçülebilir SLI tanımla.

Hafta 2:

• 30 günlük başlangıç SLO'su belirle (gerçekçi hedef).
• Dashboard ve temel alarm kur.

Hafta 3:

• Incident sonrası postmortem'e "SLO etkisi" bölümü ekle.
• Release checklist'ine "error budget durumu" maddesi koy.

Hafta 4:

• Alarm gürültüsünü azalt, burn-rate eşiklerini kalibre et.
• Yönetime aylık güvenilirlik raporu çıkar.

Sık Yapılan Hatalar

• Her servise aynı SLO'yu kopyalamak.
• Tarihsel veriye bakmadan imkansız hedef koymak.
• Çok fazla SLI tanımlayıp odak kaybetmek.
• SLO ihlalinde aksiyon planı olmamak.

Sonuç

SLO/SLI disiplini, "sistem iyi mi?" sorusunu soyuttan çıkarıp yönetilebilir hale getirir. Error budget ise hız ve kalite arasında ekipçe kabul edilmiş bir trafik ışığı görevi görür. Bu yaklaşımı doğru kurduğunda iki şey aynı anda mümkün olur: daha hızlı ürün geliştirmek ve daha az üretim krizi yaşamak. Çünkü güvenilirlik artık kişisel yorum değil, sayılarla yönetilen bir mühendislik pratiğidir.