Side project itu sering kelihatan “jalan” sampai ada error kecil yang bikin lu cuma bisa nebak-nebak.

Artikel ini bahas cara bikin observability kecil untuk side project: log yang rapi, trace sederhana, bukti deploy, dan checklist debug yang bisa dipakai tanpa setup enterprise. Intinya bukan supaya project kecil terasa seperti perusahaan besar, tapi supaya lu punya jejak yang cukup saat ada bug, lambat, atau user bilang “kok error ya?”. Buat developer yang lagi bangun personal brand, observability juga bisa jadi bahan cerita yang kredibel: bukan cuma bilang bisa bikin produk, tapi nunjukin cara lu menjaga produk tetap bisa dipahami.

Apa itu observability, versi developer solo?

Observability adalah kemampuan memahami kondisi sistem dari sinyal yang keluar: log, metric, trace, error report, dan artefak lain. OpenTelemetry menjelaskan observability sebagai cara mengumpulkan telemetry data dari aplikasi supaya perilaku sistem bisa dipahami. Dalam praktik harian, definisi sederhananya begini: saat sesuatu rusak, lu punya cukup petunjuk buat tahu mulai cek dari mana.

Masalahnya, banyak developer solo terlalu cepat lompat ke dua ekstrem. Ekstrem pertama: nggak ada catatan apa pun, jadi semua error jadi tebak-tebakan. Ekstrem kedua: langsung pasang stack observability besar yang akhirnya nggak dirawat. Menurut gua, side project butuh jalan tengah: sistem kecil yang konsisten, murah, dan benar-benar dipakai.

Kenapa side project butuh observability kecil?

Side project biasanya dibangun di sela kerja, kuliah, freelance, atau eksperimen malam-malam. Karena ritmenya putus-putus, konteks gampang hilang. Hari ini lu masih ingat kenapa endpoint dibuat begini, dua minggu lagi belum tentu.

Observability kecil bantu di tiga momen penting:

  • Saat error muncul: lu bisa cek request, waktu kejadian, dan bagian mana yang gagal.
  • Saat performa turun: lu bisa bedain apakah masalahnya database, API eksternal, frontend, atau jaringan.
  • Saat bikin konten: lu punya bukti proses, bukan cuma opini. Ini bisa jadi carousel, video debugging, atau artikel lanjutan.

Di sinilah personal branding developer terasa lebih kuat. Banyak orang bisa posting hasil akhir. Lebih sedikit yang bisa menjelaskan proses menjaga project tetap sehat dengan bahasa yang gampang dipahami.

Mulai dari log yang bisa dibaca manusia

Log adalah sinyal paling murah dan paling sering dipakai. Cloudflare Workers, misalnya, punya fitur log untuk melihat output aplikasi dan membantu investigasi perilaku Worker. Tapi log baru berguna kalau isinya jelas.

Log yang buruk biasanya seperti ini:

console.log("error")
console.log(data)

Pas kejadian beneran, lu nggak tahu error dari fitur mana, user mana, request mana, atau step mana. Untuk side project, format log sederhana sudah cukup asal konsisten:

console.log(JSON.stringify({
  level: "error",
  feature: "checkout",
  action: "create_order",
  requestId,
  userId,
  error: err.message,
  durationMs
}))

Nggak harus langsung sempurna. Yang penting log menjawab empat pertanyaan:

  • Apa yang terjadi? misalnya create_order_failed.
  • Di mana terjadi? nama fitur, route, atau job.
  • Kapan dan seberapa lama? timestamp dan durasi.
  • Bisa ditelusuri nggak? pakai requestId atau identifier lain.

Kalau lu cuma punya waktu 30 menit buat memperbaiki project lama, rapikan log di jalur paling penting dulu: login, pembayaran, upload, export, atau fitur yang paling sering dipakai user.

Trace itu bukan cuma buat perusahaan besar

Tracing sering terdengar berat, padahal konsep dasarnya sederhana. Sentry mendefinisikan tracing sebagai cara melacak perjalanan request atau operasi di dalam aplikasi, termasuk durasi dan relasi antarkomponen. Untuk developer solo, trace bisa diterjemahkan sebagai “peta perjalanan satu request”.

Misalnya user klik tombol “Generate invoice”. Di balik layar, aplikasi mungkin melakukan validasi, ambil data order, panggil API pembayaran, simpan PDF, lalu kirim email. Kalau prosesnya lambat, log biasa sering cuma bilang “request selesai 8 detik”. Trace bantu lu melihat bagian mana yang makan waktu paling banyak.

Kalau belum siap pasang tracing lengkap, lu bisa mulai dengan versi manual:

const startedAt = Date.now()
const marks = []

marks.push(["validate_input", Date.now() - startedAt])
marks.push(["fetch_order", Date.now() - startedAt])
marks.push(["generate_pdf", Date.now() - startedAt])
marks.push(["send_email", Date.now() - startedAt])

console.log(JSON.stringify({
  level: "info",
  action: "generate_invoice_trace",
  requestId,
  marks,
  totalMs: Date.now() - startedAt
}))

