KURUMSAL EĞİTİM, GOOGLE SRE MÜHENDİSLİĞİ

GOOGLE SRE: SITE RELIABILITY ENGINEERING EĞİTİMİ

2003 yılında Google mühendisi Ben Treynor Sloss, bir yazılım ekibine "bu sistemi çalıştır" görevi verdiğinde ortaya çıkan şeyi tanımladı: Site Reliability Engineering. O günden bu yana SRE; Gmail, Google Search ve YouTube'u milyarlarca kullanıcıya %99.99+ erişilebilirlik ile sunan mühendislik disiplini olarak gelişti ve tüm sektörün operasyonel mükemmellik standardına dönüştü. Artık Amazon, Netflix, Spotify, Uber ve dünyanın önde gelen yazılım şirketleri bu prensipler üzerinde sistemlerini inşa ediyor.

SRE'nin temel tezi şudur: Operasyonel problemleri, geleneksel sistem yöneticisi yaklaşımıyla değil; yazılım mühendisliği disipliniyle çözmek. Bu, toil (değer üretmeyen manuel tekrar) yerine otomasyon, postmortem kültürü yerine blameless öğrenme, reaktif müdahale yerine proaktif güvenilirlik mühendisliği demektir. SLI/SLO/Error Budget üçlüsü ise hız ile güvenilirlik arasındaki ölçülebilir dengeyi matematiksel olarak kurar.

Bu eğitim; SRE felsefesinin teorik temellerinden başlayarak dört Altın Sinyal (Latency, Traffic, Errors, Saturation) ile sistem izleme, Prometheus/Grafana ve OpenTelemetry ile gözlemlenebilirlik stack'i, SLO tanımlama ve Error Budget politikası, Chaos Engineering ile dayanıklılık testi, blameless postmortem ve incident management, Toil envanteri ve otomasyon stratejisi, kapasite planlama ve IaC ile değişmez altyapı, DevSecOps entegrasyonu ve kurumsal SRE dönüşüm yol haritasına kadar Google SRE metodolojisinin tüm boyutlarını uygulamalı ele alır.

Her modül Google'ın gerçek sistemlerinden alınmış vaka analizleriyle zenginleştirilir. Gmail 2006 outage, Google Search veri merkezi güç kesintisi ve Kubernetes rebalancing senaryoları birer mühendislik dersi olarak incelenir. Katılımcılar eğitim sonunda yalnızca SRE bilgisini değil; güvenilirlik odaklı düşünme biçimini, ölçüm kültürünü ve organizasyonel SRE dönüşümünü kendi kurumlarında uygulayabilecek yetkinliği kazanır.

EĞİTİM HEDEFİ

Bu eğitimin temel amacı; katılımcılara Google'ın Site Reliability Engineering metodolojisini hem teknik hem organizasyonel boyutuyla kavratmak ve kendi sistemlerine uygulayabilecekleri pratik yetkinlikleri kazandırmaktır. Eğitim sonunda katılımcılar; SRE felsefesini ve CALMS çerçevesini açıklar, DevOps ile SRE arasındaki tamamlayıcılığı tanımlar ve kurumsal SRE olgunluk modelindeki konumlarını değerlendirir. Bunlara ek olarak SLI, SLO ve SLA kavramlarını doğru biçimde tanımlar, gerçek bir servis için SLI metrikleri seçer ve SLO hedefini belirler, Error Budget hesabını yapar, burn rate'i izler ve budget policy kararı alır, Dört Altın Sinyal çerçevesini (Latency, Traffic, Errors, Saturation) kullanarak sistem sağlığı değerlendirir ve alert kuralı tasarlar, Prometheus ile custom metric toplar, PromQL ile anlamlı sorgu yazar ve Grafana SLO dashboard oluşturur, OpenTelemetry ile distributed tracing enstrümantasyonu yapar ve log-metrik-trace üçlüsünü korelasyonlu kullanır, Toil envanteri çıkarır, toil/engineering work oranını ölçer ve otomasyon öncelik sırası belirler, Blameless postmortem yazısı hazırlar, timeline oluşturur ve aktif aksiyon listesi üretir, Incident severity seviyelerini tanımlar, incident commander rolünü üstlenir ve on-call playbook hazırlar, Chaos Engineering hipotezi kurar, patlama yarıçapı kontrollü deney tasarlar ve sistemin yanıt sınırlarını ölçer, Canary deployment, Blue/Green ve feature flag stratejilerini güvenilirlik açısından karşılaştırır ve uygular, Terraform ile idempotent altyapı tanımlar ve değişmez altyapı (immutable infrastructure) prensibini kavrar, DORA metriklerini (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) ölçer ve iyileştirme yol haritası üretir, kurumlarında SRE ekibi kurma veya mevcut ekibi dönüştürme için olgunluk modelini uygular ve yol haritası oluşturabilir hale gelir.

