SRE Nedir, Ne İş Yapar? DevOps'tan Farkı ve Modern Güvenilirlik Mühendisliği

"Sistem çöktü, kim bakıyor?" cümlesi, çoğu ekipte gece yarısı paniğinin başlangıcıdır. Site Reliability Engineering (SRE), tam da bu paniği mühendisliğe dönüştürmek için doğdu: güvenilirliği bir şans işi olmaktan çıkarıp ölçülebilir, bütçelenebilir ve otomatikleştirilebilir bir mühendislik disiplinine çevirir. Bu yazıda SRE'nin ne olduğunu, bir SRE'nin gerçekte ne yaptığını, temel kavramlarını ve en çok karıştırılan konuyu — SRE ile DevOps arasındaki farkı — sıfırdan ve örneklerle anlatıyoruz.

SRE terimi 2003'te Google'da, Benjamin Treynor Sloss'un yedi kişilik bir ekibe "Google'ın ayakta kalmasını sağla" görevini vermesiyle ortaya çıktı. Treynor'un ünlü tanımı şudur: "SRE, bir yazılım mühendisinden operasyon işini yapmasını istediğinizde ortaya çıkan şeydir." Yani SRE, klasik sistem yöneticiliğini yazılım mühendisliği zihniyetiyle yeniden tasarlar.

SRE nedir?

Site Reliability Engineering, üretim sistemlerinin güvenilirliğini (availability), gecikmesini (latency), performansını, verimliliğini, değişiklik yönetimini, izlenmesini ve acil durum müdahalesini bir yazılım mühendisliği problemi olarak ele alan disiplindir. Temel içgörü basittir ama güçlüdür: operasyon işini insan gücü ekleyerek değil, o işi ortadan kaldıran yazılımı yazarak ölçekle.

Klasik modelde bir hizmet büyüdükçe operasyon ekibi de büyümek zorundadır — trafik iki katına çıkınca elle yapılan iş de iki katına çıkar. Bu, doğrusal (lineer) ölçeklenen bir maliyettir ve büyük ölçekte sürdürülemez. SRE ise alt-doğrusal (sublinear) ölçeklemeyi hedefler: bir otomasyon bir kez yazıldığında ister 10 ister 10.000 sunucuyu yönetsin, ek insan maliyeti neredeyse sıfırdır.

SRE'nin en çok bilinen kuralı da buradan gelir: bir SRE, zamanının en fazla %50'sini operasyonel işlere ("toil") harcamalıdır. Kalan en az %50, sistemi daha güvenilir ve daha otomatik yapacak mühendislik projelerine ayrılır. Bu sınır, ekibin operasyonel yük altında ezilip mühendislik yapamaz hâle gelmesini önleyen bir koruma mekanizmasıdır.

Bu %50 sınırının nasıl korunduğu kritiktir. Bir SRE ekibinin operasyonel yükü sınırı aşarsa, kitabın önerdiği çözüm net ve biraz da provokatiftir: fazla yük, geçici olarak geliştirici ekibe geri devredilir — yani geliştiriciler bir süre kendi servislerinin nöbetini tutar. Bu, cezalandırma değil, teşvik hizalamasıdır: kendi kodunun operasyonel maliyetini doğrudan hisseden geliştirici, daha güvenilir ve daha az bakım gerektiren kod yazmaya başlar. Böylece güvenilirlik, tek bir ekibin sırtına yıkılan bir yük olmaktan çıkıp ortak bir mühendislik hedefine dönüşür.

SRE'nin işe alım felsefesi de bu ikili doğayı yansıtır. Tipik bir SRE ekibi, kodlama mülakatlarından geçmiş yazılım mühendisleriyle; algoritmalar, işletim sistemleri ve ağlar konusunda derinleşmiş sistemcilerin karışımından oluşur. Bu karma yetkinlik, ekibin hem sistemi anlamasını hem de onu otomatikleştirecek araçları üretmesini sağlar — SRE'yi hem "sadece kod yazan" hem de "sadece sunucuya bakan" rollerden ayıran şey budur.

