Ana içeriğe geç

SRE Interview Prep#

SRE rolünün DevOps'tan ayrılan tarafı: rakam ile düşünme, kasten arıza çıkarma, kapasiteyi değil güvenilirliği mühendislik etme.

🎯 SRE rolünde aranan core skill'ler#

  1. Numerical reasoning — error budget, capacity, scale (back-of-envelope)
  2. Systems thinking — cascade, retry storm, thundering herd
  3. Calm under pressure — incident simulation
  4. Communication — postmortem, runbook
  5. Eng. craftsmanship — toil reduction, automation, observability

1️⃣ SLO Design Round#

Soru tipik: "Sana bir servis verdim — payment-api: ödeme alıyor. Aylık 100M request, 5% peak hours, p99 latency hedef ~500ms. SLO tasarla."

Adım adım nasıl yaklaşırsın:

  1. Müşteri perspektifi: Ödeme alındı mı? Latency ne kadar acı veriyor?
  2. SLI seç:
  3. Availability: HTTP 2xx oranı (5xx server hatası kabul edilmez)
  4. Latency: ödeme oluşturma p99 < 500ms
  5. (Opsiyonel) Correctness: idempotency key respect edilme oranı
  6. SLO koy:
  7. Availability: %99.95 / 30 gün → 21.6 dk down/ay budget
  8. Latency: %99.9 of requests p99 < 500ms / 30 gün
  9. SLA müşteriye: %99.9 (intern SLO buffer'lı)
  10. Multi-burn-rate alert:
  11. Fast: 14.4x burn → 2 saatte budget tükenir → SEV-1 page
  12. Slow: 6x burn → 5 günde tükenir → SEV-2 ticket
  13. Error budget policy: budget < %20 → feature freeze

💡 Ne göstermek istiyorlar: matematik + müşteri perspektifi + automate-able alert.

2️⃣ Incident Response Simulation#

Soru tipik: "Senaryo: 14:02 UTC, p99 latency 200ms → 8s sıçradı. 5xx oranı %3'e çıktı. Sen on-call'sın. İlk 5 dakikada ne yaparsın?"

Söylemen gereken sıra:

  1. Acknowledge PagerDuty alert'i (kimse "kimse görmüyor" sanmasın)
  2. Severity belirle — customer-impacting → SEV-1
  3. Incident channel aç — /incident sev-1 payment-api (otomasyon)
  4. Recent change kontrolü (en sık sebep):
  5. Son deploy ne zaman? kubectl rollout history
  6. Config değişikliği? Feature flag toggle?
  7. Quick rollback hazır — "düzeltmeye çalışmadan önce, geri dön":
  8. kubectl rollout undo deployment/payment-api
  9. Diagnosis (paralel):
  10. Downstream service latency? (DB, external API)
  11. Pod restart? OOM? CPU throttle?
  12. DB connection pool exhaust?
  13. Recent traffic spike?
  14. Communication — status page güncelle, customer comms tetikle
  15. Mitigate, sonra root cause

🔑 "Mitigate first, investigate later" prensibi. 14 dakika down olmaktansa, 4 dakika rollback + 2 saat sonra incognito root-cause araştır.

3️⃣ Capacity Planning#

Soru tipik: "Şu an servis 10K RPS. Önümüzdeki Black Friday 50K RPS bekleniyor. Hazırlığını nasıl yaparsın?"

Aşamalar:

  1. Baseline ölç (current):
  2. Şu an pod sayısı, CPU/RAM kullanımı, p99 latency
  3. DB connection sayısı, query latency

  4. Downstream API limit'leri

  5. Linear scale assumption (genelde yanlış):

  6. 5x trafik = 5x pod? Hayır. DB, cache, downstream pinch point'ler var

  7. Bottleneck tespiti — önce DB:

  8. Read: replica scale-up + read-heavy query'leri replica'ya yönlendir
  9. Write: connection pool, prepared statement cache, write batching

  10. Eğer master CPU bound → vertical scale veya sharding

  11. Cache layer:

  12. Redis hit ratio? Capacity?

  13. CDN cacheable response için kullan

  14. Load test:

  15. k6 / Gatling / Locust ile 60K RPS sustained
  16. p99 latency degrade noktası?

  17. HPA hızı yetiyor mu? (60s scale-up window?)

  18. Pre-scale (önemli!):

  19. HPA reactive → ilk dalga acı. Manuel replicas: 100 event öncesi

  20. Database connection pool pre-warm

  21. Headroom:

  22. Hedef peak'ten %30 fazla kapasite

  23. Cost: maliyet artar — finance ile koordine

  24. Monitoring tighter:

  25. Burn-rate alert eşikleri sıkılaştır

  26. On-call ekibi 2 katı (war room)

  27. Rollback plan:

  28. Eski sürüme geri dönüş (kapasite-eski sürüm uyumlu mu?)
  29. Feature flag ile yeni-feature kapatma

4️⃣ Toil Reduction#

Soru tipik: "Ekibinin toil'ünü %50'nin altına indirmen gerekti. Nasıl yaklaşırsın?"

Adımlar:

  1. Ölç: 1 hafta time-track (her saat ne yapıldı, kaç saat manuel?)
  2. Top 5 toil'i listele (en sık + en uzun)
  3. Her biri için ROI hesapla:
  4. Kaç saat tasarruf? (haftada × 52)
  5. Otomatize etmek kaç saat alır?
  6. Payback period < 3 ay olanlar öncelik
  7. Quick wins:
  8. Slack komutuyla self-service ("/restart-pod payment-api")
  9. Otomatik ticket triage (etiket, severity)
  10. Runbook'ları script'leştir
  11. Yapısal:
  12. Sık kırılan servis için reliability iyileştirmesi (root cause fix)
  13. On-call rotation healthier (alert fatigue audit)
  14. Sonuç ölç: ay sonra time-track tekrarla, çıkan grafik

Toil sıfır olmaz; kontrol altında olur. Yeni feature'lar, yeni toil yaratır. Sürekli rebalance.

5️⃣ Chaos Engineering#

Soru tipik: "İlk chaos experiment'ini nasıl tasarlarsın?"

Süreç:

  1. Steady state tanımla — normal nasıl görünüyor?
  2. p99 latency, error rate, throughput
  3. SLO'lar in-budget
  4. Hipotez kur: "Bir Postgres replica düşerse, cluster ayakta kalır."
  5. Blast radius minimize:
  6. Önce dev/staging'de
  7. Sonra prod, ama sadece %1 traffic
  8. Off-hours
  9. Tooling:
  10. Chaos Mesh / LitmusChaos / AWS FIS
  11. Bir replica pod'u 5dk için sil
  12. Observe:
  13. SLO etki yedi mi?
  14. Failover nasıl gerçekleşti?
  15. Recovery time?
  16. Result:
  17. Hipotez doğrulandı mı?
  18. Bulgular → action item'lar
  19. Iterate: her ay yeni bir scenario, sonunda continuous chaos

"Niye prod'da chaos?"#

Stage'de bulunan hatalar prod'da hep tekrar bulunur. Ama sadece prod'da bulunan hatalar prod'da olur. Karşı taraf bunu duymak istemez, ama gerçek bu.

6️⃣ Pratik problemler#

Problem A — Cascading failure#

Servis A → Servis B → Servis C
(bütün B → C çağrıları yavaşladı, A timeout retry yapıyor, B daha çok yük yiyor)

Çözümler: - Circuit breaker (Hystrix, Polly, resilience4j) - Bulkhead — connection pool'ları izole et - Backoff with jitter — retry storm'unu engelle - Load shedding — A %50 trafiği reject etsin, healthier kalsın - Adaptive concurrency limit — Netflix's concurrency-limits

Problem B — Thundering herd#

Cache miss → 1000 pod aynı DB query'sini paralel atıyor.

Çözümler: - request coalescing — aynı key'i bekleyenler tek query - probabilistic early refresh — TTL bitmeden bazı pod'lar yenilesin - stale-while-revalidate — eski değer döndür, arka planda yenile

Problem C — Hot spot#

Tek bir partition/shard tüm trafiği yiyor.

Çözümler: - Re-sharding (key prefix randomize) - Read replica per partition - Cache layer hot key'ler için - Rate limit per-key

🎓 Çalışma planı (4 hafta)#

Hafta Konu
1 SRE Book bölüm 1-5 (philosophy, SLO, incident)
2 SRE Workbook (pratik examples)
3 Production-like lab + chaos experiment
4 Mock interview (peer ya da Pramp/Interviewing.io)

📚 Hazırlık kaynakları#

  • Site Reliability Engineering — Google (ücretsiz online)
  • The SRE Workbook — Google
  • Building Secure & Reliable Systems — Google
  • Database Reliability Engineering — Campbell & Majors
  • SREcon talks YouTube
  • Mock interview: Pramp, Interviewing.io