SLO/SLI/SLA: DevOps Ekiplerine Güvenilirlik Mühendisliği Rehberi
Gecenin 3’ünde, sırf bir API gateway endpoint’i anlık olarak 500ms yavaş yanıt verdi diye PagerDuty alarmıyla uyanıp monitöre boş gözlerle baktıysanız, tebrikler: Yanlış kurgulanmış bir alarm stratejisinin kurbanı oldunuz. Modern mikroservis mimarilerinde sistemlerin kararlılığını ve reliability (güvenilirlik) seviyesini ölçmek, her saniye CPU veya memory değerlerini izleyip eşik değer aşılınca ortalığı ayağa kaldırmakla olmaz. Modern sre (Site Reliability Engineering) dünyasında, sistem sağlığını ve mühendislik eforumuzu yönetmek için kullandığımız üç kutsal kısaltmamız var: sli, slo ve sla. Bu yazıda teorik tanımların ötesine geçecek, production ortamında işinize yarayacak gerçekçi error budget hesaplamalarını ve Prometheus üzerinde burn rate tabanlı dinamik alarmları nasıl kuracağımızı öğreneceğiz.
Kavram Karmaşasını Çözelim: SLI vs. SLO vs. SLA
Bu üç kavram genellikle birbirine karıştırılır veya aynı şeymiş gibi kullanılır. İşleri basitleştirmek için aralarındaki ilişkiyi netleştirelim:
- SLI (Service Level Indicator): “Sistemimiz şu an ne kadar iyi çalışıyor?” sorusunun cevabıdır. Doğrudan ölçülebilir, anlık teknik metriklerdir. Örneğin; “Son 5 dakikadaki başarılı HTTP isteklerinin (2xx/3xx/4xx), toplam isteklere oranı.”
- SLO (Service Level Objective): “Sistemin ne kadar iyi çalışmasını hedefliyoruz?” sorusunun yanıtıdır. SLI metriğine bağlı bir hedef ve zaman aralığı tanımlar. Örneğin; “Gelen tüm isteklerin %99.9’u, 30 günlük kayan pencerede (rolling window) 200ms’in altında yanıt vermelidir.”
- SLA (Service Level Agreement): “Eğer sistemi hedeflediğimiz kadar ayakta tutamazsak ne kadar ceza ödeyeceğiz?” sorusunun ticari ve hukuki cevabıdır. Mühendislerden ziyade hukuk, ürün yönetimi (Product Management) ve müşterileri ilgilendirir. Genellikle SLO değerinden daha düşük bir taahhüt içerir (örneğin SLO %99.9 ise, SLA %99.5 olabilir).
Kısacası: SLI ölçer, SLO hedefler, SLA ise patlarsa fatura keser.
Hata Bütçesi (Error Budget): Neden Kusursuzluk Aramıyoruz?
SRE felsefesinin en büyük kabullerinden biri şudur: %100 güvenilirlik (reliability) yanlış bir hedeftir. Kullanıcılarınızın internet bağlantısı bile %100 kesintisiz değilken, altyapınız için %100 uptime hedeflemek sadece bütçenizi tüketir ve ekibin hızını (velocity) sıfırlar.
Bunun yerine Error Budget kavramını kullanırız. Formül oldukça basittir:
Error Budget = 100% - SLO%Eğer bir servis için 30 günlük SLO hedefimizi %99.9 olarak belirlediysek, bu bizim 30 günde %0.1 oranında hata yapma veya kesinti yaşama hakkımız olduğu anlamına gelir. 30 günün saniye karşılığı 2.592.000 saniyedir. Bu durumda hata bütçemiz tam olarak 2.592 saniye, yani yaklaşık 43.2 dakikadır.
Bu bütçe sadece sistemin çökmesiyle tükenmez; yeni deployment’lar sırasındaki yavaşlıklar, geçici veritabanı bağlantı kayıpları da bu bütçeden yer. Eğer ay sonuna doğru hata bütçeniz duruyorsa, production ortamına korkusuzca riskli güncellemeler (feature deployment) gönderebilirsiniz. Bütçe tükendiyse, yeni deployment’ları durdurur ve sadece reliability/bug-fix işlerine odaklanırsınız.
Prometheus ile SLI Tanımlama (Pratik Uygulama)
İşleri biraz daha pratikleştirelim. Elimizde Prometheus tarafından scrape edilen bir HTTP servisinin metrikleri olduğunu varsayalım. En popüler SLI türlerinden biri olan Availability (Kullanılabilirlik) metriğini hesaplayalım.
Burada kritik bir SRE detayı var: Genellikle 5xx durum kodlarını sunucu hatası (unavailability) kabul ederken, 4xx durum kodlarını (örneğin 404 veya 401) kullanıcı hatası olarak kabul eder ve sistemin sağlığını bozmadığı için SLI hesabına dahil etmeyiz (tabii 4xx’ler aniden tavan yapmadıysa).
Yazacağımız PromQL sorgusu şu şekildedir:
sum(rate(http_requests_total{job="my-service", status!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="my-service"}[5m]))Bu sorgu, son 5 dakika içinde 5xx dışındaki isteklerin, toplam isteklere oranını verir. Çıktı 0 ile 1 arasında olacaktır (örneğin 0.9995, yani %99.95 başarı).
Burn Rate Alerts: CPU Alarmlarını Çöpe Atın
Geleneksel alert mekanizmaları genellikle “Anlık CPU %90’ı geçerse Slack’e mesaj at” veya “Hata oranı %1’i geçerse nöbetçiyi ara” şeklindedir. Bu yaklaşımlar iki büyük sorun yaratır:
- Gürültü (Alert Fatigue): Anlık bir trafik spike’ı nedeniyle hata oranı 1 dakikalığına %2’ye çıkabilir ve kendi kendine düzelir. Boşu boşuna uykunuz bölünür.
- Yavaş Ölümler (Slow Burns): Hata oranınız saatlerce %0.2’de kalabilir. Bu oran geleneksel alarmları tetiklemez ancak 30 günlük %99.9’luk SLO bütçenizi sinsice sıfırlar.
SRE pratikleri bu sorunu Burn Rate (Tüketim Hızı) alarmları ile çözer. Burn rate, hata bütçenizi ne kadar hızlı tükettiğinizi gösteren katsayıdır.
- Burn Rate = 1: Bütçeniz tam olarak planlanan sürede (örneğin 30 günde) tükenecek demektir.
- Burn Rate = 14.4: Bütçenizin %2’sini sadece 1 saat içinde tüketeceğiniz anlamına gelir. Acil müdahale (Pager) gerekir!
- Burn Rate = 2.9: Bütçenizin %5’ini 6 saatte tüketeceksiniz demektir. Bu durumda bilet (Jira ticket) açılması yeterlidir.
Prometheus Kural Dosyası (Prometheus Alert Rules)
Aşağıdaki konfigürasyon bloğu, Google SRE Workbook standartlarına uygun olarak yazılmış, çoklu zaman pencereli (multi-window, multi-burn-rate) bir alert kuralı örneğidir. Hem anlık gürültüleri engeller hem de yavaş bütçe tüketimlerini kaçırmaz.
groups:
- name: service-slo-alerts
rules:
# Critical Alert: 1 saatlik burn rate > 14.4 VE son 5 dakikada da bu eğilim devam ediyorsa
- alert: ServiceAvailabilityCriticalBurnRate
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total}[1h]))
) > (1 - 0.999) * 14.4
and
(
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total}[5m]))
) > (1 - 0.999) * 14.4
for: 2m
labels:
severity: critical
tier: platform
annotations:
summary: "Hızlı Hata Bütçesi Tüketimi (Burn Rate 14.4x)"
description: "Hata bütçesi son 1 saatte çok hızlı tükeniyor! Current error rate: {{ $value | humanizePercentage }}"
# Warning Alert: 6 saatlik burn rate > 6 (Bütçenin %5'i 6 saatte bitiyor)
- alert: ServiceAvailabilityWarningBurnRate
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[6h]))
/
sum(rate(http_requests_total}[6h]))
) > (1 - 0.999) * 6
and
(
sum(rate(http_requests_total{status=~"5.."}[30m]))
/
sum(rate(http_requests_total}[30m]))
) > (1 - 0.999) * 6
for: 15m
labels:
severity: warning
annotations:
summary: "Yavaş Hata Bütçesi Tüketimi (Burn Rate 6x)"
description: "Son 6 saattir hata bütçesi eriyor. Nöbetçi ekibin mesai saatlerinde incelemesi önerilir."Yukarıdaki kurallarda dikkat ederseniz (1 - 0.999) * 14.4 gibi dinamik bir matematiksel formül kullandık. Buradaki 0.999 bizim SLO hedefimiz olan %99.9’dur. Eğer yarın bir gün bu hedefi %99.5’e çekmek isterseniz sadece bu katsayıları değiştirmeniz yeterli olacaktır.
Bu Yapıyı Kurduktan Sonra Sizi Ne Bekliyor?
Bu sisteme geçiş yapmak sadece teknik bir araç değişimi değil, ciddi bir kültürel dönüşümdür. Burn rate alarmlarına geçtiğinizde:
- Gecenin yarısında uyanma oranınız (false-positive paging) dramatik şekilde düşecek.
- Ekipler “Bu hafta çok downtime oldu, deployment yapmayalım” kararını hissiyatla değil, doğrudan Grafana paneline bakarak somut verilerle (Error Budget Dashboard) verecek.
- Yazılım geliştiriciler ve sistem yöneticileri aynı dile konuşmaya başlayacak: “Hata bütçemiz ne kadar kaldı?”
Kendi sistemlerinizde bu dönüşümü başlatmak için ilk adım olarak en kritik 3 servisinizi belirleyin, basit birer kullanılabilirlik SLI’ı yazın ve error budget grafiğinizi oluşturun. Unutmayın, mükemmel bir sistem kesintisiz çalışan sistem değil, ne zaman ve ne kadar hata yapabileceğini bilen ve bunu kontrol altında tutan sistemdir.