Ada satu kesalahan yang hampir semua tim engineering lakukan di awal: baru mulai mengukur setelah ada yang rusak.
Error melonjak baru pasang monitoring. Deployment sering gagal baru pikirkan change failure rate. Kode susah di-maintain baru sadar tidak ada test coverage.
Padahal metrik bukan sekadar alarm. Metrik adalah cara kamu memahami sistem sebelum sistem itu bermasalah.
---
Kenapa Metrik Itu Penting?
Tanpa metrik, kamu mengelola sistem secara tebak-tebakan.
Kamu tidak tahu apakah kode yang kamu tulis kemarin membuat sistem lebih stabil atau justru lebih rapuh. Kamu tidak tahu apakah deployment tadi memperlambat respons atau tidak. Kamu tidak tahu berapa lama tim butuh untuk pulih dari insiden.
Metrik mengubah perasaan menjadi fakta. Dan fakta adalah satu-satunya dasar keputusan yang solid.
Ada hal lain yang sering luput: metrik teknis adalah leading indicator, sedangkan keluhan user adalah lagging indicator. Ketika user sudah lapor, masalah sudah terlanjur terjadi — dan dalam bisnis, masalah yang terlanjur terjadi biasanya sudah meninggalkan kerugian. Tim yang hanya monitor keluhan user selalu bereaksi. Tim yang monitor metrik bisa antisipatif.
Yang menarik adalah: tidak semua metrik perlu diukur di waktu yang sama. Ada yang bisa — dan seharusnya — dimulai sejak hari pertama coding. Ada yang relevan setelah sistem berjalan di production. Ada yang baru bermakna ketika tim mulai berkolaborasi.
---
Sejak Hari Pertama Coding
Ini metrik yang tidak perlu menunggu production. Kamu bisa mulai mengukurnya hari ini, bahkan sebelum ada user.
| Metrik | Target | Kenapa wajib |
|---|---|---|
| Test coverage | ≥ 80% | Jaring pengaman utama |
| Cyclomatic complexity | ≤ 10 per fungsi | Kode kompleks = bug magnet |
| Linting errors | 0 | Standar kode konsisten |
Test Coverage: Jaring Pengaman Utama
Test coverage mengukur seberapa banyak kode yang dieksekusi saat test suite berjalan. Target 80% bukan angka ajaib — tapi angka yang cukup realistis untuk dicapai sambil tetap produktif.
Yang lebih penting dari angka coverage-nya adalah apa yang tidak tercakup. Coverage rendah di bagian business logic yang kritis jauh lebih berbahaya daripada coverage rendah di boilerplate konfigurasi.
Mulailah dengan menulis test untuk happy path terlebih dahulu. Lalu tambahkan edge case secara bertahap. Jangan kejar 100% — kejar coverage di tempat yang paling berisiko.
Dalam konteks bisnis, test coverage rendah adalah hutang yang bunganya dibayar lewat waktu. Semakin besar kodebase, semakin lama waktu debug setiap kali ada perubahan. Tim yang tidak mengukur ini biasanya baru sadar ketika velocity turun drastis setelah 6–12 bulan — dan di saat itu, biaya per fitur sudah jauh lebih mahal dari yang seharusnya.
Cyclomatic Complexity: Kode Kompleks adalah Bug Magnet
Cyclomatic complexity mengukur jumlah jalur independen yang ada di dalam sebuah fungsi. Setiap if, for, while, case menambah satu jalur baru.
Fungsi dengan complexity di atas 10 biasanya menandakan dua hal: fungsi itu terlalu banyak tanggung jawab, atau logikanya bisa disederhanakan.
Semakin tinggi complexity, semakin banyak kasus yang harus diuji. Semakin banyak kasus yang harus diuji, semakin besar kemungkinan ada yang terlewat. Itulah mengapa kode kompleks selalu menjadi tempat bug bersembunyi.
Sebagian besar linter modern bisa mengukur ini secara otomatis. Aktifkan rule-nya sejak awal.
Dari sisi bisnis, complexity tinggi berarti waktu onboarding engineer baru lebih lama. Engineer baru yang butuh dua minggu untuk memahami satu modul adalah engineer yang tidak produktif selama dua minggu — dan itu biaya nyata yang tidak pernah muncul di laporan, tapi selalu terasa di timeline.
Linting Errors: Standar Kode yang Konsisten
Zero linting errors bukan soal estetika. Linting menangkap pola kode yang secara statistik lebih sering menjadi sumber bug — variabel yang tidak digunakan, type coercion yang tidak disengaja, promise yang tidak di-await.
Lebih dari itu, linting membuat kode tim terasa ditulis oleh satu orang. Konsistensi mengurangi cognitive load saat code review. Dan cognitive load yang lebih rendah artinya reviewer bisa fokus ke logika, bukan ke gaya penulisan.
Secara bisnis, ini soal overhead tersembunyi. Setiap PR review yang habis membahas format dan style adalah waktu engineer senior yang bisa dipakai untuk hal yang lebih bernilai. Zero linting errors bukan obsesi kerapihan — ini investasi di efisiensi proses.
---
Sejak Pertama Deploy
Begitu sistem berjalan di production — bahkan di staging — ada set metrik baru yang harus dipantau.
| Metrik | Target | Kenapa wajib |
|---|---|---|
| Error rate | < 1% | Tahu masalah sebelum user lapor |
| Response time (p95) | < 500ms | Performa baseline |
| Availability / uptime | ≥ 99.5% | Sistem bisa diandalkan |
Error Rate: Tahu Masalah Sebelum User Lapor
Error rate adalah persentase request yang menghasilkan error dibanding total request. Target di bawah 1% bukan berarti boleh ada 1 error dari setiap 100 request — di skala besar, 1% itu bisa berarti ribuan user yang mengalami masalah setiap jamnya.
Yang membuat error rate penting bukan hanya angkanya, tapi trennya. Error rate yang naik perlahan setelah deployment adalah sinyal jelas bahwa ada sesuatu yang salah — bahkan sebelum user pertama mengirim email komplain.
Pasang alerting sejak awal. Satu email notifikasi ketika error rate melewati threshold bisa menghemat jam-jam penyelidikan di kemudian hari.
Terjemahan bisnisnya langsung: jika conversion rate aplikasimu 3% dan error rate-mu 2%, artinya lebih dari separuh potensi transaksi sedang bermasalah. Error rate bukan metrik teknis semata — ini metrik pendapatan yang kebetulan dipantau oleh engineering.
Response Time (p95): Performa Baseline
Response time p95 adalah waktu respons yang dialami oleh 95% user tercepat. Ini lebih bermakna dari rata-rata karena tidak mudah dimanipulasi oleh outlier.
Target di bawah 500ms untuk p95 adalah standar yang cukup konservatif — artinya bahkan user yang paling "sial" (kecuali 5% terakhir) masih mendapat respons yang wajar.
Yang penting adalah menetapkan baseline sejak awal. Ketika kamu mengubah query database atau menambahkan middleware baru, perubahan pada p95 akan langsung terlihat. Tanpa baseline, kamu tidak akan tahu kapan sistem mulai melambat.
Riset Google dan Amazon menunjukkan bahwa setiap tambahan 100ms response time dapat menurunkan pendapatan hingga 1%. Ini bukan angka yang dirasakan secara langsung — tidak ada alert yang bunyi ketika revenue turun perlahan — tapi ia terakumulasi diam-diam. Response time p95 adalah metrik bisnis yang tersamarkan sebagai metrik teknis.
Availability / Uptime: Sistem Bisa Diandalkan
99.5% uptime terdengar tinggi. Tapi artinya sistem boleh mati selama sekitar 43 menit per bulan. Untuk banyak aplikasi bisnis, itu sudah lebih dari cukup sebagai target awal.
Uptime rendah bukan hanya soal user yang tidak bisa akses. Downtime merusak kepercayaan — dan kepercayaan jauh lebih sulit dibangun kembali daripada sistem yang rusak.
Pantau uptime dari external monitoring, bukan hanya dari dalam server. Server bisa berjalan tapi application bisa mati. External monitoring adalah cara satu-satunya untuk melihat apa yang benar-benar dialami user.
Untuk bisnis, downtime punya dua kerugian: yang langsung dan yang tidak langsung. Yang langsung adalah transaksi yang gagal selama sistem mati. Yang tidak langsung adalah kepercayaan — dan kepercayaan jauh lebih mahal untuk dibangun kembali daripada memperbaiki sistem yang rusak. Jika kamu punya SLA dengan klien, uptime bukan target teknis lagi — ia adalah kontrak hukum.
---
Sejak Tim Mulai Berkolaborasi
Ketika lebih dari satu orang bekerja pada kodebase yang sama, dinamika berubah. Ada metrik engineering yang hanya bermakna dalam konteks kolaborasi.
| Metrik | Target | Kenapa wajib |
|---|---|---|
| Lead time for changes | < 1 hari | Kecepatan delivery |
| Change failure rate | < 15% | Stabilitas setiap deploy |
| MTTR | < 1 jam | Kemampuan recovery |
Lead Time for Changes: Kecepatan Delivery
Lead time mengukur berapa lama dari kode di-commit hingga berjalan di production. Target di bawah satu hari bukan berarti harus deploy setiap hari — tapi artinya pipeline kamu cukup efisien sehingga jika dibutuhkan, itu bisa dilakukan.
Lead time yang panjang biasanya disebabkan oleh satu dari tiga hal: proses review yang lambat, test suite yang terlalu lama, atau proses approval yang berlapis-lapis tanpa nilai nyata.
Identifikasi bottleneck-nya. Kadang satu perubahan kecil — seperti memparallelkan test — bisa memotong lead time dari satu minggu menjadi satu hari.
Dalam bahasa bisnis: lead time adalah kecepatan respons terhadap pasar. Tim yang bisa deploy dalam satu hari bisa merespons feedback user, memanfaatkan momentum, atau memperbaiki bug kritis sebelum kompetitor tahu ada celah. Tim yang lead time-nya dua minggu selalu telat satu langkah.
Change Failure Rate: Stabilitas Setiap Deploy
Change failure rate mengukur persentase deployment yang menyebabkan masalah di production — entah itu hotfix, rollback, atau insiden.
Target di bawah 15% bukan berarti boleh gagal 15 kali dari 100 deploy. Ini lebih sebagai batas atas yang membedakan tim dengan proses deployment yang sehat dari yang tidak.
Tim dengan change failure rate tinggi biasanya kekurangan salah satu dari dua hal: test coverage yang cukup, atau staging environment yang mencerminkan production secara akurat.
Dampak bisnisnya sering tidak terlihat secara langsung, tapi sangat nyata: tim yang sering mengalami deployment gagal akan mulai takut deploy. Ketika tim takut deploy, fitur tertahan. Ketika fitur tertahan, peluang bisnis hilang. Change failure rate tinggi bukan hanya masalah teknis — ini adalah rem yang memperlambat seluruh organisasi.
MTTR: Kemampuan Recovery
Mean Time to Recovery mengukur berapa lama rata-rata yang dibutuhkan untuk pulih dari sebuah insiden. Target di bawah satu jam bukan berarti kamu harus selalu bisa fix bug dalam satu jam — tapi artinya sistem kamu harus memiliki kemampuan rollback yang cepat, observability yang cukup untuk diagnosis, dan runbook yang jelas untuk skenario umum.
MTTR rendah adalah cerminan dari kesiapan tim. Tim yang bisa pulih cepat bukan karena mereka tidak pernah mengalami masalah — tapi karena mereka sudah berlatih dan menyiapkan infrastruktur untuk menghadapinya.
MTTR adalah angka yang CFO dan investor tanya pertama kali setelah insiden besar: "berapa lama downtime-nya?" Di balik pertanyaan itu ada kalkulasi sederhana — berapa kerugian per menit, dan apakah tim engineering sudah menyiapkan diri untuk meminimalkannya. Tim dengan MTTR rendah bukan hanya lebih andal secara teknis; mereka lebih aman secara bisnis.
---
Cara Bicara Metrik ke Non-Technical Stakeholder
Metrik teknis sering gagal dipahami bukan karena konsepnya sulit, tapi karena cara penyajiannya salah. Engineer bicara dalam bahasa sistem; bisnis bicara dalam bahasa uang, waktu, dan risiko.
Tiga terjemahan yang hampir selalu berhasil:
Uang — hitung kerugian konkret. Bukan "uptime turun 0.5%", tapi "sistem mati 43 menit bulan ini, dan selama itu tidak ada transaksi yang bisa diproses."
Waktu — tunjukkan konsekuensi ke timeline. Bukan "lead time kita dua minggu", tapi "kompetitor bisa rilis fitur baru dua minggu lebih cepat dari kita setiap siklus."
Risiko — framing sebagai asuransi. Bukan "kita perlu investasi di test coverage", tapi "tanpa ini, setiap perubahan kode adalah pertaruhan — dan kita tidak tahu sudah kalah sampai user lapor."
Ketika metrik teknis sudah bisa diterjemahkan ke tiga bahasa ini, diskusi dengan stakeholder berubah dari pembelaan menjadi percakapan.
---
Mulai dari Yang Paling Dekat
Tidak perlu langsung mengukur semua metrik ini sekaligus.
Jika kamu baru mulai coding: aktifkan linter, mulai tulis test, dan pasang tool untuk memantau complexity. Itu saja sudah lebih baik dari 80% tim yang baru mulai.
Jika kamu baru pertama deploy: pasang error tracking dan uptime monitoring sebelum announce ke siapapun. Sekecil apapun aplikasinya.
Jika tim kamu baru mulai berkolaborasi: mulailah mencatat waktu dari PR dibuat hingga merge, dan berapa banyak hotfix yang muncul setelah setiap deployment.
Metrik tidak harus sempurna untuk berguna. Bahkan data yang kasar lebih baik dari tidak ada data sama sekali.
Yang paling penting adalah mulai — dan mulai dari yang paling dekat dengan tahap kamu sekarang.