SRE Nedir? DevOps ile İlişkisi, Toil, Error Budget Fikri ve Küçük Ekipte SRE

Sürüm notu: Bu yazı kavramsal ve kod örneği içermiyor; alıntılar ve sayılar Google'ın Site Reliability Engineering kitabının (2016) ve The Site Reliability Workbook'un (2018) sre.google'daki çevrim içi sürümlerinden 14 Kasım 2026'da kontrol edildi.

Önce Tahmin Et

Bookstore (sitedeki serilerin ortak örnek uygulaması, bir online kitapçı) ekibinde Product Owner Selin bir sabah şunu söylüyor: "Checkout bir daha hiç durmamalı. Hedefimiz yüzde 100." Emre itiraz ediyor: "Yüzde 100 olmaz, yüzde 99,99 diyelim." Ayşe ise "yüzde 99,9 yeter" diyor. Üç soru: 30 günlük bir ayda yüzde 99,9 kaç dakika kesintiye izin verir, yüzde 99,99 kaç dakikaya? Müşterinin telefonu ve mobil bağlantısı yüzde 99 oranında sorunsuz çalışıyorsa, bu iki hedef arasındaki farkı müşteri fark eder mi? Ve yüzde 100 hedefi ekibin bir sonraki release'ini nasıl etkiler? Cevaplar yazının ortasında.

SRE Nereden Çıktı?

SRE (Site Reliability Engineering; production sistemlerinin güvenilirliğini yazılım mühendisliği yöntemleriyle yönetme disiplini) Google'da doğdu. Ben Treynor Sloss 2003'te Google'a katıldığında yedi mühendislik bir "Production Team"in başına getirildi. O güne kadar hep yazılım geliştirmişti ve ekibi bir yazılımcının çalışmak isteyeceği gibi kurdu. SRE kitabının girişinde tanımı tek cümle: "SRE is what happens when you ask a software engineer to design an operations team" (Treynor Sloss, Site Reliability Engineering, 2016).

Bu cümlenin pratikteki karşılığı şu: klasik operations ekibi sistemi elle ayakta tutar, sistem büyüdükçe ekip de büyür. SRE ekibi ise aynı işi kod yazarak çözmeye çalışır; tekrar eden operasyon işini otomatikleştirir, güvenilirliği ölçer ve "ne kadar güvenilir olmalı" sorusunu sayıya bağlar. Google bu yaklaşımı 2016'da "Site Reliability Engineering" kitabıyla, 2018'de uygulama odaklı "The Site Reliability Workbook" ile anlattı. İkisi de sre.google'da ücretsiz okunabiliyor ve bu serinin ana kaynakları.

Kısa bir tarihçe: önce yazılım ekibi kodu yazıp operations ekibine "devretti"; release'ler seyrek ve korkutucuydu. 2008'in sonlarında "DevOps" adı ortaya çıktı ve geliştirme ile operasyonun aynı hedefe bakması gerektiğini söyledi. Google'daki SRE bundan önce başlamıştı, ama kitaplar yayımlandığında DevOps'un sorduğu birçok soruya somut cevaplar veriyordu.

SRE ile DevOps Arasındaki İlişki

SRE kitabı bu ilişkiyi şöyle kuruyor: DevOps bir dizi ilke (ortak sorumluluk, küçük ve sık değişiklik, otomasyon, ölçüm), SRE ise bu ilkelerin belirli bir implementasyonu. Workbook'taki ilgili bölümün alt başlığı bunu bir yazılımcının anlayacağı dille söylüyor: "class SRE implements interface DevOps". Yani DevOps "ne" sorusunu, SRE "nasıl" sorusunu cevaplıyor.

