SLO Nedir? Hizmet Seviyesi Hedefleri Detaylı Rehberi

SLO nedir? Service Level Objective (SLO), bir ekibin kendisine belirlediği iç güvenilirlik hedefidir. Müşteri sözleşmesi değildir, gözlemlenebilirlik yığınından gelen ham bir metrik de değildir. Bir SLO'nun sorduğu soru basittir: bu servisi ne kadar güvenilir olmalı ve bunu nasıl ölçeceğiz?

Tam bir SLO şöyle görünür: /api/checkout adresine yapılan HTTP isteklerin %99,9'u başarılı bir durum döndürmeli ve 300ms içinde tamamlanmalı, 30 günlük kayan bir pencere üzerinden ölçülerek. Üç bileşen var: ölçüm, hedef ve zaman penceresi. Üçü de önemlidir.

SLI, SLO, SLA: Üç Farklı Anlamı Olan Kısaltma

Bu üç terim hep bir arada görünür. Ekipler bunları birbirinin yerine kullanır. Ancak farklı şeyler açıklar.

SLI (Service Level Indicator) izleme sisteminizin ürettiği ham ölçümdür. Toplam isteklerin yüzde olarak hata oranı. P99 gecikme süresi milisaniye cinsinden. Başarılı veritabanı yazışlarının yüzdesi. SLI, Datadog, Grafana ya da çalıştırdığınız başka bir yığından çıkan sayıdır. Ne olduğunu söyler.

SLO (Service Level Objective) SLI üzerine tanımladığınız hedefidir. Soruyu cevaplar: bu SLI'ın alabildiği tüm değerlerden hangisi aralığı kabul edilebilir olarak sayılır? SLI'nız hata oranıysa ve SLO'nuz "hata oranı 5 dakikalık pencerelerin %99'unda %0,1'in altında" ise, o zaman yalnızca bir dashboard'daki sayı değil, geçme/başarısızlık testiniz var.

SLA (Service Level Agreement) aynı mantığın dış versiyonudur, kontraktüel sonuçları vardır. SLA'nız "% 99,5 çalışma süresi ya da %20 hizmet kredisi veririz" diyebilir. SLO'nuz bu eşiğin üzerinde olmalı, böylece ekip SLA ihlalinin müşteri görüşmesine dönmesinden önce bozulmayı fark etsin.

SLO ile SLA arasındaki boşluk ihmal için bir yastık değildir. "Biz bir ihlale doğru hareket ediyoruz" i "şimdi bunu düzeltmek için zamanımız var" a çeviren tasarlanmış bir kenar boşluğudur.

Bir önemli ayrım daha: SLI'lar sürekli ölçülür, SLO'lar bir pencere üzerinden değerlendirilir. Aynı hata oranı yedi gün versus 30 gün üzerinde ölçüldüğünde çok farklı geçme/başarısızlık sonuçları verir. Kötü bir saat yedi günlük bir pencerede oldukça önemli. 30 günlük bir pencerede, kabaca dönemin yüzde biri. Doğru pencereyi seçmek hedefi seçmek kadar önemlidir.

"Ne Kadar Güvenilir?" Tamamlanmış Bir Soru Değil

Sayı seçmeden önce, servisin bozulması sırasında kullanıcının ne deneyimleyeceğini anlamalısınız. "Beş dokuz lazım" ambisyon ifadesidir, ölçüm değildir. Bir ödeme API'si %99,999 erişilebilirlikte saniyede kabaca 26 saniye hata anlamına gelir. Saniyede on işlem işleyen bir servis için uygun olabilir. Gerçek zamanlı finansal kapatma işleyen bir servis için değildir.

Doğru SLO iki faktöre bağlıdır: servisteki bozulmanın kullanıcı etkisi, ve daha sıkı bir hedefi sürdürmenin operasyonel maliyeti.

