Misi Robot Orbit NASA Mengingatkan Bahwa Automation Tetap Butuh Batas Risiko

Robot Katalyst Space yang dikirim untuk membantu NASA menaikkan orbit Neil Gehrels Swift Observatory sedang menghadapi masalah serius. Wahana LINK yang seharusnya menuju Swift mengalami kegagalan kendali, mulai berputar tidak stabil, dan kini sedang dicoba distabilkan lewat sistem cadangan.

Di permukaan, ini terdengar seperti berita teknis dari dunia antariksa. Reaction wheel gagal. Komunikasi menjadi sporadis. Thruster bermasalah. Tim misi mencoba burn menggunakan sistem lain agar putaran melambat.

Tetapi pelajarannya lebih luas dari sekadar satu robot yang kehilangan orientasi.

Banyak organisasi, termasuk bisnis di bumi, sering melihat automation sebagai cara memperpanjang umur sistem yang sudah berjalan. Kalau ada proses yang mulai terbatas, tambahkan automation. Kalau ada tim yang kewalahan, tambahkan bot. Kalau ada pekerjaan manual yang lambat, tambahkan workflow otomatis.

Kadang memang tepat.

Namun kasus ini mengingatkan satu hal sederhana: automation yang menyentuh sistem penting tidak boleh hanya dinilai dari niat baik dan potensi efisiensi. Ia harus dinilai dari kemampuan pulih saat sesuatu tidak berjalan sesuai rencana.

The Core Update

NASA untuk pertama kalinya menyewa perusahaan swasta untuk menaikkan orbit salah satu teleskop antariksa miliknya. Targetnya adalah Neil Gehrels Swift Observatory, teleskop yang diluncurkan pada 2004 dan dikenal karena kemampuannya cepat mengarah ke peristiwa antariksa singkat seperti gamma ray bursts.

Swift sudah lama bekerja melewati ekspektasi banyak orang. Namun orbitnya perlahan turun karena pengaruh tarikan Bumi. Agar observatorium ini tetap bisa beroperasi, orbitnya perlu dinaikkan.

Di sinilah Katalyst Space masuk dengan wahana LINK.

LINK diluncurkan pada 3 Juli menggunakan roket Northrop Grumman Pegasus. Setelah peluncuran, tim melakukan commissioning: mengaktifkan, menguji, dan menyiapkan sistem sebelum wahana bergerak menuju Swift.

Masalah muncul saat wahana mengalami gangguan kendali dan mulai berputar. NASA menyebut komunikasi menjadi sporadis, kemungkinan karena antena tidak selalu menghadap Bumi. Dua dari tiga reaction wheel yang mengatur orientasi wahana dilaporkan gagal. Salah satu sistem thruster juga bermasalah.

Katalyst mengatakan misi masih aktif. Tim sedang memakai set thruster lain untuk memperlambat putaran, dan perusahaan menyatakan burn yang sudah dilakukan mulai menunjukkan efek yang diinginkan.

NASA belum langsung memutuskan nasib misi. Keputusan berikutnya bergantung pada apakah wahana bisa kembali stabil dan cukup aman untuk melanjutkan rencana rendezvous dengan Swift.

The Reality Check

Secara bisnis dan teknologi, misi ini menarik karena berada di persimpangan tiga hal: urgensi, inovasi, dan risiko operasional.

Swift butuh bantuan dalam beberapa bulan. Katalyst membangun wahana dengan cepat. NASA mencoba model baru dengan memakai perusahaan swasta untuk misi peningkatan orbit teleskop. Investor dan pihak militer juga melihat potensi kendaraan seperti ini untuk servis satelit, inspeksi, dan operasi dinamis di orbit.

Semua itu masuk akal.

Tetapi masuk akal tidak sama dengan bebas risiko.

Kieran Wilson dari Katalyst bahkan pernah mengatakan sebelum misi bahwa pekerjaan ini memang menantang dan berisiko. Banyak wahana dengan siklus pengembangan lebih panjang dan pendanaan lebih besar tetap bisa gagal karena alasan yang terlihat biasa.

Kalimat itu penting karena sering hilang dalam narasi teknologi.

