Share via

Üretimde test etmek için sağa kaydırma

  • Makale

Sağa kaydırma, üretimde test etmek için DevOps işleminin devamındaki bazı testleri taşıma uygulamasıdır. Üretim ortamında test etmek, bir uygulamanın üretim ortamındaki davranışını ve performansını doğrulamak ve ölçmek için gerçek dağıtımları kullanır.

DevOps ekiplerinin hızı geliştirmenin bir yolu, sola kaydırmalı test stratejisidir. Shift left, yeni kodun üretime ulaşma süresini kısaltmak ve güvenilir bir şekilde çalışmak için daha önce DevOps işlem hattında testlerin çoğunu iter.

Ancak birim testleri gibi birçok test türü kolayca sola kayabilir, ancak bazı test sınıfları bir çözümün parçası veya tamamı dağıtılmadan çalıştırılamaz. Bir Soru-Cevap veya hazırlama hizmetine dağıtmak, benzer bir ortamın benzetimini yapabilir, ancak üretim ortamının tam bir yerine geçmez. Ekipler, üretimde belirli test türlerinin gerçekleşmesi gerektiğini fark etti.

Üretimde test şunları sağlar:

  • Üretim ortamının tam genişliği ve çeşitliliği.
  • Müşteri trafiğinin gerçek iş yükü.
  • Üretim talebi zamanla geliştikçe profiller ve davranışlar.

Üretim ortamı sürekli değişiyor. Bir uygulama değişmese bile, bağlı olduğu altyapı sürekli değişir. Üretim ortamında test, belirli bir üretim dağıtımının durumunu ve kalitesini ve sürekli değişen üretim ortamını doğrular.

Üretimde test etmek için sağa kaydırmak özellikle aşağıdaki senaryolar için önemlidir:

Mikro hizmet dağıtımları

Mikro hizmet tabanlı çözümler bağımsız olarak geliştirilen, dağıtılan ve yönetilen çok sayıda mikro hizmete sahip olabilir. Farklı sürümler ve yapılandırmalar birçok yolla üretime ulaşabileceğinden test hakkının kaydırılması bu projeler için özellikle önemlidir. Üretim öncesi test kapsamı ne olursa olsun, üretim ortamında uyumluluğun test edilmesi gerekir.

Dağıtım sonrası kaliteyi sağlama

Üretim ortamında yayınlamak, yazılım tesliminin yalnızca yarısıdır. Diğer yarısı ise üretimde gerçek bir iş yüküyle uygun ölçekte kaliteyi sağlamaktır. Ortam değişmeye devam ettiğinden, bir ekip üretimde test etme işlemini asla bitirmez.

Üretimden alınan test verileri, gerçek müşteri iş yükünden alınan test sonuçlarıdır. Üretimde test, izleme, yük devretme testi ve hata eklemeyi içerir. Bu test hataları, özel durumları, performans ölçümlerini ve güvenlik olaylarını izler. Test telemetrisi anomalileri algılamaya da yardımcı olur.

Dağıtım halkaları

Ekipler, üretim ortamını korumak için halka tabanlı dağıtımları ve özellik bayraklarını kullanarak değişiklikleri aşamalı ve denetimli bir şekilde dağıtabilir. Örneğin, müşterilerin %1'inden daha azı dağıtım halkasına geldiğinde alışveriş yapanın satın alma işlemini tamamlamasını engelleyen bir hatayı yakalamak, tüm müşterileri aynı anda değiştirmekten daha iyidir. Algılanan hatalarla özellik değeri, bu hataların net kayıplarını aşmalı ve belirli bir işletme için anlamlı bir şekilde ölçülmelidir.

İlk halka, standart tümleştirme paketini çalıştırmak için gereken en küçük boyut olmalıdır. Testler, işlem hattında daha önce diğer ortamlara karşı çalıştırılmalarına benzer olabilir, ancak test, üretim ortamında davranışın aynı olduğunu doğrular. Bu halka, herhangi bir müşteriyi etkilemeden önce yanlış yapılandırmalar gibi belirgin hataları tanımlar.

İlk halka doğrulandıktan sonra, sonraki halka test çalıştırması için gerçek kullanıcıların bir alt kümesini içerecek şekilde genişleyebilir. Her şey iyi görünüyorsa dağıtım, herkes kullanana kadar daha fazla halka ve test aracılığıyla ilerleyebilir. Tam dağıtım testin sona erdiği anlamına gelmez. Telemetri izleme, üretimde test için kritik öneme sahiptir.

Hata ekleme

Ekipler genellikle hata koşulları altında sistemin nasıl davrandığını görmek için hata ekleme ve kaos mühendisliğini devreye alır. Bu uygulamalar şunlara yardımcı olur:

  • Uygulanan dayanıklılık mekanizmalarının gerçekten çalıştığını doğrulayın.
  • Bir alt sistemdeki bir hatanın bu alt sistemde bulunduğunu ve büyük bir kesinti oluşturmak için art arda bulunmadığını doğrulayın.
  • Başka bir olayın gerçekleşmesini beklemek zorunda kalmadan, önceki bir olay için onarım çalışmasının istenen etkiye sahip olduğunu kanıtlayın.
  • Olaylarla daha iyi başa çıkabilmeleri için canlı site mühendisleri için daha gerçekçi eğitim tatbikatları oluşturun.

