Hata oranı artınca otomatik rollback yapan (self-healing) deploy altyapısını 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.