Bus Factor: Saat Sistem Bergantung pada Satu Orang

Sistem bisnis ikut berisiko ketika hanya satu orang tahu cara memperbaikinya atau memegang akses penting. Risiko ketergantungan ini disebut bus factor: berapa orang yang bisa tidak tersedia sebelum pekerjaan terhenti. Mulailah dengan panduan operasional tertulis, akses perusahaan yang dikelola bersama sesuai peran, dan latihan agar orang kedua bisa mengambil alih.

Ketergantungan pada seseorang sering baru terlihat saat ia tidak tersedia. Padahal, risiko ini dapat dipetakan sebelum terjadi pengunduran diri atau gangguan layanan.

Apa sebenarnya arti "bus factor"

Sebuah gembok dengan satu anak kunci menggambarkan risikonya: jika kunci hilang, tidak ada orang lain yang dapat membuka. Dalam tim, pengetahuan dan akses yang hanya dimiliki satu orang menimbulkan ketergantungan serupa.

Istilahnya bermula dari pesan pada milis Python tanggal 29 Juni 1994. Peneliti NIST, Michael McLay, menulis berita fiktif: "Guido's unexpected death has come as a shock to us all..." Berita itu untuk memancing diskusi soal seberapa bergantungnya proyek Python muda saat itu pada penciptanya, Guido van Rossum. Pesan itu sendiri tidak pernah memakai frasa "bus factor". Sejarah penamaannya berjalan terpisah lewat "truck number" di literatur Pattern Languages of Program Design pertengahan 1990-an.

Meski begitu, post McLay banyak dikutip sebagai contoh terdokumentasi paling awal pertanyaan ini diajukan soal proyek nyata.

Definisi kerjanya, menurut artikel bus factor di Wikipedia: jumlah minimum anggota tim yang harus tiba-tiba menghilang sebelum sebuah proyek berhenti karena kekurangan orang yang paham. Istilah yang sama juga dikenal sebagai lottery factor, truck factor, atau circus factor, tergantung siapa yang bertanya.

Buku Williams dan Kessler tahun 2003, Pair Programming Illuminated, mendefinisikan truck factor sebagai jumlah orang yang harus tertabrak truk, atau mengundurkan diri, sebelum sebuah proyek dalam masalah serius. Nama itu bertahan jadi istilah standar rekayasa perangkat lunak untuk risiko ini.

Apa kata datanya

Penelitian menunjukkan bahwa ketergantungan pengetahuan juga muncul pada proyek yang aktif dipelihara. Peneliti di UFMG membangun alat otomatis untuk memperkirakan truck factor di 133 proyek populer GitHub, lebih dari 373.000 file, 41 juta baris kode, dua juta lebih commit gabungan.

Enam puluh lima persen dari proyek-proyek itu punya truck factor 2 atau kurang. Kehilangan satu atau dua kontributor saja sudah cukup membuat sebagian besar proyek itu dalam masalah serius. Proyek sumber terbuka tersebut dikenal luas dan aktif dipelihara.

Peneliti memeriksa perkiraan tersebut dengan meminta tanggapan pengembang proyek. Mereka membuka GitHub issue di 114 dari 133 sistem dan mendapat jawaban dari 67, total 106 responden. Setelah menyingkirkan lima jawaban tidak reliabel, mereka punya data terpakai dari 62 sistem.

Sebanyak 84% setuju atau sebagian setuju bahwa orang yang ditandai alat tersebut memang kontributor utama proyek. 53% memberi penilaian positif atau sebagian positif terhadap angka truck factor itu sendiri. Jawaban tersebut mendukung temuan bahwa pengetahuan terkonsentrasi pada sedikit orang dalam proyek yang diteliti. Angka itu tidak langsung menggambarkan setiap perusahaan.

Ketika ketergantungan baru diketahui saat ada insiden

Organisasi besar kadang menangkap ini lewat audit atau rencana suksesi formal. Yang lebih kecil biasanya baru sadar saat ada kejadian. Surat pengunduran diri, sakit mendadak, minggu pertama seorang konsultan menyusuri infrastruktur, atau insiden yang tidak bisa diperbaiki siapa pun di lokasi jam 2 pagi.

Versi terburuknya terjadi di San Francisco tahun 2008. Administrator jaringan Terry Childs adalah satu-satunya orang yang memegang kata sandi administratif jaringan FiberWAN kota itu. Jaringan itu membawa data penggajian, surel, serta data penegakan hukum dan penjara.

Ketika atasannya meminta kredensialnya, ia menolak. Pemerintah kota kehilangan kendali administratif atas jaringannya sendiri. Childs kemudian dinyatakan bersalah atas felony network tampering pada April 2010 dan dijatuhi hukuman empat tahun penjara negara bagian. Ia juga diwajibkan membayar restitusi hampir $1,5 juta ke kota.

