Ortamı yeniden üretemediğinizde nasıl test edilir ve optimize edilir?

Geçmişte çeşitli ortamlarda çalıştım. Masaüstü uygulamaları, oyunlar, katıştırılmış öğeler, web hizmetleri, komut satırı işleri, web siteleri, veritabanı raporları vb. Tüm bu ortamlar aynı özelliği paylaştı: karmaşıklıkları ne olursa olsun, boyutları ne olursa olsun, makinemde veya test etmek için geliştirici ortamında her zaman uygulamanın bir alt kümesine veya dilimine sahip olabilirim.

Bugün bilmiyorum. Bugün kendimi birincil odağı ölçeklenebilirlik üzerine bir ortamda buluyorum. Çevrenin yeniden üretilmesi oldukça maliyetlidir. Ortamın bir dilimini almak, makul olsa da (bazı parçaların simüle edilmesi veya yapılmadıkları tek örnekli bir modda kullanılması gerekir), eşzamanlılığı gizlediği ve yüklemesi nedeniyle bu amacı yener. gerçek sistem karşılaşır. Küçük bir "test" sisteminin bile kusurları vardır. 2 düğümünüz ve 64 düğümünüz olduğunda işler farklı davranacaktır.

Her zaman optimizasyon yaklaşımım (ölçmek, bir şey denemek, doğruluğu doğrulamak, farklılıkları ölçmek, tekrarlamak) gerçekten işe yaramıyor çünkü sorunun önemli kısımları için 2. ve 3. adımları etkili bir şekilde yapamıyorum (eşzamanlılık sağlamlığı ve performansı altında yük). Yine de bu senaryo benzersiz görünmüyor. Bu tür bir görevi bu tür bir ortamda yapmak için ortak yaklaşım nedir?

İlgili bazı sorular var:

• bu soru (göreceli olarak) kolayca taklit edilebilen donanımın (spektrum analizörleri gibi) kullanılamamasıyla ilgilidir.
• bu soru, yalnızca üretim ortamlarında var olan hataları izlemekle ilgilidir, bu da yararlıdır - ancak farklı bir etkinlik.

Aslında zor, ama pek çok karşılaştırılabilir durumda eminim öncelikle bir organizasyonel sorun. Tek geçerli yaklaşım muhtemelen sadece bir gümüş mermi değil, birleşik önlemlerin bir karışımıdır. Deneyebileceğiniz bazı şeyler:

• günlüğe kaydetme: zaten bir yorumda yazdığım gibi, aşırı zaman ve kaynak günlüğü (bir tür profilleme) üretimdeki gerçek darboğazları tanımlamanıza yardımcı olabilir. Bu, alternatif bir uygulamanın daha iyi çalışıp çalışmayacağını size söylemeyebilir, ancak uygulamanızın tamamen yanlış kısmını optimize etmekten kaçınmanıza kesinlikle yardımcı olacaktır.

• önceden test edebileceğinizi test edin - önceden planlanmış bir sürü planla iyice. Tabii, üretimde işler farklı olacak, ama her şey değil . Farklı bir uygulamanın doğruluğu önceden önceden kontrol edilebilir - bir uygulama iyi ölçeklenirse, farklı bir sorudur. Ancak planlama çok yardımcı olabilir. Test ortamınızın sizin için çözebileceği ve çözemediği sorunları düşünün. Neredeyse her zaman ilk bakışta "önceden test edilemeyeceğine" inandığınız şeyler vardır, ancak iki kez düşünürseniz, genellikle daha olasıdır.

• Takım olarak çalışın. Yeni bir yaklaşım veya fikir denerken, bunu ekibinizin en az bir kişisiyle tartışın. Farklı bir algo uyguladığınızda, kod denetimleri ve KG konusunda ısrar edin. Önceden ne kadar çok hata ve sorun varsa, üretimde çözmeniz gereken daha az ciddi sorun olacaktır.

• Her şeyi önceden test edemeyeceğiniz için, üretimde sorun çıkmasını bekleyin. Bu nedenle, yeni kodu üretime getirirken gerçekten iyi bir geri dönüş stratejisi hazırlamaya çalışın. Yeni kodunuz eski çözümden daha yavaş arılanma riski taşıyorsa veya çökme riski varsa, en kısa sürede bir önceki ASAP sürümüne geçebildiğinizden emin olun. Üretim verilerini yok etme riski varsa, iyi bir yedek / kurtarma işlemine sahip olduğunuzdan emin olun. Ve sisteminize bir doğrulama mekanizması ekleyerek bu tür arızaları tespit ettiğinizden emin olun.

• bir proje günlüğü veya çözüm günlüğü tutun - ciddiye alın. Her gün çevre hakkında yeni bir şeyler öğreniyor, yazıyor - başarı hikayeleri ve başarısızlık hikayeleri. Aynı hatayı iki kez yapmayın.

Yani öz - deneme yanılma yöntemiyle gidemediğinizde, en iyi seçeneğiniz muhafazakar, klasik ön planlama ve KG teknikleri.

Canlı ortamı yeniden üretemiyorsanız, rahatsız edici gerçek, ne yaparsanız yapın, yeterince test edilmeyeceğidir.

Ne yapabilirsin?

Eh, ölçeğe sahip olursa olsun, bu bir süreç, sunucu kümesi veya veritabanı hacmi ile test edilmelidir olmak sıfır, bir, sonsuzluk kural potansiyel darboğazları / sınırlamalar o IO, CPU'lar, CPU yükü, diğer hususların olması nerede didiklemek akılda -işlem iletişimi vb.

Bunu yaptıktan sonra, ne tür testlerin etkilendiğine dair bir fikir edinmelisiniz. Birim testi ise, bu geleneksel olarak geliştiriciye oturur, eğer entegrasyon / sistem testi ise, o zaman ek uzmanlık veya daha iyi araçlar ile yardımcı olabilecek diğer ekiplerle temas noktaları olabilir.

Araçlardan bahsetmişken, geliştirme ortamında mümkün olanın ötesinde bir sistemi test etmek geliştiricinin görevi değildir. Bu, test bölümüne veya başka bir üçüncü tarafa aktarılmalıdır.

Odadaki fil, elbette, sistemlerin her zaman öngörülebilir şekillerde ölçeklenmemesidir!

Eski bir yaşamda, milyarlarca sıralı banka veritabanları için bir DBA'ydım ve yürütme planlarıyla donatılmıştım, genellikle girdi hacimleri göz önüne alındığında sorguların boş bir veritabanında ne kadar süreceğini tahmin edebilirdik. Ancak, bu birimler belirli bir boyuta ulaştığında, yürütme planı değişecek ve sorgu / veritabanı ayarlanmadıkça performans hızla düşecektir.

Deneyler öneririm.

Günlük kaydı tıkanıklıkları bulacaktır. Daha sonra bazı makinelerde, hatta belirli bir olasılıkla tüm makinelerde veya sınırlı bir süre için alternatif bir uygulamayı deneyebilirsiniz. Ardından iyileştirmeleri kontrol etmek için günlükleri tekrar karşılaştırın.

Alıştığınız teori-deney-ölçüm döngüsü aynıdır, ancak hipotezlerin üretimde çalıştırılması gerektiğinden - kurulumu daha pahalıdır - ve hacminize bağlı olarak, üretimden önemli veriler almak da yavaş olabilir.