SRE Nedir: SLO, SLI ve Error Budget

"Sistem yeterince stabil mi?" sorusunun cevabı çoğu ekipte bir histir. Kimse rakam veremez, kimse ne kadar kesintinin kabul edilebilir olduğunu söyleyemez ve bu belirsizlik iki tarafı da mutsuz eder: geliştirici her yayında suçlu hissettiği için yavaşlar, operasyon ise her alarmda uyandığı için tükenir. SRE, yani site güvenilirliği mühendisliği, bu belirsizliği ortadan kaldırmak için güvenilirliği sayıya bağlar. SLI ile ölçer, SLO ile hedefi koyar ve error budget ile "ne kadar hata yapabiliriz" sorusunu net bir bütçeye dönüştürür.

Bu rehberde SRE'nin ne olduğunu ve DevOps'tan nasıl ayrıldığını, doğru SLI'nin nasıl seçileceğini, SLO belirlerken hangi tuzaklara düşüldüğünü, hata bütçesinin gerçek hesabını ve nasıl harcanacağını, alarmları bu bütçeye bağlayarak gereksiz uyarılardan nasıl kurtulacağını, toil kavramını ve olay sonrası incelemenin nasıl işe yarar hale getirileceğini anlatacağım.

SRE Nedir, DevOps'tan Farkı Nedir#

SRE, operasyon işini bir yazılım mühendisliği problemi olarak ele alma yaklaşımıdır. Temel iddiası şudur: bir sistemin güvenilirliği, insanların dikkatiyle değil sistemin tasarımıyla sağlanır. Elle yapılan bakım işleri azaltılır, ölçüm otomatikleştirilir ve "ne kadar güvenilir olmalı" sorusu keyfi değil, ürünün ihtiyacına göre cevaplanır.

DevOps ile ilişkisi sık sorulur. DevOps bir felsefedir ve nasıl uygulanacağını sana bırakır; SRE ise o felsefenin somut, ölçülebilir bir uygulamasıdır. DevOps "geliştirme ve operasyon birlikte sorumlu olsun" der, SRE "işte sorumluluğun ölçüsü: şu SLI'yi şu SLO ile takip edin, bütçeniz bitince yayını durdurun" der. Kavramsal çerçeveyi tazelemek istersen DevOps nedir yazısı bu ikisinin nerede kesiştiğini açıklıyor.

SRE'nin en radikal fikri şudur: yüzde yüz güvenilirlik yanlış bir hedeftir. Yüzde yüze yaklaşmanın maliyeti üstel biçimde artar ve kullanıcı zaten farkı hissetmez; çünkü kullanıcının kendi internet bağlantısı bile o kadar güvenilir değildir. Doğru soru "nasıl hiç kesinti yaşamayız" değil, "ne kadar kesinti kullanıcı deneyimini bozmadan tolere edilebilir" sorusudur.

SLI: Kullanıcının Hissettiğini Ölçmek#

SLI (Service Level Indicator), hizmet kalitesini gösteren somut bir ölçüdür. İyi bir SLI'nin tek şartı vardır: kullanıcının gerçekten hissettiği bir şeyi ölçmelidir. CPU kullanımı iyi bir SLI değildir, çünkü CPU yüzde doksanken kullanıcı gayet memnun olabilir; buna karşılık isteklerin yüzde beşi hata dönüyorsa CPU boşta olsa da kullanıcı mutsuzdur.

En yaygın kullanılan SLI türleri şunlardır:

Dikkat edilmesi gereken en önemli nokta, gecikmenin ortalama olarak ölçülmemesidir. Ortalama gecikme, yavaş isteklerin acısını saklar: yüz isteğin doksan beşi 50 ms, beşi 8 saniye sürdüğünde ortalama 450 ms çıkar ve grafiğe bakan kimse sorun görmez; oysa her yirmi kullanıcıdan biri sayfanın açılmasını sekiz saniye bekliyordur. Bu yüzden gecikmeyi ya yüzdelik dilimlerle (p95, p99) ya da eşik bazlı oranla ifade et:

Gecikme SLI = (300 ms'den kısa sürede tamamlanan istek sayısı) / (toplam istek sayısı)

Bu biçim, kullanılabilirlik SLI'siyle aynı birimde (oran) olduğu için ikisini aynı bütçe hesabında kullanabilirsin. Nginx erişim kayıtlarından bu oranı çıkarmak için ek bir araç bile gerekmez:

# log_format içinde $request_time olduğunu varsayıyoruz (son alan)
awk '{
  toplam++;
  if ($NF + 0 < 0.300) iyi++;
} END {
  printf "Gecikme SLI: %.4f (%d/%d istek)\n", iyi/toplam, iyi, toplam
}' /var/log/nginx/access.log

