Geri Alma Bütçesi (Rollback Budget): Gözden Kaçan Dağıtım Metriği

Yazılım Teslimatı dagitim, surum-muhendisligi

Çoğu ekip dağıtım sıklığını ölçer ancak geri alma süresini ölçmez. Rollback bütçesi olmadan her sürüm tek yönlü bir bahistir ve kurtarma doğaçlamaya kalır.

  • Yazar: Orzed Team
  • 1 dk okuma
Önemli çıkarımlar
  • Geri alma bütçesi, hatalı bir dağıtımın fark edilmesinden önceki sürüme dönülmesine kadar geçen azami kabul edilebilir süredir.
  • Müşteriye dönük bir serviste bu süre 30 dakikayı aşıyorsa dağıtım hattında hemen çözülmesi gereken bir mimari sorun vardır.
  • Geri alınamayan dağıtımların en yaygın nedeni veritabanı şema taşımalarıdır; iki aşamalı taşımalar hafta sonlarını kurtarır.
  • Mesai saatleri içinde düzenli geri alma tatbikatı yapmak bir sürüm mühendisliği ekibinin alabileceği en ucuz sigortadır.

Dağıtım hatları her zaman ilgi görür; CI derleme süreleri saniyesine kadar ölçülür ve “günde N kez canlıya çıkıyoruz” cümlesi mühendislik kültürünün bir parçası olur. Geri alma (rollback) işlemleri ise nadiren aynı özeni görür; çoğu zaman eski bir wiki sayfasındaki manuel komutlardan ibarettir ve gece saat 3’te ilk kez denendiğinde çalışması umulur.

Geri alma bütçesi, “bu dağıtımın hatalı olduğunu biliyoruz” anından “canlı ortam bir önceki sürüme döndü” anına kadar geçen azami kabul edilebilir süredir. Müşteriye dönük web servisleri için bu bütçe 5 ila 15 dakika olmalıdır.

Geri Almalar Neden Beklenenden Yavaş Sürer ve Nasıl Çözülür?

Projelerde ilk gerçek geri alma süresini ölçtüğümüzde, ekibin tahmininden hampir her zaman iki ila dört kat daha uzun çıktığını görürüz. Dört temel engel ve mühendislik çözümleri şunlardır:

  1. İki aşamalı veritabanı taşımaları (Two-phase migrations): Tek yönlü sütun silme veya yeniden adlandırma işlemleri kodun geri alınmasını imkansız kılar. İlk dağıtımda eski yapıyı bozmadan yeni sütunu ekleyin, ikinci dağıtımda kodu yeni sütuna geçirin, eski sütunu ise ancak sistem kararlılaştıktan sonra üçüncü bir dağıtımda kaldırın.
  2. Sürümlü mesaj sözleşmeleri: Kuyruklar ve olay akışları dağıtımı aşar. Tüketici servislerin her zaman bir önceki mesaj şemasını (version N ve N+1) okuyabilmesini sağlayın ki hatalı üretici geri alındığında kuyruğu elle boşaltmak zorunda kalmayın.
  3. Kodla birlikte atomik dağıtılan konfigürasyon: Ortam değişkenleri ve özellik bayrakları dağıtım paketiyle birlikte gitmelidir; kodu geri aldığınızda konfigürasyon da otomatik olarak eski haline dönmelidir.
  4. Çeyreklik Geri Alma Tatbikatı: Düşük trafikli bir mesai saatinde mevcut sürümü tekrar dağıtıp geri alma akışını tetikleyin, süreyi ölçün ve kırılan adımları gerçek bir kriz yaşanmadan önce onarın.
Sıkça sorulanlar

Sıkça sorulan sorular

Bir geri alma (rollback) işlemi ne kadar hızlı olmalıdır?

Bunu bir temenni değil bütçe olarak belirleyin. Müşteriye dönük bir web servisi için tipik bütçe 5 ila 15 dakikadır. İç yönetim araçları için 15-60 dakika olabilir. Önemli olan sayının kendisinden çok yazılı olması ve ölçülmesidir.

Veritabanı şema değişikliği nedeniyle geri alma mümkün değilse ne yapmalıyız?

O zaman taşıma (migration) yanlış tasarlanmıştır. Her şema değişikliğini en az iki aşamalı yapın: önce geriye dönük uyumlu şemayı dağıtın, sonra yeni kodu devreye alın ve eski sütunu ancak haftalar sonra üçüncü bir dağıtımla silin.

SLO ihlalinde geri alma işlemi otomatik mi tetiklenmeli?

Olgun kurulumlarda evet. Ancak otomatik geri almayı yalnızca ekip en az on kez bütçe içinde temiz manuel geri alma yaptıktan ve iki aşamalı şema disiplinini oturttuktan sonra devreye alın.