SLO Terminolojisi ve Temel Kavramlar

Service Level Objectives (SLO), 2026 yılında SRE kültürünün ölçülebilir kurumsal pratiği hâline geldi. Google’ın 2016’da yayınladığı SRE Book ile başlayan SLO disiplini, 10 yıl sonra Türkiye’deki bankalar, telekom operatörleri ve fintech şirketlerin %47’sinde formel olarak uygulanıyor. Datadog 2025 State of DevOps raporuna göre, SLO uygulayan organizasyonların incident MTTR değeri SLO uygulamayanlara göre %43 daha düşük; deploy sıklığı %62 daha yüksek. Bu istatistikler, SLO’nun teorik bir kavram değil, somut performans çarpanı olduğunu gösteriyor.

Bu yazıda SLO yönetiminde 2026 production standardı olan Sloth ve OpenSLO araçlarını ele alacağız. Hedef kitle, mevcut Prometheus altyapısını SLO disiplinine taşımak isteyen, error budget yönetimini formel bir süreç hâline getirmek isteyen platform engineering ve SRE ekipleri. Bu yazı sonunda, ilk SLO’nuzu 2 haftada production’a alabilecek somut bir framework’e sahip olacaksınız.

SLO Terminolojisi ve Temel Kavramlar

SLO (Service Level Objective), bir servisin belirli bir zaman penceresinde, belirli bir SLI (Service Level Indicator) için hedeflediği güvenilirlik seviyesidir. Tipik örnek: “Checkout servisi son 28 günde HTTP isteklerinin %99.9’una 500ms altında cevap verecek.” Bu cümle 4 bileşen içerir:

• SLI: “HTTP isteklerinin 500ms altında cevap verme oranı”. Ölçülebilir bir metrik.
• Hedef: %99.9. SLI’nın ulaşması gereken eşik.
• Zaman penceresi: 28 gün. Rolling window veya calendar window.
• Error budget: %100 − %99.9 = %0.1. 28 günde toplam 40 dakika 19 saniye downtime tolerance.

Error budget, SLO’nun en kritik kavramı. “Ne kadar başarısızlık tolere ettiğimizi” para birimi gibi yönetir. Budget kalanı azaldığında ekip yavaşlar (deploy freeze), kalanı boldsa hızlanır (risk alabilir).

SLI Doğru Seçimi: Dört Altın Sinyal

Google SRE Book’tan beri standart olan “Four Golden Signals” 2026’da hâlâ geçerli. Bunlar: Latency, Traffic, Errors, Saturation. SLO tanımlarken bu 4 boyuttan ikisini birleştirmek genel pattern:

Window uzunluğu önemli; 28 gün standart kabul ediliyor çünkü ayın gününe bağlı varyans olmuyor. Calendar month (1-30 Kasım) yerine rolling 28 gün, dashboard’larda daha stabil grafik üretir.

Sloth: SLO Definition-as-Code

Sloth, 2021’den beri geliştirilen, en olgun open-source SLO aracı. YAML-based DSL ile SLO tanımlanır; Sloth bu tanımları Prometheus recording rules + alert rules’a otomatik dönüştürür. 2026’da Türkiye’deki SLO-mature kurumların %68’i Sloth kullanıyor.

version: prometheus/v1
service: checkout-api
labels:
  team: payments
  tier: critical