SLO: Hedefi Sayıya Bağlamak#

SLO (Service Level Objective), bir SLI için belirlenen hedeftir: "kullanılabilirlik SLI'si otuz günlük pencerede en az %99,9 olmalı" gibi. SLO iç bir taahhüttür; müşteriyle imzalanan ve ihlalinde bedeli olan SLA'dan farklıdır. Pratikte SLO'yu SLA'dan daha sıkı tutarsın ki müşteriye söz verdiğin seviyeyi ihlal etmeden önce kendi alarmın çalsın.

Hedef seçerken hangi rakamın ne kadar kesintiye karşılık geldiğini görmek şarttır. Otuz günlük bir ay için tablo şöyledir:

Bu tabloyu kendi ölçüm penceren için hesaplamak istersen uptime ve SLA hesaplayıcı aracımız işini görür. Rakamı seçerken üç kural işe yarar. Birincisi, mevcut performansından başla: son doksan gündeki gerçek SLI'ni ölç, hedefi ona yakın koy, sonra kademeli sıkılaştır. İkincisi, her uç nokta aynı hedefe sahip olmasın; ödeme akışı ile yardım merkezi sayfası farklı önem taşır ve aynı hedefi koymak, önemsiz bir sayfa için gece uyanmana yol açar. Üçüncüsü, hedefi ürün sahibiyle birlikte belirle; güvenilirlik seviyesi teknik değil ticari bir karardır çünkü maliyeti vardır.

Error Budget: Hata Bütçesi ve Nasıl Harcanır#

Hata bütçesi, SLO'nun yüzde yüze olan uzaklığıdır. SLO'n %99,9 ise bütçen %0,1'dir; yani otuz günde 43 dakika 12 saniyelik kesinti ya da toplam isteklerin binde biri kadar hata hakkındır. Bu, tolere edilen bir başarısızlık değil, bilinçli olarak ayrılmış bir kaynaktır ve harcanmak üzere vardır.

Bu çerçeve, DevOps'un en eski kavgasını çözer. Geliştirici hızlı yayın ister, operasyon kararlılık ister; hata bütçesi ikisini tek bir sayıda buluşturur:

1. Bütçe boldur: Risk alabilirsin. Yeni yayınlar, altyapı değişiklikleri, deneyler serbesttir.
2. Bütçe azalıyor: Yayın hızını koru ama riskli değişiklikleri kademeli açmaya geç.
3. Bütçe bitti: Özellik yayınları durur, ekip güvenilirlik işlerine odaklanır; bütçe yenilenene kadar yalnızca hata düzeltmesi ve dayanıklılık çalışması yapılır.

Üçüncü madde kâğıt üzerinde katı görünür ama asıl değeri buradadır: kararı tartışmadan çıkarıp otomatik bir kurala bağlar. "Bu hafta yayın yapalım mı" tartışması, "bütçenin yüzde kaçı kaldı" sorusuna dönüşür. Hesap da basittir:

Toplam istek           : 4.320.000
Başarısız istek        : 3.100
Gerçek başarı oranı    : 1 - (3100 / 4320000) = %99,928
SLO                    : %99,9
İzin verilen hata      : 4.320.000 × 0,001 = 4.320 istek
Harcanan bütçe         : 3.100 / 4.320 = %71,8
Kalan bütçe            : %28,2

Bu hesabı otomatikleştirmek için karmaşık bir sisteme ihtiyacın yok; erişim kayıtlarından günlük olarak üretmek yeterlidir:

#!/usr/bin/env bash
# Otuz günlük pencerede hata bütçesi tüketimi
SLO=0.999
okunan=$(awk '{print $9}' /var/log/nginx/access.log)
toplam=$(echo "$okunan" | wc -l)
hata=$(echo "$okunan" | grep -c '^5')
izin=$(echo "$toplam * (1 - $SLO)" | bc -l)
echo "Toplam: $toplam | 5xx: $hata | İzin: ${izin%.*}"
echo "Harcanan bütçe: $(echo "scale=1; $hata * 100 / $izin" | bc -l)%"

Bütçe kalmışken riskli değişikliği kademeli açmanın en pratik yolu canary deployment ile küçük bir dilime yayın yapmaktır; böylece kötü bir sürüm bütçenin tamamını değil küçük bir kısmını harcar.

Alarmları Hata Bütçesine Bağlamak#

Çoğu ekipte alarm sistemi zamanla işe yaramaz hale gelir: gece üçte çalan uyarının yarısı kendiliğinden düzelir, nöbetçi bir süre sonra bildirime bakmadan kapatmayı öğrenir ve gerçek olay geldiğinde kimse fark etmez. Bunun sebebi neredeyse her zaman eşik tabanlı alarm kullanılmasıdır: "CPU %80'i geçti", "hata oranı %1'i aştı". Bu alarmlar anlık gürültüye tepki verir ve kullanıcı etkisiyle ilgisi zayıftır.

