Mühendisleri Gece Uyandırmayan SLO Tasarımı
- Küçük bir serviste %99.9'un üzerindeki bir SLO hedefi genellikle müşteri acısına değil, anlık ağ gürültüsüne alarm çalar.
- 30 günlük kayan (rolling) pencereler neredeyse her metrik için takvim ayı pencerelerinden daha sağlıklıdır.
- Çoklu pencereli yanma hızı (multi-window burn-rate) alarmları, tek eşikli alarmlara kıyasla gürültüyü %80 azaltır.
- Kimsenin uygulamadığı bir hata bütçesi operasyonel bir disiplin değil, ekrandaki dekoratif bir sayıdır.
Çalıştığımız bir ekipte müşteriye dönük bir servis için %99.99 erişilebilirlik SLO’su ve %99.95’te çalan tek eşikli bir alarm kurulmuştu. Beş kişilik nöbet ekibi haftada ortalama dört kez (ikisi gece 03:00’te) uyanıyordu ve alarmların neredeyse tamamı mühendis bilgisayarı açana kadar kendi kendine düzelen anlık dalgalanmalardı. Bir çeyrek içinde iki mühendis rotasyondan çıkmak istedi.
Sorun SLO kavramında değil, tasarımındaki beş tercihteydi:
1. Gerçekçi Hedef, 2. Kayan Pencere ve 3. Müşteri Odaklı SLI
Mühendisler kulağa titiz geldiği için %99.99 (ayda 4 dakika 22 saniye izin) seçer ancak çoğu B2B SaaS ürünü için doğru başlangıç %99.9 (ayda 43 dakika kesinti bütçesi) seviyesidir; her ek dokuz, altyapı maliyetini ve nöbet stresini katlayarak artırır.
İkinci olarak, ayın 1’inde sıfırlanan takvim ayı yerine 30 günlük kayan (rolling) pencere kullanın; ayın 28’indeki büyük bir kesinti üç gün sonra unutulmamalıdır. Üçüncü olarak SLI (Hizmet Seviyesi Göstergesi) yük dengeleyicinin gördüğü tüm HTTP 200’leri değil, müşterinin başarı saydığı tam yaşam döngüsünü (geçerli gövde + şema uyumu + gecikme bütçesi içinde yanıt) ölçmelidir.
4. Hata Bütçesi Politikası ve 5. Çoklu Pencereli Yanma Hızı Alarmları
Yazılı bir politikası olmayan hata bütçesi dekoratiftir. Kalan bütçe %25’in üzerindeyken özellikler tam hızda çıkar; %10’un altına indiğinde ise bütçe %50’nin üzerine dönene kadar yeni özellik dağıtımları dondurulur ve ekip güvenilirlik işlerine odaklanır.
Son olarak tek eşikli alarmlar yerine Google SRE modelindeki çoklu pencereli yanma hızı (multi-window burn-rate) alarmlarını kurun. Örneğin hem son 5 dakikada hem son 1 saatte bütçe normalin 14.4 katı hızla yanıyorsa (1 saatte aylık bütçenin %2’si) nöbetçiyi uyandırın; 6 saat ve 3 günlük pencerede 3 kat yanma hızı varsa gece uyandırmak yerine gündüz incelenecek bir görev bileti açın. Yalnızca bu değişiklik bile gereksiz nöbet çağrılarını yaklaşık %80 oranında keser.
Sıkça sorulan sorular
Hangi SLO hedefiyle başlamalıyız?
İçgüdülerinizin söylediğinden daha düşük bir hedefle. Çoğu ekip %99.99'a uzanır ancak çok az ürün buna gerçekten ihtiyaç duyar. Müşteriye dönük SaaS servislerinde %99.9 (ayda 43 dakika kesinti bütçesi), kritik olmayan yollarda %99.5 ile başlayın.
Her servisin bir SLO hedefi olmalı mı?
Hayır. SLO'lar bozulmanın doğrudan müşteri acısına dönüştüğü servisler içindir. İç araçlar, toplu işler ve cron görevleri için basit bir 'çalışıyor mu' sağlık kontrolü yeterlidir; her şeye SLO koymak sinyali sulandırır.
Hata bütçesi tükendiğinde sorumluluk kimdedir?
Mühendislik ve ürün yönetiminde ortaklaşa. SLO'yu gerçek kılan kural, tükenen hata bütçesinin o servisteki yeni özellik dağıtımlarını bütçe toparlanana kadar dondurmasıdır.