"Nasıl"ın somut parçaları bu serinin yazıları: kullanıcının yaşadığını ölçen SLI (Service Level Indicator; servisin kullanıcıya ne kadar iyi hizmet verdiğini gösteren ölçüm), o ölçüm için hedef olan SLO (Service Level Objective; belirli bir zaman penceresinde tutturulması hedeflenen güvenilirlik seviyesi), hedefin bıraktığı pay olan error budget (hata bütçesi), SLO'ya dayanan alert'ler, on-call (nöbet) düzeni ve runbook'lar, incident yönetimi ve postmortem (incident sonrası yazılan, suçlu aramayan değerlendirme raporu). DORA (DevOps Research and Assessment; yazılım teslim performansını ölçen araştırma programı) metrikleri, CI/CD Temelleri serisinin "Pipeline'ı Ölçmek ve Hızlandırmak: DORA Metrikleri, Cache ve Paralellik" yazısında anlatıldığı gibi teslimatın hızını ölçüyordu; SRE bunun yanına "kullanıcı ne yaşıyor" ölçümünü koyuyor.

Yüzde 100 Neden Yanlış Hedef?

SRE kitabının girişindeki en çok alıntılanan fikirlerden biri şu: "100% is the wrong reliability target for basically everything" (Treynor Sloss, Site Reliability Engineering, 2016). İstisna olarak kalp pili ve ABS (Anti-lock Braking System; kilitlenmeyi önleyen fren sistemi) gibi hayati sistemleri sayıyor. Bir web servisi için üç gerekçe var.

Birincisi, kullanıcı farkı göremez. Müşteri Bookstore'a telefonundan, mobil ağdan, evdeki modemden bağlanıyor. Bu zincirin her halkasının kendi kesintisi var. SRE kitabının "Embracing Risk" bölümü bunu şöyle örnekliyor: yüzde 99 güvenilir bir telefon kullanan biri yüzde 99,99 ile yüzde 99,999 arasındaki farkı göremez. Önce Tahmin Et'teki ikinci sorunun cevabı da bu: müşterinin kendi tarafındaki kesinti, yüzde 99,9 ile yüzde 99,99 arasındaki farktan çok daha büyük.

İkincisi, her "nine" bir öncekinden daha pahalı. Yüzde 99'dan 99,9'a çıkmak genelde iyi bir deploy süreci ve birkaç alert ile olur. 99,99 için yedekli veritabanı, otomatik failover, birden çok bölge ve 7/24 on-call gerekir. Fazladan her dokuz, bir öncekinin birkaç katı emek ister ve kullanıcı bunun karşılığını hissetmez.

Üçüncüsü ve en önemlisi: yüzde 100 hedefi değişikliği durdurur. Her deploy bir risk; yüzde 100 hedefi olan bir ekip için en güvenli şey hiç deploy etmemek. Selin'in hedefi kâğıt üzerinde güvenilirlik istiyor, pratikte yeni özelliklerin önünü kesiyor. Üçüncü sorunun cevabı bu.

Error Budget: Hız ile Güvenilirlik Arasında Anlaşma

Hedef yüzde 100 değilse aradaki fark bir bütçe olur. SLO yüzde 99,9 ise error budget yüzde 0,1'dir: 30 günde 43.200 dakikanın binde biri, yani yaklaşık 43 dakika. Yüzde 99,99 için bu 4,3 dakikaya düşer; tek bir kötü deploy'un geri alınması bile bütçenin tamamını yer. Yüzde 99,5 için ayda 216 dakika, yani 3,6 saat. Önce Tahmin Et'teki ilk soru buydu.

Error budget'ın asıl işi bir anlaşmazlığı çözmek. Geliştirici hızlı release ister, operasyon tarafı sistemin bozulmamasını. SRE kitabı bu gerilimi "structural conflict" olarak adlandırıyor ve error budget ile çözüyor: bütçe varsa ekip risk alır, yeni sürümleri çıkarır, deneme yapar; bütçe biterse öncelik güvenilirlik işine kayar. Karar artık "bence bu deploy riskli" tartışması değil, ölçülmüş bir sayı. Bütçe harcanmak için var: hiç harcanmayan bir bütçe, hedefin gereğinden yüksek ya da ekibin gereğinden yavaş olduğunu gösterir.