EĞİTİM İÇERİĞİ

1. SRE FELSEFESİ, TARİHSEL KÖKLERİ VE GOOGLE'IN YAKLAŞIMI

• SRE'nin Doğuşu ve Temel Tezi: Ben Treynor Sloss ve 2003 Google'da SRE'nin ilk ortaya çıkışı; "Bir yazılım mühendisine operasyon görevi verildiğinde ortaya çıkan şey" tanımı; geleneksel sistem yöneticisi (sysadmin) ile SRE mühendisi arasındaki farklar: beceri seti, incentive yapısı ve otomasyon odağı; DevOps ve SRE'nin tamamlayıcı ama farklı çerçeveler olduğu; SRE kitabının (Google's SRE Book) temel tezleri ve ikinci kitap (The Site Reliability Workbook) ile uygulamaya geçiş; Platform Engineering ile SRE'nin kesişim alanı.
• SRE'nin Yedi Temel Prensibi: Hata hedefleme (risk tolerating): %100 güvenilirlik doğru hedef değil; servis seviyesi hedefleri ile kullanıcı mutluluğunun ilişkisi; toil azaltma: SRE ekibinin engineering çalışmasına odaklanması; izleme sistemleri: semptom, neden ve etkiyi ayırt etme; acil müdahale (emergency response): insan zamanını optimize eden süreçler; değişim yönetimi: dağıtımların %70 olayın kaynağı olması ve otomasyon ile yönetimi; kapasite planlama: organik büyüme ve inorganik büyüme tahmini; verimlilik ve performans: kaynak kullanımı ile gecikme dengesi.
• SRE Kültürü ve Organizasyonel Yapı: SRE ekip modelleri: embedded SRE, centralised SRE, consulting SRE; SRE ekibinin geliştirme ekibiyle operasyonel sözleşmesi; %50 engineering / %50 toil+on-call dengesi ve nasıl ölçüleceği; pager fatigue ve on-call sürdürülebilirliği; SRE mühendisi için T-shaped beceriler: derin sistem bilgisi + yazılım geliştirme; kurumsal SRE dönüşüm yol haritası: adım adım sysadmin'den SRE'ye.
• DORA Metrikleri ve SRE Olgunluk Modeli: Dört DORA metriği: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service (MTTR); Elite, High, Medium, Low performans kümeleri ve benchmark değerleri; kurumun mevcut DORA skorunu ölçme yöntemi; SRE olgunluk seviyeleri: Reactive → Proactive → Optimizing; olgunluk seviyesine göre öncelikli iyileştirme alanları; SRE ROI hesabı: mühendis saati, kesinti maliyeti ve otomasyon yatırımı.

2. SLI, SLO, SLA VE HATA BÜTÇESİ YÖNETİMİ

• SLI — Service Level Indicator Tasarımı: SLI'nın tanımı: kullanıcının deneyimlediğini ölçen sayısal gösterge; iyi SLI özellikleri: ölçülebilir, anlamlı, kontrol edilebilir; yaygın SLI türleri: availability (başarılı istek / toplam istek), latency (p50/p99/p999 yüzdelik dilim), throughput, error rate, freshness (veri tazeliği); request-based SLI vs window-based SLI; SLI kayıt yerleri: istemci tarafı vs sunucu tarafı ölçüm; kötü SLI tuzakları: CPU kullanımı SLI değildir çünkü kullanıcı deneyimini doğrudan ölçmez.
• SLO — Service Level Objective Belirleme: SLO hedefi: "Son 30 günde isteklerin %99.9'u 200ms altında yanıtlanmalı"; SLO belirleme workshopu: iş, ürün ve SRE ekibinin birlikte katıldığı SLO müzakeresi; mükemmellik tuzağı: neden %100 SLO yanlış; SLO'yu kullanıcı mutluluğuyla hizalama: "Kullanıcı ne zaman mutsuz olur?"; rolling window vs calendar window SLO; SLO güven aralığı: koşulsuz ve koşullu SLO farkı; SLO kırılma senaryolarının takımla önceden mutabık kalınması; paydaş iletişiminde SLO dili ve beklenti yönetimi.
• SLA — Service Level Agreement ve Hukuki Boyut: SLA, SLO ve SLI hiyerarşisi: SLA genellikle SLO'dan daha gevşek; SLA ihlalinin finansal ve yasal sonuçları; SLA tasarım prensibi: SLO'yu "buffer" ile SLA'ya dönüştürme; müşteri SLA sözleşmesinde uptime hesabı: aylık dakika ve izin verilen kesinti; GCP ve AWS SLA standartlarının analizi; SLA izleme ve ihlal bildirimi süreci.
• Error Budget — Hata Bütçesi Politikası: Error Budget hesabı: 1 − SLO target = izin verilen hata oranı; aylık dakika cinsinden Error Budget: %99.9 → 43.8 dk/ay, %99.99 → 4.38 dk/ay; burn rate: bütçenin hızlı tükenmesini izleme; multi-window burn rate alert: 5% hızla 1 saatte + %2 hızla 6 saatte eş zamanlı uyarı; Error Budget Policy: budget tükenince feature freeze ve güvenilirlik sprint; budget fazlası: risk alma, kaos deneyi yapma, teknik borç ödeme; Error Budget görünürlüğü: geliştirme ve SRE ekibinin aynı dashboard'u izlemesi.

3. DÖRT ALTIN SİNYAL VE GÖZLEMLENEBİLİRLİK (OBSERVABILITY)

• Dört Altın Sinyal Çerçevesi: Latency: başarılı ve başarısız isteklerin ayrı ölçülmesi, p99 latency neden p50'den kritik; Traffic: HTTP istek sayısı/sn, mesaj kuyruğu tüketim hızı, kullanıcı oturumu; Errors: açık hata (HTTP 5xx) ve gizli hata (yanlış içerik dönen HTTP 200) ayrımı; Saturation: CPU, bellek, disk, ağ doygunluğu ve "kuyruğun büyüme hızı" metrikleri; USE (Utilization, Saturation, Errors) ve RED (Rate, Errors, Duration) yöntemlerinin karşılaştırması; hangi sinyal hangi hizmet türü için önceliklidir.
• Prometheus ile Metrik Toplama: Prometheus veri modeli: metric name, label ve time series; scrape konfigürasyonu: job ve target tanımı; dört metrik tipi: Counter (monotonik artış), Gauge (anlık değer), Histogram (dağılım), Summary (yüzdelik dilim); client kütüphanesi ile custom metrik: Python prometheus_client, Go promtheus/client_golang; PromQL: rate(), irate(), histogram_quantile(0.99), topk(), sum by(); Recording Rule ile sık kullanılan sorguların önceden hesaplanması; Alertmanager ile routing, grouping ve silence.
• Grafana ile Dashboard ve Görselleştirme: Grafana datasource: Prometheus, Loki, Tempo entegrasyonu; RED dashboard: Request Rate, Error Rate, Duration panelleri; SLO panel: good_events/total_events oranı ve hedef çizgisi; alert panel ve alert state görselleştirme; heatmap ile latency dağılımı; Grafana provisioning ile GitOps versiyonlama; shared panel template ile çok-servis dashboard; Grafana OnCall ile alert routing ve on-call schedule yönetimi.
• OpenTelemetry ile Uçtan Uca Observability: Gözlemlenebilirliğin üç sütunu: metrik + log + trace korelasyonu; OpenTelemetry (OTel) SDK: trace enstrümantasyonu ve span oluşturma; trace context propagation: W3C TraceContext ve B3; OTel Collector pipeline: receiver → processor → exporter; sampling: head-based vs tail-based; Jaeger/Tempo ile trace backend; Loki ile yapılandırılmış log ve trace-to-log korelasyonu; cardinality sorunu ve yüksek kardinaliteli etiketlerden kaçınma.

4. TOİL YÖNETİMİ, OTOMASYON VE INFRASTRUCTURE AS CODE

• Toil'i Tanımlama ve Ölçme: Toil kriterleri: manuel, tekrarlayan, otomasyon potansiyeli olan, büyümeyle artan, geçici değer; toil vs overhead vs engineering work ayrımı; toil envanteri: haftalık on-call günlüğü ile toil aktivitelerini kaydetme; toil ısı haritası: ekip bazlı en yüksek toil alanları; %50 toil eşiği: SRE güvenilirlik sözleşmesi; toil'in ekip morali, burn-out ve inovasyon üzerindeki olumsuz etkileri; yöneticiye toil verisi sunma: maliyet-fayda analizi ile otomasyon öncelik kararı.
• Otomasyon Stratejisi ve Araçları: Otomasyon olgunluk basamakları: manuel → belgelenmiş → yarı-otomasyon → tam otomasyon → öz-onarım (self-healing); Python ile sistem otomasyon scriptleri: subprocess, paramiko, requests; Ansible ile konfigürasyon yönetimi: playbook, role ve inventory; idempotensi: aynı playbook'u defalarca çalıştırmanın sistemi aynı duruma getirmesi; runbook'u script'e dönüştürme örneği; otomasyon testi: dry-run ve canary execution; otomasyon güvenilirliği: scriptin kendisi güvenilir değilse otomasyon tehlikeli olur.
• Infrastructure as Code ile Değişmez Altyapı: IaC prensipleri: idempotence, declarative, version controlled, automated; Terraform yapısı: provider, resource, data, variable, output, module; terraform plan ile güvenli değişiklik önizlemesi; state yönetimi: remote backend, state lock, import; değişmez altyapı (immutable infrastructure): sunucu güncellemek yerine yeni sunucu oluştur ve eski'yi yok et; Phoenix Server vs Snowflake Server anti-pattern; Packer ile makine imajı oluşturma; Golden Image stratejisi ve image versiyonlama; GitOps ile IaC: her değişiklik PR üzerinden, terraform plan CI'da.
• Konfigürasyon Yönetimi ve Drift Detection: Konfigürasyon drifti: gerçek durum ile tanımlanan durumun ayrışması; terraform plan ile drift tespiti; AWS Config, GCP Config Connector ile sürekli uyumluluk kontrolü; Ansible ile idempotent konfigürasyon uygulama; secret yönetimi: HashiCorp Vault veya cloud-native secret servisi; konfigürasyon şifreleme: ansible-vault; konfigürasyon değişikliklerinin audit log ile izlenmesi.

5. İNCİDENT MANAGEMENT, BLAMELESS POSTMORTEM VE ON-CALL KÜLTÜRÜ

• Incident Lifecycle ve Severity Seviyeleri: Incident tanımlama: kullanıcı etkili her olay; severity matrisi: SEV1 (tam hizmet kesintisi), SEV2 (kritik özellik etkilendi), SEV3 (kısmi etki), SEV4 (küçük etki); incident detection kaynakları: alert, müşteri bildirimi, iç gözlem; alert'ten incident'e: triage süreci ve tanıma kararı; status page yönetimi: anlık durum güncellemesi ve müşteri iletişimi; MTTR bileşenleri: tespit süresi (MTTD) + tanılama (MTTK) + kurtarma (MTTR).
• Incident Command System (ICS): Incident Commander (IC) rolü: koordinasyon, iletişim ve karar kanalını kontrol etme; Communications Lead: status page, internal Slack ve müşteri iletişimi; Operations Lead: teknik müdahale koordinasyonu; Subject Matter Expert (SME): alan uzmanı katılımı; savaş odası (war room) vs asenkron yönetim; incident sırasında bilişsel yük azaltma: checklist ve communication template; "fix first, understand later" prensibi; escalation matrix ve yanlış escalation maliyeti.
• Blameless Postmortem Kültürü: Blamelessness neden önemli: suçlama kültürü hatayı gizler, öğrenmeyi engeller; postmortem şablonu: özet, durum zaman çizelgesi, tespit ve müdahale zaman çizelgesi, kök neden analizi, baş tetikleyici, katkıda bulunan faktörler, aksiyon maddeleri, öğrendiklerimiz; 5-Neden (5 Whys) tekniği ile kök neden derinlemesine inceleme; sistem odaklı analiz: hatayı yapan kişi değil, sistemi anlama; postmortem paylaşımı: şirket içi yayın ve kültür inşası; Google'ın public postmortemlerinin analizi.
• On-Call Sürdürülebilirliği ve Runbook: On-call sürdürülebilirlik prensipleri: haftalık 2'den az uyku bozan alert hedefi; alert kalitesi: her alert actionable olmalı; pager fatigue tanımı ve önleme stratejileri; on-call rotasyon: yeterli dinlenme süresi ve fair dağılım; shadow on-call ile yeni üyelerin yetiştirilmesi; runbook tasarımı: adım adım, test edilmiş, minimum ambiguity; playbook otomasyonu: PagerDuty veya Opsgenie ile runbook linki ve otomasyon aksiyonu; post-incident on-call review: alert kalitesini düzenli gözden geçirme.

6. CHAOS ENGINEERING VE SİSTEM DAYANIKLILIĞI

• Chaos Engineering Prensipleri: Netflix Chaos Monkey'in tarihsel rolü ve Simian Army; Chaos Engineering manifestosu: hipotez → ölçüm → deney → öğrenme döngüsü; "patlama yarıçapı" (blast radius) kontrolü: en küçük deney ile en fazla öğrenme; üretim vs üretim benzeri ortamda chaos; steady state hipotezi: normal sistem davranışının baseline'ını belirleme; chaos deneyi tipleri: kaynak tükenmesi, ağ bölünmesi, süreç öldürme, gecikme enjeksiyonu, veri tutarsızlığı; GameDay etkinliği planlama ve yürütme.
• Chaos Araçları ve Teknikler: Chaos Mesh ile Kubernetes üzerinde pod kill, network delay, CPU stress, disk fill hata enjeksiyonu; AWS Fault Injection Simulator (FIS) ile managed chaos; Gremlin ile attack kategorileri: State, Network, Resource; Istio fault injection: HTTP abort ve delay via VirtualService; tc (traffic control) ile Linux ağ gecikme simülasyonu; toxiproxy ile bağımlılık hata simülasyonu; Litmus Chaos ile Kubernetes operator tabanlı chaos; chaos deney sonuçlarını monitoring ile korelasyonlu izleme.
• Resilience Desenleri ve Devre Kesiciler: Resilience 4J ile Circuit Breaker: CLOSED→OPEN→HALF_OPEN state machine; fallback: devre açıkken alternatif yanıt; bulkhead: havuz izolasyonu ile cascade failure önleme; retry: exponential backoff + jitter ile retry storm önleme; timeout: servis zincirine end-to-end deadline yayma; rate limiting: token bucket ve sliding window algoritmaları; graceful degradation: kritik olmayan özelliği geçici olarak devre dışı bırakma; load shedding: aşırı yükte seçici istek reddi.
• Disaster Recovery ve İş Sürekliliği: RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) tanımı ve DR planına etkisi; DR tipleri: backup/restore, warm standby, hot standby, aktif-aktif; yük devretme (failover) testi: planlı ve plansız; data replication lagı ve RPO hesabı; chaos deneyi olarak DR tatbikatı; DR runbook ve automation; backup doğrulama: backup'ın çalıştığını kanıtla — "test edilmemiş backup, backup değildir".