Bir SRE ne iş yapar? Bir günün içinden

SRE'nin işi "sunucuya bakmak" değildir; sistemin güvenilirliğini mühendislikle üretmektir. Tipik sorumluluk alanları şunlardır:

• İzleme ve uyarı (monitoring & alerting) sistemlerini tasarlamak: neyin, ne zaman, kime uyarı üreteceğine karar vermek.
• SLO'ları tanımlamak ve hata bütçesini takip etmek; sürüm hızını bu bütçeye göre yönetmek.
• Toil'i (tekrarlayan elle iş) ölçmek ve otomasyonla ortadan kaldırmak.
• Nöbet (on-call) tutmak: olaylara müdahale etmek, kök nedeni bulmak, sistemi eski hâline getirmek.
• Olay sonrası suçlamasız postmortem yazmak ve aynı arızanın tekrarını önleyecek iyileştirmeleri planlamak.
• Kapasite planlaması ve performans/maliyet verimliliği üzerinde çalışmak.
• Yeni servisler için "production readiness review" yapmak: bir servis canlıya çıkmadan önce güvenilirlik açısından değerlendirmek.

Somutlaştıralım. Sabah, bir SRE gece boyunca üretilen uyarıları gözden geçirir; gereksiz gürültü üreten bir uyarı varsa eşiğini düzeltir. Öğleden önce, geçen hafta yaşanan bir kesintinin postmortem'ini bitirir ve çıkan aksiyon maddelerinden birini — örneğin bir sağlık kontrolü (health check) eklemeyi — koda döker. Öğleden sonra, sık tekrar eden bir manuel işi (diyelim sertifika yenileme) otomatikleştiren küçük bir araç yazar. Gün boyunca nöbetteyse, gelen bir alarmda önce belirtiyi (symptom) doğrular, sonra dört altın sinyale bakar, kök nedeni izole eder ve düzeltir. İşin ağırlığı "yangın söndürme" değil, "yangının bir daha çıkmamasını sağlayacak mühendislik" üzerinedir.

Bu işin belki de en yanlış anlaşılan yanı budur: iyi bir SRE'nin başarısı, çözdüğü olay sayısıyla değil, hiç olay çıkmadan geçen zamanla ölçülür. Sürekli yangın söndüren bir ekip aslında başarısızdır; çünkü mühendislik yapacak zamanı kalmamıştır. SRE'nin nihai hedefi kendini gereksiz kılmaktır: sistemi o kadar otomatik, o kadar kendini iyileştiren (self-healing) hâle getirmek ki, insan müdahalesi istisna olsun, kural değil. Bu yüzden bir SRE'nin en değerli çıktısı çoğu zaman bir gösterge paneli, bir otomasyon aracı ya da bir mimari iyileştirmedir — gece 3'te atılan kahramanca bir müdahale değil.

SRE ile geliştirici ekipler arasındaki ilişki de bir ortaklıktır, bir hizmet ilişkisi değil. SRE, bir servisi "devralmadan" önce onun belirli olgunluk ölçütlerini karşılamasını bekler: yeterli test, anlamlı gösterge panelleri, yazılı runbook'lar ve makul bir operasyonel yük. Bu "production readiness review", güvenilirliği canlıya çıktıktan sonra değil, tasarım aşamasında masaya getirir — ki güvenilirliği en ucuz ve en etkili biçimde sağlamanın yolu tam da budur.

SRE'nin temel kavramları

SLI, SLO ve SLA

SLI (Service Level Indicator), hizmetin bir yönünü ölçen niceliksel bir metriktir — örneğin başarılı isteklerin oranı ya da isteklerin %99'unun altında kaldığı gecikme. SLO (Service Level Objective), bir SLI için belirlenen hedeftir — örneğin "aylık başarı oranı %99.9". SLA (Service Level Agreement) ise müşteriyle yapılan, ihlali maddi/hukuki sonuç doğuran resmî sözleşmedir. Kısaca: SLI ölçer, SLO hedefler, SLA taahhüt eder. SLO neredeyse her zaman SLA'dan daha katıdır; çünkü şirket, müşteriye söz verdiği eşiğe dayanmadan önce kendi iç alarmını almak ister.