Doğru yaklaşım, alarmı hata bütçesinin tüketim hızına bağlamaktır. Soru "şu an hata var mı" değil, "bu hızla devam edersek bütçemiz ne zaman biter" olur.

Bu yaklaşımın iki büyük faydası vardır. Birincisi, kısa süreli ve küçük dalgalanmalar alarm üretmez çünkü bütçeyi kayda değer biçimde tüketmezler. İkincisi, sessiz ama sürekli bir bozulma — hata oranının aylardır binde ikide takılı kalması gibi — eşik alarmında hiç görünmezken burada kendini gösterir. Alarm sayısını azaltmanın en hızlı yolu, mevcut alarm listeni açıp her biri için "bu çaldığında kullanıcı gerçekten etkilenmiş oluyor mu ve insanın hemen bir şey yapması gerekiyor mu" diye sormaktır; iki soruya da "hayır" diyen her alarmı bildirime değil panoya taşı.

Toil: Elle Yapılan Tekrarlı İşi Ölçmek#

Toil, sistemin büyümesiyle doğru orantılı artan, elle yapılan, tekrarlayan ve kalıcı değer üretmeyen iştir. Her hafta elle sertifika yenilemek, dolan diski elle temizlemek, her yayında elle üç komut çalıştırmak toil'dir. Bir hata düzeltmek toil değildir çünkü tekrarlanmaz; ama aynı hatayı her hafta elle geçici olarak çözmek toil'dir.

Toil'in tehlikesi sinsi olmasıdır: her biri on beş dakika süren işler ayda saatlere ulaşır ve ekibin iyileştirme yapacak zamanı kalmaz, dolayısıyla toil daha da büyür. SRE pratiğinde kural, toil'in çalışma zamanının belirli bir oranını (yaygın olarak yarısını) geçmemesidir. Ölçmek için ayrıntılı bir sisteme gerek yok; bir ay boyunca elle yapılan işleri basit bir listeye yazmak bile şaşırtıcı sonuçlar verir.

Toil'i azaltmanın sırası önem taşır:

1. Ortadan kaldır. İş gerçekten gerekli mi? Haftalık elle temizlik yerine log döndürme kurmak sorunu tamamen bitirir.
2. Kaynağını düzelt. Disk neden doluyor? Sebebi çözmek, temizliği otomatikleştirmekten iyidir. Konteyner disk şişmesinin kaynakları için Docker diski doldurdu yazısına bakabilirsin.
3. Otomatikleştir. Kaldırılamıyorsa betiğe dönüştür ve zamanlanmış görev haline getir. Zamanlanmış görev kurulumu için Linux cron görevleri yazısı temel referanstır.
4. Belgele. Otomatikleştirilemeyen iş en azından adım adım yazılı olsun; tek kişinin hafızasında duran süreç en pahalı toil türüdür.

Olay Sonrası İnceleme#

Bir kesinti yaşandığında en değerli çıktı, sistemin bir daha aynı şekilde bozulmamasıdır. Bunu sağlayan şey olay sonrası incelemedir ve işe yaraması için iki şart taşır: suçlamayan olmalı ve eyleme dönüşmeli.

Suçlamayan olmak, "kim yaptı" sorusunu tamamen dışarıda bırakmak demektir. Bir kişi yanlış komutu çalıştırabildiyse asıl bulgu, o komutun bir koruma olmadan çalıştırılabiliyor olmasıdır. İnsan davranışına odaklanan bir inceleme, bir sonraki olayda bilginin saklanmasına yol açar ve elindeki tek gerçek veri kaynağını kurutur.

İşe yarayan bir inceleme belgesi şunları içerir:

1. Zaman çizelgesi: Ne zaman başladı, ne zaman fark edildi, ne zaman düzeldi. Fark edilme süresi genellikle en öğretici sayıdır.
2. Kullanıcı etkisi: Kaç kullanıcı, hangi işlevi, ne kadar süre kullanamadı; harcanan hata bütçesi ne kadar.
3. Tetikleyici ve katkıda bulunan etkenler: Tek bir "kök neden" aramaktan kaçın; gerçek olaylarda genellikle birkaç şey aynı anda üst üste gelir.
4. Neyin işe yaradığı: Hızlı teşhis edilmesini sağlayan şey neyse onu da yaz, sadece eksikleri değil.
5. Sahipli aksiyon maddeleri: Her maddenin bir sahibi ve tarihi olsun; sahipsiz madde yapılmaz.