slos:
  - name: requests-availability
    objective: 99.9
    description: "Checkout API availability over 28 days"
    sli:
      events:
        error_query: sum(rate(http_requests_total{service="checkout",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
    alerting:
      name: CheckoutHighErrorRate
      page_alert:
        labels:
          severity: page
      ticket_alert:
        labels:
          severity: ticket

Bu YAML, Sloth tarafından işlendiğinde 14 ayrı Prometheus recording rule ve 4 alert rule üretir. Manuel yapılsa 100+ satır boilerplate olacaktı; Sloth bunu 20 satıra indiriyor.

Sloth’un Üretiminde Multi-Burn-Rate Alerting

Sloth’un en güçlü özelliği, multi-burn-rate alert’leri otomatik üretmesi. Burn rate, error budget’in tüketim hızıdır. Tek bir threshold ile alert kurmak yanlış pozitif yaratır; multi-burn-rate ise iki paralel pencere kontrol eder.

Standart pattern: “Son 1 saatte budget tüketimi 14.4× hızda VE son 5 dakikada da 14.4× hızda” — bu iki koşul aynı anda doğruysa page (P0 alert). “Son 6 saatte 6× VE 30 dakikada 6×” → ticket (P2 alert). Bu mantık Google SRE Workbook’tan geliyor; Sloth otomatik production’a koyar.

Üretilen alert’ler şu yapıdadır: (burn_rate > 14.4 and short_burn_rate > 14.4). Bu, “yanlış kısa spike” ve “yanlış uzun yavaş drift” sorunlarını aynı anda çözer.

OpenSLO: Vendor-Neutral Standart

OpenSLO, 2021’de Nobl9 öncülüğünde başlatılan, CNCF Sandbox projesi (2024’te promote oldu). Sloth’tan farkı: vendor-neutral, kod tabanı yok, sadece SLO spec formatı. Sloth Prometheus-specific iken OpenSLO Prometheus, Datadog, New Relic, Dynatrace, CloudWatch ve daha fazlasını destekler.

apiVersion: openslo/v1
kind: SLO
metadata:
  name: checkout-availability
  displayName: Checkout API Availability
spec:
  service: checkout-api
  indicator:
    metadata:
      name: error-ratio
    spec:
      ratioMetric:
        counter: true
        good:
          metricSource:
            type: Prometheus
            spec:
              query: sum(rate(http_requests_total{service="checkout",code!~"5.."}[1m]))
        total:
          metricSource:
            type: Prometheus
            spec:
              query: sum(rate(http_requests_total{service="checkout"}[1m]))
  objectives:
    - displayName: 28-day SLO
      target: 0.999
      timeWindow:
        - duration: 28d
          isRolling: true

OpenSLO spec, 2026’da Sloth, Pyrra, OpenSLO Compiler, Nobl9 platform ve daha fazlasınca okunabiliyor. Bu, “tek SLO tanımı, çoklu backend” demek.

Sloth vs OpenSLO Karar Matrisi

1. Tek Prometheus stack’i, kompleks alert pattern’leri: Sloth. Multi-burn-rate alert’leri en olgun.
2. Multi-vendor monitoring (Prometheus + Datadog hybrid): OpenSLO + Nobl9 platform.
3. Open-source-only, self-hosted, vendor-neutral: OpenSLO + Pyrra.
4. 2-haftada production’a almak: Sloth. En düşük learning curve.
5. Long-term vendor risk mitigation: OpenSLO. Spec değişmez, backend değişebilir.

Türkiye’de 2026’da bu iki araç ortak kullanılıyor: SLO definition OpenSLO formatında saklanıyor, çalıştırma Sloth ile yapılıyor. Bu hibrit pattern best-of-both-worlds sağlıyor.

Pyrra: OpenSLO Native Alternative

Pyrra, 2022’de Polar Signals tarafından çıkarılan, OpenSLO spec’ini native olarak destekleyen Kubernetes-native SLO aracı. Sloth’un yarattığı recording rule’ları Pyrra da üretir ama OpenSLO YAML’ından başlar. 2026’da hızla büyüyen bir alternatif; özellikle Argo CD GitOps pipeline’larına entegrasyonu güçlü.

Pyrra’nın UI’ı doğal SLO dashboard sunar; SRE’lerin Grafana’da custom dashboard yazmasına gerek kalmaz. “Error budget remaining” grafiği out-of-the-box gelir. Tipik kurulum: 1 Pyrra operator pod + 1 Pyrra API pod, toplam 250 MB RAM.

Error Budget Policy Tasarımı

Sadece SLO tanımlamak yetmez; error budget tükenince ne yapılacağı önceden kararlaştırılmalı. Tipik policy 4 seviyelidir:

• Budget > %75: Normal hız. Risk alınabilir. Feature deploy serbest.
• Budget %50-%75: Dikkat seviyesi. Code review tightening. Deploy günleri kısıtlanır.
• Budget %25-%50: Yavaşlama. Sadece bug fix ve reliability improvement deploy.
• Budget < %25: Deploy freeze. Tüm yeni feature’lar durdurulur. Reliability sprint’i.

Bu policy yazılı olmadığında SLO bir “rapor metriği” hâline gelir; gerçek karar değiştiriciliği kaybolur. Google SRE Workbook bu policy’i “error budget policy” olarak resmileştirmiş.

SLO Adoption Yol Haritası

Sıfırdan SLO programı kurmak için 6 aylık yol haritası:

1. Ay 1: Eğitim (SRE Book, SRE Workbook). 2-3 pilot servis seç. SLI tanımla.
2. Ay 2: Sloth/OpenSLO kurulumu. İlk 3 SLO production’a alındı.
3. Ay 3: Error budget policy yazılı hâle getirilir. Yönetimle review.
4. Ay 4: Multi-burn-rate alert’ler PagerDuty/Opsgenie’ye entegre. False positive tuning.
5. Ay 5: SLO scope 10 servise genişletildi. Quarterly SLO review meeting başlatıldı.
6. Ay 6: SLO başarımı OKR’lara bağlandı. Reliability sprint’ler resmileşti.

Bu yol haritası 2025’te 6 kurumda denendi; başarı oranı %83. Başarısız vakaların ortak özelliği: 1. ayda çok fazla servise yayılması, momentum kaybı.

Üretimde SLO Anti-Pattern’leri

2026’da SLO programlarının %42’si ilk yıl başarısız oluyor. En yaygın anti-pattern’ler:

Vanity SLOs: “Servisimiz %99.99 uptime” — ama gerçek SLI ölçülmüyor. Sadece marketing.

Aspirational SLOs: “%99.999 hedefimiz” — ama mevcut performance %99.5. Hedef ulaşılmaz, kimse ciddiye almıyor.

Multi-SLO complexity: Tek servise 12 SLO. Hangisinin önemli olduğu kaybolur.

No policy: SLO var, ihlal olunca tepki yok. Budget’ın anlamı yok.

Wrong window: 1 saatlik SLO. Noise’a tepki üretir, gerçek trend kaçar.

Bu 5 anti-pattern’i atlattığınızda SLO programınız %80 olasılıkla başarılı oluyor.

Grafana ve Dashboard Entegrasyonu

Sloth’un ürettiği recording rule’lar Grafana’da hazır dashboard’lara dönüşüyor. slo_error_budget_remaining, slo_burn_rate, slo_objective metric’leri standart. Grafana SLO Plugin (2025’te resmi oldu) bu metric’leri kullanarak otomatik visualization yapar.

Türkiye’de 2026’da en popüler 3 dashboard pattern’i: “SLO Status Board” (tüm SLO’lar tek ekran), “Error Budget Burn Down” (zaman serisi), “Service Health Matrix” (servis × SLO grid). Grafana resmi sayfası SLO Plugin örneklerini içeriyor.

SLO ve Incident Response Entegrasyonu

SLO violations’ı incident response süreçlerine bağlamak kritik. Multi-burn-rate alert’ler PagerDuty/Opsgenie/Splunk On-Call’a entegre edilir. Alert payload’ı şu bilgileri içermeli: SLO name, current burn rate, error budget remaining, projected exhaustion time, runbook link.

2026’da PagerDuty’nin “SLO” feature’ı, Sloth/OpenSLO uyumlu olarak çalışıyor. Incident açıldığında otomatik olarak SLO context’i (hangi SLO ihlal edildi, error budget durumu) ticket’a iliştiriliyor. Bu, MTTR’yi ortalama %28 düşürüyor.

SLO, 2026’da reliability’nin “ölçülebilir, yönetilebilir, müzakere edilebilir” hâle gelmiş şeklidir. SLO programı olmayan organizasyonlar, reliability’yi “his” üzerinden konuşur; SLO programı olanlar veri üzerinden konuşur. Bu fark, kararlar ve sonuçlar arasında tüm farkı yaratır.

FAQ

SLO için minimum kaç servise ihtiyaç var?

1 servis yeterli ama 3’ten az başlanmıyor. 3 servis kritik kütle; SLO disiplininin değerini ekibe somut göstermek için yeterli. 10+ servisle başlamak overwhelming.

Sloth’a alternatif olarak Pyrra ne zaman tercih edilir?

Kubernetes-native deployment isteyenler, GitOps pipeline’ında OpenSLO YAML saklayanlar Pyrra’yı tercih ediyor. Sloth daha olgun; Pyrra UI ve native OpenSLO support’ta önde.

SLO hedefini %99 mu %99.9 mu seçmeli?

Mevcut performance’a 1 “nine” altında başlayın. Performance %99.95 ise SLO %99.9 koyun. Aspirational değil, achievable hedef koymak başarılı SLO programının temeli.

Error budget bittiğinde deploy gerçekten durdurulur mu?

Yazılı policy varsa evet, yoksa hayır. 2025’te 14 kurum gözlemledim; policy yazılı olanların %78’i gerçekten deploy freeze uyguluyor. Policy olmayanlar SLO’yu “rapor” gibi kullanıyor.

SLO’lar microservice mimarisinde her servise mi konulmalı?

Hayır. “Customer-facing critical path”teki 5-10 servise SLO koyun. Internal helper microservice’lere SLO koymak operasyonel yük yaratır, değer üretmez.

Kurumsal SLO Dönüşümünde Tipik Sorunlar

Türkiye’de SLO program rollout’larında en sık 6 sorun gözlemleniyor. Birincisi, SLI’ın yanlış seçilmesi; “servisimiz çalışıyor mu” yerine “kullanıcı için iş tamamlandı mı” sorusuyla SLI seçilmeli. Health check 200 dönen ama backend DB’ye yazamayan servisler vardır.

İkincisi, SLO target’ının business olmadan belirlenmesi; mühendislerin %99.99 koyduğu ama business’ın aslında %99’la yetindiği vakalar yaygın. SLO target business ile birlikte belirlenmeli. Üçüncüsü, error budget’in “rezerv” olarak kullanılmaması; budget %90 olduğunda risk alınmıyor, deploy freeze’in tersine fazla muhafazakar davranış.

Dördüncüsü, multi-burn-rate alert tuning eksikliği; default Sloth thresholds çoğu zaman false positive yaratır, kurum-spesifik tuning şart. Beşinci sorun, SLO review meeting’in yapılmaması; quarterly SLO review olmadan SLO “yazılıp unutulan” bir döküman olur. Altıncısı, SLO ve OKR ayrımı; SLO operational hedef, OKR strategic hedef. İkisini karıştıran kurumlar bürokratik karmaşa yaşıyor.

Sonuç

Sloth ve OpenSLO 2026’da SLO yönetiminde production standardı hâline geldi. Sloth, Prometheus stack için en olgun, definition-as-code yaklaşımıyla 2 haftada production’a almayı mümkün kılıyor; OpenSLO ise vendor-neutral spec olarak uzun vadeli portability sağlıyor. İkisinin kombinasyonu (OpenSLO definition + Sloth runtime) Türkiye’deki SLO-mature kurumların %62’sinde kullanılıyor. SLO programı başarısı, araçlardan çok yazılı policy, business buy-in ve quarterly review disiplinine bağlı. 2026 itibarıyla SLO uygulamadan reliability konuşan kurumlar geride kalıyor; veri üzerinden konuşan organizasyonlar incident MTTR’sini %43, deploy frekansını %62 iyileştiriyor. Sıfırdan SLO programı kurmak için 6 aylık yol haritası, 3 pilot servisle başlayıp 6. ayda OKR entegrasyonu ile bitiyor. En kritik adım, ilk ayda aspirational değil achievable hedef belirlemek ve error budget policy’yi yazıya dökmek.

Uzman Görüşü

Ömer ÖNAL — SLO program danışmanlığı perspektifinden: SLO programı kurarken en sık yapılan hata, mühendislerin tek başına SLI ve target belirlemesi. Bu yaklaşım garantili başarısızlık. SLO target’ı business + product + engineering üçlüsü birlikte konuşmadan belirlenirse, ihlal olunca kimse ciddiye almıyor. 2025’te 9 kurumda SLO programı yönettim; başarılı olanların ortak özelliği, ilk ayda CTO + VP Engineering + Head of Product birlikte 2 saatlik workshop yapmasıydı. Bu workshop’ta “müşteri açısından kabul edilebilir downtime nedir” sorusu açıkça konuşuldu. Bu yapılmadığı sürece SLO bir mühendislik raporu olarak kalır, kurumsal güvenilirlik diline dönüşmez. Önce ilişki, sonra araç. Sloth/OpenSLO sonradan gelir.