7. KAPASİTE PLANLAMA, PERFORMANS VE MALİYET OPTİMİZASYONU

• Kapasite Planlama Metodolojisi: Organik büyüme: mevcut talep büyüme trendinden gelecek kapasiteyi tahmin etme; inorganik büyüme: kampanya, ürün lansmanı veya iş ortaklığının trafik etkisi; kapasite "N+2" prensibi: bir zone/bölge başarısız olsa ve bir bakım penceresi varsa yeterli kapasite; headroom: anlık kapasite - peak trafik / anlık kapasite oranı; load test ile gerçek kapasite sınırlarını ölçme; Kubernetes HPA ve KEDA ile otomatik kapasite yönetimi; kapasite planında öngörmede başarısız olmanın maliyeti: under-provision vs over-provision.
• Performans Analizi ve Profilleme: Dört performans analizi boyutu: CPU, memory, I/O, network; Linux perf, flamegraph ve ebpf ile sistem seviyesi profilleme; uygulama profilleme: Python cProfile, Go pprof, Java async-profiler; veritabanı sorgu analizi: EXPLAIN ANALYZE ve slow query log; N+1 sorgu anti-pattern ve ORM'de önleme; cache hit ratio izleme ve cache invalidation stratejisi; CDN ve edge cache ile origin yük azaltma; connection pool boyutlandırma: Little's Law ile teorik hesap.
• FinOps ve SRE Maliyet Kültürü: Maliyet görünürlüğü: ekip/servis bazlı bulut maliyeti etiketleme; unit economics: bir API isteğinin maliyeti vs geliri; rightsizing: CPU/memory kullanım azlığı tespiti ve makine tipi düşürme; Spot/Preemptible VM ile batch ve CI/CD maliyeti azaltma; otomatik kapatma: kullanılmayan geliştirme ortamları; Idle resource temizleme otomasyonu; maliyet anomali tespiti ve alert; SRE ve FinOps entegrasyonu: performance + reliability + cost üçgeninde denge.