Ini belum secanggih OpenTelemetry, tapi cukup buat menemukan bottleneck awal. Kalau project mulai serius, baru lu pertimbangkan instrumentation yang lebih standar agar data bisa dikirim ke tool observability.

Simpan bukti deploy dan hasil test

Observability bukan cuma apa yang terjadi saat runtime. Jejak build dan deploy juga penting. GitHub Actions punya konsep workflow artifacts: file yang dihasilkan workflow dan bisa disimpan untuk dipakai setelah job selesai. Buat side project, artefak ini bisa berupa hasil test, screenshot Playwright, bundle report, coverage, atau file export.

Kenapa ini penting? Karena banyak bug muncul setelah deploy, lalu pertanyaan pertama biasanya: “Perubahan terakhir apa?” Kalau lu punya artefak deploy, lu bisa cek:

  • commit mana yang naik ke production,
  • test apa yang jalan sebelum deploy,
  • screenshot UI sebelum dan sesudah perubahan,
  • asset atau export apa yang dihasilkan pipeline.

Untuk personal branding, ini juga bahan konten yang kuat. Lu bisa bikin carousel “cara gua ngecek deploy side project sebelum tidur” dengan screenshot CI, checklist, dan contoh failure. Itu jauh lebih kredibel daripada sekadar quote motivasi soal konsisten bikin produk.

Checklist observability kecil yang realistis

Kalau lu mau mulai minggu ini, jangan langsung bikin sistem besar. Pakai checklist kecil ini:

  • 1. Tambahkan request ID. Setiap request penting harus punya ID yang muncul di log.
  • 2. Rapikan log error. Minimal ada fitur, action, pesan error, dan konteks aman tanpa data sensitif.
  • 3. Catat durasi proses utama. Fokus ke fitur yang lambat atau punya banyak step.
  • 4. Simpan artefak CI. Screenshot, report test, atau file build yang membantu investigasi.
  • 5. Buat runbook pendek. Tulis langkah cek pertama saat error muncul.
  • 6. Review seminggu sekali. Cari error berulang, bukan cuma error paling heboh.

Checklist ini sengaja sederhana. Tujuannya supaya lu benar-benar jalan, bukan berhenti karena merasa butuh dashboard mahal dulu.

Hal yang perlu dijaga: jangan log data sensitif

Log yang terlalu detail bisa jadi masalah keamanan. Jangan asal mencatat password, token, session cookie, nomor identitas, data pembayaran, atau payload pribadi user. Prinsipnya: log harus cukup buat debug, tapi nggak boleh jadi tempat bocornya data sensitif.

Kalau butuh konteks user, pakai ID internal. Kalau butuh payload, simpan field yang relevan saja. Kalau error dari API eksternal terlalu panjang, ringkas pesan dan simpan kode error. Ini bagian yang sering dilupakan developer karena saat debugging kita ingin melihat semua hal. Tapi sistem yang sehat bukan cuma mudah dicek, ia juga aman saat dicek.

Angle konten: ubah debugging jadi aset personal branding

Gua suka angle ini karena observability kecil menghubungkan skill teknis dengan storytelling. Lu bisa bikin banyak turunan konten dari satu setup sederhana:

  • Video pendek: “side project gua error, ini 3 log yang langsung gua cek.”
  • Carousel: “checklist observability buat developer solo.”
  • Thread: “kenapa log rapi bikin AI coding agent lebih berguna.”
  • Artikel lanjutan: “cara bikin request ID di Nuxt API atau Cloudflare Workers.”

Konten seperti ini memperlihatkan lu bukan cuma builder yang bisa bikin fitur, tapi operator yang paham cara merawat sistem. Buat audiens Indonesia yang lagi belajar software development, ini relatable banget karena banyak yang baru sadar pentingnya observability setelah project pertama mulai dipakai orang.

FAQ singkat

Apakah side project wajib pakai OpenTelemetry?

Nggak wajib. OpenTelemetry bagus sebagai standar, tapi side project bisa mulai dari log terstruktur, request ID, dan catatan durasi manual. Kalau traffic dan kompleksitas naik, baru pertimbangkan instrumentation lebih serius.

Tool observability apa yang paling penting dulu?

Mulai dari tool yang sudah tersedia di platform lu. Kalau pakai Cloudflare Workers, manfaatkan log platform. Kalau pakai GitHub Actions, simpan artifact penting. Kalau pakai Sentry, mulai dari error tracking dan tracing dasar.

Apakah observability bisa jadi konten personal branding?

Bisa banget. Justru proses debugging, deploy, dan monitoring sering lebih menarik daripada hasil akhir. Orang bisa belajar dari keputusan teknis lu, bukan cuma melihat produk jadi.

Takeaway

Observability kecil bukan proyek tambahan yang ribet. Ini kebiasaan kerja: catat sinyal penting, simpan bukti deploy, dan bikin sistem lu lebih mudah dipahami saat ada masalah. Buat developer yang ingin dikenal sebagai builder, kebiasaan ini jadi pembeda. Lu nggak cuma membuat sesuatu yang kelihatan jalan, lu juga menunjukkan cara menjaga project tetap bisa dipercaya.

Referensi / Bacaan Lanjut

Tags:
#Software Development#Developer Workflow#Observability#Debugging#Personal Branding