Kita sering terlalu cepat terpukau pada kata “robot”, “autonomous”, “private space”, atau “servicing mission”. Padahal dalam sistem nyata, nilai teknologi tidak hanya terlihat saat semua berjalan normal. Nilainya terlihat saat ada komponen gagal, komunikasi putus-putus, orientasi hilang, dan tim harus memutuskan apakah sistem masih bisa dipercaya.

Di banyak bisnis, versi kecil dari masalah ini terjadi setiap hari.

Automation dibuat untuk mengirim follow-up lead. Tetapi saat data sumber salah, pesan tetap terkirim. Dashboard dibuat untuk memberi status order. Tetapi saat input tidak konsisten, dashboard terlihat rapi namun menyesatkan. Bot support dibuat untuk mempercepat respons. Tetapi saat eskalasi tidak jelas, pelanggan justru terjebak dalam loop.

Masalahnya bukan automation itu buruk.

Masalahnya adalah automation sering dibuat dengan asumsi dunia akan rapi.

Padahal sistem yang penting harus dirancang untuk kondisi tidak rapi: data terlambat, koneksi putus, status tidak lengkap, manusia lupa update, API gagal, perangkat tidak merespons, atau keputusan harus ditunda karena risiko belum jelas.

Dalam misi orbit, kegagalan reaction wheel dan thruster adalah isu teknis besar. Dalam bisnis, padanannya bisa berupa integrasi pembayaran yang gagal, pipeline sales yang salah status, webhook yang tidak masuk, atau reminder otomatis yang terus berjalan walau konteks sudah berubah.

Bedanya hanya skala. Prinsipnya sama.

Automation tanpa fallback bukan efisiensi. Itu pemindahan risiko ke tempat yang lebih sulit dilihat.

The Havedev Way

Dari sudut pandang Havedev, berita ini bukan alasan untuk takut memakai automation. Justru sebaliknya: automation tetap penting, tetapi harus dimulai dari desain risiko yang jujur.

Sebelum membuat sistem otomatis, bisnis perlu bertanya beberapa hal sederhana.

• apa yang terjadi kalau data masuk tidak lengkap?
• siapa yang diberi tahu kalau automation gagal?
• kapan proses otomatis harus berhenti dan menunggu manusia?
• status apa yang menunjukkan sistem sedang tidak sehat?
• apakah ada jalur manual yang masih bisa dipakai?
• apakah dashboard membedakan “berhasil”, “tertunda”, dan “gagal” dengan jelas?

Pertanyaan ini terdengar tidak sekeren membuat AI agent, integrasi baru, atau dashboard real-time. Tetapi justru di sinilah kualitas sistem terlihat.

Banyak automation gagal bukan karena idenya buruk, tetapi karena tidak punya bahasa operasional untuk membaca kondisi gagal.

Sistem yang baik tidak hanya tahu cara menjalankan tugas. Ia juga tahu kapan harus berhenti, kapan harus meminta bantuan, dan kapan harus mengakui bahwa statusnya belum aman.

Untuk bisnis, ini bisa berarti hal sederhana.

Form lead tidak langsung memicu rangkaian follow-up panjang jika nomor telepon tidak valid. Automation invoice tidak menandai pembayaran selesai sebelum konfirmasi jelas. Bot support tidak terus menjawab jika pelanggan memakai kata yang menunjukkan komplain serius. Dashboard internal tidak menyembunyikan error sinkronisasi di balik angka yang terlihat normal.

Tidak semua proses butuh sistem kompleks. Tetapi proses yang dekat dengan uang, pelanggan, atau reputasi perlu punya fallback yang jelas.

Misi Katalyst dan NASA masih berjalan. Bisa saja tim berhasil menstabilkan wahana dan misi berlanjut. Bisa juga NASA memutuskan risikonya terlalu besar. Kita belum tahu hasil akhirnya.

Namun pelajarannya sudah cukup jelas.

Teknologi yang kuat bukan teknologi yang menjanjikan semuanya otomatis. Teknologi yang kuat adalah teknologi yang tetap bisa dibaca saat sedang bermasalah.

Dalam bisnis, pertanyaan terpenting sebelum menambah automation bukan hanya “apa yang bisa dibuat otomatis?”

Pertanyaan yang lebih sehat adalah: “kalau automation ini gagal, apakah tim bisa melihatnya, menghentikannya, dan mengambil alih tanpa membuat masalah lebih besar?”

Kalau jawabannya belum jelas, mulai dari sana.

---

Sumber referensi berita: TechCrunch