Son 90 gün içinde servisi %99,3 erişilebilirliğe kaydettiyse, ilk SLO'nuzu %99,9'da başlatmak aspirasyon, kalibrasyon değildir. Pratik yaklaşım: son 90 günün SLI verisini çekin, SLO'yu şu anki performanstan biraz sıkı ayarlayın, ardından üç ayda bir gözden geçirin. %99 SLO ile gerçek hata bütçesi politikası ihlal ettiğinde göz ardı edilen %99,9 SLO'dan daha iyidir.

Servis türüne göre yaygın SLO hedefleri:

• Kullanıcı karşılı API'ler (ödeme, kimlik doğrulama): %99,9 erişilebilirlik, 500ms'nin altında P99 gecikme

• İç servisler (veri yapı, toplu işler): %99,5 başarı oranı, iş tamamlanmasında ölçülen

• Yönetim araçları: %99 erişilebilirlik sık yeterli

• Arka plan işçileri: HTTP durumundan çok iş tamamlanma zamanında SLO

İzlemek için SLI seçerken, Google SRE kitabından dört sinyali başlangıç noktası olarak kullanın: erişilebilirlik (istek başarılı oldu mu?), gecikme (ne kadar uzun sürdü?), verim (sistem kaç istek işliyor?), hata oranı (ne kesri başarısız oldu?). Her servisin dördüne de ihtiyacı yoktur. Çoğu ekip ilk ikisine + bir gecikme yüzdeye gerçek sinyal alır. Güvenilir bir tabana sahip olmadan daha fazla SLI eklemek gürültü yaratmak için yaygın bir yoldur, ek içeri yokken.

Hata Bütçesi: Hedeften Operasyonel Karara

Hata bütçesi matematiksel olarak SLO'nuzun tersıdır. Erişilebilirlik SLO'nuz %99,9 ise, ölçüm penceresinde isteklerin %0,1'i başarısız olabilir. Ayda bir milyon istek alan bir servis için SLO ihlal etmeden önce bu 1.000 başarısız istek anlamındadır.

Hata bütçesi SLO'ları operasyonel olarak yararlı kılar. Onsuz, SLO ihlal edilen ve sonra tartışılan bir eşik. Bir hata bütçesi politikası ile, bir karar çerçevesi olur.

Hata bütçesi sağlıklıyken, diyelim ayda kalan 2 haftayla %80 kaldıysa, ekip hızlı göndermeyi yapabilir. Yeni özellikler, deneyler, riskli deployment'lar sınırlar içinde. Hata bütçesi hızın şu an kısıtlayıcı olmadığını söyleyen sinyaldir.

Hata bütçesi azalırken, ekip kayar. Kritik olmayan değişiklikler beklemeye gider. Dağıtım politikası sıkılaşır. Güvenilirlik onarımları öncelik alır. Hata bütçesi karar verdi, yönetici "stabildir mi?'' yargısı yapmaması.

Somut senaryo: bir ödeme servisi Salı öğleden sonra 12 dakikalık bozulma yaşadı, ayın hata bütçesinin %15'ini tüket. Perşembe günü başka bir olay %12 daha tüketti. Ayın ilk haftasında %27 tüketilmiş durumda, hata bütçesi politikası tetikleniyor: postmortem tamamlanıp kök neden düzeltilene kadar yeni özellik dağıtımı yok. Bu karar ürün/mühendislik müzakeresi değil. Veriden okunuyor.

Google, SRE Çalışma Kitabında hata bütçesi politikasını yayınladı: tek bir olay üç aylık hata bütçesinin %20'sinden fazlasını tüketirse postmortem gerek. Uyarlanacak somut bir politikadır.

Yanma oranı uyarıları bunu daha ileri götürür. Hata bütçesi neredeyse bitene kadar beklemek yerine, tüketim oranı bütçeyi pencere bitmeden bitireceğini önerirse uyarı ateşler. Servisi normal oranın 14 katında hata bütçesi tüketiyorsa, 30 günlük bir bütçeyi kabaca 50 saatte bitirirsiniz. Bu oran uyarısı ekibe postmortem bildirimi yerine cevaplamak için iki gün vermesi.

