- Antithesis berupaya menerapkan pengujian otonom deterministik yang terbukti efektif di FoundationDB ke perangkat lunak umum, untuk mengubah bug sistem terdistribusi yang sulit direproduksi menjadi masalah yang dapat diulang
- Sebelum mengimplementasikan basis data, FoundationDB membuat simulasi single-thread dan single-process, sehingga skenario kegagalan langka dapat dijalankan ulang dengan seed acak yang sama
- Pendekatan ini menjadikan kegagalan nondeterministik seperti konkurensi, latensi dan pengurutan ulang jaringan, masalah disk, serta kegagalan mesin sebagai target pengujian; di FoundationDB, bug yang dilaporkan pelanggan dinilai hanya 1–2 kasus sepanjang masa hidupnya
- Agar perangkat lunak yang sudah ada tidak perlu ditulis ulang dari awal, Antithesis membuat hypervisor yang mengemulasikan komputer deterministik, dan saat ini berfokus pada pengujian keandalan sistem terdistribusi dan toleransi kegagalan
- Antithesis telah bekerja sama dengan MongoDB, Ethereum Foundation, dan Palantir, serta berkembang dari alat untuk menemukan bug langka menjadi layanan pengujian berkelanjutan yang terus memverifikasi build terbaru
Antithesis yang Berawal dari Pengalaman FoundationDB
- Setelah dikembangkan lebih dari 5 tahun dalam mode stealth, Antithesis memperkenalkan platform yang didasarkan pada pengalaman pengujian deterministik yang diperoleh dari FoundationDB
- Sebelum peluncuran publik, mereka telah melakukan perekrutan serta bekerja dengan pelanggan awal dan investor; inti pertama yang mereka ungkap adalah cara menguji sistem kompleks secara berulang
Masalah Verifikasi Tersulit pada Basis Data Terdistribusi
- Pada 2010, FoundationDB mulai membangun basis data terdistribusi yang skalabel dan toleran kegagalan dengan dukungan transaksi ACID
- Saat itu Spanner belum dipublikasikan, dan banyak orang salah memahami teorema CAP seolah-olah konsistensi kuat dan ketersediaan tinggi tidak mungkin dicapai bersama
- Tantangan terbesar bukanlah basis datanya sendiri, melainkan bagaimana menguji sistem seperti itu dan memperoleh keyakinan atas kebenarannya
“Unknown Unknowns” yang Terlewat oleh Pengujian Konvensional
- Perangkat lunak harus mampu menangani situasi yang tidak sempat dibayangkan pengembang sebelumnya, tetapi pengujian umum kuat dalam memverifikasi kasus yang sudah diperkirakan
- Jika sebuah kasus sudah dapat diantisipasi hingga layak dijadikan pengujian, besar kemungkinan kodenya juga telah ditulis untuk menangani situasi tersebut
- Karena itu, pengujian konvensional berguna untuk mencegah regresi, tetapi lemah dalam menangkap kegagalan tak terduga yang muncul dari pengguna nyata dan lingkungan operasional
- Pada sistem penyimpanan terdistribusi, masalah ini menjadi lebih besar
- Konkurensi terjadi sekaligus di dalam mesin dan antar-mesin
- Jaringan dapat menimbulkan latensi dan pengurutan ulang paket
- Sumber kegagalan menjadi luas, mulai dari disk, kegagalan mesin, pemadaman listrik, kebakaran pusat data, hingga kesalahan manusia
- Jika bug fatal sensitif terhadap urutan kejadian di banyak mesin, bug tersebut sulit direproduksi lagi bahkan setelah sekali ditemukan
Simulasi Deterministik FoundationDB
- Tim FoundationDB terlebih dahulu membuat simulasi jaringan berbasis event yang sepenuhnya deterministik sebelum menulis basis datanya
- Seluruh klaster disimulasikan di dalam aplikasi single-thread dan single-process, dan eksekusinya digerakkan oleh generator angka acak yang sama
- Di klaster virtual, mereka dapat menyuntikkan gangguan jaringan, mematikan mesin, dan menciptakan berbagai kondisi abnormal secara berulang
- Jika suatu eksekusi menemukan bug pada logika aplikasi, urutan kejadian yang sama dapat dijalankan ulang dengan seed acak yang sama
- Berkat ini, bahkan bug yang sangat langka pun dapat dilacak dengan menambahkan log atau mengulangi prosedur debugging
- Presentasi terkait disampaikan di Strangeloop 2014, dan videonya dapat dilihat di sini
Cara Pengujian Mengubah Kecepatan Pengembangan
- Di FoundationDB, bug yang dilaporkan pelanggan sepanjang sejarah perusahaan dinilai hanya 1–2 kasus
- Kyle Kingsbury, alias “aphyr”, tidak menguji FoundationDB dengan Jepsen karena menganggap tidak ada yang bisa ditemukan
- Ketika pengujian menjadi mampu langsung mengungkap bug baru, cara tim memprogram pun berubah
- Compiler dan sistem tipe yang kuat memberi keyakinan terhadap jenis bug tertentu, tetapi itu berbeda dari menjalankan perangkat lunak nyata dalam ribuan situasi tak terduga
- Berbekal kepercayaan ini, tim FoundationDB berani melakukan perubahan besar
- Mereka menghapus semua dependensi termasuk Zookeeper dan menulis implementasi Paxos sendiri dalam waktu singkat; implementasi tersebut dimasukkan dalam makalah FoundationDB
- Mereka menulis ulang seluruh subsistem pemrosesan transaksi agar lebih cepat dan lebih skalabel
- Dampak terbesarnya bukan hanya peningkatan stabilitas basis data, tetapi juga memberikan produktivitas setara tim 50 kali lebih besar kepada tim engineering kecil
Kekosongan yang Terlihat Setelah Akuisisi Apple
- Apple mengakuisisi FoundationDB pada 2015 dan menggunakannya sebagai fondasi “cloud infrastructure” Apple
- Beberapa tahun kemudian, FoundationDB dirilis sebagai open source
- Bahkan setelah anggota tim FoundationDB tersebar ke berbagai perusahaan teknologi besar lain, organisasi-organisasi tersebut tidak memiliki pengujian simulasi deterministik ala FoundationDB
- Perubahan pada sistem backend berjalan lambat karena dampak sistem yang tidak disengaja sulit diprediksi, sementara diagnosis dan perbaikan bug produksi menghabiskan waktu engineer senior selama berbulan-bulan
- Pada 2018, bersama Dave Scherer, Antithesis dimulai dengan tujuan menyediakan pengujian otonom deterministik ala FoundationDB kepada tim lain
Cara Membuat Perangkat Lunak yang Ada Menjadi Deterministik
- FoundationDB adalah proyek greenfield yang sejak awal dirancang untuk diuji dengan cara ini, dan dependensinya pun dapat dihilangkan
- Perangkat lunak umum membuat thread, memeriksa waktu, meminta nilai acak dari kernel, dan berkomunikasi dengan perangkat lunak lain melalui jaringan
- Karena metodologi pengembangan yang mengharuskan semua perangkat lunak ditulis ulang dari awal sulit diadopsi luas, Antithesis menulis hypervisor yang mengemulasikan komputer deterministik
- Hasilnya, perangkat lunak yang berjalan di dalam hypervisor dapat ditempatkan dalam lingkungan eksekusi deterministik
- Proses ini mencakup pekerjaan menangani perilaku tingkat rendah seperti extended page table pada CPU Intel
- Masalah menemukan pelanggaran properti di ruang status program arbitrer lebih sulit daripada halting problem, dan bahkan jika ada oracle penghentian untuk semua program, bisa saja tetap ada properti pengujian yang tidak dapat dihitung
Platform Saat Ini dan Contoh Pelanggan
- Platform Antithesis bertujuan menerima perangkat lunak pengguna, menemukan bug, dan membuat bug yang ditemukan selalu dapat direproduksi
- Mereka berupaya mempertahankan kemampuan reproduksi bahkan dalam kasus kompleks ketika banyak layanan berkomunikasi melalui jaringan
- Setelah bug ditemukan, fitur debugging yang kuat dapat diterapkan
- Dalam jangka panjang, platform ini dirancang untuk menemukan berbagai jenis bug pada beragam perangkat lunak, tetapi saat ini berfokus pada pengujian keandalan sistem terdistribusi dan toleransi kegagalan, bidang yang sudah mereka kuasai
- Selama beberapa tahun terakhir, mereka bekerja sama dengan tim engineering yang mengoperasikan sistem besar dan kompleks dengan keandalan kritis
- Mereka bekerja sama selama beberapa tahun dengan MongoDB untuk membantu menguji core server software dan WiredTiger storage engine
- Dengan Ethereum Foundation, mereka mulai bekerja sama sekitar 1 tahun sebelum Merge untuk membantu pengujian Merge, dan kerja sama masih berlanjut hingga kini
- Mereka juga bekerja sama dengan Palantir
Dari Alat Bug Langka Menjadi Layanan Pengujian Berkelanjutan
- Pelanggan awal menggunakan Antithesis seperti alat pasukan khusus untuk menemukan dan mereproduksi bug yang paling sulit ditemukan dan paling berbahaya
- Seiring platform menjadi lebih matang dan lebih interaktif, penggunaannya bergeser menjadi layanan berkelanjutan yang terus menguji build terbaru
- Tujuannya adalah mengurangi waktu antara saat bug diperkenalkan dan saat bug ditemukan
- Ketika FoundationDB dikembangkan, pendekatan ini membuat diagnosis dan perbaikan bug jauh lebih mudah, sekaligus meningkatkan efisiensi dan kualitas perangkat lunak
- Antithesis ingin berbicara dengan organisasi yang mengoperasikan sistem terdistribusi serta mementingkan keandalan dan produktivitas engineering
- Bagi orang yang ingin menangani masalah sulit, mereka mengarahkan ke lowongan kerja
1 komentar
Opini Hacker News
Rasanya istilah “developer 10x yang legendaris” sudah terdistorsi menjadi berarti orang yang bekerja 15 jam sehari, 6,5 hari seminggu, lalu burnout
Produktivitas 10x yang sesungguhnya, atau bahkan 50x, datang dari orang yang mengimplementasikan sesuatu yang hampir tak seorang pun anggap mungkin atau pahami, sehingga perangkat lunak yang berfungsi bisa dibuat dalam waktu jauh lebih singkat
Terlalu sering manajer lebih memperhatikan orang yang mengerjakan pekerjaan senilai 8 jam selama 12 jam, dibanding orang yang menyelesaikan pekerjaan yang sama dalam 8 jam
Selain itu, upaya yang menyimpang dari ‘normal’ tidak dipandang baik, dan waktu untuk memperbaiki proses juga tidak masuk jadwal; akibatnya, dalam situasi yang menganggap cukup membawa ember lebih cepat, membuat gerobak dorong justru ditekan
Jadi engineer 10x itu ada. Pada usia 30, mereka punya kira-kira 20 tahun pengalaman pemrograman, bukan 10 tahun
Pengalaman kerja mereka juga jauh lebih banyak. Walau pada usia 15 awalnya hanya pekerjaan aneh membantu kerabat sesekali, sekitar usia 18 mereka sudah masuk perusahaan profesional dan bekerja sambil belajar ilmu komputer
Setidaknya dulu begitu. Dari 2004 sampai sekitar 2018 itu nyata, tapi aku tidak tahu apakah masih mungkin dalam kondisi rekrutmen sekarang
Agar engineer 10x ada, cukup ada beberapa contoh saja. Tampaknya kebanyakan orang sepakat bahwa mereka langka, dan sebagai contoh engineer 10x yang bisa dilihat publik, orang ini bisa disebut. Ia sendiri pasti tidak akan pernah mengatakan begitu, tapi dugaanku ia adalah engineer 10x: https://bellard.org/
Kalau tidak setuju, aku penasaran bagian mana yang berbeda. Aku hanya seperti orang dalam kisah orang buta meraba gajah, hanya menyentuh sebagian, dan tidak mengklaim melihat gambaran keseluruhan
Developer tipe pasukan satu orang yang bisa melakukan semuanya sendiri tidak terlalu cocok untuk tim yang pekerjaannya distandardisasi, dipecah kecil-kecil, dan didistribusikan
Orang seperti itu paling cocok mengerjakan proyeknya sendiri tanpa rekan atau manajer yang mengganggu, tetapi kebanyakan tempat kerja tidak seperti itu
Begitu menjadi bagian dari tim, sehebat apa pun dirinya, ia tidak bisa mengerjakan terlalu banyak hal sendirian, dan akhirnya melambat karena harus menangani masalah yang dibuat anggota tim yang lebih lambat atau lebih lemah, atau masalah dari sisi manajemen. Jadi meski ada rockstar, tim bergerak dengan kecepatan penyebut bersama terendah
Fakta bahwa kami membuat tool internal dan sangat dekat dengan proses serta para pemangku kepentingan juga membantu
“Hmm, ada cara lain untuk mencapai ini” itulah yang termasuk 10x; intinya bukan melakukan lebih cepat
Mungkin ini tulisan pengantar terbaik yang pernah kubaca sejauh ini
Tulisan ini membangun landasan dengan baik tentang siapa orang-orangnya dan apa yang mereka buat, lalu menjelaskan bahwa apa yang sedang dibuat sekarang adalah hasil dari apa yang pernah mereka buat sebelumnya
Terasa seperti mereka ingin menyelesaikan masalah ini untuk semua orang, sepertinya karena mereka sendiri sudah mengalami betapa bagusnya solusi itu
Lalu mereka juga menunjukkan tim-tim yang sudah menggunakannya, termasuk nama-nama cukup besar dengan sistem yang kompleks
Semua ini dibungkus dalam tulisan yang bagus dan mengena bagi developer dan founder, dan landing page-nya juga luar biasa
Aku ingin melihat beberapa kasus penggunaan dan contoh nyata
Sebagai gantinya, mereka mencantumkan beberapa nama perusahaan besar, mengklaim produk inovatif yang bekerja seperti sihir, lalu memasukkan buzzword khas seperti ‘programmer 10x’ dan ‘stealth mode’. Menyebut nama pelanggan sambil mengatakan stealth mode itu tidak konsisten
Karena menawarkan cara hidup, cara berpikir, dan cara eksekusi yang belum pernah kualami, tulisan itu membuatku menginginkan solusinya
Tulisan yang ditautkan itu 3/4 isinya sejarah dan alasan sebelum akhirnya mengatakan apa yang sebenarnya mereka buat
Seperti blog resep yang menyebalkan: kita ingin membuat pancake vegan, tetapi penulisnya mulai dengan cerita masa kecilnya
Pitch yang bagus, dan saya tidak ingin terdengar negatif, tetapi kalimat seperti “menemukan semua bug” rasanya hanya bisa benar jika definisi bug dibuat sangat sempit
Bug paling jahat dan sulit ditemukan yang pernah saya alami sejauh ini lebih banyak berada di sekitar logika bisnis aplikasi daripada sekadar masuk ke status error
Misalnya, ketika database mencatat transaksi pelanggan sudah selesai tetapi tidak ada item pembelian yang selesai, bagaimana itu harus ditampilkan di halaman transaksi terbaru pelanggan?
Dalam kasus seperti itu, mengimplementasikan “sesuatu muncul dan tidak crash” sangat berbeda dari memastikan bahwa pilihan itu benar-benar masuk akal dalam konteks pilihan-pilihan lain di seluruh stack
Untuk database, ada juga masalah seperti “query planner membuat rencana yang sangat tidak efisien pada kasus batas ini”
Jenis seperti ini tidak mungkin dideteksi otomatis. Karena masalahnya bukan program mencapai status error, melainkan memahami apa arti ‘benar’ dalam aplikasi sejak awal
Mungkin standar saya untuk bug terlalu tinggi, tetapi membayangkan nol bug berbeda dengan membuat software di dunia nyata. Namun kalau nol runtime error, saya bisa menerimanya
Namun memang benar FoundationDB sangat terkenal karena mendorong praktik pengujian ke garis depan: https://apple.github.io/foundationdb/testing.html
Biasanya ini akan tercium arogan atau terlalu percaya diri, tetapi di sini mereka benar-benar mencapai sesuatu yang sangat dekat dengan nol bug
Tentu kita tidak bisa membuktikan proposisi negatif, tetapi fakta bahwa mereka mencapai kondisi “semua hijau” seperti itu memberi keyakinan besar bahwa mereka membangun di atas fondasi yang kokoh, dan seiring waktu terbukti memang demikian
Masalah di sekitar logika bisnis bukanlah kegagalan sistem; sistem bekerja sesuai spesifikasi, dan spesifikasinya belum cukup mencakup semuanya, jadi sekarang tinggal melakukan perbaikan iteratif
Tentu banyak software kekurangan dokumentasi, dan itu adalah bug dokumentasi
Namun alasan definisi ini bagus adalah karena meskipun dokumentasinya tidak lengkap, ia membuat kita bertanya, “apakah kita benar-benar akan mendokumentasikan perilaku ini, atau mengubah perilakunya lalu mendokumentasikan itu?”
Setidaknya bagi saya, ini membuat lebih sulit untuk begitu saja menutupi perilaku yang aneh
Sejak mengetahui bidang ini dari panduan simulasi
sledhttps://sled.rs/simulation.html, saya jadi sangat tertarik. Tulisan itu memberi gambaran umum tentang bagaimana FoundationDB melakukannyaSekarang di tempat kerja, saya sedang menulis layanan agar berjalan di atas
madsimhttps://github.com/madsim-rs/madsim?tab=readme-ov-file#madsim, untuk mencoba memperkenalkan pendekatan pengujian serupaDengan begitu, kami tetap bisa menulis layanan bergaya async/await di tokio, tetapi dalam pengujian menggantinya dengan executor deterministik yang mem-patch semua sumber nondeterminisme, termasuk dependensi yang memanggil sistem operasi. Ini berjalan cukup mulus
Penulis artikel ini tidak berlebihan ketika mengatakan biaya awalnya sangat besar. Menangani semua sumber nondeterminisme yang mungkin, serta menulis ulang layanan agar bisa diuji dan berbentuk sans-IO https://sans-io.readthedocs.io/, membutuhkan banyak upaya engineering
Namun setelah sistemnya siap, keyakinan yang Anda rasakan terhadap kode sulit dijelaskan dengan kata-kata. Jika digabungkan dengan alat seperti quickcheck https://github.com/BurntSushi/quickcheck?tab=readme-ov-file#quickcheck, Anda bisa menguji ratusan ribu kasus kegagalan halus seperti input/output, urutan event, timeout, packet loss, kegagalan filesystem, dan sebagainya
Pengujian semacam ini adalah alat yang sangat kuat untuk dimasukkan ke toolbox, jika Anda punya kesabaran dan ketekunan untuk berinvestasi
Antithesis sendiri juga terlihat sangat keren. Membawa pengujian deterministik hingga ke lapisan di bawah sistem operasi itu luar biasa, dan tampaknya akan memungkinkan pengujian seluruh sistem tanpa harus merangkai harness secara manual setiap kali. Saya tidak sabar ingin mencobanya
Sebagian besar kompleksitas yang saya lihat dalam sistem seperti itu berasal dari kenyataan bahwa pemanggilan “fungsi” bersifat asinkron, bergantung pada sistem operasi, mungkin dieksekusi suatu saat nanti atau tidak sama sekali, mengembalikan sekumpulan string yang harus di-parse agar bisa masuk kembali ke sistem tipe statis, dan memiliki mode kegagalannya sendiri
Hal yang tampak sederhana, yaitu mengabstraksikan logika menjadi komponen bernama—fungsi—menjadi sangat kompleks
Jika logikanya tetap berada dalam proses yang sama dan kita hanya memanggil fungsi, kegagalan-kegagalan halus yang disebutkan tadi tidak perlu diuji
Monolith tidak selalu merupakan pilihan yang baik atau tepat, tetapi saya sangat skeptis apakah tren arsitektur software berbasis layanan saat ini memang dapat dibenarkan dan sepadan dengan imbalannya
Saya juga penasaran apakah ada perusahaan yang menggunakan Rust dan mengembangkan dengan cara seperti ini
Sebagai tambahan, TigerBeetle juga merupakan produk yang ditulis dengan cara seperti ini
madsimatau pengujian simulasi deterministik untuk aplikasi JavaTulisannya benar-benar menarik
Kalau bisa menuliskan kalimat seperti “Memprogram dalam kondisi seperti ini ibarat hidup dikelilingi medan gaya yang melindungi dari segala bahaya… Karena ada bug, kami menghapus semua dependensi termasuk Zookeeper, lalu dalam waktu sangat singkat menulis sendiri implementasi Paxos, dan implementasi itu tidak memiliki bug” dan mendukungnya dengan bukti, itu pasti sangat keren.
Di buku itu disebutkan bahwa karena bug dalam paket perangkat lunak numerik, saat mencoba menyelesaikan masalah sendiri ia jadi harus men-debug perangkat lunak orang lain, dan itu sangat membuat frustrasi; maka selain paket aljabar linear, biasanya ia membuat sendiri.
Hal yang lebih merepotkan, menurutnya, adalah paket menyembunyikan cacat dalam perumusan masalah. Jika sekumpulan persamaan dimasukkan ke solver, meski kondisinya buruk atau ada singularitas tak terduga sehingga jawabannya melenceng dari realitas fisik, solver biasanya tetap mengeluarkan solusi tanpa protes; dan jika itu terkubur di dalam program besar, kemungkinan seperti itu bisa membuat kita mengabaikannya.
Bahkan ketika perilaku mencurigakan ditemukan, sulit masuk ke dalam paket untuk menelusuri masalahnya, sehingga pada akhirnya harus memprogram ulang sendiri; kalau sejak awal melakukannya begitu, kemungkinan besar kita sudah masuk lebih dalam ke realitas masalah dan menyingkirkan kekacauan logis lebih dini.
Pada akhirnya, apakah akan melakukan ini bergantung pada seberapa ketat Anda sendiri, seberapa ketat dependensi tertentu, dan berapa banyak waktu yang tersedia. Saya tidak akan menulis database sendiri, karena itu terlalu kompleks dan ada banyak pilihan yang sudah teruji baik. Sebaliknya, jika hanya memakai sebagian fitur dari paket kecil yang pengujiannya lemah, membuat sendiri bisa masuk akal.
Namun saya tidak mengklaim bahwa spesifikasi saya tidak memiliki bug.
Ada tiga pemikiran yang muncul.
Pertama, ini ide bagus yang muncul pada waktu yang tepat. Melihat sentimen developer terhadap fuzzer, static typing, memory safety, protokol terstandar, container, dan sebagainya, rasanya orang-orang akhirnya mulai kehabisan kesabaran terhadap perangkat lunak yang tidak stabil.
Kedua, tampaknya ini menargetkan pasar niche. Biayanya 2 dolar per CPU per jam, 7000 dolar per CPU per tahun jika reservasi, tidak ada tier gratis untuk hobi atau free/open source, dan untuk mencoba atau membeli pun harus menghubungi mereka. Ini model bisnis yang menyakitkan tetapi valid. Hanya saja agak disayangkan karena tidak mengejar dampak positif sebesar mungkin.
Ketiga, kualitas tulisan dan dokumentasinya tinggi, dan saya sangat suka adanya kalimat seperti “Jika bug ditemukan di produksi atau oleh pelanggan, Anda harus meminta penjelasan kepada kami” di dokumentasinya.
Beginilah cara mendapatkan simpati developer. Ini mengingatkan saya pada Mullvad, yang masih saya rekomendasikan kepada orang-orang meski dulu pernah mengecewakan saya.
Hal itu disebutkan di https://news.ycombinator.com/item?id=39358526. Sebagai catatan, saya adalah co-founder Antithesis.
Hardware pun bisa mulai menambahkan fitur untuk mendukungnya, dan 30 tahun lagi mungkin ini akan menjadi cara komputasi bekerja begitu saja.
Namun sebelum para pelopor benar-benar menyebarkannya, mereka harus lebih dulu menutup biaya anak panah yang pertama mengenai mereka. Ini harus dilihat bukan sebagai satu peristiwa, melainkan sebagai awal dari sebuah proses.
Dari dokumentasinya, bug yang dirancang untuk ditemukan platform ini adalah jenis bug liar yang jarang terjadi di produksi dan “tidak bisa direproduksi”.
Sebagian besar tim masih harus memperbaiki masalah yang jauh lebih besar dan bug yang jelas. Faktanya, kebanyakan perangkat lunak produksi saat ini bahkan hampir tidak punya unit test.
Saya penasaran bagaimana biayanya berlipat dalam kasus penggunaan nyata.
Saya bertemu Antithesis di Strangeloop tahun ini dan berbicara dengan para karyawannya. Dibandingkan dengan kondisi terkini injeksi kegagalan otomatis yang saya ikuti saat bekerja di Amazon sekalipun, menurut saya produk ini adalah lompatan besar dibanding banyak sistem verifikasi formal yang digunakan saat ini.
Saya benar-benar bisa mengikuti proses pelacakan bug dari isu yang mereka temukan di Apache Spark streaming. Berdasarkan dokumentasinya, mereka menemukan kesalahan correctness yang halus dan ganas dalam pekerjaan umum, jenis edge case dengan visibilitas rendah yang akan menjadi masalah bertahun-tahun.
Pada akhirnya, kasus itu berakhir dengan dokumentasinya yang salah, tetapi setelah melihat prosesnya, sulit membayangkan betapa pentingnya alat seperti Antithesis bagi perusahaan yang membangun sistem terdistribusi.
Semoga segera ada tulisan blog yang masuk jauh ke detail teknis. Saya ingin mendengar bagaimana mereka sampai pada pendekatan saat ini.
Saya tidak ingin langsung ikut dalam siklus ekspektasi yang terlalu panas, tetapi ini terdengar seperti cawan suci. Bukankah kita bisa memakai aplikasi yang sudah ada apa adanya, dan dengan asumsi sudah ter-container, cukup memeriksa properti di atasnya?
Titik yang selalu menjadi penghalang adalah fondasi mesin, yaitu CPU dan sistem operasi yang nondeterministik.
Karena hampir mustahil membangun ulang seluruh stack komputasi vertikal, mereka tampaknya menghindari masalah itu dengan membuat simulator deterministik berfidelitas tinggi.
Namun saya penasaran bagaimana mereka memeriksa ekuivalensi antara simulator dan sistem operasi yang ada. Kedengarannya bukan pekerjaan sepele. Meski begitu, saya cukup yakin dengan ide ini.
Setelah itu, mereka menjalankan pengujian sambil menyuntikkan segala macam kegagalan, seperti kegagalan sistem operasi, masalah jaringan, race condition dan kondisi timing, masalah random number generator, dan lain-lain.
Besar kemungkinan ini adalah satu-satunya cara praktis saat ini untuk menguji hal-hal seperti itu secara andal, tetapi Anda tetap harus menulis semua pengujiannya dan mendefinisikan status aplikasi.
Katanya ini adalah “platform yang menerima perangkat lunak lalu memburu bug di dalamnya”, jadi sebenarnya ini apa?
Kelihatannya seperti layanan cloud yang menjalankan integration test. Sepertinya kita harus mencari tahu cara men-deploy ke lingkungan khusus ini, dan tetap harus menulis integration test menggunakan pustaka khusus.
Tapi bahkan setelah melakukan semua refactoring integrasi itu, saya tidak mengerti bagaimana ia bisa menemukan bug nyata yang sebelumnya belum ditemukan oleh integration test saya di lingkungan saya sendiri.
Namun Antithesis tidak mengharuskan pengujian manual atau penulisan integration test.
Anda perlu memaketkan sistem perangkat lunak ke dalam container, yang relatif sederhana, lalu menulis workload yang meniru operasi normal sistem. Misalnya untuk situs e-commerce: melihat produk, menambahkan ke keranjang, melakukan pembayaran, dan sebagainya.
Berdasarkan itu, Antithesis menjalankan workload, mengubah input, menyuntikkan kegagalan, lalu mulai menguji perangkat lunak dan mencari pelanggaran properti pengujian.
Lebih dari 60 properti pengujian tersedia secara bawaan, seperti crash dan kehabisan memori. Untuk lebih mengekspos masalah yang spesifik pada sistem, Anda juga bisa—dan pada praktiknya memang harus—mendefinisikan properti kustom.
Saat pengujian berjalan, pelanggaran properti dilaporkan, beserta banyak informasi debug yang berguna. Eksekusi pengujian yang sangat menarik khususnya bisa dianalisis lebih jauh karena dapat di-rewind, inputnya diubah, artefaknya diambil, logging ditambahkan, dan sebagainya.
Sejauh ini hanya itu yang saya tahu. Saya menduga ada semacam fuzzing dan analisis statis, atau definisi tindakan yang dapat dilakukan perangkat lunak.
Terus terang, ini tampak banyak tumpang tindih dengan hal yang ingin diselesaikan oleh bahasa Vale: https://vale.dev/
Hanya saja, alih-alih membuat bahasa baru agar perangkat lunak baru secara bawaan berada dalam kondisi seperti itu, mereka tampaknya berfokus membuat perangkat lunak yang sudah ada menjadi sedekat mungkin dengan kondisi tersebut.
Dengan menggunakan hypervisor, mereka mengubah seed acak, membuat permintaan HTTP gagal atau berjalan lama, memutus koneksi antarserver, mengubah urutan respons server, dan menciptakan berbagai hal yang biasanya tidak bisa Anda kendalikan tetapi terjadi di dunia nyata.
Lalu mereka membandingkannya dengan respons workload yang diharapkan untuk mencari kondisi apa yang merusak sistem.
Itu sebabnya mereka menjualnya sebagai kontrak tahunan. Strukturnya adalah Anda membayar agar workload terus dijalankan sepanjang tahun dan mencoba segala kombinasi kegagalan.
Saya sangat menantikannya dan sempat membaca sekilas dokumentasinya, tetapi saya tidak terlalu paham bedanya ini dengan unit test yang diacak.
Kalau sudah punya kumpulan unit test, bukankah itu 99% pekerjaannya? Apakah saya salah paham?
Ini kesimpulan saya setelah membaca seri getting started di dokumentasi, terutama bagian Workloads https://antithesis.com/docs/getting_started/workload.html
Halaman How Antithesis Works mungkin bisa menjawab bagaimana ini berbeda dari sekadar menggabungkan unit test: https://antithesis.com/docs/introduction/how_antithesis_works.html
Ringkasnya, unit test bisa membantu menyusun workload, tetapi tidak wajib.
Kami secara otonom menjelajahi jalur eksekusi sistem perangkat lunak dengan memperkenalkan input, kegagalan, dan lain-lain yang berbeda, lalu menemukan perilaku yang mungkin tidak pernah diantisipasi oleh penulis unit test.
Jika Anda menulis test untuk fungsi yang melakukan panggilan jaringan lalu menulis hasilnya ke disk, test akan gagal jika kode tidak bisa menangani kasus seperti panggilan jaringan gagal atau macet tanpa batas, ruang disk habis, atau listrik padam tepat sebelum file ditutup.
Jadi ya, memang benar, tetapi ini memperluas ruang yang bisa diuji semudah unit test ke tingkat kompleksitas yang jauh lebih menarik.