# Apa Itu Technical Debt: Pandangan Platform Engineer URL: https://upstreamapi.com/id/journal/apa-itu-technical-debt Type: blog Locale: id Published: 2026-09-26 Updated: 2026-09-26 --- > Bagi platform engineer, technical debt bukan soal kode quality score. Ini adalah risiko deployment yang terakumulasi, memperlebar blast radius, dan selalu muncul di post-mortem insiden production. ## Apa Itu Technical Debt: Pandangan Platform Engineer Pukul 02.47. Notifikasi PagerDuty berbunyi. Anda membuka laptop, melihat deployment yang stuck pada tahap rollout ketiga dari lima, dan menyadari bahwa service yang bermasalah menggunakan library authentication yang sudah deprecated sejak dua tahun lalu. Tiket untuk migrasinya ada di backlog. Sudah ada di sana selama empat sprint. Tidak pernah masuk ke sprint aktif karena selalu ada hal yang lebih mendesak. Apa itu technical debt? Bukan itu definisi formalnya. Tapi itulah bagaimana utang teknis terasa pukul tiga pagi, ketika deployment gagal dan Anda tidak yakin seberapa jauh dampaknya akan meluas. ## Technical Debt Bukan Soal Kode yang Kurang Rapi Sebagian besar engineer pertama kali mendengar "technical debt" dalam konteks code review: fungsi yang terlalu panjang, nama variabel yang tidak deskriptif, test coverage yang tipis. Definisi itu tidak salah, tapi terlalu sempit untuk seorang platform engineer yang bertanggung jawab atas keandalan sistem secara keseluruhan. Technical debt adalah keputusan teknis yang menunda biaya jangka panjang demi kecepatan jangka pendek. Setiap kali tim memilih solusi yang "cukup untuk sekarang" daripada solusi yang tepat, mereka sedang menambah saldo utang. Itu bisa berupa arsitektur yang diambil karena deadline mepet, dependency yang tidak diupdate karena tidak ada bandwidth, abstraksi yang dilewati karena sprint sudah penuh, atau dokumentasi yang tidak pernah ditulis karena dianggap bisa nanti. Ward Cunningham, yang memperkenalkan metafora ini di awal 1990-an, selalu menekankan bahwa utang teknis tidak secara inheren buruk. Masalahnya adalah ketika utang dibiarkan tanpa manajemen aktif, ia berbunga. Setiap lapisan kompleksitas yang ditambahkan di atas fondasi yang lemah membuat sistem semakin mahal untuk diubah, semakin sulit untuk dipahami, dan semakin rentan terhadap kegagalan yang tidak terduga. Dalam perspektif SRE dan platform engineering, utang teknis adalah liabilitas operasional. Ia tidak diam di codebase, tidak terasa sampai Anda mencoba mengubah sesuatu atau sampai sesuatu pecah di tengah malam. ![Tim engineering sedang meninjau arsitektur teknis dan merencanakan strategi refactoring](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/4fe267-img-2.webp) ## Dua Jenis Technical Debt yang Perlu Dibedakan Tidak semua utang teknis lahir dari kelalaian. Ada perbedaan penting yang menentukan bagaimana Anda harus meresponsnya: **Utang yang disengaja:** Tim memutuskan secara sadar untuk mengambil jalan pintas karena alasan bisnis yang valid. "Kita deploy dulu dengan hardcoded config, nanti setelah validasi produk kita buat service config yang proper." Utang ini tidak berbahaya selama ada catatan eksplisit tentang keputusan tersebut, batas waktu yang disepakati, dan kapasitas aktual untuk membayarnya sebelum bertumpuk. **Utang yang tidak disengaja:** Muncul dari kurangnya pengetahuan, komunikasi yang buruk antar tim, atau tekanan waktu yang tidak terkelola. Ini jauh lebih umum, dan jauh lebih berbahaya, karena tidak ada yang tahu kapan tagihan akan datang atau seberapa besar jumlahnya. Tim sering baru menyadari keberadaannya saat sedang menghadapi insiden. Platform engineers yang efektif tahu cara membedakan keduanya di backlog mereka. Saat melakukan triage, pertanyaan pertama selalu: apakah seseorang pernah secara sadar memutuskan ini, atau kita baru saja menemukan bahwa sistem bekerja dengan cara yang tidak ada yang dokumentasikan? ## DORA Metrics Memberikan Sinyal Sebelum Insiden Terjadi DORA metrics bukan sekadar laporan untuk ditampilkan di quarterly review. Mereka adalah sistem deteksi dini yang jujur tentang kesehatan operasional sistem Anda, dan technical debt hampir selalu terlihat di dalamnya sebelum ia memunculkan insiden. Deployment frequency yang menurun secara konsisten jarang karena tim malas atau kurang termotivasi. Lebih sering karena setiap deployment semakin kompleks, membutuhkan lebih banyak koordinasi antar tim, dan membawa risiko regresi yang semakin besar. Itu adalah gejala technical debt yang sudah mencapai level operasional, bukan lagi sekadar masalah kode. Lead time for changes yang terus naik dari hitungan jam ke hitungan hari mengindikasikan satu hal: terlalu banyak konteks yang harus dipahami sebelum seseorang berani mengubah kode. Itu bukan masalah produktivitas individu. Itu adalah tanda bahwa arsitektur sudah tidak readable bagi siapapun selain orang yang menulisnya, dan knowledge tersebut semakin menjadi risiko single point of failure. Dalam laporan DORA Research, elite performers melakukan deployment 182 kali lebih sering dibandingkan tim di kuartil bawah, dengan MTTR di bawah satu jam versus lebih dari satu minggu untuk insiden yang sebanding. Gap sebesar itu tidak terbentuk karena perbedaan bakat. Gap itu terbentuk karena perbedaan dalam cara kedua kelompok mengelola utang teknis mereka selama bertahun-tahun. Change failure rate yang tinggi adalah sinyal paling langsung. Jika lebih dari 15% deployment Anda memicu rollback atau hotfix darurat, ada sesuatu yang fundamental salah dalam sistem, dan jawabannya hampir pasti bukan di deployment pipeline itu sendiri. ## Empat Kategori Technical Debt Berdasarkan Risiko Operasional Tidak semua utang teknis setara bobotnya. Cara yang paling efektif untuk memprioritaskan adalah mengklasifikasikannya berdasarkan dampak operasional, bukan berdasarkan seberapa buruk rasanya secara teknis. **Kategori 1: Debt Infrastruktur Kritis** Komponen yang, ketika gagal, berdampak langsung pada SLO. Termasuk dependency yang sudah end-of-life, konfigurasi security yang tidak diperbarui, service tanpa fallback atau circuit breaker yang teruji. Ini harus masuk backlog dengan prioritas tertinggi dan tidak perlu menunggu sprint planning berikutnya. **Kategori 2: Debt Observabilitas** Service tanpa distributed tracing yang memadai, log yang tidak terstruktur, alert yang terlalu banyak noise dan false positive. Ketika insiden terjadi, debt observabilitas langsung memperpanjang MTTD (Mean Time to Detect) dan memperlambat respons seluruh tim. Tim yang tidak bisa mendiagnosis masalah dengan cepat akan selalu berjuang menekan MTTR. **Kategori 3: Debt Arsitektur** Coupling yang terlalu ketat antar service, bounded context yang tidak jelas, data model yang dipaksakan untuk kebutuhan yang sudah jauh berubah. Kategori ini biasanya tidak menyebabkan insiden langsung, tapi menjadi akselerator risiko ketika jenis masalah lain muncul, dan ia membuat setiap perubahan baru jauh lebih mahal dari seharusnya. **Kategori 4: Debt Operasional** Runbook yang tidak pernah diupdate, proses deployment manual yang tidak terdokumentasi, knowledge yang hanya ada di kepala satu atau dua orang. Kategori ini sering dianggap tidak urgent sampai satu-satunya engineer yang memahami sistem tersebut sedang berlibur, sakit, atau resign. ![Developer sedang meninjau kode legacy yang kompleks dengan banyak log error di layar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/311630-img-3.webp) ## Cara Triage Technical Debt Seperti Production Alert Platform engineers sudah terlatih melakukan triage production alert dengan cepat dan sistematis: severity, blast radius, urgency. Prinsip yang sama berlaku ketika Anda menilai item-item di backlog teknis. Sebelum memutuskan prioritas, jawab pertanyaan-pertanyaan ini untuk setiap item: - Jika komponen ini gagal hari ini, berapa besar blast radius-nya? Satu service, satu domain bisnis, atau seluruh platform? - Apakah ada observabilitas yang cukup untuk memberi tahu tim sebelum pengguna merasakan dampaknya? - Berapa rata-rata waktu yang dibutuhkan untuk debug ketika masalah muncul di area ini? - Apakah ada single point of failure dari sisi knowledge, bukan hanya dari sisi infrastruktur? - Dalam 90 hari terakhir, berapa insiden yang root cause-nya ada di komponen ini? Jawaban atas lima pertanyaan itu jauh lebih berharga dari angka complexity score dari tool manapun. Tool bisa membantu mengukur dan memvisualisasikan utang teknis, tapi judgment tentang dampak operasional tetap ada di tangan engineer yang memahami konteks production dan sejarah insiden sistem tersebut. Prioritas tertinggi bukan selalu untuk kode yang paling rumit atau paling lama tidak disentuh. Prioritas tertinggi adalah untuk utang yang paling sering berkontribusi pada insiden dan yang blast radius-nya paling lebar ketika gagal. ## Mengukur Technical Debt: Angka Berguna, Konteks Lebih Berguna Tool seperti SonarQube, CodeScene, dan Datadog memberikan angka yang terukur: technical debt ratio, code health score, coupling metrics, hotspot analysis. Angka-angka ini berguna sebagai titik awal untuk diskusi dan sebagai cara melihat tren, tapi berbahaya jika dijadikan satu-satunya dasar pengambilan keputusan. Technical debt yang paling mematikan dalam sistem production sering kali tidak terdeteksi oleh static analysis. Utang arsitektur yang hanya terlihat ketika Anda mencoba mengubah sesuatu secara signifikan. Utang operasional yang baru terasa ketika satu-satunya orang yang paham sistem itu tidak bisa on-call. Utang observabilitas yang membuat MTTD melonjak dari menit ke jam ketika insiden terjadi. Metric operasional yang lebih jujur dari code complexity score: - Berapa lama rata-rata PR review untuk service ini dibandingkan service lain dengan kompleksitas serupa? - Seberapa sering deployment ke service ini memicu hotfix dalam 48 jam pertama setelah release? - Berapa insiden dalam 90 hari terakhir yang root cause-nya ada di komponen ini? - Bisakah engineer baru setup, jalankan, dan debug service ini secara mandiri dalam dua jam dengan dokumentasi yang ada? Jawaban atas pertanyaan-pertanyaan itu lebih mencerminkan kondisi sebenarnya daripada skor dari dashboard manapun, dan jauh lebih mudah dikomunikasikan kepada stakeholder non-teknis yang perlu memahami implikasi bisnisnya. ## Technical Debt Tidak Dibayar dengan Niat, Tapi dengan Alokasi "Kita akan refactor nanti" adalah kalimat yang paling sering muncul sebelum insiden paling parah. Nanti tidak pernah datang tanpa alokasi kapasitas yang eksplisit dan komitmen yang dipegang konsisten dari sprint ke sprint. Tim yang berhasil mengelola technical debt tidak menunggu sprint khusus refactoring yang selalu terdorong mundur ketika ada feature baru yang lebih mendesak. Mereka mengalokasikan persentase tetap dari kapasitas sprint, biasanya antara 15-20%, secara konsisten setiap sprint untuk pekerjaan yang langsung mengurangi risiko operasional. Ini bukan kemewahan. Ini adalah praktik engineering yang mempertahankan deployment velocity jangka panjang. Cara meyakinkan stakeholder yang berfokus pada feature velocity: tunjukkan data sebelum dan sesudah. Ketika tim dapat mendemonstrasikan bahwa menangani technical debt di area tertentu menghasilkan penurunan change failure rate yang konkret dalam satu kuartal, atau MTTR yang lebih pendek secara konsisten, percakapan tentang prioritas menjadi berbeda. Angka-angka itu ada di DORA metrics Anda. Anda hanya perlu mengukurnya sebelum dan sesudah, bukan hanya setelah. Utang teknis bukan masalah masa depan. Ia adalah risiko yang berjalan sekarang, terakumulasi setiap sprint, dan menagih bunganya pada saat yang paling tidak nyaman: ketika Anda sedang melakukan rollout fitur penting, atau ketika traffic pengguna sedang di puncaknya. Post-mortem berikutnya akan bertanya: mengapa tidak ada yang tahu komponen ini bekerja dengan cara seperti itu? Jawaban untuk pertanyaan itu ada di backlog yang tidak pernah disentuh. ## FAQ ### Apa itu technical debt dalam konteks software engineering? Technical debt adalah akumulasi keputusan teknis yang menunda biaya jangka panjang demi kecepatan jangka pendek. Ini bisa berupa arsitektur yang tidak optimal, dependency yang outdated, atau dokumentasi yang tidak lengkap. Dalam perspektif SRE, utang teknis adalah liabilitas operasional yang terus tumbuh sampai dibayar secara aktif. ### Apa perbedaan utang teknis yang disengaja dan yang tidak disengaja? Utang yang disengaja dibuat dengan keputusan sadar dan terdokumentasi, umumnya dapat dikelola jika ada batas waktu yang jelas. Yang berbahaya adalah utang tidak disengaja yang muncul dari kurangnya pengetahuan atau tekanan waktu, karena tidak ada yang tahu kapan dan seberapa besar tagihan akan datang. ### Bagaimana DORA metrics membantu mengidentifikasi technical debt? DORA metrics bukan pengukur langsung technical debt, tapi mereka menunjukkan dampaknya. Deployment frequency yang menurun, lead time yang naik, dan change failure rate yang tinggi sering merupakan gejala utang teknis yang sudah mencapai level operasional. Gunakan tren DORA untuk menentukan area yang perlu audit lebih dalam. ### Berapa persen kapasitas sprint yang sebaiknya dialokasikan untuk membayar technical debt? Tim yang efektif mengalokasikan 15-20% kapasitas sprint secara konsisten untuk mengurangi utang teknis berrisiko tinggi. Persentase ini bukan aturan mutlak, tapi benchmark yang terbukti. Yang penting adalah konsistensi: sprint khusus refactoring yang tidak rutin hampir selalu terdorong mundur oleh feature baru. ### Tool apa yang paling efektif untuk mengukur technical debt? SonarQube dan CodeScene bagus untuk static analysis dan code health metrics. Datadog efektif untuk mengukur dampak operasional melalui DORA metrics dan deployment analytics. GitHub Copilot membantu dalam proses refactoring. Namun ingat, angka dari tool hanyalah titik awal. Konteks operasional dan sejarah insiden lebih menentukan prioritas. ### Kapan technical debt harus diprioritaskan di atas feature development? Segera, ketika komponen bermasalah terlibat dalam lebih dari dua insiden dalam 90 hari, ketika change failure rate di service tersebut konsisten tinggi, atau ketika hanya satu atau dua orang yang benar-benar memahami cara kerjanya. Kondisi ini menandakan utang sudah berada di jalur yang akan menyebabkan insiden besar. ### Bagaimana cara meyakinkan stakeholder untuk mengalokasikan waktu pada technical debt? Gunakan data DORA sebelum dan sesudah penanganan utang teknis. Tunjukkan bahwa mengurangi utang di area tertentu menghasilkan penurunan change failure rate dan MTTR yang konkret dan terukur. Framing yang efektif: ini bukan maintenance cost, ini investasi untuk mempertahankan deployment velocity dan mengurangi risiko insiden jangka panjang.