Datadog ve Grafana gibi araçlar çok pencere, çok yanma oranı uyarısını bkutunun dışında destekler. Kurulum öğleden sonra alır. Ona sahip olmamak SLO ihlallerini müşteriler zaten fark ettikten sonra bulmayı anlamına gelir.

İlk SLO'nuzun Sayısını Yanlış Almadan Ayarlamak

En yaygın hata, ölçümü oluşturmadan önce hedefe başlamaktır.

Adım 1: SLI'yı tanımlayın. "Erişilebilirlik" bir SLI değildir. "Hata durumunun olmayan HTTP istekleri (2xx/3xx), tüm HTTP isteklere bölünen" bir SLI'dır. Ölçüm zaten sahip telemetriden üretilir olmalı. "Yakında enstrüman" söylemek SLO'nun veri kaynağı olmadığı anlamına gelir.

Adım 2: Tarihi verileri çekin. Son 60 ila 90 güne bakın. SLI gerçekten nasıl görünüyor? En kötü iki üç gün neydi? Bu bugün ulaşılabilir hedefin ne olduğunu ve ilk ihlalden önce ne kadar yer olduğunu söyler.

Adım 3: Ölçüm penceresini ayarlayın. 30 günlük kayan pencereler en yaygın ve duyarlı, her zaman güncel veriyi verir. Takvim ayı pencereleri ay sınırlarında uçurum etkisi yaratır. 7 günlük kayan pencereler daha hassas ama güvenilirlik kası inşa eden ekipler için çok sık tetikleyebilir.

Adım 4: İhtiyaç olmadan önce hata bütçesi politikasını yazın. Hata bütçesi yanma oranı hangi seviyede ekip kritik olmayan değişiklikleri durdurur? Hangi oranında acil durum çağrı yaşlıya?

Adım 5: Bir servisle başlayın. 15 serviste SLO tanımlamak 15 dashboard'u hiç okuyan kimsenin yapısını verir. En kullanıcı tarafı servis ile başlayın, bir çeyrek çalıştırın, ayarlayın, sonra genişletin.

Ölçüm penceresi seçenekleri ve etkisi:

• 7 günlük kayan: hızlı geri bildirim, kısa olaylara daha hassas, uyarı yorgunluğu yaratabilir

• 30 günlük kayan: en yaygın, sinyal ve gürültüyü dengeler

• 90 günlük kayan: toplu işler gibi seyrek ama kritik işlemler için yararlı

Çalışılmış örnek: e-ticaret API için, ilk SLO'nuz "isteklerin %95'i /checkout'a başarılı ve 500ms içinde geri dön, 28 günlük kayan pencereden ölçülür" olabilir. Bu somut SLI verir (başarı oranı + gecikme birleştiriliyor), spesifik hedef (%95), tanımlı pencere (28 gün). Oradan: hata bütçesi hesapla: isteklerin %5'i başarısız ya da yavaş olabilir. Günde 200.000 istek alıyorsanız, aylık hata bütçe SLO ihlal etmeden önce kabaca 280.000 başarısız istek.

SLO İzlemesi Kod Tabanı İşine Nerede Bağlanır

Beklenenden daha hızlı yanma gösteren hata bütçesi çoğunlukla altyapı değil, kod tabanı sorunudur. Gecikme artışı code review'de fark edilmeyen N+1 sorgularına kaynaklanır. Erişilebilirlik düşüşü belirli bir yük kombinasyonunun altında tek tetikleyen kod yolunda null gösterici istisnasına kaynaklanır. SLO semptomları algılar. Kod tabanı nedeni içerir.

Bu, "uyarı ateşlenmesi" ile "kök neden tanısı" arasındaki zaman pratik kısıtlama olur. Ödeme servisi hata bütçesinin %30'unu üç günde tüketiyorken ve acil durum mühendisi 150.000 satırlık monorepo'da yeniden deneme mantığını grep ile bulmalıyken, SLO işini yapıyor. Kök neden analizi için araçlar değil.

