Problem statement di industri

YouTube adalah salah satu platform hiburan terbesar di dunia. Setiap hari jutaan orang menonton video, mulai dari musik, film, tutorial, hingga berita terbaru. Namun, tidak jarang beberapa konten di YouTube dibatasi oleh wilayah (geo-blocking) atau koneksi internet melambat karena faktor jaringan. 

Bug seperti ini sering dianggap tidak prioritas. Dampaknya terlihat kecil karena frekuensinya rendah. Tim sering berkata, nanti kita lihat lagi kalau muncul.

Padahal bug langka adalah indikator risiko sistemik. Ia sering muncul dari kombinasi kondisi ekstrem, race condition, edge case data, atau inkonsistensi state antar modul.

Bug jenis ini memiliki karakteristik:

• Tidak mudah direplikasi.
• Log sering tidak cukup detail.
• Dampak bisa besar meski jarang.
• Muncul saat kondisi load atau data tertentu.
• Sering melibatkan lebih dari satu modul.

Banyak insiden besar di industri berawal dari bug langka yang diabaikan.

Amazon pernah mengalami outage pada AWS S3 tahun 2017 karena kesalahan konfigurasi internal yang jarang dilakukan. GitHub pernah mengalami data corruption karena kondisi failover yang jarang terjadi. Masalah jarang bukan berarti masalah kecil.

Kenapa banyak engineer salah approach

Kesalahan pertama adalah mindset frekuensi sama dengan prioritas.

Engineer melihat angka. Satu kali dalam sebulan. Mereka berpikir low impact. Padahal satu kali bisa berarti satu data rusak. Satu invoice salah. Satu transaksi gagal.

Kesalahan kedua adalah menunggu reproduksi ulang.

Banyak developer berkata, kita tunggu saja sampai kejadian lagi. Ini reaktif. Anda membiarkan sistem produksi menjadi alat eksperimen.

Kesalahan ketiga adalah debugging terlalu lokal.

Engineer sering fokus pada satu function. Mereka tidak melihat sistem sebagai alur state yang utuh. Padahal bug langka sering muncul dari interaksi antar modul.

Kesalahan keempat adalah kurang observability.

Log tidak cukup granular. Tidak ada correlation id. Tidak ada snapshot state sebelum dan sesudah proses.

Kesalahan kelima adalah bias pengalaman.

Engineer merasa, dari pengalaman saya ini tidak mungkin. Sistem tidak peduli pengalaman Anda. Sistem peduli pada kondisi aktual.

Framework berpikir yang benar

Saat Anda menghadapi bug 1x dalam 1 bulan, gunakan pendekatan sistematis.

Pertama. Asumsikan bug valid sampai terbukti salah.

Jangan mulai dari asumsi user salah. Mulai dari asumsi sistem Anda salah.

Kedua. Identifikasi invariant sistem.

Tulis aturan yang tidak boleh dilanggar. Misalnya:

• Status canceled tidak boleh kembali ke normal.
• Data dengan flag reject tidak boleh diproses create.
• Setiap transaksi harus memiliki satu record audit.

Jika invariant rusak, berarti ada jalur eksekusi yang melanggarnya.

Ketiga. Rekonstruksi timeline.

Kumpulkan:

• Timestamp event.
• Urutan request.
• Perubahan state.
• Log sebelum dan sesudah.

Buat timeline detail. Tanpa asumsi.

Keempat. Evaluasi race condition dan concurrency.

Bug langka sering muncul dari:

• Dua request paralel.
• Retry mechanism.
• Background job dan user action yang overlap.

Kelima. Perbaiki observability sebelum memperbaiki kode.

Tambahkan:

• Structured logging.
• Correlation id.
• Log state input dan output.
• Alert untuk pelanggaran invariant.

Anda tidak bisa memperbaiki yang tidak bisa Anda lihat.

Contoh kasus nyata

Kasus pada sistem distribusi internal.

Masalah muncul satu kali dalam satu bulan. Data Delivery Order yang sudah canceled tiba tiba kembali aktif dan lanjut ke proses berikutnya.

Aturan sistem jelas. Status canceled tidak boleh kembali normal. Hanya bisa diinject manual oleh developer.

Tim melakukan pengecekan awal:

• Tidak ada proses inject manual.
• Tidak ada error log.
• Data dibuat pada tanggal berbeda.
• Cross check function validasi terlihat benar.

Dua function memvalidasi status. Keduanya seharusnya mencegah data invalid.

Namun pada kondisi tertentu, kedua function gagal handle. Kenapa?

Setelah investigasi lebih dalam, ditemukan skenario berikut:

• User A membuka halaman dan memuat data lama.
• Admin membatalkan status di waktu berbeda.
• User A tetap menyimpan perubahan dari session lama.
• Sistem tidak melakukan revalidasi state terakhir sebelum commit.
• Tidak ada optimistic locking atau version check.

Bug hanya muncul saat kombinasi ini terjadi. Itulah mengapa hanya satu kali dalam sebulan.

Frekuensi rendah karena membutuhkan:

• Data spesifik.
• Dua user.
• Waktu tertentu.
• Urutan aksi tertentu.

Solusi bukan hanya memperbaiki satu function. Solusi meliputi:

• Menambahkan version column untuk optimistic locking.
• Revalidasi status di layer service sebelum commit.
• Logging state lama dan baru.
• Alert jika invariant dilanggar.

Setelah perubahan ini, tidak ada kejadian ulang selama beberapa bulan.

Insight dan refleksi pribadi

Bug langka menguji kedewasaan engineering Anda.

Anda bisa memilih dua sikap.

Sikap pertama. Tunggu sampai kejadian lagi. Tambah log sedikit. Lanjut fitur lain.

Sikap kedua. Perlakukan setiap pelanggaran invariant sebagai alarm arsitektur.

Saya belajar beberapa hal penting:

• Frekuensi tidak sama dengan risiko.
• Observability lebih penting daripada tebakan.
• Sistem harus dirancang defensif.
• Validasi harus dilakukan di boundary yang tepat.
• State harus dianggap sumber kebenaran, bukan asumsi di memori.

Sebagai engineer profesional, tugas Anda bukan hanya membuat fitur berjalan. Tugas Anda menjaga integritas sistem dalam semua kondisi.

Bug langka memaksa Anda berpikir sebagai arsitek. Bukan hanya coder.

Penutup yang kuat

Bug 1x dalam 1 bulan adalah sinyal. Bukan gangguan kecil.

Jika Anda mengabaikannya, Anda menunda krisis.

Jika Anda membedahnya, Anda meningkatkan kualitas sistem secara struktural.

Engineering profesional tidak diukur dari seberapa cepat Anda menutup tiket. Engineering profesional diukur dari bagaimana Anda menjaga sistem tetap benar saat kondisi tidak ideal.

Sistem produksi selalu berbicara melalui anomali kecil.