Kesalahan Saya pada Rover Mars Senilai 500 Juta Dolar

• Pada Februari 2003, di cleanroom JPL, Spirit Mars Rover tinggal 2 minggu lagi sebelum dikirim ke lokasi peluncuran, dan satu kesalahan koneksi break-out-box bisa saja merusak wahana antariksa senilai 500 juta dolar
• Spirit dan Opportunity adalah misi rover Mars kembar yang hampir menelan biaya 1 miliar dolar dari NASA, dan jadwalnya nyaris tidak memberi ruang untuk memulihkan kerusakan besar
• Tepat setelah pulsa listrik masuk ke arah wahana antariksa, bukan ke motor, telemetri terputus, tetapi apakah ada kerusakan dan apa penyebabnya belum bisa langsung dipastikan
• Keesokan harinya, terputusnya telemetri dipastikan disebabkan oleh pelepasan lead multimeter Fluke 87III, sementara lonjakan listrik sebenarnya tetap menjadi objek analisis pada channel driver motor H-Bridge
• Setelah analisis selama beberapa minggu, proyek memutuskan hardware tersebut Use As Is, memperbaiki prosedur, lalu terus menjalankan pengujian yang sama; motor terkait pada Spirit berfungsi normal di Mars

---

Insiden pengujian pada Spirit tepat sebelum peluncuran

• Pada Februari 2003, di cleanroom Building 179 High Bay 1 milik NASA JPL, Spirit Mars Rover tinggal 2 minggu lagi sebelum dikirim ke Cape Canaveral
• Spirit dan Opportunity adalah misi rover Mars kembar, wahana antariksa kompleks yang saat itu hampir menelan investasi 1 miliar dolar dari NASA
• Pada tahap perakitan dan pengujian, sebelum wahana antariksa ditutup untuk terakhir kalinya di Bumi, semua sistem harus diuji secara menyeluruh dan dipastikan berfungsi normal
• Kedua rover itu memiliki total 62 motor brushed-type
  • Penggerak dan kemudi roda
  • Kontrol lengan robot
  • Pembidikan kamera
  • Pengarahan antena ke Bumi
  • Gerakan pembukaan dan deployment setelah pendaratan
• Objek pengujian malam itu adalah motor RAT-Revolve di dalam Rock Abrasion Tool(RAT) pada ujung lengan robot Spirit
  • Motor RAT-Revolve bertugas memutar grinder dan brush di atas batuan Mars

Prosedur memeriksa kondisi motor lewat sinyal listrik

• Membongkar motor dan memeriksa bagian dalamnya setelah setiap pengujian lingkungan tidaklah praktis
• Sebagai gantinya, motor dipisahkan dari wahana antariksa lalu dihubungkan ke catu daya eksternal dan strip chart recorder untuk memeriksa kinerja listriknya
• Pada motor normal, arus saat spin-up turun mulus dalam bentuk eksponensial, sedangkan jika ada anomali akan muncul blip pada sinyal
• Pengujian menggunakan break-out-box, dan jika koneksinya salah, arus besar dapat masuk ke tempat yang keliru dan menyebabkan kerusakan fatal
• Pada pemeriksaan awal, antarmuka koneksi, pengaturan catu daya, pengaturan strip chart, dan pulsa uji singkat pada motor referensi semuanya dipastikan normal

Pulsa listrik yang masuk ke arah yang salah

• Saat energi dikirim ke motor RAT-Revolve, strip chart menampilkan sinyal yang tidak familiar dan juga berbeda dari sinyal khas motor rusak
• Setelah menelusuri kabel, diketahui bahwa karena kesalahan break-out-box, pulsa listrik tidak masuk ke motor, melainkan ke arah berlawanan pada antarmuka konektor, yaitu ke sisi wahana antariksa
• Spirit tinggal dua minggu lagi sebelum dikirim untuk persiapan peluncuran, sehingga jika muncul masalah besar, tidak ada waktu untuk memulihkannya
• Insiden itu segera dilaporkan kepada test conductor Leo, dan pada saat yang sama datang respons bahwa telemetri dari wahana antariksa terputus
• Tim langsung menjalankan prosedur shutdown darurat, lalu diperintahkan keluar dari cleanroom untuk menilai kronologi insiden dan kerusakan

Hilangnya telemetri dan penilaian awal

• Segera setelah insiden, ada dua fakta yang terkonfirmasi
  • Pulsa listrik besar masuk ke tempat yang tidak dimaksudkan
  • Telemetri wahana antariksa berhenti
• Keterkaitan antara kedua peristiwa itu belum langsung jelas
• Tim menilai kemungkinan besar lonjakan listrik masuk ke rangkaian driver motor H-Bridge
  • H-Bridge diperlakukan sebagai rangkaian yang mengendalikan aliran listrik
  • Karena back-EMF, bagian ini termasuk salah satu bagian rover yang dirancang untuk menahan energi tambahan