Hata bütçesi (error budget)

SRE'nin belki de en zarif fikri budur. Eğer güvenilirlik hedefin %99.9 ise, geri kalan %0.1 senin "izin verilen güvenilmezliğin"dir — yani bir bütçe. Bu bütçe yeni özellik yayınlamak, risk almak ve deneme yapmak için harcanabilir. Böylece geliştirici ekip ile SRE ekibi artık birbiriyle çatışmak yerine ortak ve nesnel bir ölçüye bakar: bütçe tükenmemişse yeni sürümler çıkabilir; tükenmişse sistem yeniden istikrara kavuşana dek yayınlar durur. "Ne kadar hızlı yayınlamalıyız?" sorusu öznel bir tartışma olmaktan çıkıp veriyle yönetilen bir karara dönüşür.

Örnek: 30 günlük bir pencerede %99.9 hedefiniz varsa, hata bütçeniz yaklaşık 43 dakikadır. Bir dağıtım 20 dakikalık kısmi kesinti yaratırsa bütçenin yarısını harcamış olursunuz. Modern platformlar bu "yanma oranını" (burn rate) gerçek zamanlı hesaplayıp bütçe çok hızlı tükeniyorsa erken uyarı verir.

Toil (angarya)

Toil; elle yapılan, tekrarlayan, otomatikleştirilebilir, kalıcı değer üretmeyen ve hizmetle birlikte ölçeklenen operasyonel iştir. "Her sabah şu raporu elle üret", "her dağıtımda şu servisi elle yeniden başlat" tipik toil örnekleridir. SRE, toil'i bir düşman olarak görür ve ölçer: toil oranı %50'yi aşarsa bu bir alarmdır. Toil ile mücadele, bugün platform mühendisliği (platform engineering), IaC (Terraform/Ansible/Pulumi) ve GitOps (ArgoCD/Flux) hareketlerinin de itici gücüdür.

Gözlemlenebilirlik (observability) ve dört altın sinyal

Bir sistemi izlerken nereye bakılır? Google'ın cevabı "dört altın sinyal"dir: gecikme (latency), trafik (traffic), hatalar (errors) ve doygunluk (saturation). Bu dört sinyal, çoğu üretim sorununu erken yakalar. Modern dünyada gözlemlenebilirliğin üç sütunu (metrics, logs, traces) ve OpenTelemetry standardı bu felsefeyi taşır; RED (Rate, Errors, Duration) ve USE (Utilization, Saturation, Errors) metodları da dört altın sinyalin sektördeki türevleridir.

Nöbet (on-call) ve sürdürülebilirlik

SRE'ler sırayla nöbet (on-call) tutar: belirli bir süre boyunca sistemin sağlığından sorumlu olur ve bir alarm çaldığında müdahale eder. Ama nöbet insani bir maliyettir ve SRE bunu da mühendislik disipliniyle yönetir. Kitabın koyduğu ölçüler nettir: bir mühendisin nöbet yükü, vardiya başına belirli sayıda olayı geçmemeli; her olaya kök neden analizi yapılacak kadar zaman kalmalı ve gece uyandıran alarmların sayısı sıkı takip edilmelidir. Amaç, tükenmişliği (burnout) önleyip nöbeti sürdürülebilir kılmaktır — çünkü yorgun bir ekip, güvenilir bir sistem üretemez.

İyi nöbetin bir başka kuralı da şudur: her uyarı, insanı uyandırmayı hak edecek kadar acil ve eyleme dönüştürülebilir olmalıdır. Eyleme dönüştürülemeyen ya da kendi kendine düzelen bir uyarı, ya otomatikleştirilmeli ya da tamamen kaldırılmalıdır. Alarm gürültüsü, gerçek olayları görünmez kılan en sinsi güvenilirlik düşmanıdır.

Olay yönetimi ve postmortem kültürü

