Rekayasa Perangkat Lunak Saat Server Tidak Bisa di-Reboot

Web server Anda crash jam 3 pagi. Kubernetes me-restart-nya. Pengguna melihat halaman error sebentar. Tidak ada yang kena pecat. Sekarang bayangkan server Anda mengorbit Mars, proses restart-nya memakan waktu 45 menit (selama itu tidak ada kontrol sikap, tidak ada pengaturan termal, dan tidak ada komunikasi), “pengguna”-nya adalah pesawat antariksa senilai $2,5 miliar, dan tidak ada Kubernetes sama sekali, hanya kode Anda dan CPU tahan radiasi yang menjalankannya.

Software antariksa beroperasi di bawah batasan yang membuat rekayasa perangkat lunak biasa terasa santai. Anda tidak bisa deploy hotfix. Anda tidak bisa SSH masuk dan mengecek log. Anda tidak bisa menambah server saat beban naik. Setiap baris kode harus benar sebelum peluncuran, karena setelah diluncurkan, software itu harus berjalan sendiri selama bertahun-tahun atau bahkan puluhan tahun, di atas hardware yang perlahan rusak akibat radiasi, dengan tautan komunikasi yang punya jeda beberapa menit dan bandwidth hanya beberapa kilobit per detik.

Batasan yang Membentuk Segalanya

Radiasi. Di luar angkasa, partikel berenergi tinggi terus-menerus menghantam komponen elektronik. Satu partikel saja bisa membalik satu bit di memori (disebut single-event upset, atau SEU), merusak isi register, atau membuat prosesor freeze. Ini bukan kejadian langka. Satelit LEO mengalami ribuan bit flip per hari. Hardware kelas antariksa memakai komponen tahan radiasi yang lebih lambat, lebih mahal, dan tertinggal beberapa generasi dari hardware konsumen. Prosesor di rover Mars Perseverance adalah RAD750, kira-kira setara PowerPC era 1998 yang berjalan di 200 MHz.

Jeda komunikasi. Mars berjarak 4 sampai 24 menit dengan radio (tergantung posisi orbitnya). Jupiter 33 sampai 54 menit. Ini bukan sekadar latency. Artinya, pesawat harus menangani masalah secara mandiri setidaknya selama waktu bolak-balik sinyal, sebelum kontrol di Bumi bahkan bisa melihat masalahnya, apalagi mengirim perintah. Ketika probe Voyager menghadapi anomali pada jarak lebih dari 22 jam cahaya dari Bumi, software-nya mengambil keputusan sendiri selama hampir dua hari.

Tidak ada akses fisik. Anda tidak bisa mengganti komponen yang rusak, menambah RAM, atau mengganti hard drive. Jika komputer utama mati dan cadangannya juga tidak berfungsi, misinya selesai. Setiap mode kegagalan harus sudah diantisipasi di level software sebelum peluncuran.

Bedanya Kode Antariksa

Software antariksa memakai teknik yang di pengembangan software biasa akan dianggap over-engineering yang konyol.

Triple modular redundancy (TMR). Komputasi krusial dijalankan tiga kali di tiga prosesor independen. Sebuah voter membandingkan ketiga hasilnya dan memakai jawaban mayoritas. Jika satu prosesor menghasilkan jawaban salah akibat radiasi, dua lainnya akan mengalahkannya lewat voting. Beberapa sistem bahkan menjalankan lima salinan (pentuple redundancy) untuk jaminan ekstra.

Memory scrubbing. Sebuah proses latar belakang terus-menerus membaca memori, mengeceknya dengan error-correcting code (ECC), dan memperbaiki error satu bit sebelum menumpuk menjadi error multi-bit yang tidak bisa diperbaiki. Proses ini berjalan terus. Setiap byte memori dicek dan dikoreksi beberapa kali per detik.

Watchdog timer. Timer hardware yang harus di-reset secara berkala oleh software. Jika software hang (mungkin karena lockup akibat radiasi), timer habis dan memicu reset hardware. Software harus dirancang agar bisa bertahan dari reboot tak terduga di titik mana pun dalam eksekusinya. Komputasi apa pun bisa terputus dan harus dimulai ulang.

