Bus Factor: Ketika Satu Orang Jadi Titik Kegagalan Tunggal

Bus Factor: Ketika Satu Orang Jadi Titik Kegagalan Tunggal

Pemilik SME membaca email pengunduran diri, lalu mencari runbook deploy. Ternyata runbook itu cuma ada di kepala satu orang. Vault menyimpan password admin yang tidak pernah disentuh siapa pun selama dua tahun. Nomor langsung vendor tersimpan di ponsel yang dua minggu lagi ikut keluar pintu.

Semua ini tidak muncul di risk register sampai hari itu tiba. Risiko ini punya nama, dan sudah lebih lama serta lebih banyak diteliti daripada yang disadari kebanyakan pemilik bisnis.

Apa sebenarnya arti "bus factor"

Bayangkan tim Anda seperti kunci gembok dengan satu anak kunci saja. Hilang kuncinya, semua orang di luar. Itulah bus factor rendah.

Istilahnya bermula dari post di mailing list 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. Post 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 resign, sebelum sebuah proyek dalam masalah serius. Nama itu bertahan jadi istilah standar rekayasa perangkat lunak untuk risiko ini.

Apa kata datanya

Gampang mengira ini cuma terjadi di tim yang ceroboh. Kenyataannya tidak. Peneliti di UFMG membangun tool otomatis untuk mengestimasi 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. Ini codebase open-source yang dikenal luas dan aktif dipelihara, bukan proyek sampingan terbengkalai.

Para peneliti mengecek estimasi mereka ke kenyataan dengan bertanya langsung ke developer-nya. 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.

Dari situ, 84% setuju atau sebagian setuju bahwa orang yang ditandai tool sebagai truck-factor authors memang benar kontributor utamanya. 53% memberi penilaian positif atau sebagian positif terhadap angka truck factor itu sendiri. Konsentrasi pengetahuan bukan hipotesis. Itu kondisi normal di kebanyakan codebase, dikonfirmasi oleh orang yang menulis kodenya sendiri.

Bagaimana SME menyadarinya dengan cara yang keras

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 password administratif jaringan FiberWAN kota itu. Jaringan itu membawa data payroll, email, serta data penegakan hukum dan penjara.

Ketika atasannya meminta kredensialnya, ia menolak. San Francisco terkunci dari 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.

Kebanyakan insiden bus factor berakhir dengan seminggu downtime yang mahal, bukan di ruang sidang. Tapi kegagalan dasarnya sama: satu orang memegang kunci yang tidak bisa dijangkau siapa pun.

Tiga tersangka biasa di operasi IT kecil

Kebanyakan SME yang saya tangani punya versi mereka sendiri dari tiga titik kegagalan tunggal yang sama. IT cuma tempat paling mudah untuk melihat polanya:

• Satu admin dengan akses root atau vault. Kredensial server, login registrar domain, akses cloud console, semuanya cuma bisa dijangkau lewat ingatan satu orang atau satu password manager yang tidak dibagi.
• Satu developer yang paham codebase lama. Tanpa komentar, tanpa catatan arsitektur, aturan bisnis yang tidak terdokumentasi terkubur di dalam conditional yang tidak pernah disentuh sejak ditulis.
• Satu freelancer atau kontak vendor yang tidak pernah menulis apa pun. Integrasi hardware, script custom, keanehan firmware, semuanya hidup di kepala orang lain, yang bahkan bukan pegawai Anda.

Perbaikan, urut dari yang paling ringan

Tulis runbook-nya. Tim Site Reliability Engineering Google secara tegas menyatakan mereka berusaha meminimalkan titik kegagalan tunggal, termasuk manusia. Mereka mewajibkan proses on-call 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.

Pindahkan kredensial ke vault bersama dengan kepemilikan berbasis peran. Password manager dengan akun tim, bukan ingatan satu orang, bukan spreadsheet di laptop. Akses harus tetap bertahan saat ada yang keluar tanpa harus buru-buru mereset semuanya sekaligus.

Pakai code review sebagai forcing function. Pull request yang cuma bisa disetujui satu orang, karena cuma satu orang yang paham kodenya, adalah masalah bus factor yang menyamar jadi proses. Review seringan apa pun sudah menyebarkan konteks yang tadinya cuma mengendap di satu kepala.

Bangun checklist handover 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.

Di mana konsultan luar berperan

Mendatangkan bantuan dari luar bisa menggerakkan angka ini ke dua arah. Konsultan yang mendokumentasikan sambil jalan, menambah entri ke vault bersama bukan catatan pribadi, dan menulis kode yang bisa direview, menaikkan bus factor Anda.

Konsultan yang membangun sesuatu yang cuma dia sendiri pahami, dengan kredensial yang cuma 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 di kontrak itulah risiko ini sebenarnya diputuskan.

Cek 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 resign besok, siapa yang punya kredensial deploy?
• Apakah ada runbook tertulis untuk tiga proses operasional utama Anda, atau semuanya cuma ada di kepala satu orang?
• Apakah kontak vendor dan freelancer terdokumentasi di tempat yang bisa dijangkau seluruh tim, bukan cuma di satu ponsel?
• Apakah ada yang pernah mereview kode yang menjalankan bisnis Anda, selain orang yang menulisnya?

Tidak satu pun dari ini butuh lebih dari satu sore untuk dijawab. Kebanyakan SME menemukan jawabannya lebih buruk dari yang mereka kira. Tetap lebih baik daripada mengetahuinya lewat email pengunduran diri.