8. DEVSECOPS, GÜVENİLİR CI/CD VE KURUMSAL SRE DÖNÜŞÜMÜ

• Güvenilirlik Odaklı CI/CD Pipeline Tasarımı: "Bütün olayların %70'i değişiklikten kaynaklanır" ve değişim yönetiminin önemi; pipeline güvenilirlik kapıları (reliability gates): test coverage, latency regression, error rate spike; canary deployment: %5 → %20 → %100 kademeli trafik kaydırma ve metrik izleme; Blue/Green deployment: anlık trafik yönlendirme değişimi ve rollback kolaylığı; feature flag: özelliği kod olmadan an'da disable etme; otomatik rollback: SLO ihlali algılandığında önceki versiyona dönme; deployment frekansı artırırken değişiklik başarısızlık oranını düşürme — elite DORA profili.
• DevSecOps ve SRE Güvenlik Entegrasyonu: TDSecOps: güvenliği SDLC'nin en başına taşıma; SAST ile statik kod analizi: güvenlik açığını commit aşamasında yakalama; DAST ile çalışan uygulama testi: OWASP ZAP ile API güvenlik taraması; SCA: bağımlılık kütüphanelerindeki CVE tarama; container image scanning: Trivy ile Dockerfile'dan imaja kadar; OWASP Top 10'u SRE perspektifinden okuma: erişilebilirlik ve güvenliğin kesişimi; security SLO: güvenlik açığı kapama süresi hedefi; SRE ve güvenlik ekibinin ortak on-call senaryosu.
• Kurumsal SRE Dönüşümü ve Yol Haritası: SRE dönüşümünün başarısız olduğu on senaryo ve nasıl önlendiği; SRE sponsorluk: C-level desteği neden zorunlu; "SRE ekibi" kurmadan önce SRE kültürü: önce değerler; mevcut operasyon ekibini SRE'ye dönüştürme: beceri geliştirme yol haritası; SRE'nin değerini ölçme: kesinti azalması, MTTR düşüşü, toil oranı; SRE olgunluk modeli: Reactive → Proactive → Predictive; SRE'yi ölçeklendirme: 1 SRE'den 100 SRE'ye organizasyon yapıları; embedding SRE vs platform SRE seçim kriterleri.
• Kapsamlı Final Projesi — SRE Diagnostic ve Roadmap: Katılımcılar gerçek (anonim) veya hayali bir sistemin SRE diagnostic çalışmasını yapar: mevcut SLI seçimi ve SLO önerisi, Error Budget hesabı, toil envanteri, monitoring gap analizi, incident management süreç değerlendirmesi, chaos experiment tasarımı, DORA metrik baseline belirleme ve 3 aylık SRE iyileştirme yol haritası. Gruplar hazırladıkları mimari değerlendirme ve yol haritasını sunarak eğitimi tamamlar.