• Wahana antariksa sudah dalam keadaan mati, dan tim memutuskan untuk memeriksa apakah masalahnya teratasi dengan menyalakan daya kembali
• Menjelang tengah malam, laporan insiden bahkan sudah sampai ke manajer proyek Pete, dan ada kemungkinan penjadwalan ulang proyek berskala sekitar 1.000 orang

Reboot gagal dan penyebab sebenarnya ditemukan keesokan hari

• Prosedur standar penyalaan daya wahana antariksa dijalankan lagi, tetapi bahkan setelah perangkat elektronik dan software aktif, telemetri tidak kembali
• Pada rack ground support equipment ada lampu indikator merah yang menyala saat menerima pulsa pada setiap clock cycle, digunakan seperti detak jantung robot sebanyak 8 kali per detik
• Catu daya menunjukkan tahapan tegangan dan perubahan arus yang familiar, tetapi lampu indikator tidak menyala dan telemetri juga tidak keluar
• Keesokan harinya, saat urutan kejadian ditinjau kembali, multimeter digital Fluke 87III menjadi petunjuk kunci
• Pada hari sebelumnya, saat mencari multimeter yang diperlukan untuk pengujian, lead dari sebuah multimeter yang tampak memantau tegangan bus di dekat wahana antariksa dilepas
  • Multimeter ini sebenarnya sedang melengkapi rangkaian daya telemetri pengujian darat wahana antariksa
  • Saat lead dilepas, koneksi daya telemetri terputus

Spirit masih hidup, dan hardware digunakan apa adanya

• Tim mengembalikan multimeter ke peran semulanya dan menyalakan kembali daya wahana antariksa
• Telemetri kembali hidup, dan dipastikan bahwa Spirit belum mati
• Kerugian sebenarnya hanya sekitar beberapa jam, dan pengujian dilanjutkan
• Selama beberapa minggu berikutnya, channel H-Bridge motor RAT-Revolve dianalisis, dan diskusi rinci berlanjut mengenai kemungkinan thin-film demetallization
• Pada akhirnya proyek memutuskan hardware tersebut Use As Is
• Persiapan peluncuran rover berlanjut, dan setelah Spirit tiba di Mars, motor RAT-Revolve berfungsi normal

Cara menangani pengalaman kegagalan

• Insiden ini mengarah pada keyakinan bahwa berbagi pengalaman kegagalan dapat menjadi pembelajaran baik bagi orang yang bercerita maupun yang mendengarkan
• Di Planetary Resources, dalam proses rekrutmen dan budaya tim, kandidat diminta membagikan failure story mereka
• Di tengah krisis, Ernie berkata, “Saat nanti Anda harus menyetujui bahwa sesuatu baik-baik saja, ingatlah perasaan ini”
• Setelah insiden, sebagian orang berpendapat bahwa pengujian berisiko harus dihentikan, tetapi karena pentingnya pengujian untuk memastikan apakah motor akan berfungsi normal di Mars, pengujian tetap dilanjutkan
• Manajer proyek Pete membiarkan orang yang sama terus memimpin pengujian, dengan penilaian bernada “kita sudah membayar biaya pendidikannya, dan dialah orang yang paling kecil kemungkinannya mengulangi kesalahan ini”
• Setelah itu prosedur diperbaiki agar kesalahan yang sama tidak terulang, dan pengujian yang sama dilakukan kembali berkali-kali
• Pengalaman ini menjadi tolok ukur yang mengingatkan pada rasa takut dan penyesalan saat itu ketika harus memberikan persetujuan atau jaminan penting

[GN⁺]

Opini Hacker News