AI yardımlı kod araması gözlemlenebilirlik yığını yanında enstrüman edilmiş ekipler olay sırasında önemli ölçüde daha kısa tanı-kökü süresi bildir. Ödeme servisi 503 yanıtları üzerinde yeniden denemeleri nerede işlediğine doğal dil sorgusu dakikalar yerine 20 dakika içinde ilgili fonksiyonu ortaya çıkarır. 43 dakika hata bütçesi penceresi sorun okunmak yerine onarım için harcanır.

Ekipler SLO'ları Yanlış Alıyor: Dört Yol

Çok fazla SLO. 12 SLO'yu aynı anda izleyen ekip iki ay içinde uyarılarını arka plan gürültüsü olarak kabul edecek. Kullanıcı tarafı davranış en göze çarpan üç ila beş SLO, on mühendislik ekibi için çalışabilir bir tavan. Daha fazlasına ihtiyaç varsa, katmanlar halinde kuruluşlandırın: hata bütçesi politikalarını tetikleyen kritik SLO'lar, veri oluşturan bilgilendirici SLO'lar.

Altyapı değil, kullanıcı deneyimi ölçüm. İşlemci kullanımı, bellek kullanımı, disk I/O yararlı debug sinyalleri. SLI'lar olmadığı sürece sizin doğrudan kullanıcı bozulması ile ilişkili: istek başarı oranı, P95 ya da P99'un yanıt zamanı, ilk anlamlı verinin görünüm zamanı ölçün.

Operasyonel maliyet analizi olmadan SLO'lar ayarla. %99,99 erişilebilirlik elde etmek tipik olarak aktif yedeklilik, çok bölgeli failover ve herhangi bir saatte hemen acil durum yanıtı gerek. Ekip o şekilde sürdürülebilir olarak çalışamıyorsa, SLO düzenli ihlal edilir ve sonra göz ardı edilen. İhlal edilen-göz ardı hata bütçesi: kurguya davranış öğretir.

Hata bütçesi verisi suçlamak için kullan. Tüketilen hata bütçesine ilk cevap neydi bunu tetikleyen değişikliği kimin yayınladığını bulmanız ise, raporlama dürüst olmayı bırakacak. Hata bütçeleri ekip kaynağıdır. Bütçe düştüğünde, soru "ne düzeltiyoruz?" kişi sorumluluk değil.

Kuruluş sağlık testi: acil durum mühendislik toplantısında geçerli hata bütçesi durumunu toplama paylaş, siyasi tartışma tetiklemez? Hayırsa, SLO'lar etrafı kültür hedeflerin kendisine daha fazla dikkat gerek. Güvenilirlik metrikler karar araçları yalnızca ekip rapor sorunun kişi risk yaratmadığına güvenirse.

SLO'lar Üç Ayda Bir, Bir Kere Değil, Gözden Geçirme

SLO'yu ayarla bitmez kalibrasyon. Servisler değişir, trafik desenler kayar, belirli güvenilirlik seviyesi tutmanın maliyeti değişir.

Her 90 gün, dört soru çalıştır:

1. SLO tuttu mu? Evetse, rahat mıydı, hedefi sıkı yapabileceğini önerme?

2. Hata bütçesi tamamen tüketildi mi? Hangisi olayları onu çalıştırdı?

3. SLO faydalı sinyal yüzey veya ekip hata bütçesi politikasını geçersiz kıldı?

4. Ölçüm penceresi servis nasıl kullanılıyor için yeterli mi?

Ekip üç ayda hata bütçesi politikasını geçersiz kıldıysa ikiden fazla, SLO yanlış kalibre olmuş olasıdır. Hedef çok sıkı, pencere çok kısa, ya da ölçüm kullanıcılar gerçekten deneyimle yansımıyor.

SLO'lar kalibrasyon araçları. Güvenilirlik iyileşir, trafik büyür, işletme downtime toleransı değişirken ayarlanmış. Üç ayda bir SLO'larını gözden geçir ve ayarla ekip güvenilirlik uygulamayı çalıştırıyor. Bir kere ayarladığıkları ve kimse dokunmadığından ekip dashboard ile sayılar yok hiçkimse anlamlı için.