Yayınlandıktan Hemen Sonra Çöken Uygulamaları Yakalamak

25 Eylül'de üç yayın, uygulamanın API'si her açılışta birkaç saniye içinde çökmesine rağmen başarılı işaretlendi. Yayın "başarılı" olduğu için geri alma çalışmadı; birkaç dakika sonra bir arka plan kontrolü bu yayınları başarısız saydı ve tüm site 404 hatasına düştü. Sağlık kontrolü, çökmeleri barındırma platformunun olay listesinde sayıyordu; bu liste makine başına yalnızca son beş olayı tutar. Bir çökme döngüsü listeyi sürekli dolu tutar ve sayı hiç artmaz. Artık bunun yerine en yeni çökmenin zamanını karşılaştırıyor; çökme döngüsüne giren bir yayın başarısız olur ve önceki sürüm geri yüklenir.

Bir yayın neyi bekler

Mythex'te arka uçlu bir uygulama yayınladığınızda, yeni sürüm platformumuzun makinelerine dağıtılır ve bir sağlık kontrolü yayının canlı mı yoksa başarısız mı olduğuna karar verir. Başarısız olduysa, bir geri alma önceki sürümü geri koyar.

Zor kısım, "başladı"nın "hizmet veriyor" ile aynı şey olmamasıdır. Platform, bir makineyi ayağa kalkar kalkmaz başlamış olarak bildirir. Açılıştan bir saniye sonra çöken bir uygulama hemen yeniden başlatılır ve kısa bir süre sonra yeniden başlamış gibi görünür. Bu yüzden sağlık kontrolü zamanla birkaç katman kazandı:

1. İki kez bak. Bir makine başlamış göründükten sonra kısa süre bekle ve tekrar bak. Açılışta bir çökme, genellikle ikinci bakışta başarısız olur.
2. Çökme döngülerini izle. Platform bir makinenin sürekli çöktüğünü ve yeniden başlatmayı bıraktığını bildirirse, başarısız say.
3. Bu yayın başladığından beri olan çökmeleri say. İki "başladı" bakışı bir yeniden başlatmayı kapsayabilir. Bu yüzden bu yayın başladığından beri herhangi bir çökme olduysa, üçüncü kez bak; önceki bakıştakinden daha fazla çökme varsa, uygulama ayakta kalmıyor demektir.

Bu olduğunda başarısız olan üçüncü kontrol oldu.

Sayı neden sabit kaldı

Çökme bilgisi, her makinenin olay listesinden gelir: başlamalar, çıkışlar, yeniden başlatmalar. Platform makine başına yalnızca son beş olayı tutar.

Açılıştan 2,5 saniye sonra çöken bir uygulama düşünün; bunlardan biri de böyleydi. Her döngü bir çökme ve bir başlama ekler. Birkaç döngüden sonra liste doludur. Bundan sonra her yeni olay eski birini dışarı iter. Liste ilerler, ama her zaman yaklaşık aynı karışımı tutar: birkaç çökme, birkaç başlama.

Yani "bu yayın başladığından beri kaç çökme oldu" sorusu her bakışta aynı sayıyı döndürdü. İkinci bakış, diyelim ki iki çökme gördü. Üçüncü bakış da iki çökme gördü; farklı çökmeler, ama aynı sayı. Kontrol, çökmelerin durduğu sonucuna vardı ve yayını geçirdi.

Bu, 25 Eylül'de iki uygulamada üç kez oldu. Her seferinde:

• yayın canlı olarak işaretlendi,
• hiçbir şey başarısız olmadığı için geri alma çalışmadı,
• sonradan çalışan bir arka plan işi olan mutabakatımız, birkaç dakika sonra dağıtımı başarısız saydı,
• ve tüm site 404 döndürdü.

Zamanında başarısız olan bir yayın kurtarılabilir: geri alma önceki sürümü geri yükler. Birkaç dakika geç, başarılı ilan edildikten sonra başarısız olan bir yayın ise geri almayı zaten atlamıştır.

Nasıl bulduk

Yerelde yeniden ürettik: çalışan bir API alıp uyuttuk, sonra açılışta çöken bir değişiklikle yeniden yayınladık. Sağlık kontrolü yayını canlı olarak işaretledi.

Bu üretimdekiyle eşleşti: üç yayının her birinde uygulama her açılışta birkaç saniye içinde öldü, ama kontrolün karşılaştırdığı çökme sayısı bakışlar arasında hiç artmadı.

Düzeltme: sayıyı değil, en yeni çökmeyi karşılaştır

Kontrol artık çökmeleri saymak yerine, yayın başladığından beri en son çökmenin zamanına bakıyor.

İkinci bakışta, yayın başladığından beri herhangi bir çökme görülürse, kontrol bekleyip üçüncü kez bakar. Üçüncü bakıştaki en yeni çökme, ikincideki en yeni çökmeden daha sonra ise, makine aradaki sürede yeniden çökmüş demektir. Ayakta kalmıyor; yayın, uygulamanın yeniden başlatıldığını ve yayından sonra tekrar tekrar çöktüğünü söyleyen bir mesajla başarısız olur.

Bu, olay listesi ne kadar kısa olursa olsun işe yarar. Beş olaylık kayan bir pencere, kaç çökme olduğunu gizleyebilir; ama yeni bir çökmenin olduğunu gizleyemez. En yeni olay her zaman tutulan olaydır.

Bu değişiklikle yerel yeniden üretim doğru davranıyor: yayın başarısız oluyor ve önceki imaj geri yükleniyor. Ayrıca platformun davranışını taklit eden bir test var: her bakış bir çökme ve bir başlama ekliyor ve listeyi beşe kırpıyor; sonucun geçiş değil, başarısızlık olduğunu doğruluyor.

Öğrendiklerimiz

• Saydığınız verinin şeklini bilin. Sınırlı bir listede yapılan sayım, liste dolduğunda bir anlam ifade etmez. Sınır gizli değildi; sadece kontrolü ona göre tasarlamamıştık.
• "Kaç tane oldu?" yerine "yeni bir şey oldu mu?" sorusunu tercih edin. En yeni zaman damgası kırpmadan sağ çıkar. Toplam çıkmaz.
• Geç başarısızlık erken başarısızlıktan daha kötüdür. Aynı bozuk derleme, yayın başarısız olup geri alınırsa zararsızdır; önce başarılı ilan edilirse siteyi indirir.
• Gerçek koşullarla yeniden üretin. Hata, olay listesini doldurmaya yetecek kadar çökmüş bir makine gerektiriyordu. Testte tek bir hızlı çökme bunu göstermezdi.

Bu düzeltme, aynı gün yapılan ve geri almanın eski sürümü silmek yerine geri koymasını sağlayan başka bir düzeltmeyle birlikte çalışır: başarısız bir yeniden yayın asla çalışan bir arka ucu silmez. Uygulamanız başlangıçta çöktüğü için yayınlanamıyorsa, yayın sorun giderme dokümanları ve AI ile yapılmış bir uygulamayı hata ayıklama rehberimiz iyi başlangıç noktalarıdır.