• Tulisannya benar-benar bagus
  Sebagai insinyur perangkat lunak, saya masih teringat kejadian serupa yang saya alami di awal karier. Sekitar 10 tahun lalu, saya menghabiskan beberapa bulan membangun versi baru layanan web untuk klien konsultasi, dan pada hari rilis saya bertanggung jawab atas deployment. Saat itu prosedur pengembangan dan deployment hampir sepenuhnya manual. Bagian yang bisa diotomatisasi saya buat dengan skrip dan SQL, lalu saat menekan Enter untuk melakukan pengujian terakhir tepat sebelum deployment, saya sadar bahwa saya baru saja menggantinya ke kredensial produksi
  Ketika error menumpuk dan layanan tidak merespons, saya yakin saya telah menghancurkan databasenya. Namun berkat seseorang yang beberapa jam sebelumnya sudah menyelesaikan backup untuk persiapan rilis, sebagian besar berhasil dipulihkan. Sejak itu, saat menangani database dan sistem produksi, kata hati-hati saja rasanya tidak cukup, dan saya bertekad tidak akan pernah mengulanginya

  • Kami juga memakai arsitektur event sourcing, jadi jarang sekali mengakses database produksi secara langsung. Saat diperlukan, kami membuka tunnel melalui bastion host dengan shell script, lalu mengekspos variabel lingkungan standar untuk konfigurasi klien Postgres
    Test suite kami, saat berjalan, menghapus lalu membuat ulang atau mengosongkan tabel. Suatu hari lead developer menjalankan make test setelah melakukan eksplorasi perbaikan bug di DB produksi. Kode test mengikuti variabel lingkungan apa adanya, sehingga terhubung ke produksi, bukan Docker, dan segera menghapus serta membuat ulang tabel-tabel produksi itu puluhan kali
  • Sekitar 10 tahun lalu di tempat saya berkonsultasi, seorang staf internal yang menangani produk lain login ke DB development dan DB produksi secara bersamaan di jendela berbeda, lalu keliru menghapus database produksi. Saat hendak memulihkan, ternyata backup sudah gagal selama berbulan-bulan, dan jadi jelas kenapa mereka mempekerjakan konsultan untuk membantu produk baru
    Untungnya, tiap situs pelanggan memiliki DB lokal yang disinkronkan dengan DB pusat, sehingga produk tetap berjalan meski koneksi terputus. Ia bekerja panjang selama 3–4 hari, menggabungkan backup lama dan data pelanggan untuk membangun ulang master DB
  • Saya pernah menjalankan migrasi ke database produksi dari dalam Visual Studio. Kalau dipikir lagi, itu sebenarnya bisa dipulihkan, tetapi saat semua tabel mulai menghilang dari tampilan tree di VS, rasanya jantung saya berhenti
    Satu detik kemudian semuanya muncul lagi; ternyata hanya view yang sedang di-refresh. UI yang benar-benar mengerikan
  • Sekitar 15 tahun lalu, saat bersiap pulang menjelang akhir pekan panjang, seorang teman dari marketing meminta perubahan cepat di situs pelanggan. Perusahaannya kecil, sekitar 15 orang, dan jumlah pelanggan terlalu banyak untuk kami tangani, jadi saya punya hak akses database produksi yang seharusnya tidak saya miliki
    Untuk mengubah teks marketing produk, saya menulis kueri UPDATE singkat. Begitu kueri itu tidak langsung selesai, saya tahu saya sudah kacau: tanpa kondisi, seluruh data diperbarui dan ribuan deskripsi produk berubah. Admin DB yang punya akses backup berada di zona waktu lain dan sudah pulang. Setelah lebih dari satu jam menelepon, kami akhirnya bisa memulihkannya
    Perubahan cepat saat hendak keluar kantor berubah menjadi penanganan masalah berjam-jam. Teman marketing saya terus meminta maaf, tetapi kesalahannya milik saya. Menurut saya tidak ada keluhan dari pelanggan karena saat itu Jumat pukul 5 sore pada akhir pekan hari libur
  • Sekitar 20 tahun lalu di tempat saya bekerja, ada kebijakan bahwa saat menjalankan perintah sudo, orang lain harus memeriksa perintahnya sebelum Enter ditekan. Kebijakan atau kebiasaan serupa bisa diterapkan untuk semua hal yang dilakukan di produksi

