Çoğu üretim ekibi, alarm yorgunluğundan şikayet eder. Sebep genelde tek: alarmlar semptomlar üzerinden değil, eşikler üzerinden kurulur. Bir CPU değeri %85’i geçince uyaran sistem, kullanıcının gerçekten etkilenip etkilenmediğini bilmez.
Service Level Objective (SLO) nedir?
SLO, “kullanıcı için hizmetin kabul edilebilir olduğu durumun” sayısal tanımıdır. Örneğin:
- Erişilebilirlik: son 28 günün %99.9’unda en az bir başarılı yanıt
- Gecikme: son 28 günde isteklerin %95’i 250 ms altında
SLO, ne kadar mükemmel olmalıyız sorusuna cevaptır. Geri kalan kısım — yani hata bütçesi — risk almak için harcanabilir.
SLO-temelli alarm
Burada anahtar kavram burn rate’tir: hata bütçenizi ne hızda harcıyorsunuz?
burn_rate = (hata_oranı / (1 - SLO_hedefi))
İki seviyeli alarm tasarımı önerimiz:
- Hızlı. 1 saatlik pencere, burn rate > 14.4 → bütçeyi 2 günde bitirir → sayfa.
- Yavaş. 6 saatlik pencere, burn rate > 6 → bütçeyi 5 günde bitirir → ticket.
Bu yaklaşım, kısa dalgalanmaları yutar ama gerçek bütçe yanmasını yakalar.
Pratik öneriler
- Her servise değil, kullanıcı yolculuğuna SLO koyun. Checkout, login, search gibi.
- Alarmlar runbook’a bağlı olsun. Sayfa atan her alarmın çözüm adımları yazılı olmalı.
- Bütçe konuştuğunda durun. Aylık bütçe yandıysa yeni özellik değil, kararlılık çalışılır.
İyi tasarlanmış SLO’lar, gece 3’te boşuna uyandırılmayan ekiplerin ortak sırrıdır.
