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.

Kısa cevap

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. Bu bağın alt katmanı olan trafik geçiş stratejisini — canary mi, blue-green mi — fintek API’si için deploy stratejisi kaydında ayrıca konuşmuştuk.

Neden

1. Anomali ancak kısmi trafikte ucuza yakalanır. Yeni sürümü hemen %100’e açarsan hata oranındaki artışı gördüğünde bütün trafik zaten etkilenmiş olur; canary ağırlığındaki bir pencere aynı sinyali küçük bir kitleyle verir.
2. Rollback yeni bir deploy değil, hazır olana geçiştir. Deployer release’leri saklar, Kubernetes eski ReplicaSet’i tutar; bu yüzden geri dönüşü otomatikleştirmek güvenlidir.
3. Eşik yanlış kurulursa sistem kendi kendini sürekli geri alır. Gürültüye takılan bir health-gate flapping üretir; makul bir eşik ve minimum örnek sayısı olmadan otomasyon zarar verir.
4. Otomatik rollback kodu geri alır, veriyi değil. Migration geriye uyumlu değilse geri dönüş şemayı tutarsız bırakır — ve otomasyon nedeni de anlamaz, yalnızca kanamayı durdurur.

Ne yapmalı

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. Health-gate’i araçlara bağla. 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ı.

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.