# Hata oranı artınca otomatik rollback yapan (self-healing) deploy altyapısını nasıl tasarlarım?

> Yeni sürümü canary ağırlığında bir bake süresi boyunca 5xx ve latency eşiğine karşı ölçün; eşik aşılırsa son kararlı sürüme dönüp ekibi yalnızca uyarın.

- Soruldu: 2026-06-12
- Yanıtlandı: 2026-06-13
- Soran: Emir
- Etiketler: ci-cd, dayaniklilik, observability
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/hata-artisinda-otomatik-rollback-ve-kendi-kendini-iyilestiren-deploy/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Yeni sürüm DeployerPHP/Kubernetes ile başarıyla canlıya alındı, pipeline yeşil yandı. Ama 5 dk sonra üretimde 5xx hata oranı %10'un üzerine çıktı. Bunu bir mühendis ekran başında beklemek yerine; Prometheus/Grafana veya New Relic metriklerini izleyip anomaliyi yakalayan ve eşik aşılınca otomatik olarak bir önceki kararlı sürüme dönen self-healing altyapıyı nasıl tasarlarım?


Kısa cevap: Bir insanı dashboard başında bekletme — metrikleri doğrudan deploy'un içine göm. Doğru desen, otomatik analizle çalışan **progressive delivery**.

Yaşadığın şey net: pipeline yeşil yanıyor ama "yeşil" sadece deploy'un teknik başarısı; üretimdeki gerçek sağlık değil. İkisini birbirine bağlaman lazım.

1. **Deploy sonrası bir canary ağırlığında "bake" süresi tut.** Yeni sürümü hemen %100'e açma; bir süre kısmi trafikte beklet ve bu pencerede Prometheus/New Relic'ten 5xx oranı, latency ve kritik iş metriklerini bir eşiğe/baseline'a karşı sorgula. Anomali bu pencerede yakalanır.
2. **Eşik aşılırsa otomatik olarak son kararlı sürüme dön.** Health-gate breach olunca pipeline insan beklemeden `rollback` tetikler ve ekibi **uyarır**. İnsan gece nöbetinde değil, sadece bilgilendirilir.
3. **Önceki release'i hazır tut ki rollback anlık olsun.** Deployer release'leri saklar, Kubernetes eski ReplicaSet'i tutar — geri dönüş yeni bir deploy değil, hazır olana geçiştir. Tooling: k8s'te Argo Rollouts / Flagger bu canary analizini + rollback'i otomatik yürütür; Deployer'da deploy sonrası metrik polling yapıp breach'te `deploy:rollback` çağıran bir health-gate adımı ekle.
4. **Guardrail'leri doğru kur, yoksa flapping olur.** Makul bir eşik seç (gürültüye takılıp sürekli rollback yapmasın), minimum örnek sayısı şart koş ve **sadece deploy'u** geri al — data migration'ı değil. Bu yüzden migration'lar geriye uyumlu olmalı; yoksa rollback şemayı tutarsız bırakır.

**Sonuç:** Ben olsam canary + otomatik metrik analizi + son-kararlıya auto-rollback kurar, insanı nöbetçi değil **uyarılan** taraf yapardım — self-healing olan deploy, kişi değil. Otomatik rollback sorunu durdurur ama nedeni anlamaz; o yüzden bunu suçlu aramayan bir post-mortem kültürüyle tamamla — kalıcı düzeltme oradan gelir.

## İlgili Yazılar

- [Fintek API'si için Canary mi, Blue-Green deployment mı?](https://www.muhammetsafak.com.tr/sor-bakalim/canary-mi-blue-green-mi-fintek-api-icin-deploy-stratejisi/) — Sor Bakalım
- [Log storm ve disk dolma krizini nasıl önlerim?](https://www.muhammetsafak.com.tr/sor-bakalim/log-storm-ve-disk-dolma-krizini-onlemek/) — Sor Bakalım
- [Correlation ID'yi HTTP isteğinden kuyruğa düşen job'lara kadar nasıl taşımalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/correlation-idyi-http-isteginden-kuyruga-dusen-joblara-kadar-nasil-tasimaliyim/) — Sor Bakalım