• Saya teringat kalimat: jika seorang intern menghapus database produksi, itu bukan intern yang buruk, melainkan proses yang buruk
  Apakah ini masalah proses atau masalah manusia sulit dinilai dengan mudah, karena ekspektasi terhadap pegawai tetap tentu lebih tinggi. Namun ketika membayangkan posisinya, saya ikut merasakan ketakutan dan penderitaan pada saat ia menyadari apa yang terjadi. Termasuk perasaan harapan yang sempat gagal lalu hidup kembali. Saya belum pernah menangani proyek yang diandalkan begitu banyak orang
  Menurut saya, mereka semua pahlawan

  • Di sebuah perusahaan sekuritas besar, sebuah skrip test tanpa sengaja menyentuh produksi dan membuat transaksi uji valuta asing palsu bernilai jutaan dolar
    Dalam panggilan postmortem, kalimat pembukanya adalah: “Kita tidak akan menyalahkan orang yang membuat transaksi itu. Itu kesalahan jujur. Sebaliknya, mari kita bahas mengapa developer bisa mengakses API transaksi produksi tanpa autentikasi”
  • Dalam kegagalan organisasi seperti ini, individu tidak boleh disalahkan. Saya melihat dua masalah proses: jika steker bisa dipasang terbalik, seharusnya sejak awal dibuat tidak mungkin, atau risikonya diidentifikasi sehingga dua orang atau lebih memeriksa arahnya; dan alat seperti multimeter yang sedang digunakan tidak boleh sampai terlepas
    Jika menyalahkan individu, hanya orang itu yang dipecat dan seluruh organisasi menjadi lebih lemah. Itu sama saja dengan mengeluarkan satu-satunya orang yang telah mempelajari pelajaran mahal tersebut. Seseorang baru layak dimintai pertanggungjawaban pribadi ketika ada niat untuk merugikan, dan dalam kasus itu hukum bisa ikut campur
  • Pada pekerjaan web development pertama setelah lulus sekolah, sejak hari pertama saya menjatuhkan situs web produksi. Puluhan ribu pengunjung terdampak dan semua sales lead berhenti, tetapi kami menghidupkannya kembali dalam beberapa menit, melewati momen sulit saat seluruh tim dan CEO di ruangan sebelah menonton
    Beberapa tahun kemudian, ketika saya hendak keluar, situs yang rapuh dan tidak stabil itu sudah saya ubah menjadi sistem dengan automated testing, beberapa lapis backup, sistem failover di beberapa data center, serta pelatihan dan onboarding untuk developer baru. Itu masa awal AWS, belum zaman situs produksi bisa di-deploy dengan satu klik
    Karena pengalaman itu, saya belajar version control yang tepat, development environment, Redis, sharding dan clustering, VM, replikasi Postgres dan MySQL, wiki, monit, DNS, load balancer, reverse proxy, dan lainnya. Karena saya tidak ingin pernah lagi menjatuhkan situs
    Itu memang perusahaan kecil yang membayar 15 dolar per jam kepada seorang putus sekolah SMA dengan sedikit pengalaman WordPress untuk mengurus situs web produksi. Namun setelah kesalahan itu, mereka tidak memecat saya; mereka memberi kebebasan dan kepercayaan untuk belajar di lapangan serta memperbaiki sistem, dan sampai sekarang saya masih berterima kasih
  • Kasus ini berbeda. Ini rover tunggal khusus pertama yang menyandang nama itu, dan meski sudah ada berbagai macam proses, tidak semuanya bisa diprediksi. Mungkin setelah itu prosesnya diperbaiki, tetapi perlu diingat bahwa bagi mereka itu juga pengalaman pertama
    Banyak aturan dan proses yang lebih baik tidak selalu berarti bagus. Kadang birokrasi justru membuat NASA yang sudah lambat menjadi lebih lambat. Dalam misi jenis pertama, ada kalanya kita harus bergantung pada manusia, bukan proses, dan mengambil risiko
  • Saya tidak bisa berhenti memikirkan apa yang akan terjadi jika rover itu benar-benar hancur. Yang mencegahnya tampak murni seperti keberuntungan, dan sepertinya ia bisa saja menghubungkan ke lead lain yang salah tanpa rangkaian pelindung
    Artinya, ada bagian yang ditentukan di luar kemampuan penulis, dan sama besarnya kemungkinan ia selamanya dikenang sebagai orang yang merusak rover, persis seperti yang ia takutkan

• Ini sangat berkaitan dengan pengalaman saya sendiri. Di sebuah maskapai besar, saya sering memilih untuk menangani proyek yang paling sulit dan berisiko, dan salah satunya adalah mengimplementasikan penyedia pembayaran baru untuk situs web dengan cepat. Situs itu menjual tiket senilai jutaan euro setiap hari
  Beberapa detik setelah deployment, kami melewatkan perbedaan antara lingkungan pengujian dan produksi, dan ternyata satu variabel penting kosong di produksi. Itu sesuatu yang seharusnya bisa diperkirakan kalau saya membaca dokumentasi lebih banyak dan mempersiapkan diri, jadi penjualan berhenti total dan dada saya rasanya mencelos. Setelah proses rollback yang panjang, penjualan terhenti selama beberapa jam, pelanggan marah berdatangan, dan kerugian mencapai jutaan euro
  Saya mencegat CEO di lift dan mengatakan bahwa ini sepenuhnya kesalahan saya dan saya siap menerima konsekuensi apa pun, termasuk dipecat. Ia tertawa dan menjawab kira-kira, “Kenapa saya harus mengeluarkan Anda? Kami baru saja menghabiskan jutaan untuk melatih Anda. Sekarang Anda bisa bekerja lebih baik daripada kemarin.” Pengalaman ini membentuk saya dalam banyak hal, termasuk soal kepemimpinan sejati, dan setelah itu saya berhasil menyelesaikan banyak proyek berisiko tinggi

  • Kalimatnya terlalu rapi, dan detail seperti langsung menemui CEO atau kombinasi “top performer” dengan “perusahaan kehilangan jutaan” terasa agak kurang meyakinkan, jadi rasanya seperti ditulis oleh LLM atau setidaknya cerita yang direkayasa
  • Saya sering merasa halaman pemesanan tiket maskapai itu rusak di suatu tempat lebih dari separuh waktu. Mungkin tidak sampai layar kosong total, tetapi sering rusak sampai tidak bisa memesan tiket, dan menurut saya layar kosong malah lebih baik. Karena tidak membuang 30 menit
    Internet secara umum juga sering rusak. Saat checkout Black Friday, webshop Nike error, lalu solusi helpdesk-nya semacam “pakai aplikasi saja”
  • Kerugiannya mungkin tidak sebesar yang dibayangkan. Selama beberapa jam tidak ada yang bisa membeli tiket, jadi secara teori mereka kehilangan pendapatan jutaan untuk periode itu, tetapi itu mengasumsikan orang-orang tidak mencoba lagi nanti
    Kenyataannya, menurut saya downtime tidak otomatis berubah sepenuhnya menjadi kerugian. Twitter pada masa awal sering down karena popularitas dan arsitekturnya, tetapi orang-orang tidak berhenti memakai Twitter
    Dalam layanan online, downtime bukan selalu bencana atau akhir perusahaan. Lain halnya kalau itu peralatan luar angkasa atau perangkat lunak high-frequency trading yang bisa membuat perusahaan bangkrut, dan karena itu harus ada mekanisme pengaman yang lebih ketat. Secara teori begitu, tetapi dalam praktiknya, industri luar angkasa dan high-frequency trading pun kadang lebih buruk daripada layanan web CRUD rapuh yang dibuat dari praktik terbaik yang mereka pelajari
  • Kalau saya penanggung jawab maskapai, saya berharap reaksinya lebih dekat dengan semangat analisis pascakecelakaan penerbangan. Caranya harus mencari dan memperbaiki penyebab sistemik
    Deployment ke produksi mungkin membutuhkan seseorang seperti kopilot yang ikut memeriksa dan punya wewenang menghentikan rollout, bersama dengan mekanisme perlindungan DevOps yang umum
  • Saya teringat lelucon lama yang berakhir dengan, “Kenapa harus saya pecat? Kami baru saja menghabiskan jutaan untuk melatihnya!”
    Orang yang menangani proyek berisiko tinggi sering diremehkan. Banyak manajer lebih memilih karyawan yang stabil tetapi tidak menghasilkan nilai apa pun, daripada karyawan yang nilai harapannya positif tetapi volatil