EĞİTİM YÖNTEMİ

• Google Postmortem ve Vaka Analizi: Her modül başında Google, Netflix, AWS veya Cloudflare'in gerçek olayları analiz edilir. "Bu outage'da hata bütçesi nasıl tükendi?", "Incident Commander ne yapabilirdi?", "Hangi toil bu hataya zemin hazırladı?" soruları grup tartışması ile derinlemesine incelenir — soyut konseptler gerçek olayların prizmasından kavranır.
• Uygulamalı Laboratuvarlar: Prometheus ve Grafana kurulumu ve SLO dashboard oluşturma; PromQL ile burn rate alert yazma; Chaos Mesh ile Kubernetes pod kill ve latency injection deneyi; Terraform ile idempotent altyapı oluşturma ve drift tespiti; blameless postmortem şablonu doldurma ve peer review; incident simülasyonu: eğitmen tarafından yönetilen gerçekçi alarm senaryosu.
• SRE Düşünce Egzersizleri: "Bu sistemin SLI'si ne olmalı?" SLI seçim egzersizi; "Error Budget'ımız tükenirse ne yaparız?" karar senaryosu; "Bu alerting rule actionable mı?" alert kalite değerlendirmesi; "Bu toil mı yoksa engineering work mi?" sınıflandırma egzersizi — SRE bakış açısı zihinsel bir kas olarak geliştirilir.
• Incident Simülasyonu (GameDay): İleri modüllerde eğitmen kontrolünde gerçekçi bir "sistem krizi" senaryosu oynanır: monitoring dashboard'larında anormallik, incident commander rolü üstlenme, blameless postmortem yazımı. Katılımcılar hem teknik hem iletişim boyutunu gerçek baskı altında deneyimler.
• Akran Öğrenimi ve Geribildirim: SRE diagnostic projesi gruplar halinde hazırlanır; her grubun SLO önerisi ve toil envanteri diğer gruplar tarafından SRE perspektifinden değerlendirilir; yapıcı geri bildirim kültürü eğitim boyunca post-mortem blamelessness ile paralel işlenir.
• Danışmanlık ve Açık Soru-Cevap: Her gün sonunda açık danışmanlık zamanı; katılımcılar kendi sistemleri için SLO tasarımı, toil azaltma stratejisi, monitoring gap analizi ve SRE dönüşüm planlaması konularında uzmana yöneltir, kişisel geri bildirim alır.