Aksiyon maddelerini takip etmeyen bir inceleme, yalnızca güzel yazılmış bir arşiv belgesidir. Bir sonraki incelemeyi açtığında ilk yapman gereken şey, öncekinin maddelerinin kapanıp kapanmadığına bakmaktır.

Sıkça Sorulan Sorular#

SLO ile SLA arasındaki fark nedir#

SLA müşteriyle yapılan sözleşmedir ve ihlal edildiğinde genellikle para iadesi gibi ticari bir sonucu vardır. SLO ise ekibin kendine koyduğu iç hedeftir ve sözleşmesel bir bedeli yoktur. İyi bir uygulama, SLO'yu SLA'dan belirgin biçimde daha sıkı tutmaktır; böylece müşteriye verilen söz ihlal edilmeden önce kendi alarmın çalar ve müdahale için zamanın olur.

%99,9 uptime ayda ne kadar kesinti demek#

Otuz günlük bir ayda %99,9 hedefi 43 dakika 12 saniyelik toplam kesintiye izin verir. %99,95 bunu 21 dakika 36 saniyeye, %99,99 ise 4 dakika 19 saniyeye indirir. Bu son rakam, alarmın çalıp nöbetçinin uyanmasına bile zor yeter; yani %99,99 hedefi neredeyse tamamen otomatik müdahale gerektirir ve maliyeti buna göre artar.

Hata bütçesi bitince gerçekten yayın durdurulmalı mı#

Kuralın amacı ceza vermek değil, önceliği otomatik olarak değiştirmektir. Bütçe bittiğinde özellik yayınlarını durdurup güvenilirlik işlerine geçmek, tartışmayı kişisel olmaktan çıkarıp veriye bağlar. Pratikte katı bir durdurma yerine "riskli değişiklikler durur, düşük riskli düzeltmeler devam eder" biçiminde uygulanır; önemli olan kuralın önceden yazılı ve herkesçe kabul edilmiş olmasıdır.

Küçük bir ekip için SLO belirlemek anlamlı mı#

Evet, hatta daha kolaydır. Tek bir SLI ile başla — genellikle kullanılabilirlik en iyi başlangıçtır — son doksan gündeki gerçek değerini ölç ve hedefi ona yakın koy. Karmaşık araç gerekmez; ters vekil sunucunun erişim kayıtları ve günlük çalışan basit bir betik ilk aylar için fazlasıyla yeterlidir. Önemli olan rakamın var olması ve düzenli bakılmasıdır.

SLI'yi nereden ölçmeliyim, sunucudan mı istemciden mi#

Kullanıcıya en yakın noktadan ölçmek en doğrusudur; ideal olan istemci tarafıdır çünkü ağ sorunları da oraya yansır. Ancak istemci ölçümü kurmak zahmetlidir ve uygulama açılamıyorsa veri de gelmez. Pratik denge, ana ölçümü yük dengeleyici veya ters vekil sunucu katmanında yapmak ve buna dışarıdan periyodik yoklama ekleyerek "sunucu tamamen erişilemez" durumunu da yakalamaktır.

Toil'i sıfıra indirmek mümkün mü#

Hayır ve hedef de bu değildir. Her sistemde bir miktar elle iş kalır; amaç bunun kontrolden çıkmasını engellemektir. Yaygın kabul gören sınır, ekibin zamanının en fazla yarısının toil'e gitmesidir. Bu oran aşıldığında iyileştirme yapacak zaman kalmaz ve toil kendi kendini besleyerek büyür; ölçmeye başlamak bile genellikle bu döngüyü kırmak için yeterlidir.

Kapanış#

SRE'nin özü karmaşık araçlar değil, birkaç net karardır: kullanıcının hissettiği bir şeyi SLI olarak seç, hedefi ürün sahibiyle birlikte SLO olarak yaz, aradaki farkı hata bütçesi olarak kabul et ve alarmlarını bu bütçenin tüketim hızına bağla. Buna elle yapılan tekrarlı işi ölçmeyi ve olaylardan sonra insan değil sistem düzeltmeyi eklediğinde, güvenilirlik tartışması his olmaktan çıkıp ortak bir dile kavuşur.

Bu ölçümleri yapabilmek için erişim kayıtlarına ve metriklerine hâkim olabildiğin bir ortama ihtiyacın var; VDS ve bulut sunucu paketlerimiz tam root erişimiyle kendi izleme yığınını kurmana imkân verir. İzleme, yedekleme ve güncelleme yükünü devretmek istersen sunucu yönetimi hizmetimiz bunu üstlenir; kesinti sebeplerinin başında gelen saldırılara karşı DDoS koruma çözümümüz hata bütçeni korumanın en pratik yollarından biridir.