Tech

Şema geçişim, dağıtılan servislerin buna dayanıp dayanamayacağı kontrol edilmeden neden çalışır?

Fırsat

Bir üretim veritabanına şema değişikliği gönderdiğinizde, geçiş; halihazırda çalışan servis sürümlerinin yeni yapıyı okuyup okuyamayacağını ya da yazıp yazamayacağını herhangi bir araç doğrulamadan önce çalışır. Silinen bir sütun veya yeniden adlandırılan bir alan, eski pod'lar boşalmayı tamamlamadan veritabanına ulaşır; geri alma şemayı geri yükler, ancak bu aralıkta yeni sürüm tarafından yazılan verileri geri getirmez. ORM araçları diff'lerden SQL üretir; ancak dağıtım topolojisi, eş zamanlı servis sürümleri veya canlı okuma-yazma kalıpları hakkında hiçbir modelleme yapmaz. Ekipler bunu, araçlarla zorunlu kılınmayan wiki'lerde ve sözel bilgide belgelenen genişlet-daralt ritüelleriyle telafi eder. Yalnızca geçen yıl, tek bir sıra dışı adım birden fazla serviste zincirleme arızaları tetikledi ve belgelenmiş 4,5 milyon dolarlık bir olaya neden oldu.

Neden önemli

Canlı servis topolojinizi modelleyen bir ön uçuş uyumluluk kontrolü, bir dağıtımın en riskli adımını uygulamaya basmadan önce üzerine düşünebileceğiniz bir şeye dönüştürür.

Fırsatı nasıl puanlıyorum

Fırsat Puanı benim kendi değerlendirmem, bir ölçüm değil: ne kadar acı verdiği, ne sıklıkla etkisi olduğu ve bugün için ne kadar az çözüm bulunduğu. Daha yüksek puan, inşa etmeye daha değer olduğunu düşündüğüm anlamına gelir.

Ciddiyet9/10

Ortaya çıktığında ne kadar sorun yarattığı.

Sıklık8/10

İnsanların bununla gerçekte ne sıklıkla karşılaştığı.

Boşluk7/10

Bugün bunun için ne kadar az iyi araç bulunduğu.