HEDEF KİTLE

SRE VE OPERASYON MÜHENDİSLERİ

• Mevcut sistem yönetimi veya operasyon rolünü SRE metodolojisiyle güçlendirmek isteyen mühendisler; SLI/SLO/Error Budget konseptlerini kurum içinde uygulamak, monitoring stack'ini SRE odaklı yeniden yapılandırmak ve blameless postmortem kültürünü yerleştirmek isteyen operasyon ekipleri; on-call sürdürülebilirliği, toil azaltma ve incident management süreçlerini sistematize etmek isteyen site reliability mühendisleri.

DEVOPS VE PLATFORM MÜHENDİSLERİ

• CI/CD pipeline'ına güvenilirlik kapıları (SLO-based deployment gate) ve otomatik rollback eklemek isteyen DevOps mühendisleri; Terraform ile IaC, Ansible ile konfigürasyon yönetimi ve GitOps pratiklerini SRE perspektifinden derinleştirmek isteyen platform mühendisleri; Chaos Engineering ile sistemin dayanıklılık sınırlarını proaktif olarak keşfetmek isteyen altyapı mühendisleri.

YAZILIM GELİŞTİRİCİLER VE BACKEND MÜHENDİSLERİ

• Yazdıkları kodun production'da nasıl davrandığını SRE metrikleriyle ölçmek isteyen geliştiriciler; servislerine SLI/SLO tanımlamak, OpenTelemetry ile tracing eklemek ve Prometheus custom metrik yazmak isteyen backend mühendisleri; "You build it, you run it" kültürünü benimseyen ve operasyonel sorumluluğu geliştirme ekibiyle paylaşmak isteyen yazılım ekipleri.

