SRE Ne Çözer
Site Reliability Engineering’e Hoş Geldiniz
Site Reliability Engineering (SRE), 2003 yılında Google’da doğdu. Ben Treynor Sloss küçük bir operasyon ekibini devraldı ve ekibi, üretim sistemlerini insan çağrı cihazları yerine mühendislerin yönettiği bir yapıya dönüştürdü. Ortaya çıkan model, büyük ölçekli internet servislerini işletmenin standart yaklaşımı haline geldi.
Geleneksel operasyon ekipleri servisleri manuel işlerle ayakta tutuyordu: sunucuyu yeniden başlat, mühendisi çağır, runbook yaz, umut et. Bu model ölçeklendikçe çöker. Elli kişilik bir ekip beş bin sunucuyu manuel olarak yeniden başlatamaz. Belirli bir büyüklüğün ötesinde manuel operasyonlar, tüm verimli saatleri tüketen bir vergiye dönüşür.
SRE modeli tersine çevirir. Sistemler büyüdükçe daha fazla operatör yerine yazılım mühendisleri işe alınır ve onlara şu talimat verilir: operasyonel işleri sizin yerinize yapacak kodu yazın. İşiniz, operasyon problemlerine uygulanan yazılım mühendisliğidir. Çıktınız: otomasyon, izleme ve tasarlanmış güvenilirlik; manuel müdahaleler değil.
SRE uygulamasını üç temel fikir yönlendirir:
- Hizmet Seviyesi Hedefleri (SLO’lar): önceden üzerinde anlaşılmış sayısal güvenilirlik hedefleri
- Hata bütçeleri: SLO’nun tersi; risk alma için harcanır
- Toil’in ortadan kaldırılması: sistem boyutuyla doğrusal olarak artan her türlü operasyonel iş yok edilmelidir
Bu üç fikir, postmortem’lerden nöbet rotasyonlarına, kapasite planlamasından izlemeye ve sürüm mühendisliğine kadar her SRE pratiğine yansır.
Geleneksel Operasyonlar ve SRE Karşılaştırması
Geleneksel Operasyonların Ölçekte Neden Çöktüğü
Tipik bir ops ekibi, yönettiği sistemlerle doğrusal olarak büyür. Sunucuları iki katına çıkarın, operatörleri de iki katına çıkarın. Bu, küçük dağıtımlar için finansal olarak mantıklıdır ancak ölçekte felaket yaratır: karesel bir sorundan işe alım yaparak çıkamazsınız.
SRE, operasyonel çalışmayı bir mühendisin zamanının yüzde ellisiyle sınırlar. Diğer yarısı mühendisliğe ayrılmalıdır: araçlar geliştirmek, süreçleri otomatikleştirmek ve onları ilk etapta yüzde elliye getiren zahmeti ortadan kaldırmak. Eğer zahmet uzun süre yüzde elliyi aşarsa, ekip işi geliştirme ekibine geri vermeli veya daha fazla SRE işe almalıdır. Yüzde elli kuralı, SRE ekibinin sürekli baskı altında geleneksel bir ops ekibine dönüşmesini önler.
Arıza modlarını karşılaştırın:
- Geleneksel ops: daha fazla olay daha fazla manuel müdahaleye yol açar, bu da önleme için daha az zaman bırakır ve daha fazla olay yaratır. Bir felaket döngüsü.
- SRE: daha fazla olay postmortem'leri tetikler, bunlar otomasyon fırsatlarını ortaya çıkarır ve bir sonraki olayın müdahale süresini azaltır. Çalıştığında erdemli bir döngü.
SLI, SLO, SLA
Üretimi Yöneten Üç Harf
Ölçüm olmadan güvenilirlik tiyatrodur. SRE, güvenilirliği önceden üzerinde anlaşılmış ve herkesin doğrulayabileceği bir sayıya dönüştürür.
Hizmet Seviyesi Göstergesi (SLI): bir hizmet davranışının ölçümüdür. Örnekler: istek gecikmesi, hata oranı, verim, kuyruk derinliği. SLI, grafiğe dökebileceğiniz bir şeydir.
Hizmet Seviyesi Hedefi (SLO): bir SLI için hedef değer veya aralıktır. Örnek: '28 günlük kayan pencere içinde HTTP isteklerinin %99,9'u başarılı olur.' SLO, kendinize ve kullanıcılarınıza kabul edilebilir hizmet kalitesi hakkında verdiğiniz bir vaattir.
Hizmet Seviyesi Sözleşmesi (SLA): genellikle ihlal durumunda mali cezalar içeren sözleşmeye dayalı bir taahhüttür. Örnek: 'Aylık erişilebilirlik %99,9'un altına düşerse %10 iade ederiz.' SLA, avukatlar tarafından uygulanan bir vaattir.
Kritik ayrım: SLA'nız her zaman SLO'nuzdan daha gevşek olmalıdır. Dahili olarak %99,9 hedefliyorsanız ve harici olarak %99,9 sözleşme yapıyorsanız, sıfır marjınız vardır. SRE'ler genellikle SLO'ları SLA'dan bir dokuz daha sıkı çalıştırır: %99,95 hedef, %99,9 sözleşme. Bu boşluk, kaçınılmaz kötü haftayı emer.
Hata Bütçeleri: SLO'nun Tersi
Güvenilirlik Hedeflerinden Mühendislik Kararlarına
Bir SLO, bir güvenilirlik hedefi belirler. Hata bütçesi, geriye kalan kısımdır: hedefi kaçırmadan önce harcayabileceğiniz başarısızlık miktarı.
Eğer SLO’nuz 28 günlük bir dönemde %99.9 başarı vaat ediyorsa, hata bütçeniz isteklerin %0.1’i kadardır; bu da ayda yaklaşık 40 dakika tam kesinti anlamına gelir. Bu bütçe, planlı yayınlar, deneysel özellikler, kaos mühendisliği veya sorunlu bir bağımlılığa tolerans göstermek için istediğiniz gibi harcayabileceğiniz bir kaynaktır.
Hata bütçeleri, geliştirme ile operasyonlar arasındaki çatışmayı yeniden çerçeveler. Bütçe olmadan her kesinti, kimin hatalı değişikliği yayınladığı ve bir sonrakini nasıl önleyeceği üzerine bir tartışmaya dönüşür. Bütçe ile:
- Bütçe kalır: daha hızlı yayın yapın, daha fazla risk alın, deneyler yürütün. Bütçe bunu karşılar.
- Bütçe tükendi: yeni özellik yayınlarını durdurun, riskli değişiklikleri dondurun, bütçe yeniden oluşana kadar güvenilirlik çalışmalarına odaklanın.
Bu yaklaşım, güvenilirliği duygusal bir tartışmadan ölçülebilir bir kaynağa dönüştürür. Mühendisler, bütçeyi diğer üretim girdileri gibi bilinçli şekilde harcayabilir.
Toil'i Tanımlama
Toil Olarak Sayılanlar
Her operasyon görevi toil olarak nitelendirilmez. SRE, toil'i kesin olarak şöyle tanımlar: manuel, tekrarlı, otomatikleştirilebilir, taktiksel, kalıcı değeri olmayan ve hizmet büyüdükçe doğrusal olarak ölçeklenen iş.
Altı özelliğin tümü geçerli olmalıdır. Tek seferlik bir veri taşıma işlemi manueldir ancak tekrarlı değildir: bu toil olarak nitelendirilmez. Kıdemli bir mühendis yeni bir hizmet mimarisi tasarlarken taktiksel bir karar alır ancak kalıcı değer katar: bu da toil olarak nitelendirilmez.
Toil olarak nitelendirilen örnekler:
- Bellek sızıntısı nedeniyle çöken bir hizmeti manuel olarak yeniden başlatmak
- Olay müdahalesi sırasında sohbet kanalına günlük parçaları yapıştırmak
- Yeni bir veritabanı sağlamak için bilet formu doldurmak
- Elle yürütülen üç aylık kapasite raporu
- Tek tek onaylanan rutin dağıtım talepleri
Yüzde elli kuralı, toil’i bir SRE’nin zamanının yarısıyla sınırlar. %50’nin üzerine çıkıldığında ekip, sorumluluğu ürün ekibine geri vermeli ya da daha fazla mühendis işe almalıdır; ancak hedef değişmez: toil’i sıfıra indirmek için aynı işi insan müdahalesi olmadan yapan mühendislik sistemleriyle değiştirmek.
Otomasyon yalnızca zaman kazandırmaz. İnsan hatalarının tüm bir sınıfını tamamen ortadan kaldırır. Veritabanı hazırlayan bir betik, uzun bir vardiyadan sonra adımları unutmaz.
Toil Denetim Mantığı
Ekibiniz zamanını nasıl harcadığını takip eder. Geçen çeyrek dağılım şöyleydi: %30 dağıtım, %25 olay müdahalesi, %20 kapasite çalışması, %15 özellik geliştirme, %10 ürün ekiplerinden gelen tek seferlik talepler.
On-Call Hijyeni
Mühendisler, Pager'lar Değil
On-call gerçek bir maliyete sahiptir. Uyku düzeni bozulur, hafta sonları kesintiye uğrar ve bilinmeyen sorunların yarattığı stres birikir. SRE, on-call’ı sürdürülebilir bir kaynak olarak ele alır, kahramanca bir yük olarak değil.
Sağlıklı on-call rotasyonları birkaç ilkeye dayanır:
- Tazmin edilen süre: on-call saatleri izin, ek ödeme veya eşdeğer bir faydayla karşılanır. Ücretsiz on-call ekibi tükenmişliğe sürükler.
- Makul rotasyon derinliği: altı kişilik bir ekipte birincil ve ikincil on-call varsa her mühendis üç haftada bir nöbet tutar. İki kişilik rotasyonlar kariyerleri yok eder.
- Sayfa hacmi bütçesi: Google’ın SRE kitabı, on iki saatlik vardiyada en fazla iki sayfa önerir. Bu sınırın üstünde ekip, sadece dayanmak yerine alarm hacmini azaltmak için mühendislik zamanı ayırmalıdır.
- Yalnızca eyleme geçirilebilir alarmlar: her sayfa insan müdahalesi gerektirmelidir. Bir sayfa göz ardı edilecek, otomatikleştirilecek veya normal çalışma sırasında tekrar tekrar tetiklenecekse var olmamalıdır. Alarm yorgunluğu bir güvenilirlik kusurudur.
- Güneşi takip eden devirler: küresel ekipler, vardiyaları saat dilimi sınırlarında devreder; böylece sistem gerçekten sabaha kadar bekleyemeyecek durumdaysa kimse sabah 3’te çağrı almaz.
Blameless Postmortem'lar
Kesintiler Nasıl İyileştirmelere Dönüşür
Her önemli olay bir postmortem alır: ne olduğu, neden olduğu, neyin düzelttiği ve tekrarını önleyecek değişikliklerin yazılı analizi. Postmortem, SRE’nin bileşik faiz eşdeğeridir: her biri sisteme kalıcı güvenilirlik katar.
Blameless (suçsuz) demek, belgenin hataları bireylere değil sistemlere ve süreçlere atfetmesidir. Bir mühendis yanlış komutu çalıştırdıysa, postmortem şu soruları sorar: Sistem bu komutu neden izin verdi? Hiçbir güvenlik önlemi neden yakalamadı? Sisteme, dokümantasyona veya araca yapılacak hangi değişiklik, bir sonraki mühendisin aynı hatayı yapmasını engeller?
Blameless yaklaşımı tek bir nedenle vardır: insanlar cezalandırılma korkusuyla hatalarını gizler. Gizlenen hatalar bir sonraki olaya dönüşür. Blameless kültürün maliyeti, açıklanmamış kusurların birikmesinin maliyetine kıyasla ucuz kalır.
Postmortem’lar genellikle şunları kapsar:
- Özet: olayın ve etkisinin tek paragraflık tanımı
- Zaman Çizelgesi: dakikası dakikasına, zaman damgalı yeniden yapılandırma
- Kök neden analizi: hatanın oluşmasına izin veren teknik ve süreç faktörleri
- Tespit: ekibin olayı nasıl öğrendiği ve ne kadar sürdüğü
- Çözüm: hizmeti geri yüklemek için alınan eylemler
- Öğrenilen dersler: ne işe yaradı, ne işe yaramadı
- Eylem maddeleri: somut, sahipli ve zaman sınırlı mühendislik görevleri
Eylem maddeleri bir takip aracında tutulur. Diğer tüm mühendislik işleri gibi önceliklendirilirler. Eylem maddesi içermeyen postmortemler hikaye anlatımına dönüşür. Çalışma hiçbir şeyi değiştirmez.
Dört Altın Sinyal
Her Servisin Ölçmesi Gerekenler
Google'un SRE kitabı, kullanıcıya dönük her servisin mutlaka göstermesi gereken dört sinyal önerir: latency, traffic, errors ve saturation. Birlikte ele alındıklarında, servisin sağlığını kullanıcının bakış açısından tanımlarlar. Daha az sinyalle izleme kör noktalar bırakır; yüzlerce metrikle izleme ise ekibi alarm yorgunluğuna gömer.
Latency: isteklerin ne kadar sürdüğü. Ortalamaları değil, dağılımları izleyin. p50 (medyan) tipik deneyimi gösterir. p99, kullanıcıların en kötü %1’ini tanımlar. Yalnızca ortalama, uzun kuyrukları gizler: medyanı 50 ms, p99’u 5.000 ms olan bir servis, ortalamada sorunsuz görünür ancak her yüz kullanıcıdan birini mahveder.
Traffic: servise gelen talep. Web servisi için saniyedeki istek sayısı anlamına gelir. Akış servisi için eşzamanlı bağlantı sayısı. Toplu iş için dakikada işlenen öğe sayısı. Traffic, kapasite kararlarıyla ilişkilidir ve iş yükü anomalilerini ortaya çıkarır.
Errors: başarısız isteklerin oranı. Açık hatalar (HTTP 500), örtük hatalar (bozuk veri içeren HTTP 200) ve politika hataları (SLO’yu karşılamayacak kadar yavaş yanıt) hepsi sayılır. Bunları ayırt etmek önemlidir: kötü yük içeren bir 200 yanıtı, çoğu zaman dürüst bir 500’den daha fazla kullanıcıyı etkiler.
Doygunluk: sistemin ne kadar dolu çalıştığı. CPU kullanımı, kuyruk derinliği, bellek baskısı, bağlantı havuzu doluluk oranı. Doygunluk gelecekteki gecikmeyi öngörür: %95 CPU’da çalışan bir sistemde, kullanıcıya yansıyan gecikme artmadan önce çok az boş kapasite kalır.
Çoğu SRE uyarısı bu dört sinyalden türetilir. Belirti temelli uyarı (kullanıcıların fark edeceği durumlarda tetiklenen) neden temelli uyarıdan (CPU %80’i aştığında tetiklenen) daha iyidir. Dört altın sinyal belirtileri tanımlar.
SRE Kariyer Yolları
SRE Becerilerinin Değer Kazandığı Yerler
SRE kariyerleri, mühendisin disiplinin hangi kısmından en çok keyif aldığına göre ayrılır:
Altyapı SRE: diğer ekiplerin üzerinde çalıştığı platformları kurar. Kubernetes, servis mesh’leri, iç bulut. Yoğun sistem mühendisliği, dağıtık sistemler teorisi ve platform tasarımı. Büyük şirketlerde iş ölçeklenebilir olduğu için çok iyi ücret ödenir: tek bir altyapı SRE’si yüzlerce ürün mühendisini destekler.
Gömülü SRE: belirli bir servisin güvenilirliğini artırmak için ürün mühendisliği ekibiyle birlikte çalışır. Yarı mühendis, yarı koç. Güçlü iletişim ve kod inceleme becerileri teknik derinlik kadar önemlidir. Öğretmeyi seven mühendisler için genellikle en iyi yoldur.
Güvenilirlik araçları: gözlemlenebilirlik yığınını kurar: izleme, uyarı, panolar, postmortem araçları, olay yönetim platformları. Yoğun frontend ve veri mühendisliği çalışması. Çıktısı diğer tüm ekipler tarafından kullanılır.
Üretim mühendisliği: Facebook/Meta’nın kapasite, dağıtım ve trafik yönetimi odaklı SRE tanımı. Yoğun ağ ve sistem çalışması.
Değerli teknik sertifikalar: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional ve CNCF sertifikaları (Kubernetes Administrator, Kubernetes Application Developer) bulut-yerel yetkinliği gösterir. Linux Foundation sertifikaları sistem derinliğini işaret eder. Bu sertifikaların hiçbiri portföy çalışmalarının yerini almaz, ancak işe alım elemanlarının ön eleme süreçlerinde yardımcı olur.
Sonuç
Şimdi Öğrendikleriniz
Site reliability engineering, Google'un ölçeklendirme sorununa bulduğu bir çözüm olarak başladı ve artık sektör genelinde uygulanan bir disipline dönüştü. Şunları ele aldınız:
- Manuel operasyonlardan mühendislik temelli güvenilirliğe geçiş
- SLI'lar, SLO'lar, SLA'lar ve SLO'nun tersi olan hata bütçesi kavramı
- Toil tanımı, %50 kuralı ve mühendislik odaklı azaltma
- Sürdürülebilir nöbet rotasyonları ve suçlamasız postmortem uygulaması
- Hizmet izleme için başlangıç noktası olarak dört altın sinyal
- SRE kariyer yolları ve kapıları açan sertifikalar
En önemli iki fikir şunlardır. Güvenilirlik, önceden üzerinde anlaşılmış bir sayıdır. Ve emek, bir kusurdur, iş tanımı değildir. Bu iki fikri ileriye taşırsanız, SRE'nin geri kalanı doğal olarak gelir.
Önerilen okumalar: Google'ın SRE Kitabı (ücretsiz çevrimiçi: sre.google/books/), uygulamalı alıştırmalar için SRE Çalışma Kitabı ve Charity Majors'ın gözlemlenebilirlik üzerine yazıları. geometry-of eşlik eden ders, SRE uygulamasının altındaki görsel yapıya daha derinlemesine iner: gecikme dağılımları, hata bütçesi konileri, bağımlılık grafikleri ve gösterge paneli düzenleri.