• Saya bekerja di industri TV. Pada pekerjaan pertama saya 30 tahun lalu di sebuah stasiun TV lokal kecil, saya dilatih sebagai operator tape untuk siaran berita. Tape siaran ditumpuk dalam jumlah besar, dan ada empat VTR untuk pemutaran. Tugas saya adalah memasukkan tiap tape dan menyetelnya ke titik preroll 1 detik
  Ketika pemutaran tape selesai dan tiba waktunya mengeluarkannya, sangat mudah untuk menekan tombol eject pada VTR yang sedang mengudara, bukan VTR yang baru saja selesai. Orang yang melatih saya akan mengatupkan gigi dan menarik napas dengan suara peringatan keras setiap kali saya meraih tombol eject, dan suara itu membuat saya berhenti, mengecek dua sampai tiga kali, baru mengeluarkan tape
  Itu benar-benar menjengkelkan, tetapi efektif untuk mengondisikan saya agar berhati-hati. Kebijakan stasiun adalah: jika pertama kali mengeluarkan tape saat siaran langsung, libur sehari tanpa dibayar; kedua kalinya masa percobaan; ketiga kalinya dipecat. Beberapa rekan kehilangan pekerjaan dan merusak siaran berita karena kelalaian kronis. Berkat pelatih yang menyebalkan itu, saya belajar kebiasaan memeriksa dan memeriksa lagi, dan saya tidak pernah mengeluarkan tape yang sedang mengudara

  • Ini menjelaskan kenapa kompilasi blooper siaran lama yang populer di TV pada awal 80-an terlihat seperti itu. Reporter sedang mengatakan sesuatu, tetapi video latar menampilkan adegan yang sama sekali tidak nyambung