Bir olay (incident) çıktığında SRE, yapılandırılmış bir olay komuta sistemi (incident command) uygular: net roller (olay komutanı, operasyon, iletişim), tek bir gerçeklik kaynağı ve sakin bir koordinasyon. Bu yapı, panik ve kaos yerine soğukkanlı bir iş bölümü sağlar; herkesin "ben ne yapıyorum" sorusuna net bir cevabı olur. Olay kapandıktan sonra suçlamasız (blameless) bir postmortem yazılır: amaç kimin hata yaptığını bulmak değil, sistemin ve sürecin insan hatasına neden izin verdiğini anlamaktır. Suçlama kültürü insanları gerçeği saklamaya iter; suçlamasızlık ise öğrenmeyi mümkün kılar.

İyi bir postmortem'in iskeleti şu sorulara yanıt verir: ne oldu (zaman çizelgesi), kullanıcı ne kadar etkilendi (etki), kök neden neydi, olayı ne tetikledi, nasıl tespit edildi, nasıl çözüldü ve tekrarı önlemek için hangi somut aksiyonlar (sahibiyle ve tarihiyle) alınacak. Bu aksiyonlar takip edilmezse postmortem bir tören olur; takip edilirse sistem her olaydan biraz daha güçlü çıkar.

Güvenilirlik ekonomisi: neden %100 hedeflenmez?