Sürekli değişen sistemlerde çalışması gereken pahalı testler olduğundan hata ekleme denemelerini otomatikleştirmek iyi bir uygulamadır.

Kaos mühendisliği etkili bir araç olabilir, ancak müşteri etkisi az veya hiç olmayan kanarya ortamları ile sınırlı olmalıdır.

Yük devretme testi

Hata eklemenin bir biçimi, iş sürekliliğini ve olağanüstü durum kurtarmayı (BCDR) desteklemek için yük devretme testidir. Ekiplerin tüm hizmetler ve alt sistemler için yük devretme planları olmalıdır. Planlar şunları içermelidir:

  • Hizmetin iş üzerindeki etkisinin açık bir açıklaması.
  • BCDR planlarını geliştirme aşamasında platform, teknoloji ve kişiler açısından tüm bağımlılıkların haritası.
  • Olağanüstü durum kurtarma yordamlarının resmi belgeleri.
  • Olağanüstü durum kurtarma tatbikatlarını düzenli olarak yürütmek için bir tempo.

Devre kesici hata testi

Devre kesici mekanizması, genellikle bu bileşendeki hataların kendi sınırları dışına yayılmasını önlemek için belirli bir bileşeni daha büyük bir sistemden keser. Aşağıdaki senaryoları test etmek için devre kesicileri kasıtlı olarak tetikleyebilirsiniz:

  • Devre kesici açıldığında bir geri dönüşün çalışıp çalışmadığı. Geri dönüş, birim testleriyle çalışabilir, ancak üretimde beklendiği gibi davranıp davranmayacağını bilmenin tek yolu, bunu tetikleyecek bir hata eklemektir.

  • Devre kesicinin gerektiğinde açılacak doğru duyarlılık eşiğine sahip olup olmadığı. Hata ekleme, kesme yanıt hızını gözlemlemek için gecikme süresini zorlayabilir veya bağımlılıkların bağlantısını kesebilir. Yalnızca doğru davranışın gerçekleştiğini değil, aynı zamanda yeterince hızlı gerçekleştiğini de doğrulamak önemlidir.

Örnek: Redis cache devre kesiciyi test etme

Redis cache , yaygın olarak kullanılan verilere erişimi hızlandırarak ürün performansını artırır. Redis'e kritik olmayan bir bağımlılık alan bir senaryo düşünün. Redis devre dışı kalırsa, istekler için özgün veri kaynağını kullanmaya geri dönebileceği için sistem çalışmaya devam etmelidir. Redis hatasının bir devre kesici tetiklediğini ve geri dönüşün üretimde çalıştığını onaylamak için bu davranışlara karşı düzenli aralıklarla testler çalıştırın.

Aşağıdaki diyagramda Redis devre kesici geri dönüş davranışına yönelik testler gösterilmektedir. Amaç, kesici açıldığında çağrıların nihai olarak SQL'e gitmesini sağlamaktır.

Diagram showing tests for the Redis circuit breaker and fallback behavior.

Yukarıdaki diyagramda redis çağrılarının önünde kesicilerin olduğu üç AT gösterilmektedir. Bir test, devre kesiciyi bir yapılandırma değişikliğiyle açmaya zorlar ve ardından çağrıların SQL'e gidip gitmediğini gözlemler. Başka bir test daha sonra, çağrıların Redis'e geri döndüğünü onaylamak için devre kesiciyi kapatarak karşı yapılandırma değişikliğini denetler.

Bu test, kesici açıldığında geri dönüş davranışının çalıştığını doğrular, ancak devre kesici yapılandırmasının gerektiğinde kesiciyi açtığını doğrulamaz. Bu davranışı test etmek için gerçek hataların benzetimi gerekir.

Hata aracısı, Redis'e giden çağrılarda hatalara neden olabilir. Aşağıdaki diyagramda hata ekleme ile test gösterilmektedir.

Diagram showing Redis circuit breaker testing with fault injection.

  1. Hata enjektör Redis isteklerini engeller.
  2. Devre kesici açılır ve test geri dönüşün çalışıp çalışmadığını gözlemleyebilir.
  3. Hata kaldırılır ve devre kesici Redis'e bir test isteği gönderir.
  4. İstek başarılı olursa, çağrılar Redis'e geri döner.

Diğer adımlar kesicinin duyarlılığını, eşiğin çok yüksek mi yoksa çok düşük mü olduğunu ve diğer sistem zaman aşımlarının devre kesici davranışını engelleyip engellemediğini test edebilir.

Bu örnekte, kesici beklendiği gibi açılmaz veya kapatılamazsa canlı site olayına (LSI) neden olabilir. Hata ekleme testi olmadan, bu tür testleri laboratuvar ortamında yapmak zor olduğundan sorun algılanmayabilir.

Sonraki adımlar