• Sepakat bahwa orang yang pernah melakukan kesalahan seperti itu tidak akan mengulanginya lagi. Jadi, memecat orang yang secara teknis melakukan kesalahan dan jelas-jelas tersiksa karenanya biasanya merupakan pilihan buruk.
  Namun menurut saya itu bukan pelajaran yang “sebenarnya”. Jika mempertimbangkan biaya dan risikonya, pelajarannya adalah komponen yang diuji dengan lonjakan daya besar harus diberi konektor pengujian khusus yang tidak kompatibel dengan komponen yang mudah mengeluarkan asap.
  Ini bukan proyek breadboard kecil, melainkan proyek raksasa yang dibuat oleh banyak orang di lembaga pemerintah, dengan prosedur resmi yang memakan banyak waktu dan biaya, bahkan kadang jadi bahan ejekan. Logika “mari serahkan robot 500 juta dolar yang bisa meledak kalau salah langkah kepada orang berusia 28 tahun” terdengar sangat aneh.

  • Benar bahwa desainnya seharusnya membuatnya tidak mungkin salah colok. Saya kira dalam praktiknya sebagian besar memang dirancang begitu, tetapi konfigurasi keliru yang tidak terpikirkan pada tahap desain tetap bisa muncul.
    Terutama saat pengujian, sering kali orang menangani kabel, konektor, dan rangkaian khusus yang berbeda dari “konfigurasi normal”. Menurut saya pelajarannya adalah pekerjaan penting sebisa mungkin dilakukan dengan prinsip 4-eyes. Cara satu orang mengerjakan lalu orang lain memeriksa tiap langkah sebelum lanjut sangat efektif menangkap “kesalahan konyol” seperti dalam artikel itu.
    Namun karena tekanan jadwal dan sebagainya, tidak selalu mungkin dua orang mengawasi satu pengujian, jadi di dunia nyata kesalahan seperti ini terjadi. Seluruh sistem harus dibuat tangguh.
  • Awalnya saya juga berpikir begitu. Namun kalau itu peralatan sekali pakai yang hanya melewati satu siklus pengujian, penilaian seperti ini memang sulit.
    Di komputasi juga ada banyak pekerjaan serupa yang dilakukan persis sekali sebagai bagian dari upgrade atau migrasi pada database produksi atau konfigurasi router. Kadang biaya membuat pengaman lebih besar daripada berhati-hati sejak awal. Kita tidak selalu bisa berhati-hati sempurna, tetapi pengaman juga tidak selalu bisa dibuat sempurna, dan kita bisa melakukan kesalahan serupa karena memercayai pengaman yang cacat.
    Dalam situasi di cerita itu, mungkin seharusnya ada partner seperti pair programming versi hardware, yang tugasnya hanya memverifikasi bahwa semua yang dilakukan penulis sudah benar. Bukan asisten yang membantu dengan pembagian peran seperti Mary, melainkan seseorang yang satu-satunya tugasnya adalah mengikuti dan memeriksa.
  • Kalau dibaca dengan saksama, daya masuk ke lead keluaran daya H-bridge, dan karena H-bridge adalah rangkaian elektronik yang kuat, pada akhirnya tidak ada yang rusak. Shutdown tidak terkait.
    Kalau masuk ke jalur data motor controller, kemungkinan besar ada sesuatu yang terbakar. Tidak bisa dikesampingkan apakah tipe konektornya berbeda, tetapi dua konektor yang salah disambungkan itu memang ditetapkan sebagai tipe yang sama.
  • Saat umat manusia pertama kali mendarat di Bulan, usia rata-rata para engineer Mission Control adalah 28 tahun.
  • Karena bekerja di industri ini, saya bisa menjelaskan bagaimana hal seperti ini bisa terjadi. Bahkan pada proyek mahal, tidak mungkin memaksakan konektor unik di semua tempat. Sebab requirement saling bersaing.
    Khususnya konektor punya banyak requirement konservatif, seperti produk yang sudah tersertifikasi, derating tertentu, jarak antar-pin, backshell yang diground-kan, dan sebagainya. Pada akhirnya hanya ada beberapa seri konektor yang digunakan dan disimpan dalam inventaris, dan tidak realistis membuat semuanya sama sekali tidak tumpang tindih berapa pun biayanya. Biasanya orang menstandardisasi sinyal yang sama, atau mencoba membuatnya unik agar tidak bertumpang tindih.
    Misalnya, konektor eksternal wahana antariksa membutuhkan konektor tipe soket untuk mencegah short saat penanganan, sementara harness tengah tidak akan pernah dilepas dan bisa dipasangi konektor tipe pin secara simetris. Lalu ketika breakout box untuk pengujian dibutuhkan, muncul peluang untuk memasang box itu terbalik.
    Atau satu sisi breakout box bisa berupa konektor 100 pin, sedangkan sisi lain harus terhubung ke 25 perangkat uji. Tidak ada 25 konektor berbeda yang bisa dipilih, dan tidak mungkin memaksakan requirement khusus pada semua perangkat uji.
    Wahana antariksa semakin bergeser ke mikrokontroler lokal dan diagnostik lokal, jadi peralatan uji semacam ini untuk semua sinyal analog makin berkurang. Motor pun sekarang kemungkinan besar brushless, dan alih-alih breakout box seperti ini, pengujian maupun penerbangan akan mengandalkan telemetri dari motor driver.
    Konektor aerospace juga, seperti industri lain, makin bisa dikonfigurasi saat pemesanan, dan dengan menambahkan key, meski ada 10 konektor yang “sama”, semuanya bisa dibuat hanya cocok di tempatnya masing-masing. Tetap saja, meminta semua peralatan uji dikonfigurasi seperti itu masih tidak realistis.

