irfo
Moderatör
- Katılım
- 7 Ocak 2026
- Mesajlar
- 290
- Tepkime puanı
- 2
- Puanları
- 18
Geleneksel dünyada yazılımcılar (Dev) yeni özellikler eklemek isterken, sistem yöneticileri (Ops) sistemin stabil kalması için değişime direnirlerdi. Google, bu bitmek bilmeyen savaşı sona erdirmek için 2003 yılında yeni bir disiplin ortaya attı: Site Reliability Engineering (SRE).
Google’ın VP’si Ben Treynor SRE’yi şöyle tanımlıyor: "SRE, bir yazılım mühendisine operasyonel görevler verdiğinizde ortaya çıkan şeydir."
Bu iki kavram genellikle birbirine karıştırılır. En basit tabiriyle; DevOps bir felsefedir, SRE ise bu felsefenin somut bir uygulamasıdır.
Bir SRE mühendisinin günlük hayatını yöneten üç kutsal terim vardır:
SRE kültüründe en büyük düşman "Toil" yani tekrarlayan, manuel ve otomatize edilebilecek işlerdir. Google'ın kuralına göre bir SRE mühendisi zamanının en fazla %50'sini operasyonel işlere (Toil), geri kalanını ise sistemdeki otomasyonu geliştirmeye ayırmalıdır.
SRE, operasyonu bir "yazılım problemi" olarak görür. Eğer sürekli aynı manuel işleri yapmaktan yorulduysanız ve sisteminizin güvenilirliğini şansa bırakmak istemiyorsanız, Google'ın bu disiplinli yaklaşımı size yol gösterecektir.
Google’ın VP’si Ben Treynor SRE’yi şöyle tanımlıyor: "SRE, bir yazılım mühendisine operasyonel görevler verdiğinizde ortaya çıkan şeydir."
SRE ve DevOps Arasındaki Fark Nedir?
Bu iki kavram genellikle birbirine karıştırılır. En basit tabiriyle; DevOps bir felsefedir, SRE ise bu felsefenin somut bir uygulamasıdır.
| Özellik | DevOps | SRE |
|---|---|---|
| Odak | Kültürel değişim ve duvarları yıkmak. | Sistemi yönetmek için kod yazmak. |
| Hata Payı | Hataları azaltmayı hedefler. | Hata bütçesini (Error Budget) yönetir. |
| Ölçüm | Sürekli iyileştirme. | SLI, SLO ve SLA ölçümleri. |
SRE’nin Altın Kuralları ve Terimleri
Bir SRE mühendisinin günlük hayatını yöneten üç kutsal terim vardır:
- [] SLI (Service Level Indicator): Neyi ölçüyoruz? (Örn: Yanıt süresi, hata oranı). [] SLO (Service Level Objective): Hedefimiz ne? (Örn: "İsteklerin %99.9'u 200ms altında yanıtlanmalı"). [] SLA (Service Level Agreement): Sözümüzü tutmazsak ne olur? (Genellikle müşteriye karşı hukuki/maddi sorumluluk). [] Error Budget (Hata Bütçesi): %100 kusursuzluk imkansızdır. SRE, %0.1'lik bir hata payına izin verir. Bu bütçe dolana kadar yeni özellikler (features) hızla çıkılabilir. Bütçe biterse, tüm ekip sisteme odaklanır.
Toil (Angarya) ile Mücadele
SRE kültüründe en büyük düşman "Toil" yani tekrarlayan, manuel ve otomatize edilebilecek işlerdir. Google'ın kuralına göre bir SRE mühendisi zamanının en fazla %50'sini operasyonel işlere (Toil), geri kalanını ise sistemdeki otomasyonu geliştirmeye ayırmalıdır.
Python:
Bir SRE'nin hayali: Manuel kontrol yerine otomasyon
def check_system_health(cpu_usage): if cpu_usage > 90: auto_scale_up() # Manuel müdahale yok, kod hallediyor else: print("Sistem stabil.")Neden SRE Yaklaşımını Benimsemelisiniz?
- [] Veriye Dayalı Kararlar: "Bence sistem yavaş" yerine "SLI verilerimize göre %10 sapma var" diyerek konuşursunuz. [] Hız ve Güvenlik Dengesi: Hata bütçesi sayesinde, geliştiriciler ve sistemciler arasındaki çatışma yerini ortak bir matematiksel hedefe bırakır.
- Gözlemlenebilirlik: SRE ekipleri, sistemin içini görmeye (Logging, Monitoring, Tracing) takıntılıdır.
Sonuç
SRE, operasyonu bir "yazılım problemi" olarak görür. Eğer sürekli aynı manuel işleri yapmaktan yorulduysanız ve sisteminizin güvenilirliğini şansa bırakmak istemiyorsanız, Google'ın bu disiplinli yaklaşımı size yol gösterecektir.