YAZILIM MİMARLARI VE TEKNİK LİDERLER

• Mikroservis mimarisinde güvenilirlik, dayanıklılık (circuit breaker, bulkhead, retry) ve observability tasarımını sistematize etmek isteyen yazılım mimarları; DORA metriklerini ölçerek ekibinin delivery performansını iyileştirmek isteyen teknik liderler; kurumda SRE ekibi kuracak veya mevcut operasyon ekibini SRE metodolojisine dönüştürecek mühendislik yöneticileri.

ÜRÜN YÖNETİCİLERİ VE IT YÖNETİCİLERİ

• SLO ve Error Budget kavramlarını anlayarak güvenilirlik-hız dengesini iş kararlarına yansıtmak isteyen ürün yöneticileri; sistem kesintilerinin kurumsal maliyet ve müşteri memnuniyetine etkisini ölçmek ve SRE yatırımının ROI'sini değerlendirmek isteyen IT direktörleri ve CTO'lar; digital transformation sürecinde güvenilirlik kültürünü organizasyona yaymak isteyen liderler.

KATILIMCILARDAN BEKLENTİLERİMİZ

• Sistem ve Ağ Temelleri: Linux komut satırı: process yönetimi (ps, top, kill), log okuma (journalctl, tail -f), ağ tanılama (curl, netstat, ss, tcpdump); TCP/IP, DNS, HTTP/HTTPS protokollerine aşinalık; sistem kaynakları: CPU, memory, disk, network kavramları ve izleme araçları (htop, iostat, vmstat). Bu bilgiler SRE observability ve kapasite planlama konularını anlamayı doğrudan destekler.
• Temel Yazılım Geliştirme veya Operasyon Deneyimi: Herhangi bir programlama dilinde (Python, Java, Go, C# vb.) en az 1 yıllık deneyim veya sistem yönetimi/operasyon rolünde 1+ yıl çalışmış olmak; bir uygulamanın nasıl dağıtıldığını ve çalıştığını genel olarak anlamak; git ile versiyon kontrolü (commit, push, PR) ve basit bash betik yazabilmek. SRE hem mühendislik hem operasyon perspektifini birleştirir; her iki geçmişten katılımcılar da eşit değer alır.
• Temel Cloud veya Container Bilgisi: Herhangi bir bulut platformunda (AWS, GCP, Azure) sanal makine oluşturabilmek; Docker kavramını bilmek: container, image, Dockerfile; Kubernetes'e aşinalık faydalıdır ancak zorunlu değildir — Kubernetes bağlamı eğitimde açıklanır. Monitoring araçlarına sıfırdan başlanacağı için Prometheus/Grafana bilgisi gerekli değildir.
• Aktif Katılım ve Sistem Sorumluluğu: En değerli katılımcılar; kendi sistemlerinde yaşadıkları gerçek olayları, toil sorunlarını ve monitoring açıklarını eğitimde paylaşmaya istekli olanlardır. SRE öğrenimi teorik değil deneyimseldir: grup tartışmalarına aktif katılım, incident simülasyonunda rol üstlenme ve final projesine ekip çalışmasıyla katkı eğitimden alınan değeri katlar.
• Değişime ve Kültürel Dönüşüme Açıklık: SRE yalnızca araç öğrenmek değil; "suçlama kültürü"nden "blameless öğrenme kültürü"ne, "reactive müdahale"den "proaktif güvenilirlik mühendisliği"ne zihinsel bir geçiştir. Kurumunda bu kültürü yerleştirmeye istekli, değişim ajanlığını üstlenmeye hazır katılımcılar eğitimden en yüksek kurumsal değeri üretir.