• Sekadar sebagai catatan, saya juga menambahkan cerita saya. Pekerjaan pertama saya setelah lulus kuliah adalah di startup content marketing yang memakai PHP dan PerconaDB(MySQL). Pengalaman PHP saya tidak banyak, tetapi saya punya kepercayaan diri tanpa dasar khas orang baru. Karena selama 6 bulan setelah lulus saya belum mendapat pekerjaan, saya juga sangat ingin memberi kesan baik.
  Saya ditugaskan memperbarui feature flag agar fitur baru dinyalakan untuk semua pelanggan, kecuali pelanggan yang secara eksplisit ingin mematikannya. Flag itu disimpan di database sebagai bilangan bulat 4 dan 5 di dalam array string.
  Untuk melakukan pekerjaan yang diperlukan, saya memakai fungsi PHP array_reverse, tetapi karena tidak membaca dokumentasinya, saya tidak tahu bahwa tanpa argumen kedua, yang dibalik adalah nilainya, bukan key-nya. Akibatnya database rusak persis kebalikan dari yang dibutuhkan, dan anehnya lolos QA.
  Beberapa jam kemudian baru ketahuan, dan saat itu saya masih harus commuting hampir 3 jam sekali jalan, jadi pada saat itu manajemen pun sudah terlibat. Itu bisa diperbaiki dengan mudah memakai skrip kebalikan, tetapi sejumlah masalah lain seperti QA dan kegagalan backup DB juga terungkap.
  Keesokan harinya, lead architect datang dan berkata bahwa itu semacam ritus peralihan saat bekerja dengan PHP, dan dia sendiri pernah melakukannya di awal kariernya. Saya masih mengingat dan menghargai hal itu. Pada akhirnya saya dipecat, dan meski itu membantu saya berkembang sebagai engineer, momen itu dan beberapa minggu setelahnya jelas membuat semangat saya jatuh.

  • Dia memecatmu karena kesalahan array_reverse itu?

• Ceritanya ditulis dengan sangat menarik, tetapi juga membingungkan
  Tim ini tampaknya melakukan beberapa kesalahan, bukan satu kesalahan saja. Juga tidak jelas apakah akibatnya benar-benar bisa merusak wahana antariksa, atau hanya membuang waktu dan menimbulkan kebingungan soal mengapa wahana itu tidak menyala
  Kesalahan pertama adalah tidak menyadari bahwa multimeter itu bukan hanya melakukan pengukuran, melainkan sedang melengkapi rangkaian. Kedengarannya seperti desain yang sangat buruk, dan kalau memang harus seperti itu, multimeter tersebut seharusnya sama sekali tidak boleh disentuh. Ini bukan kesalahan satu orang, melainkan masalah yang melibatkan setidaknya dua orang, orang yang mengelola mereka, sampai pihak penanggung jawab yang membiarkan sistem seperti itu ada
  Kesalahan kedua ada pada breakout box. Mereka melihat bahwa daya telah salah dikirim ke arah wahana antariksa, lalu ketika wahana tidak menyala, mereka menyimpulkan lonjakan daya telah merusak wahana. Namun mereka tidak yakin sebenarnya arus itu mengalir ke mana dan apa yang rusak, dan pada akhirnya kesimpulan itu keliru
  Alasan wahana tidak menyala adalah karena sebelum insiden, multimeter sudah dilepas dari rangkaian. Kalimat tentang analisis berminggu-minggu terhadap kanal H-bridge motor RAT-Revolve dan diskusi mengenai kemungkinan demetalisasi film tipis masih membuat bingung: apakah maksudnya mereka menilai lonjakan daya yang salah itu mungkin mengalir melalui kanal tersebut dan merusaknya?

  • Ada juga hal yang terlewat: petugas telemetri Leo tidak melaporkan hilangnya telemetri sampai ia mengatakan bahwa si pencerita telah melakukan kesalahan. Bukankah semua pengujian seharusnya dibatalkan sampai telemetri kembali?
  • Wahana itu sendiri sebenarnya menyala dengan baik. Karena multimeter sedang menghubungkan rangkaian telemetri, mereka tidak bisa menerima informasi sampai rangkaian itu dipulihkan
    Daya memang benar-benar masuk ke rangkaian itu, dan mereka sedang mencoba menilai apakah ada kerusakan. Hanya saja, motor driver seharusnya mampu menahan daya yang kembali dari motor, jadi kemungkinan besar mereka menilai bahwa itu tidak rusak