Bunun çalışması için üç şey gerekiyor: kullanıcının yaşadığını ölçen bir SLI, üzerinde anlaşılmış bir SLO ve bütçe bittiğinde ne olacağını önceden yazan bir error budget policy. SLI'ı serinin ikinci yazısında, SLO ve policy'yi üçüncüsünde ele alıyoruz.

Toil: Ölçülmesi Gereken Operasyon İşi

SRE'nin ikinci temel kavramı toil (production'ı işletmek için yapılan, elle yapılan ve tekrar eden, kalıcı değer üretmeyen iş). SRE kitabının "Eliminating Toil" bölümü bir işi toil yapan özellikleri şöyle sayıyor: elle yapılıyor, tekrar ediyor, otomatikleştirilebilir, o anki sorunu çözüyor ama kalıcı bir iyileştirme bırakmıyor ve servis büyüdükçe doğrusal olarak artıyor. Her toil işi bu özelliklerin hepsini taşımak zorunda değil; ne kadar çoğunu taşıyorsa o kadar toil.

Toil, sevilmeyen iş demek değil. Toplantılar ve İK yazışmaları overhead; sıkıcı ama kalıcı değer bırakan iş (örneğin alert configuration'ını baştan temizlemek) toil sayılmıyor. Bookstore'dan toil örnekleri:

• Disk dolduğunda sunucuya bağlanıp eski log dosyalarını elle silmek.
• Kurumsal müşterilerin aylık sipariş CSV (virgülle ayrılmış değerler) dosyasını her ay elle import edip hataları tek tek düzeltmek.
• Ödeme sağlayıcısı yavaşladığında API'yi elle restart etmek, çünkü "genelde düzeliyor".
• Her release'te aynı yedi adımı bir wiki sayfasından bakarak elle uygulamak.
• Sertifika süresi dolmadan önce takvim hatırlatmasıyla elle yenilemek.

Google'ın kuralı, SRE'lerin zamanının en fazla yüzde 50'sinin toil ve operasyon işine gitmesi; kalanı mühendislik, yani toil'i azaltan ve sistemi iyileştiren işler. Kitaba göre Google'ın iç anketlerinde ortalama toil oranı yaklaşık yüzde 33 çıkmış, ama kişiden kişiye yüzde 0 ile 80 arasında değişiyor. Sınırın amacı şu: toil servisle birlikte büyür; ölçülmezse ekibin bütün zamanını yer ve kimse sistemi iyileştirmeye vakit bulamaz. Küçük bir ekip için de ilk adım aynı: bir hafta boyunca operasyon işine giden saatleri yazmak.

Küçük Ekipte SRE

Bookstore'un ayrı bir SRE ekibi yok; Selin, Emre ve Ayşe hem yazıyor hem işletiyor. Google'ın kitabındaki her şeyi uygulamak bu ekibi boğar. Seçici olmak gerekiyor. Her ekibin alması gerekenler: iki üç kritik kullanıcı yolculuğu için SLO, SLO'ya bağlı az sayıda alert, her alert için bir runbook, haftalık on-call rotasyonu ve büyük incident'lardan sonra kısa bir postmortem. Lüks olanlar: ayrı bir SRE ekibi, birden çok saat diliminde follow-the-sun (gün boyunca nöbetin saat dilimleri arasında devredilmesi) on-call, otomatik bir chaos engineering platformu, yönetim kurulu imzalı error budget policy'leri.

Başlamadan önce yapılacak ilk iş envanter: production'da ne var, kim bakıyor, bugün neye bakılıyor? Bookstore ekibinin çıkardığı tablo şöyle:

Tablonun tek satırında bile kullanıcının yaşadığı şey ölçülmüyor. CPU alarmı, checkout'un çalışıp çalışmadığını söylemiyor; ödeme sağlayıcısının kimsenin sorumluluğunda olmaması da ileride incident'ın en uzun süren kısmı olacak. Serinin geri kalanı bu boşlukları sırayla dolduruyor.

Üretimde Dikkat

SRE bir unvan değişikliği değil. Operations ekibinin adını "SRE" yapıp aynı işi yapmaya devam etmek hiçbir şeyi değiştirmez; değişiklik ölçümle başlar. Önce ölçülebilir bir SLI, sonra onun geçmiş verisi, sonra bir hedef. Geçmiş veri yokken konan SLO tahminden ibarettir.

Operasyon işini görünür kıl. Kimin kaç kez page aldığını (gece telefonla uyandıran acil alarm), kaç saatin elle müdahaleye gittiğini yazmayan bir ekip toil'in büyüdüğünü fark etmez. Basit bir tablo yeter: tarih, ne oldu, kaç dakika sürdü, otomatikleştirilebilir mi?

Güvenilirlik sorumluluğunu yazan ekipte tut. Küçük ekiplerde "bir kişi operasyona baksın" çözümü cazip, ama o kişi kodu değiştiremiyorsa yalnızca elle müdahale eder. SRE'nin fikri, sistemi işletenin onu değiştirebilmesi.

Sık Düşülen Tuzaklar

Her şeye SLO koymak. Yirmi endpoint için yirmi SLO, kimsenin bakmadığı yirmi grafik demek. Kullanıcının gerçekten önemsediği iki üç yolculukla başla.

Error budget'ı ceza olarak kullanmak. Bütçe bitince "kim bozdu" diye sormak ekibi incident'ları gizlemeye iter. Bütçe bir karar aracı; kişi değil sistem hakkında konuşur.

Toil'i kahramanlıkla çözmek. Gece yarısı sunucuya bağlanıp elle düzelten kişi takdir görür, ama aynı iş haftaya yine gelir. Asıl iş, ikinci kez yapılan elle müdahaleyi kayda almak ve otomasyon için iş kaydı açmak.

Altyapı metriğini güvenilirlik sanmak. CPU, bellek ve disk alarmları sorunun nedenini aramak için faydalı; ama kullanıcı CPU'yu görmez, hatayı ve bekleme süresini görür.

Ne Zaman Gerekmez?

Tek kişilik bir hobi projesinde ya da kullanıcısı olmayan bir iç prototipte tam SRE süreci gereksiz. On-call rotasyonu, error budget policy ve postmortem toplantısı en az birkaç kişilik bir ekip ve bekleyen kullanıcılar varsa anlamlı. Böyle bir projede iki şey yeter: bir health check ve bir uptime kontrolü. Ama ilk ödeme alan kullanıcı geldiği gün en azından checkout için bir SLI tanımlamaya değer.

Küçük Bir Deneme

★☆☆ 28 günlük bir pencerede yüzde 99,95 SLO'nun error budget'ını dakika olarak hesapla. Aynı hedef 30 günlük pencerede kaç dakika ediyor? Farkın neden önemli olabileceğini düşün.

★★☆ Kendi ekibinde bir hafta boyunca operasyon işine giden her işi yaz: ne yapıldı, kaç dakika sürdü, elle mi yapıldı, tekrar ediyor mu? Toil özelliklerine göre sınıflandır ve toplam sürenin haftalık çalışma saatine oranını bul.

★★★ Bakımını yaptığın bir servis için yukarıdaki envanter tablosunu çıkar. "Bugün ne izleniyor" sütununda kullanıcının yaşadığını ölçen kaç satır var? Ödeme ya da e-posta sağlayıcısı gibi dış bağımlılıklar için bir sahip yaz.

Error budget'ın işe yaraması için önce kullanıcının yaşadığını doğru ölçmek gerekiyor. Bir sonraki yazıda Bookstore'un kritik kullanıcı yolculuklarını çıkarıyoruz ve ASP.NET Core'un built-in http.server.request.duration metric'inden checkout için SLI'lar türetiyoruz: hangi istek "iyi", hangisi "geçerli", hangi ölçüm noktası neyi göremez.