Sezgilerimize aykırı gelse de, bir sistemin hedefi asla %100 güvenilirlik olmamalıdır. Bunun iki nedeni var. Birincisi maliyet: her ek "dokuz" (%99'dan %99.9'a, oradan %99.99'a) altyapı, yedeklilik ve mühendislik açısından katlanarak pahalılaşır. İkincisi algı: kullanıcının sisteme ulaştığı zincirde zaten Wi-Fi, mobil şebeke, DNS ve tarayıcı gibi güvenilirliği %100 olmayan katmanlar vardır; sizin %99.99 ile %100 arasındaki farkınızı kullanıcı çoğu zaman hiç fark etmez. Yani son dokuzu kovalamak, kimsenin görmediği bir mükemmelliğe servet harcamak demektir.

Doğru soru şudur: "Kullanıcı için yeterince iyi olan hedef nedir?" Bu hedef belirlenince, geri kalan pay bilinçli olarak harcanabilir bir kaynağa — hata bütçesine — dönüşür. Bir dakikalık somut örnek: 30 günlük bir pencerede %99.9 hedefi, toplam yaklaşık 43 dakika 12 saniyelik bir hata bütçesi demektir. %99.95 hedefi bunu ~21 dakikaya indirir; %99.99 ise ~4.3 dakikaya. Hedefi bir basamak yükseltmek bütçeyi neredeyse onda birine düşürür — ve o daralan payı korumanın mühendislik maliyeti de aynı oranda artar. Bu yüzden SLO seçimi teknik olduğu kadar ekonomik ve ürünsel bir karardır.

Değişiklik yönetimi ve otomasyon: güvenilirliğin motoru

Üretim kesintilerinin büyük çoğunluğu, sistemde yapılan bir değişiklikten (yeni sürüm, yapılandırma değişikliği, altyapı güncellemesi) kaynaklanır. Bu yüzden SRE'de değişiklik yönetimi güvenilirliğin kalbindedir. Temel prensipler: değişiklikleri kademeli (progressive) uygula, hataları hızlı ve otomatik tespit et, sorun çıkınca güvenle geri al (rollback). Canary dağıtımlar, mavi-yeşil (blue-green) dağıtımlar ve aşamalı yayınlar (staged rollout) bu felsefenin somut araçlarıdır.

Otomasyon ise SRE'nin en güçlü kaldıracıdır — ama iki ucu keskin bir bıçaktır. İyi otomasyon toil'i yok eder, tutarlılığı artırır ve insan hatasını azaltır. Kötü tasarlanmış otomasyon ise bir hatayı saniyeler içinde tüm filoya yayabilir. Bu yüzden SRE, otomasyonu "bir insanın yaptığı işi tekrarlayan script" olarak değil, "sistemin istenen durumunu bildirimsel (declarative) olarak tanımlayan ve o duruma kendi kendine yakınsayan" bir yaklaşım olarak tasarlar. Kubernetes'in "istenen durum" (desired state) mantığı ve GitOps tam olarak bu fikrin modern hâlidir.

SRE vs DevOps: fark tam olarak nedir?

En sık sorulan soru bu. Kısa cevap: DevOps bir kültür ve ilkeler bütünü (bir arayüz), SRE ise o ilkeleri hayata geçiren somut bir uygulamadır (bir sınıf). Google'ın kendi ifadesiyle: "class SRE implements DevOps". DevOps; silolaşmayı azalt, hataları normalleştir, kademeli değişim uygula, araç ve otomasyondan yararlan, her şeyi ölç der. SRE bu ilkelerin her birine somut bir karşılık sunar.

Yani ikisi rakip değil; SRE, DevOps'un "nasıl"ını verir. Bir organizasyon DevOps kültürünü benimseyip güvenilirliği SLO ve hata bütçesiyle yönetmeye başladığında, aslında SRE yapıyordur. Pratikte iş ilanlarında "DevOps Engineer" ve "SRE" başlıkları çoğu zaman örtüşür; farkı belirleyen, güvenilirliğin niceliksel (SLO tabanlı) yönetilip yönetilmediğidir.

Kapasite planlaması ve verimlilik

Güvenilirliğin görünmeyen yarısı kapasitedir: yeterli kaynak yoksa en zarif yazılım bile doygunluğa (saturation) girip yavaşlar ya da çöker. SRE, kapasite planlamasında iki tür büyümeyi öngörmek zorundadır: organik büyüme (kullanıcı tabanının doğal artışı) ve inorganik büyüme (yeni özellik lansmanları, pazarlama kampanyaları, sezonluk zirveler). İkisi birlikte modellenir, talep tahmin edilir ve altyapı buna göre önceden hazırlanır.

Ama kapasitenin diğer yüzü verimliliktir. Sonsuz kaynak eklemek güvenilirliği artırır ama maliyeti sürdürülemez kılar. SRE, gecikme (latency), yük ve maliyet arasındaki dengeyi sürekli ayarlar: otomatik ölçekleme (autoscaling), doğru makine tipleri, önbellekleme ve gereksiz kaynakların budanması. Modern bulutta bu, FinOps pratikleriyle ve Kubernetes'in kaynak istekleri/limitleriyle iç içe geçmiştir — güvenilirlik ile maliyet arasında bilinçli bir mühendislik dengesi kurulur.

SRE, sysadmin ve platform mühendisliğinden nasıl ayrılır?

Klasik sistem yöneticisi (sysadmin) çoğunlukla elle operasyon yapar; başarısı "sistem ayakta mı" ile ölçülür. SRE ise aynı hedefe kod yazarak ulaşır ve başarısını SLO/hata bütçesiyle ölçer. Platform mühendisliği (platform engineering) ise daha yeni bir kavramdır: geliştiricilerin kendi kendine yetebileceği iç geliştirici platformları (IDP) kurar — yani SRE ve DevOps ilkelerini bir ürüne dönüştürür. Üçü de örtüşür; ama SRE'nin ayırt edici imzası, güvenilirliği niceliksel bir mühendislik hedefi olarak ele almasıdır.

Bunu bir örnekle netleştirelim: bir veritabanının diski dolmak üzere. Bir sysadmin gece yarısı bağlanıp diski elle büyütür — sorun çözülür ama bir sonraki sefere yine aynı iş vardır. Bir SRE ise diskin dolma eğilimini bir SLI olarak izler, kapasiteyi önceden planlar ve diski belirli bir eşikte otomatik büyüten (ya da eski verileri arşivleyen) bir mekanizma yazar; böylece o gece yarısı çağrısı bir daha hiç gelmez. Bir platform mühendisi ise bunu tek bir servis için değil, tüm ekiplerin kullanabileceği self-servis bir yetenek hâline getirir. Aynı sorun, üç farklı olgunluk seviyesi — ve SRE'nin katkısı, çözümü koda ve ölçüme gömmesidir.

SRE'nin günlük araç kutusu

SRE'nin araçları, işin katmanlarını izler: ölçmek, otomatikleştirmek, dağıtmak ve müdahale etmek. Uçtan uca tipik bir yığın şöyle görünür:

• Gözlemlenebilirlik: Prometheus + Grafana (metrik), OpenTelemetry (enstrümantasyon), Loki/ELK (log), Jaeger/Tempo (trace), Alertmanager (uyarı).
• SLO ve hata bütçesi: Nobl9, Grafana SLO, Datadog SLO, Google Cloud Service Monitoring — SLO'ları kod olarak tanımlar ve yanma oranı uyarısı üretir.
• Orkestrasyon: Kubernetes (Borg'un fikrî torunu) ve yönetilen türevleri (EKS/GKE/AKS).
• Altyapı kod olarak: Terraform, Pulumi, Ansible — sağlama (provisioning) toil'ini yok eder.
• CI/CD ve GitOps: GitHub Actions/GitLab CI, ArgoCD/Flux — güvenli, tekrarlanabilir dağıtım.
• Olay yönetimi: PagerDuty/Opsgenie (nöbet ve eskalasyon), Slack tabanlı ChatOps, runbook otomasyonu (Rundeck, AWS Systems Manager).

Dikkat: araçlar disiplinin kendisi değildir. Prometheus kurmak sizi SRE yapmaz; SLO tanımlamak, hata bütçesiyle karar almak ve suçlamasız öğrenmek yapar. Araç, ilkenin hizmetindedir — tersi değil.

Yaygın yanlış anlamalar

• "SRE = nöbet tutan kişi." Nöbet işin bir parçasıdır ama özü değildir; öz, toil'i mühendislikle yok etmektir.
• "SRE = DevOps'un yeni adı." Hayır — DevOps ilke, SRE o ilkelerin somut, ölçülebilir uygulamasıdır (SLO/hata bütçesi ile).
• "Daha fazla uyarı = daha güvenli." Tam tersi; nedene değil belirtiye dayanmayan aşırı uyarı, gerçek olayları gürültüde boğar.
• "%100 çalışma süresi hedeftir." Hayır; hedef, kullanıcı için yeterli olan SLO'dur — geri kalanı bilinçle harcanan bir bütçedir.
• "Otomasyon her zaman iyidir." Kötü otomasyon bir hatayı tüm filoya yayabilir; bildirimsel ve geri alınabilir tasarım şarttır.

Nasıl SRE olunur? Yol haritası

SRE, hem sistem hem yazılım tarafını isteyen bir rol olduğu için geniş ama net bir temel gerektirir. Önerilen sıra:

1. 1Linux temelleri: süreçler, ağ (ss, tcpdump), sistem servisleri (systemd, journalctl), performans (top, iostat). Terminalde rahat ol.
2. 2Bir programlama dili: Python veya Go ile küçük otomasyonlar ve araçlar yazabilmek. "Bash script"ten "gerçek araç"a geçiş SRE'nin özüdür.
3. 3Ağ ve dağıtık sistemler: DNS, HTTP, yük dengeleme, önbellek, tutarlılık, kuyruklar. Neden yavaş/hatalı olduğunu anlamak için.
4. 4Konteyner ve orkestrasyon: Docker + Kubernetes. Modern üretim ortamlarının ortak dili.
5. 5IaC ve CI/CD: Terraform, GitHub Actions/GitLab CI, GitOps. Toil'i öldürmenin araçları.
6. 6Gözlemlenebilirlik: Prometheus + Grafana, OpenTelemetry, log/trace sistemleri. Dört altın sinyali ölçmek için.
7. 7SRE pratikleri: SLO tasarımı, hata bütçesi, postmortem yazımı, olay yönetimi. Kavramları gerçek senaryolarda uygula.

Türkiye'de ve uzaktan SRE kariyeri

SRE/DevOps rolleri, hem Türkiye'deki büyük teknoloji ve finans şirketlerinde hem de uzaktan çalışan uluslararası ekiplerde en çok aranan pozisyonlar arasında. Bulut (AWS/GCP/Azure), Kubernetes ve Terraform yetkinliği, bu piyasada en yüksek getirili beceri setlerinden biridir. İyi haber: bu becerilerin hepsi pratikle, gerçek sistemleri bozup düzelterek kazanılır — sertifikalar (CKA, AWS SAA, Terraform Associate) bu yolculukta hem yön verir hem de işverene sinyal gönderir.

Sık sorulan sorular

SRE olmak için mutlaka kod yazmak gerekir mi?

Evet. SRE'yi klasik sistem yöneticiliğinden ayıran tam da budur: elle iş yapmak yerine o işi ortadan kaldıracak yazılımı yazmak. Uzman düzeyde geliştirici olmak şart değil, ama Python/Go ile araç yazabilmek beklenir.

Küçük bir şirketin SRE'ye ihtiyacı var mı?

Ayrı bir SRE ekibine belki değil, ama SRE ilkelerine kesinlikle. Beş kişilik bir startup bile SLO tanımlamaktan, hata bütçesi düşünmekten, toil'i azaltmaktan ve suçlamasız postmortem yazmaktan yararlanır. İlkeler ölçekten bağımsızdır; yalnızca uygulama biçimi ölçeğe göre değişir.

SRE mi DevOps mühendisi mi olmalıyım?

İkisi zıt kariyerler değil. Aynı beceri temeli (Linux, bulut, Kubernetes, IaC, gözlemlenebilirlik) her ikisini de besler. SRE tarafına yönelmek istiyorsan güvenilirliği niceliksel yönetmeyi (SLO, hata bütçesi) ve olay/postmortem kültürünü öne çıkar.

Hata bütçesi tükenince gerçekten yayın durur mu?

İyi işleyen bir SRE kültüründe evet — ama bu bir ceza değil, önceden mutabık kalınan bir politikadır. Bütçe tükendiğinde ekip, yeni özellik yerine güvenilirlik işine (bug düzeltme, dayanıklılık iyileştirmeleri) odaklanır ve sistem tekrar hedefin üstüne çıkınca yayınlar açılır. Bu politika CI/CD hattına da bağlanabilir: bütçe kritik seviyeye inince otomatik "deploy freeze" tetiklenir.

Postmortem neden 'suçlamasız' olmalı?

Çünkü amaç kimin butona yanlış bastığını bulmak değil, sistemin ve sürecin o yanlış basışa neden izin verdiğini anlamaktır. İnsanlar suçlanacağını hissederse gerçeği saklar, detayları yumuşatır ve ekip öğrenemez. Suçlamasızlık, dürüst anlatımı mümkün kılar; böylece aynı arıza bir daha çıkmasın diye gerçek kök nedene inilebilir.

Daha derine inmek istersen, Google'ın SRE kitabının kapsamlı Türkçe özetini de hazırladık — SLO'dan toil'e, olay yönetiminden otomasyona kadar tüm disiplini modern bulut sistemleriyle karşılaştırarak anlatıyor: /blog/site-reliability-engineering-turkce-ozet

Son bir çerçeve: SRE'yi bir başlık ya da bir araç yığını olarak değil, bir düşünme biçimi olarak görmek en doğrusudur. "Bu işi elle mi yapıyorum, yoksa yapan yazılımı mı yazıyorum?", "Kullanıcı için yeterli güvenilirlik nedir ve bunu ölçebiliyor muyum?", "Bu olaydan sistemim ne öğrendi?" — bu üç soru, hangi unvana sahip olursanız olun, işinizi SRE zihniyetiyle yapmanızı sağlar. Disiplinin gücü, tam da ölçekten ve unvandan bağımsız bu ilkelerdedir.

Özetle: SRE, güvenilirliği bir umut değil bir mühendislik çıktısı yapar. Kavramları okumak iyi bir başlangıç; ama kalıcı öğrenme, gerçek sistemleri bozup düzelterek gelir. Cloudpuz'un hands-on lab'ları ve SRE rotası tam da bu refleksi kazandırmak için tasarlandı.