// Simplified space software patterns
// Watchdog — must be kicked regularly or hardware resets
void main_loop(void) {
while (1) {
kick_watchdog();  // Reset the timer — we're alive
// All operations must complete within watchdog timeout
read_sensors();
kick_watchdog();
run_attitude_control();
kick_watchdog();
check_thermal_limits();
kick_watchdog();
process_ground_commands();
kick_watchdog();
}
}
// Critical value stored with redundancy
typedef struct {
int32_t value_a;  // Primary copy
int32_t value_b;  // Redundant copy
int32_t value_c;  // Third copy for voting
} RedundantInt;
int32_t read_redundant(RedundantInt *r) {
// Majority vote — tolerates one corrupted copy
if (r->value_a == r->value_b) return r->value_a;
if (r->value_a == r->value_c) return r->value_a;
if (r->value_b == r->value_c) return r->value_b;
// All three differ — flag anomaly
raise_anomaly(MEMORY_CORRUPTION);
return r->value_a;  // Best guess
}

Pengujiannya Adalah Produknya

Jet Propulsion Laboratory milik NASA memperkirakan bahwa pengujian software antariksa memakan 60-80% dari total usaha pengembangan. Bukan 60% waktu, tapi 60% dari total biaya. Pengujiannya lebih mahal daripada pengembangannya, karena pengujian harus membuktikan kebenaran sampai tingkat yang bahkan tidak didekati oleh pengujian software biasa.

Setiap jalur kode harus diuji. Bukan “code coverage tinggi” seperti yang dimaksud web developer. Maksudnya benar-benar setiap jalur di setiap fungsi, termasuk jalur error, jalur timeout, dan jalur yang menangani kegagalan hardware. Branch coverage 100% itu titik awal, bukan tujuan akhir.

Selain unit test, software antariksa juga menjalani hardware-in-the-loop testing (menjalankan software asli di hardware penerbangan asli sambil mensimulasikan lingkungan antariksa), stress testing durasi panjang (berjalan berbulan-bulan untuk menemukan bug yang bergantung pada timing), dan fault injection testing (sengaja merusak memori, mematikan prosesor, dan memutus tautan komunikasi untuk memastikan software bisa pulih).

Formal verification semakin sering dipakai untuk komponen yang paling kritis. Alih-alih menguji bahwa kode bekerja untuk input tertentu, formal verification membuktikan secara matematis bahwa kode bekerja untuk semua input yang mungkin. Ini mahal dan lambat, tapi untuk kode yang mengatur sikap (orientasi) pesawat atau mengelola propulsinya, biayanya terbayar.

Yang Tetap Bisa Salah

Meski sudah sedemikian ketat, software antariksa tetap gagal. Kegagalan-kegagalannya penting untuk dipelajari karena memperlihatkan batas dari rekayasa paling hati-hati sekalipun.

• Mars Climate Orbiter (1999) hancur karena satu tim memakai satuan imperial dan tim lain memakai metrik. Software-nya benar, yang salah adalah spesifikasinya. Tidak ada jumlah pengujian yang bisa menangkap spesifikasi yang keliru.
• Ariane 5 Flight 501 (1996) meledak karena nilai float 64-bit dikonversi ke integer 16-bit dan overflow. Kodenya dipakai ulang dari Ariane 4, di mana nilai tersebut tidak pernah melebihi rentang 16-bit. Kode itu benar untuk Ariane 4 dan salah secara fatal untuk Ariane 5.
• Mars Polar Lander (1999) kemungkinan jatuh karena getaran sensor saat kaki pendarat dibuka ditafsirkan sebagai sentuhan tanah, sehingga mesin mati pada ketinggian 40 meter. Ini masalah interpretasi sensor yang bergantung pada timing, dan tidak tertangkap oleh pengujian karena tes tidak mereplikasi karakteristik getaran secara sempurna.
• Cacat cermin awal Hubble (1990) bukan bug software. Cerminnya digerinda ke bentuk yang salah karena instrumen pengujian yang salah kalibrasi. Alat ujinya sendiri yang punya bug.