Insiden bus factor dapat menyebabkan gangguan layanan yang mahal, meskipun tidak sampai menjadi perkara di pengadilan. Tapi kegagalan dasarnya sama: satu orang memegang kunci yang tidak bisa dijangkau siapa pun.

Tiga bentuk ketergantungan dalam operasi TI kecil

Banyak usaha kecil dan menengah yang saya tangani punya versi mereka sendiri dari tiga titik kegagalan tunggal yang sama. IT hanya tempat paling mudah untuk melihat polanya:

• Satu pengelola memegang seluruh akses penting. Kredensial server, login registrar domain, akses cloud console, semuanya hanya bisa dijangkau lewat ingatan satu orang atau pengelola kata sandi yang tidak memiliki akses tim.
• Satu pengembang memahami seluruh kode lama. Tanpa komentar, tanpa catatan arsitektur, aturan bisnis yang tidak terdokumentasi terkubur di dalam percabangan kode yang tidak pernah ditinjau setelah dibuat.
• Satu pekerja lepas atau kontak vendor menyimpan semua pengetahuan sendiri. Integrasi perangkat keras, skrip khusus, perilaku tidak biasa pada firmware, semuanya hidup di kepala orang lain, yang bahkan bukan pegawai Anda.

Perbaikan, urut dari yang paling ringan

Tulis panduan operasional (runbook). Tim Site Reliability Engineering Google secara tegas menyatakan mereka berusaha meminimalkan titik kegagalan tunggal, termasuk manusia. Mereka mewajibkan prosedur petugas siaga didokumentasikan sebelum sebuah produk diluncurkan, selagi pengetahuan itu masih segar di kepala seseorang. Ini perbaikan paling murah, dan yang paling sering dilewatkan SME karena tidak ada yang menagih biaya untuk menulis dokumentasi.

Simpan kredensial dalam penyimpanan rahasia bersama dengan akses sesuai peran. Gunakan pengelola kata sandi dengan akun tim agar akses tidak bergantung pada ingatan seseorang atau lembar kerja di laptop. Akses harus tetap bertahan saat ada yang keluar tanpa harus buru-buru mereset semuanya sekaligus.

Gunakan peninjauan kode untuk membagikan pengetahuan. Jika perubahan hanya dapat diperiksa satu orang, tim masih bergantung padanya. Peninjauan bersama membantu orang kedua memahami konteks dan aturan bisnis dalam kode.

Bangun daftar pemeriksaan serah terima yang terstruktur. Daftar akses, kontak vendor, catatan arsitektur, keanehan yang diketahui: ditulis sebelum seseorang pergi, bukan disusun ulang di bawah tekanan setelah mereka tidak ada.

Bagaimana konsultan membantu mengurangi ketergantungan?

Bantuan dari luar dapat mengurangi atau justru menambah ketergantungan. Konsultan yang mendokumentasikan sambil jalan, menyimpan akses dalam penyimpanan bersama dan menulis kode yang dapat ditinjau, menaikkan bus factor Anda.

Konsultan yang membangun sesuatu yang hanya dia sendiri pahami, dengan kredensial yang hanya dia pegang, justru menurunkannya. Anda sudah membayar untuk menambah satu titik kegagalan tunggal, bukan menghilangkannya. Sebelum menandatangani apa pun, periksa bagaimana kontrak kerja freelance mengatur kepemilikan IP dan dokumentasi, karena kontrak dapat mensyaratkan bukti serah terima. Periksa bahwa akses dan dokumentasi yang disepakati benar-benar diberikan.

Periksa akses dan kesiapan pengganti minggu ini

Bus factor yang rendah bukan sekadar kemungkinan teoretis. Itu terukur, dan bisa diperbaiki dengan beberapa pertanyaan konkret:

• Kalau orang teknis paling senior di tempat Anda mengundurkan diri besok, siapa yang punya kredensial penerapan sistem?
• Apakah ada runbook tertulis untuk tiga proses operasional utama Anda, atau semuanya hanya ada di kepala satu orang?
• Apakah kontak vendor dan freelancer terdokumentasi di tempat yang bisa dijangkau seluruh tim, bukan hanya di satu ponsel?
• Apakah ada yang pernah meninjau kode yang menjalankan bisnis Anda, selain orang yang menulisnya?

Pertanyaan ini dapat menjadi pemeriksaan awal sekitar satu sore. Jika jawabannya belum jelas, tentukan orang kedua, dokumentasikan prosedurnya, dan uji pengambilalihan sebelum terjadi pergantian staf.