Üretimde en pahalı arıza tipi “tam çöküş” değildir; kontrolsüz çöküştür. Trafik artar, bağımlılık yavaşlar, thread pool dolar, queue şişer… ve sistem bir anda her şeyi aynı anda kaybetmeye başlar. Bu yazıda, bu senaryoyu tasarım seviyesinde “kontrollü kayıp”a çevirmeyi anlatıyorum: SLO tabanlı degrade modları ve load shedding.
Degrade modu ne demek?
Degrade modu; sistemin baskı altındayken “her şeyi aynı kaliteyle verme” iddiasından vazgeçip, önceden tanımlı bir şekilde bazı özellikleri kısmayı kabul etmesidir.
Örnek degrade hedefleri:
- p95 gecikmeyi koru, “recommendation” gibi pahalı bileşeni kapat
- ödeme akışını koru, raporlama/arama sonuçlarını geciktir
- admin/arka ofis endpoint’lerini kıs, müşteri endpoint’lerini koru
Load shedding: Neyi “reddederim”?
Load shedding iki soruya cevap verir:
- Hangi talepleri reddediyorum?
- Hangi sinyalle reddetmeye başlıyorum/durduruyorum?
Ben genelde şu sırayı tercih ederim:
- Low-priority batch: arka plan işler (recompute, refresh, export)
- Best-effort API: “nice-to-have” endpoint’ler
- Anonim trafik: kimliksiz/ratelimit’siz girişler
- Misbehaving client: hatalı retry fırtınası yaratan istemciler
SLO sinyali: Hangi metrikle tetiklerim?
Degrade modu bir “panic button” değil, bir otomasyon olmalı. Tetik sinyallerini iki grupta ele alırım:
- Sistem sinyalleri: p95/p99 latency, error rate, queue depth, conn pool saturation, thread pool utilization
- İş sinyalleri: checkout success rate, login success, order placement, critical workflow completion
Hedef: yanlış pozitifleri azaltıp doğru zamanda devreye girmek.
Kontrol yüzeyi: Degrade modunu nereden yönetirim?
Üretimde pratik olan model şu üç parçayı birleştirir:
- Traffic shaping: ingress (LB / API gateway) üzerinde rate limit + priority
- Feature flags: pahalı özelliği kapat / cache’e dön
- Queue policy: öncelikli kuyruk + TTL + drop stratejisi
Tek bir katmana güvenmek (sadece gateway veya sadece flag) yeterli olmaz. Gerçek sistemler katmanlıdır.
Karar matrisi: “Ne zaman neyi kısarım?”
Aşağıdaki matrisi runbook’a koyunca, incident sırasında daha az tartışma olur:
- Latency yükseliyor, error düşük → cache agresifleşsin, pahalı endpoint limitlensin
- Error yükseliyor, bağımlılık timeout → downstream’e giden çağrılar kısılsın, retry politikası sertleşsin
- Queue büyüyor → TTL düşsün, low-priority işler drop edilsin
- Conn pool doygun → concurrency limit düşsün, read-only kopyaya yönlensin
Uygulanabilir bir başlangıç paketi
“Büyük dönüşüm” beklemeden ilk adım olarak şunlar yeterli olur:
- Her kritik akış için 1 adet degrade playbook (kapatılacak özellik listesi)
- API gateway’de priority + rate limit (en azından anonymous vs authenticated ayrımı)
- Uygulamada 1–2 kritik yerde concurrency limiter
- Queue için TTL + DLQ + drop policy
- Observability’de SLO burn ve “degrade active” dashboard paneli
Son söz: Kontrollü kayıp, operasyonel olgunluktur
Degrade modu “kaliteyi düşürmek” değil; tüm sistemi ayakta tutmak için bilinçli bir tercihtir. Bu disiplin kurulduğunda incident’ların tonu değişir: panik yerine yönetilebilir kararlar, tahmin edilebilir etkiler ve daha kısa MTTR.