Benang merahnya: kodenya benar sesuai spesifikasinya, tapi spesifikasinya tidak sesuai dengan kenyataan. Ini jenis bug yang paling sulit dicegah, karena ia ada di celah antara model dan dunia nyata.

Yang Bisa Dipelajari Software di Bumi

Kebanyakan dari kita tidak menulis software antariksa. Tapi beberapa praktiknya bisa langsung diterapkan untuk membangun sistem yang andal di Bumi.

Rancang untuk restart. Software antariksa mengasumsikan ia bisa di-reboot kapan saja dan harus pulih ke kondisi yang sudah diketahui baik. Layanan web juga harus punya sifat ini. Kalau server Anda crash dan restart, apakah ia pulih tanpa intervensi manual? Apakah ia melanjutkan pemrosesan dari titik terakhir, atau kehilangan pekerjaan? Pola defensive engineering yang dianggap wajib oleh insinyur antariksa sering dianggap opsional di web development, padahal seharusnya tidak.

Uji mode kegagalan, bukan cuma jalur bahagia. Pengujian software antariksa secara khusus menyuntikkan kegagalan: mematikan proses, merusak memori, memutus koneksi jaringan, dan mengembalikan kode error dari setiap system call. Kebanyakan pengujian aplikasi web hanya fokus pada apakah fitur berjalan, bukan apakah sistem menangani kegagalan dengan baik.

Redundansi untuk data kritis. Jika aplikasi Anda menyimpan data yang mahal untuk dibuat ulang, seperti catatan keuangan, konten pengguna, atau state konfigurasi, simpan secara redundan dan verifikasi secara berkala. Replikasi database adalah contoh yang paling jelas, tapi redundansi di level aplikasi (checksum, validasi, pengecekan integritas berkala) bisa menangkap korupsi yang justru ikut tereplikasi.

Watchdog untuk proses kritis. Jika sebuah proses tidak boleh hang, pantau. Bukan sekadar “apakah prosesnya jalan”, tapi “apakah prosesnya benar-benar bergerak maju”. Health check yang memverifikasi bahwa sistem benar-benar berfungsi, seperti memproses request, memperbarui state, dan memenuhi deadline, bisa menangkap kegagalan yang terlewat oleh monitoring level proses.

Software Antariksa Generasi Baru

Industri antariksa komersial (SpaceX, Rocket Lab, Planet) sedang menantang sebagian tradisi ini. SpaceX memakai Linux dan C++ di flight computer Falcon 9-nya, yang menurut standar aerospace tradisional itu dianggap sesat. Planet Labs mengoperasikan ratusan satelit kecil dan memperlakukannya lebih seperti sistem terdistribusi ketimbang hardware buatan khusus. Jika satu satelit gagal, konstelasinya yang mengompensasi.

Pergeseran ini mencerminkan pertanyaan yang lebih luas: seberapa andal sebenarnya yang Anda butuhkan? Rover Mars senilai $2,5 miliar layak mendapat lima tahun pengujian. Satelit komunikasi seharga $500.000 yang hanya salah satu dari ratusan dalam konstelasi tidak perlu sebanyak itu. Praktik engineering harus menyesuaikan dengan profil risikonya, bukan mengikuti tradisi buatan era lain secara membabi buta.

Tapi pelajaran intinya tetap berlaku apa pun anggarannya: software yang tidak bisa diakses secara fisik setelah deployment harus lebih andal daripada software yang bisa. Entah Anda meluncurkan pesawat antariksa, deploy ke armada IoT, atau menjalankan jaringan edge computing, prinsipnya sama. Kalau Anda tidak bisa SSH masuk dan memperbaikinya, software-nya harus bisa menangani sendiri. Pola pikir ini, diterapkan dengan bijak, membuat semua software jadi lebih baik.