• Sebagai insinyur mekanik dan dirgantara, aku berharap kisah-kisah paling menakutkanku hanya sebatas nyaris membuat komputer utama rover tak berawak seharga 500 juta dolar menjadi brick
  Aku pernah menjadi senior yang memberikan persetujuan kritis keselamatan untuk hal-hal yang membawa nyawa manusia. Setelah sebuah kecelakaan jatuh, saat melihat foto komponen yang hancur, aku harus menanggung perasaan seperti “bagaimana kalau itu karena perhitunganku salah?”, “bagaimana kalau sambunganku yang tergelincir?”, “bagaimana kalau karena prosedur pengujian yang tidak memadai untuk prediksi umur lelah terakselerasi atau retak korosi tegangan?”, “bagaimana kalau itu sesuatu yang tidak sempat kami tangkap sebelum pengiriman karena terburu-buru masuk produksi?”
  Membaca cerita kegagalan dari bidang serupa memang menarik, tetapi kisah-kisah yang dibagikan secara terbuka di HN membuatku berpikir bahwa PTSD akibat pekerjaan bukanlah kompetisi. Bagi sebagian orang, biayanya untuk terapi saja lebih mahal

  • Aku teringat sebuah kalimat dari novel penulis favoritku. Itu adalah ucapan seorang instruktur pengelasan setelah ia menceritakan anekdot post-mortem yang cukup harfiah terkait inspeksi keselamatan yang dipalsukan

    He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

    “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

    He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
    -- Lois McMaster Bujold, Falling Free

  • Aku juga berpikir hal yang sama tentang paragraf terakhir. Bagian di teks asli yang menulis “aku langsung kembali ke momen itu — ruangan, pencahayaan, kursi tempatku duduk, meja, rasa perut yang mendadak kosong...” terdengar seperti respons trauma
    Syukurlah ia bisa menyalurkan energi itu ke arah menjadi lebih baik, tetapi tidak semua orang merespons trauma dengan cara yang sama, dan reaksi semacam itu juga tidak mudah dibandingkan. Misalnya, menurutku ada terlalu banyak variabel sosial untuk menjadikannya pertanyaan rekrutmen
  • Aku penasaran apakah bagian “harus merasakan ‘bagaimana kalau itu karena perhitunganku salah?’ saat melihat foto komponen yang hancur setelah kecelakaan jatuh” pada akhirnya adalah sesuatu yang tak terhindarkan akan kembali ke seseorang
    Sekalipun itu detail yang tidak bisa ditangkap oleh prosedur, tetap ada seseorang yang bertanggung jawab membuat prosedur yang baik. Bisa saja ada banyak faktor, tetapi pada akhirnya tampaknya akan ada seseorang yang memikul tanggung jawab dengan cukup langsung
    Menarik untuk memikirkannya dalam konteks seperti rekayasa perangkat lunak atau masyarakat secara umum, ketika kesalahan individu diatribusikan kepada kelompok
  • Aku sungguh berharap ada lebih banyak orang seperti Anda di industri dirgantara, dan lebih sedikit orang yang merancang, mengimplementasikan, serta menyetujui MCAS pada Boeing 737 MAX
  • Mengejutkan bahwa tidak ada konseling kelompok untuk insinyur, atau kalaupun ada, sulit ditemukan. Aku tidak bekerja di bidang berisiko tinggi, tetapi aku sering berada di posisi mendengarkan cerita orang-orang dari sektor penerbangan atau perkeretaapian
    Menurutku itu bisa cukup berat jika seseorang punya empati dan tidak mengambil sikap “setelah roket naik, jatuhnya di mana bukan urusan departemenku”. Akan bagus jika ada kelompok dukungan sejawat untuk orang-orang yang membuat sistem wajib-selamat atau menangani dampaknya. Perusahaan tidak selalu menyediakan konseling yang baik
    Perhimpunan teknik atau organisasi insinyur profesional mungkin bisa menyediakan layanan seperti ini dari iuran anggota, tetapi mungkin saja orang enggan menggunakannya karena takut kehilangan lisensi atau sertifikasi profesional. Dulu mungkin orang melampiaskannya dengan mabuk di pub bersama rekan kerja, tetapi ketergantungan alkohol atau terganggunya kerja esok hari bukan hal baik, dan budaya pub juga tidak seperti dulu lagi

• Saya jadi teringat insiden ketika satelit NOAA-N Prime jatuh karena baut untuk mengikatnya ke dudukan uji tidak cukup.
  Akar penyebabnya—kalau tidak tepat, tolong koreksi—adalah baut inspeksi sinar-X yang digunakan untuk mengamankan satelit terlalu mahal, sehingga “dipinjam” untuk proyek lain dan tidak dikembalikan. Saat satelit dibalik ke posisi horizontal, satelit itu jatuh ke lantai, dan biaya perbaikannya mencapai 135 juta dolar AS.
  https://en.m.wikipedia.org/wiki/NOAA-19

  • Kalau “periksa baut” ditambahkan ke errata atau lampiran prosedur pembalikan, apakah sedikit sindiran masih bisa dimaklumi?

• Menarik bahwa kekhawatiran itu sebenarnya bisa dihindari jika sejak awal pengurutan kronologis dilakukan dengan lebih baik. Jika mereka membandingkan timestamp pada pembacaan tes dengan timestamp terakhir dari sistem telemetri, mereka akan tahu bahwa telemetri sudah gagal sebelum pengujian dijalankan.
  Salah satu penyebabnya juga adalah penggunaan ungkapan yang tidak presisi seperti “sepertinya semua telemetri wahana antariksa baru saja terputus”, alih-alih memakai timestamp yang tepat. Pelajarannya adalah kita harus benar-benar memastikan bagaimana peristiwa-peristiwa dalam insiden saling terhubung secara tepat. Kita mudah melihat dua sinyal berbeda lalu mengasumsikan kausalitas ke arah tertentu, padahal dalam kenyataannya bisa saja sebaliknya.