Bir şey canınızı mı sıkıyor?
(antithesis.com)- Antithesis, FoundationDB’de işe yaradığı görülen deterministik otonom test yaklaşımını genel yazılımlara da uygulayarak, yeniden üretmesi zor dağıtık sistem hatalarını tekrarlanabilir problemlere dönüştürmeyi hedefliyor
- FoundationDB, veritabanını uygulamadan önce tek iş parçacıklı, tek süreçli simülasyon kurdu ve aynı rastgele tohumla nadir hata durumlarını yeniden çalıştırabildi
- Bu yaklaşım; eşzamanlılık, ağ gecikmesi ve yeniden sıralama, disk sorunları, makine arızaları gibi deterministik olmayan hataları test edilebilir hale getirdi ve FoundationDB’de tüm dönem boyunca müşteri tarafından bildirilen hata sayısının yalnızca 1-2 olduğu değerlendirildi
- Antithesis, mevcut yazılımların baştan yazılmasını gerektirmemek için deterministik bir bilgisayarı taklit eden bir hipervizör geliştirdi ve şu anda dağıtık sistem güvenilirliği ile hata toleransı testlerine odaklanıyor
- MongoDB, Ethereum Foundation ve Palantir ile çalıştı; nadir hataları bulan bir araçtan, en güncel derlemeleri sürekli doğrulayan sürekli test hizmetine evrildi
FoundationDB deneyiminden doğan Antithesis
- Antithesis, 5 yılı aşkın süre gizlilik içinde geliştirildikten sonra, FoundationDB’de edinilen deterministik test deneyimine dayanan platformunu duyurdu
- Kamuya açılmadan önce işe alım, ilk müşteriler ve yatırımcılarla çalıştı; ilk açıkladığı temel nokta ise karmaşık sistemleri tekrarlanabilir biçimde test etme yöntemi oldu
Dağıtık veritabanlarında en zor doğrulama problemi
- FoundationDB, 2010’da ACID işlemlerini destekleyen, ölçeklenebilir ve hata toleranslı bir dağıtık veritabanı geliştirmeye başladı
- O dönemde Spanner henüz yayımlanmamıştı ve CAP teoreminin güçlü tutarlılık ile yüksek erişilebilirliğin birlikte imkânsız olduğu şeklinde yanlış anlaşıldığı durumlar da vardı
- En büyük zorluk, veritabanının kendisinden çok, böyle bir sistemin nasıl test edileceği ve doğruluğuna nasıl güvenileceğiydi
Geleneksel testlerin kaçırdığı “bilinmeyen bilinmeyenler”
- Yazılım, geliştiricinin önceden aklına gelmeyen durumları da ele alabilmelidir; ancak genel testler, önceden tahmin edilmiş senaryoları doğrulamada güçlüdür
- Eğer belirli bir durum test edilecek kadar öngörülmüşse, kod da büyük olasılıkla o durumu işleyecek şekilde yazılmıştır
- Bu yüzden geleneksel testler regresyonu önlemede yararlıdır, fakat gerçek kullanıcıların ve üretim ortamlarının ortaya çıkardığı beklenmedik hataları yakalamada zayıftır
- Dağıtık depolama sistemlerinde bu sorun daha da büyür
- Hem makine içinde hem makineler arasında eşzamanlılık vardır
- Ağ, gecikme ve paketlerin yeniden sıralanmasına yol açabilir
- Diskler, makine arızaları, elektrik kesintileri, veri merkezi yangınları ve insan hataları gibi çok geniş bir hata kaynağı yelpazesi vardır
- Kritik bir hata birden fazla makineye yayılan olay sırasına duyarlıysa, bir kez bulunsa bile yeniden üretmek zor olabilir
FoundationDB’nin deterministik simülasyonu
- FoundationDB ekibi, veritabanını yazmadan önce tamamen deterministik, olay tabanlı bir ağ simülasyonu oluşturdu
- Tüm kümeyi tek iş parçacıklı, tek süreçli bir uygulama içinde simüle etti ve yürütmeyi aynı rastgele sayı üreteciyle sürdürdü
- Sanal kümede ağ arızaları enjekte edebiliyor, makineleri kapatabiliyor ve çeşitli anormal durumları tekrar tekrar oluşturabiliyordu
- Belirli bir çalıştırma uygulama mantığında bir hata bulursa, aynı olay sırasını aynı rastgele tohumla yeniden çalıştırabiliyordu
- Bu sayede çok nadir hatalar bile log ekleyerek veya hata ayıklama adımlarını tekrarlayarak izlenebilir hale geldi
- İlgili sunum 2014’te Strangeloop’ta yapıldı; videoya buradan ulaşılabilir
Testin geliştirme hızını değiştirme biçimi
- FoundationDB’de şirketin tüm tarihinde müşteriler tarafından bildirilen hata sayısının yalnızca 1-2 olduğu değerlendirildi
- Kyle Kingsbury, yani “aphyr”, Jepsen ile FoundationDB’yi test ettiğinde bulunacak bir şey olmadığını düşündüğü için test etmediğini söyledi
- Testler yeni hataları hemen ortaya çıkarır hale gelince, ekibin programlama biçimi de değişti
- Derleyici ve güçlü tip sistemi belirli hata türleri için güven verir, ancak bu, yazılımı binlerce beklenmedik durumda gerçekten çalıştırmakla aynı şey değildir
- Bu güven sayesinde FoundationDB ekibi büyük değişiklikler yaptı
- Zookeeper dâhil tüm bağımlılıkları kaldırdı ve kısa sürede kendi Paxos uygulamasını yazdı; bu uygulama FoundationDB makalesinde yer aldı
- Tüm işlem işleme alt sistemini daha hızlı ve daha ölçeklenebilir olacak şekilde yeniden yazdı
- En büyük etki yalnızca veritabanı kararlılığının artması değildi; aynı zamanda küçük bir mühendislik ekibine 50 kat daha büyük bir ekibin üretkenliğini kazandırdı
Apple satın alımından sonra ortaya çıkan boşluk
- Apple, FoundationDB’yi 2015’te satın aldı ve bunu Apple’ın “cloud infrastructure” temelinde kullandı
- Birkaç yıl sonra FoundationDB açık kaynak olarak yayımlandı
- FoundationDB ekibindekiler başka büyük teknoloji şirketlerine dağıldıktan sonra bile, bu kuruluşlarda FoundationDB tarzı deterministik simülasyon testi yoktu
- Sistemde istenmeyen etkileri öngörmek zor olduğu için arka uç sistem değişiklikleri yavaş ilerliyor, üretim hatalarının teşhis ve düzeltilmesi için kıdemli mühendislerin aylarca zamanı harcanıyordu
- 2018’de Dave Scherer ile birlikte Antithesis’i başlattılar; amaç, FoundationDB tarzı deterministik otonom testi diğer ekiplere de sunmaktı
Mevcut yazılımlar nasıl deterministik hale getiriliyor?
- FoundationDB, baştan itibaren bu şekilde test edileceği düşünülerek tasarlanmış bir greenfield projeydi ve bağımlılıklarını da kaldırabiliyordu
- Genel amaçlı yazılımlar iş parçacıkları oluşturur, zamanı kontrol eder, çekirdekten rastgele değer ister ve ağ üzerinden başka yazılımlarla iletişim kurar
- Tüm yazılımların baştan yazılmasını gerektiren bir geliştirme metodolojisinin yaygınlaşması zor olduğundan, Antithesis deterministik bir bilgisayarı taklit eden bir hipervizör geliştirdi
- Sonuç olarak hipervizör içinde çalışan yazılım deterministik bir yürütme ortamına alınabiliyor
- Bu süreç, Intel CPU’lardaki extended page table gibi düşük seviyeli davranışlarla çalışmayı da içeriyor
- Rastgele bir programın durum uzayında özellik ihlallerini bulma problemi, durma probleminden bile daha zordur; tüm programlar için bir durma oracle’ı olsa bile hesaplanamaz test özellikleri var olabilir
Güncel platform ve müşteri örnekleri
- Antithesis platformu, kullanıcının yazılımını alıp hataları bulmayı ve bulunan hataların her zaman yeniden üretilebilmesini sağlamayı hedefliyor
- Birden çok servisin ağ üzerinden iletişim kurduğu karmaşık durumlarda bile yeniden üretilebilirliği korumaya çalışıyor
- Bir hata bulunduktan sonra güçlü hata ayıklama yetenekleri uygulanabiliyor
- Uzun vadede farklı yazılım türlerindeki birçok hata çeşidini bulacak şekilde tasarlansa da, şu anda deneyim sahibi olduğu dağıtık sistem güvenilirliği ve hata toleransı testine odaklanıyor
- Son birkaç yılda güvenilirliğin kritik olduğu büyük ve karmaşık sistemleri işleten mühendislik ekipleriyle çalıştı
- MongoDB ile birkaç yıldır iş birliği yaparak core server software ve WiredTiger storage engine testlerine destek verdi
- Ethereum Foundation ile Merge’den yaklaşık 1 yıl önce çalışmaya başlayarak Merge testlerine yardımcı oldu ve iş birliği hâlen sürüyor
- Palantir ile de çalışıyor
Nadir hata aracından sürekli test hizmetine
- İlk müşteriler Antithesis’i, bulunması ve yeniden üretilmesi en zor, en riskli hataları ortaya çıkaran bir özel kuvvet aracı gibi kullandı
- Platform olgunlaşıp daha etkileşimli hale geldikçe, en güncel derlemeleri sürekli test eden bir sürekli hizmete dönüştü
- Amaç, hatanın sisteme girdiği an ile tespit edildiği an arasındaki süreyi kısaltmak
- FoundationDB’nin geliştirildiği dönemde bu yaklaşım, hata teşhisi ve düzeltmesini çok daha kolay hale getirerek verimliliği ve yazılım kalitesini artırdı
- Antithesis, dağıtık sistemler işleten ve güvenilirlik ile mühendislik üretkenliğine önem veren kuruluşlarla iletişim kurmak istiyor
- Zor problemler üzerinde çalışmak isteyenler için iş ilanları da bulunuyor
1 yorum
Hacker News yorumları
“Efsanevi 10x geliştirici” ifadesi, haftada 6,5 gün 15’er saat çalışıp tükenen insanları anlatıyormuş gibi çarpıtılmış hissi veriyor.
Gerçek 10x, hatta 50x üretkenlik; neredeyse kimsenin mümkün görmediği ya da anlamadığı şeyleri hayata geçirip, çalışan yazılımı çok daha kısa sürede yapılabilir hâle getiren kişilerden geliyor.
Yöneticiler, aynı işi 8 saatte bitiren kişiden ziyade 8 saatlik işi 12 saatte yapan kişiyi çok daha sık fark ediyor.
Ayrıca “normal”in dışına çıkan denemelere iyi gözle bakılmıyor; süreçleri iyileştirmeye ayrılmış zaman da takvimde yer almıyor. Bu yüzden, kovaları daha hızlı taşımanın yeterli görüldüğü bir ortamda el arabası yapmak bastırılıyor.
Bu yüzden 10x mühendisler var. 30 yaşına geldiklerinde 10 değil, yaklaşık 20 yıllık programlama deneyimine sahip oluyorlar.
Mesleki deneyimleri de çok daha fazla oluyor. 15 yaşında bir akrabanın işine ara sıra yardım etmek gibi tuhaf işlerle başlasalar bile, 18 yaş civarında profesyonel bir şirkete girip bilgisayar bilimi eğitimiyle birlikte çalışıyorlar.
En azından eskiden böyleydi. 2004’ten yaklaşık 2018’e kadar bu gerçekti; bugünkü işe alım ortamında hâlâ mümkün mü bilmiyorum.
10x mühendisin var olması için birkaç örnek yeterli. Nadir oldukları konusunda sanırım çoğu kişi hemfikir; kamuya açık görülebilecek 10x mühendis örneği olarak şu kişi gösterilebilir. Kendisi asla böyle söylemez ama tahminimce 10x mühendistir: https://bellard.org/
Katılmıyorsanız hangi noktada farklı düşündüğünüzü merak ederim. Ben de körlerin fili tarif etmesi gibi yalnızca bir kısmına dokunan biriyim; bütün resmi gördüğümü iddia etmiyorum.
Her şeyi tek başına halleden tek kişilik ordu tipi geliştirici, işlerin standartlaştırılıp küçük parçalara ayrılarak dağıtıldığı ekiplerle pek uyumlu değildir.
Böyle insanlar, araya giren iş arkadaşları ya da yöneticiler olmadan kendi projeleri üzerinde çalıştıklarında en iyi performansı verirler; ama çoğu iş yeri böyle değildir.
Bir ekibin parçası olunca, ne kadar iyi olursanız olun tek başınıza aşırı fazla iş yapamazsınız; sonunda daha yavaş ya da daha zayıf ekip arkadaşlarının yarattığı sorunlarla veya yönetim kaynaklı problemlerle uğraşırken hızınız düşer. Bu yüzden ekip, içinde rockstar olsa bile en düşük ortak paydanın hızıyla ilerler.
İç araçlar geliştiriyor olmamız ve süreçlere, paydaşlara çok yakın olmamız da yardımcı oluyor.
“Hımm, bunu başarmanın başka bir yolu var” demek 10x’e karşılık geliyor; mesele daha hızlı yapmak değil.
Şimdiye kadar okuduğum en iyi giriş yazısı olabilir.
İnsanların kim olduğunu ve ne yaptıklarını iyi bir temele oturtuyor; şu anda yaptıkları şeyin daha önce yaptıklarının sonucu olduğunu açıklıyor.
Bu sorunu herkes için çözmek istedikleri hissini veriyor; çünkü görünüşe göre çözümün ne kadar iyi olduğunu bizzat deneyimlemişler.
Ardından bunu hâlihazırda kullanan ekipleri de gösteriyor; karmaşık sistemlere sahip oldukça büyük isimler var.
Bütün bunlar geliştiriciler ve kurucular üzerinde iyi çalışan güzel bir yazıyla paketlenmiş; landing page de harika.
Gerçek kullanım senaryoları ve örnekler görmek isterdim.
Bunun yerine birkaç büyük şirketin adını sıralamış, sihir gibi çalışan devrimsel bir ürün olduğunu iddia etmiş ve “10x programcı”, “stealth mode” gibi tipik moda sözcükleri eklemişler. Müşteri adlarını açıklayıp bir yandan stealth mode demek kendi içinde tutarsız.
Şimdiye kadar deneyimlemediğim bir yaşam biçimi, düşünme biçimi ve uygulama biçimi sunduğu için o çözümü istememi sağlıyor.
Bağlantı verilen yazının dörtte üçü, gerçekte ne yaptıklarını söyleyene kadar tarihçe ve gerekçelerden oluşuyor.
Vegan pankek yapmak istiyorum ama yazarın çocukluk hikâyesinden başlayan sinir bozucu tarif blogları gibi.
Harika bir sunum ve olumsuz görünmek istemem ama “tüm hataları bulduk” gibi bir cümlenin ancak hata tanımı çok dar tutulursa doğru olabileceğini düşünüyorum
Şimdiye kadar karşılaştığım en kötü ve bulunması en zor hatalar, bir hata durumuna düşmekten çok uygulamanın iş mantığının çevresindeydi
Örneğin veritabanında müşterinin tamamlanmış işlemi kayıtlıyken tamamlanmış satın alma kalemi yoksa, bu müşterinin son işlemler sayfasında nasıl gösterilmeli gibi bir sorun
Böyle durumlarda “bir şey görünsün ve çökmesin”i uygulamak ile bunun tüm yığın boyunca diğer seçimlerle bağlam içinde gerçekten anlamlı bir seçim olduğunu garanti etmek çok farklı şeyler
Veritabanı tarafında da “sorgu planlayıcı bu sınır durumda çok verimsiz bir plan üretiyor” gibi sorunlar var
Bu tür şeyleri otomatik tespit etmek mümkün değil. Çünkü mesele programın bir hata durumuna ulaşması değil, en başta uygulamada ‘doğruluk’un ne olduğunu anlamak
Hata çıtasını fazla yükseğe koyuyor olabilirim ama sıfır hata hayal etmek ile gerçek dünyada yazılım yapmak aynı şey değil. Yine de sıfır çalışma zamanı hatası denirse bunu kabul edebilirim
Yine de FoundationDB’nin test pratiklerinde çıtayı yükseltmesiyle gerçekten ünlü olduğu doğru: https://apple.github.io/foundationdb/testing.html
Normalde bu kibirli ya da aşırı özgüvenli kokardı ama burada gerçekten sıfır hataya çok yaklaşılmıştı
Elbette olumsuz bir önermeyi kanıtlayamazsınız ama böyle “hepsi yeşil” bir duruma ulaşmış olmak, sağlam bir temel üzerine inşa edildiğine dair büyük güven veriyordu; zamanla bunun gerçekten böyle olduğu ortaya çıktı
İş mantığı çevresindeki sorunlar sistemin başarısızlığı değil; sistem spesifikasyona göre çalışmıştır, spesifikasyon yeterince kapsayıcı değildir, artık yapılacak şey yineleyerek iyileştirmektir
Elbette birçok yazılımda belge eksikliği var ve bu da bir belge hatası
Yine de bu tanımın iyi yanı, belgeler eksik olsa bile “bu davranışı gerçekten belgeleyecek miyiz, yoksa davranışı değiştirip onu mu belgeleyeceğiz?” diye sordurması
En azından benim için garip davranışları üstünkörü geçiştirmeyi zorlaştırıyor
Bu alanı
sledsimülasyon rehberinde https://sled.rs/simulation.html öğrendiğimden beri büyük ilgi duyuyorum. O yazı FoundationDB’nin bunu nasıl yaptığını kabaca gösteriyorŞu anda iş yerimizde benzer bir test yaklaşımı getirmek için, servisimizin
madsimhttps://github.com/madsim-rs/madsim?tab=readme-ov-file#madsim üzerinde çalışacak şekilde yazılması üzerinde çalışıyorumBöylece tokio’da async/await tarzı servis yazmaya devam ederken, testlerde işletim sistemini çağıran bağımlılıklar dahil tüm determinizm dışı kaynakları yamalayan bir deterministik yürütücüye geçebiliyoruz. Oldukça pürüzsüz çalışıyor
Bu yazının yazarının başlangıç maliyetinin çok büyük olduğunu söylemesi abartı değil. Olası tüm determinizm dışı kaynakları ele almak ve servisi test edilebilir, sans-IO https://sans-io.readthedocs.io/ biçiminde yeniden yazmak ciddi mühendislik emeği gerektiriyor
Ama sistem bir kez yerine oturduğunda, koda dair hissettiğiniz güveni kelimelerle anlatmak zor. quickcheck https://github.com/BurntSushi/quickcheck?tab=readme-ov-file#quickcheck gibi araçlarla birleştirince giriş/çıkış, olay sırası, zaman aşımları, paket kaybı, dosya sistemi arızaları gibi yüz binlerce ince başarısızlık senaryosunu test edebiliyorsunuz
Bu tür testler, yatırım yapacak sabrınız ve sebatınız varsa araç kutusunda bulundurulabilecek çok güçlü bir araç
Antithesis’in kendisi de çok havalı görünüyor. Deterministik testi işletim sisteminin altındaki katmana indirmek müthiş; her seferinde elle harness örmeden tüm sistemi test etmeyi sağlayacak gibi. Bir an önce denemek istiyorum
Böyle sistemlerde gördüğüm karmaşıklığın önemli bir kısmı, “fonksiyon” çağrısının asenkron olmasından, işletim sistemine bağımlı olmasından, bir gün çalışabilecek ya da hiç çalışmayabilecek olmasından, statik tip sistemine geri girebilmek için ayrıştırılması gereken string demetleri döndürmesinden ve kendine ait hata modlarının bulunmasından kaynaklanıyor
Mantığı adlandırılmış bileşenlere, yani fonksiyonlara soyutlamak gibi görünüşte basit bir iş aşırı karmaşık hale geliyor
Mantığı aynı süreç içinde tutup sadece fonksiyon çağırırsanız, bahsettiğim o ince başarısızlıkları test etmenize gerek kalmaz
Monolit her zaman iyi ya da doğru seçim değildir ama günümüzde servis tabanlı yazılım mimarisi modasının haklı ve karşılığını veren bir şey olduğu konusunda çok şüpheciyim
Ayrıca Rust kullanan şirketlerde bu şekilde geliştirme yapılıp yapılmadığını da merak ediyorum
Ek olarak TigerBeetle da bu şekilde yazılmış bir ürün
madsimya da deterministik simülasyon testi benzeri bir şey var mı merak ediyorumYazı gerçekten çok eğlenceli
“Bu durumda programlama yapmak, tüm zararlardan koruyan bir güç alanıyla çevrili yaşamak gibi… Hata olduğu için Zookeeper dâhil tüm bağımlılıkları sildik, çok kısa sürede kendi Paxos uygulamamızı yazdık ve onda hata yoktu” gibi bir cümle kurup bunu kanıtla destekleyebilmek gerçekten harika bir şey olurdu
O kitapta, sayısal yazılım paketlerindeki hatalar yüzünden kendi problemini çözmeye çalışırken başkasının yazılımında hata ayıklamak zorunda kalmanın çok bunaltıcı olduğu; bu yüzden doğrusal cebir paketleri dışında genelde kendi yazılımlarını yaptıkları söyleniyor
Daha can sıkıcı olan noktanın, paketlerin problemin formülasyonundaki kusurları gizlemesi olduğu düşünülüyor. Bir denklem kümesini çözücüye verdiğinizde, koşullanması kötü olsa ya da beklenmedik bir tekillik yüzünden sonuç fiziksel gerçeklikle uyuşmasa bile çoğu zaman şikâyet etmeden bir çözüm döndürür; büyük bir programın içine gömüldüğünde de bu olasılığı göz ardı etmenize yol açabilir
Şüpheli bir davranış fark etseniz bile paketin içine girip sorunu kurcalamak zor olduğundan sonunda onu kendiniz yeniden programlamanız gerekir; baştan öyle yapsaydınız muhtemelen problemin gerçekliğine daha derinlemesine girer ve mantıksal karmaşayı önceden ortadan kaldırırdınız deniyor
Sonuçta bunu yapıp yapmamak, sizin ne kadar titiz olduğunuza, belirli bağımlılığın ne kadar titiz olduğuna ve ne kadar zamanınız olduğuna bağlı. Kendi veritabanımı yazmam; çünkü çok karmaşık ve iyi test edilmiş çok sayıda seçenek var. Buna karşılık, testleri zayıf küçük bir paketin yalnızca bazı işlevlerini kullanıyorsanız, kendiniz yapmak mantıklı olabilir
Ama spesifikasyonumda hata olmadığını iddia etmiyorum
Aklıma üç düşünce geliyor
Birincisi, doğru zamanda ortaya çıkmış harika bir fikir. Fuzzer’lar, statik tipler, bellek güvenliği, standartlaştırılmış protokoller, container’lar vb. konusundaki geliştirici duyarlılığına bakınca, insanların kararsız yazılımlara karşı sonunda sabrını yitirmeye başladığı hissi oluşuyor
İkincisi, niş bir pazarı hedefliyor gibi. CPU başına saatlik 2 dolar, rezervasyonla CPU başına yıllık 7000 dolar; hobi ya da özgür/açık kaynak kullanım için ücretsiz katman yok, deneme ya da satın alma için de iletişime geçmek gerekiyor. Acı verici ama geçerli bir iş modeli. Yine de mümkün olan en büyük olumlu etkiyi hedeflememesi üzücü
Üçüncüsü, yazı ve dokümantasyon kalitesi yüksek; dokümantasyonda “Hatalar prodüksiyonda veya müşteriler tarafından bulunursa bizden açıklama istemelisiniz” gibi bir ifadenin yer alması gerçekten hoşuma gidiyor
Geliştiricilerin sempatisini kazanmanın yolu tam olarak bu. Geçmişte beni hayal kırıklığına uğratmış olsa da hâlâ insanlara önerdiğim Mullvad aklıma geliyor
Bununla ilgili https://news.ycombinator.com/item?id=39358526 adresinde bahsetmiştim. Not olarak, Antithesis’in kurucu ortaklarındanım
Donanım da bunu destekleyen özellikler eklemeye başlayabilir ve 30 yıl sonra bu, bilişimin çalışma biçiminin ta kendisi olabilir
Ama öncüler bunu gerçekten yaygınlaştırmadan önce, ilk yedikleri okların maliyetini çıkarmak zorundalar. Bunu tek bir olay değil, bir sürecin başlangıcı olarak görmek gerekiyor
Dokümantasyona bakılırsa bu platformun bulmak üzere tasarlandığı hatalar, prodüksiyonda yalnızca nadiren ortaya çıkan, zorlu “yeniden üretilemeyen” türden hatalar
Çoğu ekibin düzeltmesi gereken çok daha büyük sorunları ve bariz hataları var. Aslında günümüzde prodüksiyon yazılımlarının çoğu, birim testlerine bile ancak sahip denecek düzeyde
Gerçek kullanım örneklerinde maliyetin nasıl katlandığını merak ediyorum
Bu yıl Strangeloop’ta Antithesis ile tanışıp çalışanlarıyla konuştum; Amazon’da çalışırken izlediğim otomatik hata enjeksiyonunun son durumuyla kıyaslayınca bile bu ürünün, bugün kullanılan birçok biçimsel doğrulama sistemine göre muazzam bir sıçrama olduğunu düşünüyorum
Gerçekten de Apache Spark Streaming’de buldukları bir sorun için hata izleme sürecini takip edebildim. Dokümantasyona göre, yaygın bir işlemde ince ve kötü huylu bir doğruluk hatası bulmuşlardı; düşük görünürlüklü bir sınır durumunda yıllarca baş ağrısı yaratabilecek bir sorundu
Sonunda dokümantasyonun yanlış olduğu ortaya çıktı, ama o süreci gördükten sonra dağıtık sistemler geliştiren bir şirket içinde Antithesis gibi araçların ne kadar önemli hâle geleceğini hayal etmek bile zor
Yakında teknik ayrıntılara derinlemesine giren bir blog yazısı çıkmasını umuyorum. Mevcut yaklaşıma nasıl ulaştıklarını duymak isterim
Hemen abartılı beklenti döngüsüne atlamak istemiyorum ama bu kulağa kutsal kâse gibi geliyor. Mevcut uygulamayı olduğu gibi kullanıp, container’laştırılmış olduğunu varsayarak, onun üzerinde yalnızca özellikleri sınamak yeterli değil mi?
Hep takıldığımız nokta makinenin temeli, yani deterministik olmayan CPU ve işletim sistemiydi
Tüm dikey bilişim yığınını baştan yapmak fiilen imkânsız olduğuna göre, bunlar yüksek sadakatli deterministik bir simülatör yaparak o sorunu etrafından dolaşmış oluyor
Yine de simülatör ile mevcut işletim sistemi arasındaki eşdeğerliği nasıl test ettiklerini merak ediyorum. Önemsiz bir iş gibi durmuyor. Yine de bu fikre epey ikna oldum
Ardından işletim sistemi arızaları, ağ sorunları, yarış durumları ve zamanlama koşulları, rastgele sayı üreteci sorunları gibi her türlü hatayı enjekte ederek testleri çalıştırıyorlar
Bugün bunları güvenilir biçimde test etmenin pratikte tek uygulanabilir yolu büyük olasılıkla bu; ama yine de tüm testleri yazmanız ve uygulama durumunu tanımlamanız gerekiyor
“Yazılımı alıp içindeki hataları avlayan bir platform” deniyor; peki gerçekte ne?
Entegrasyon testlerini çalıştıran bir bulut servisi gibi görünüyor. Bu özel ortama nasıl dağıtım yapılacağını çözmek gerekiyor ve sanırım özel kütüphaneler kullanarak entegrasyon testlerini yine de yazmanız gerekiyor.
Ama tüm bu entegrasyon refaktörünü yapsanız bile, benim ortamımda kendi entegrasyon testlerimle zaten bulamamış olacağım gerçek hataları nasıl bulacağını anlamıyorum.
Ancak Antithesis manuel test ya da entegrasyon testi yazmayı gerektirmez.
Yazılım sistemini konteyner olarak paketlemeniz gerekiyor; bu nispeten basit. Ardından sistemin normal çalışmasını taklit eden bir iş yükü yazmanız gerekiyor. Örneğin bir e-ticaret sitesi için ürünleri görüntüleme, sepete ekleme, ödeme gibi işlemler olur.
Buna dayanarak Antithesis iş yükünü çalıştırır, girdileri değiştirir, arıza enjekte eder ve yazılımı test edip test özelliklerinin ihlallerini bulmaya başlar.
Çökme, bellek yetersizliği vb. 60’tan fazla test özelliği yerleşik olarak gelir. Sisteme özgü sorunları daha fazla ortaya çıkarmak için özel özellikler de tanımlayabilirsiniz; pratikte de bunu yapmalısınız.
Test çalışırken özellik ihlalleri raporlanır ve çok sayıda yararlı hata ayıklama bilgisi içerir. Özellikle ilginç test çalıştırmaları geri sarılabildiği, girdileri değiştirilebildiği, çıktıları alınabildiği, loglama eklenebildiği için ek analiz yapmak mümkündür.
Şu ana kadar bildiğim bu kadar. Bir tür fuzzing ve statik analiz ya da yazılımın gerçekleştirebileceği davranışların tanımı olduğunu tahmin ediyorum.
Açıkçası Vale dilinin çözmeye çalıştığı şeyle epey örtüşüyor gibi görünüyor: https://vale.dev/
Ancak yeni yazılımın varsayılan olarak bu durumda olmasını sağlayacak yeni bir dil yapmak yerine, mevcut yazılımı bu duruma yaklaştırmaya odaklanıyor gibi.
Hipervizörü kullanarak rastgelelik seed’ini değiştiriyor, HTTP isteklerini başarısız kılıyor ya da uzun sürdürตüyor, sunucular arası bağlantıları koparıyor, sunucu yanıtlarının sırasını değiştiriyor ve normalde kontrol edemediğiniz ama gerçek hayatta olan her türlü şeyi oluşturuyor.
Sonra beklenen iş yükü yanıtlarıyla karşılaştırıp hangi koşulların sistemi bozduğunu anlıyor.
Bu yüzden yıllık sözleşmeyle satılıyor. Yapı şu: iş yüklerini tüm yıl boyunca sürekli çalıştırıp her tür başarısızlık kombinasyonunu denemesi için ödeme yapıyorsunuz.
Çok heyecanlandım ve dokümanlara biraz göz attım, ama bunun rastgeleleştirilmiş birim testlerinden nasıl farklı olduğunu pek anlayamadım.
Zaten bir birim testi koleksiyonunuz varsa işin %99’u bu değil mi diye düşünüyorum. Yanlış mı anlıyorum?
Dokümanlardaki başlangıç serisini, özellikle Workloads bölümünü okuyarak vardığım sonuç bu: https://antithesis.com/docs/getting_started/workload.html
How Antithesis Works sayfası, bunun birim testlerini sadece bir araya getirmekten nasıl farklı olduğuna yanıt verebilir: https://antithesis.com/docs/introduction/how_antithesis_works.html
Özetle, birim testleri iş yükünü oluşturmanıza yardımcı olabilir ama zorunlu değildir.
Biz farklı girdiler, arızalar vb. getirerek yazılım sisteminin yürütme yollarını otonom olarak keşfeder ve birim testi yazarının öngörmemiş olabileceği davranışları buluruz.
Ağ çağrısı yapıp sonucu diske yazan bir fonksiyon için test yazdıysanız; ağ çağrısının başarısız olması ya da süresiz takılması, disk alanının yetersiz kalması, dosyayı kapatmadan hemen önce elektriğin gitmesi gibi durumları kodunuz işleyemiyorsa test başarısız olur.
Yani evet doğru, ama birim testleri kadar kolay test edilebilen alanı çok daha ilginç bir karmaşıklık seviyesine genişletiyor.