Di prod berfungsi: apa itu, mengapa terjadi dan apa bahayanya

Apa arti frase “di prod berfungsi”

“Di prod berfungsi” — ini adalah ungkapan tetap di kalangan pengembang yang menggambarkan situasi ketika kode berfungsi di server produksi tetapi menolak bekerja di lingkungan pengujian atau di mesin lokal rekan kerja. Secara lahiriah terdengar seperti “tidak ada masalah”, padahal sebenarnya masalah itu ada — hanya saja tidak muncul di lingkungan produksi. Akar perbedaan terletak pada perbedaan konfigurasi, versi, dan data antar lingkungan.

Frasa ini lahir sebagai lawan dari alasan terkenal lainnya — “Di lokal saya berfungsi”. Jika pengembang mengatakan “lokal berfungsi”, berarti bug hanya ada pada orang lain. Dan jika “di prod berfungsi” — bug hanya ada di staging atau lingkungan pengujian, tetapi produksi bersih. Ironi nasib: dalam kedua kasus masalahnya nyata, hanya saja tidak muncul pada orang yang melihat. Menurut penelitian DevOps Research and Assessment (DORA) 2023, tim dengan tingkat otomatisasi penyebaran tinggi menghadapi perbedaan seperti ini 3 kali lebih jarang.

Dari sudut pandang bisnis, situasi “di prod berfungsi” lebih berbahaya dari yang terlihat. Jika bug ada di staging tetapi tidak di produksi, pengembang dapat mengabaikannya — dan pada penyebaran berikutnya kesalahan akan masuk ke produksi. Kelegaan sementara berubah menjadi masalah masa depan yang harus diperbaiki di bawah tekanan pengguna.

Mengapa pengembang mengatakan “di prod berfungsi”

Alasan psikologis dari ketahanan frase ini — refleks defensif. Pengembang yang melihat bug di staging tetapi tidak di produksi, secara tidak sadar dapat meremehkan masalah: “kalau di produksi semuanya baik, berarti ini tidak mendesak”. Bias kognitif klasik — kesalahan survivor, di mana kesuksesan produksi yang terlihat lebih besar daripada ancaman potensial dari kegagalan di masa depan.

Alasan kedua — tanggung jawab yang kabur. Jika produksi berfungsi tetapi staging tidak, yang bersalah adalah lingkungan, bukan kode. Pengembang melepaskan tanggung jawab atas bug, melimpahkannya ke insinyur DevOps atau administrator. Menurut Atlassian State of DevOps 2022, dalam tim tanpa lingkungan penyebaran terpadu (Docker, Kubernetes), pelimpahan tanggung jawab seperti itu terjadi 60% lebih sering.

Alasan ketiga — takut akan rilis dengan zero downtime. Jika pengembang memperbaiki bug di staging dan meluncurkan perbaikan, ini akan memerlukan code review ulang, pengujian, dan deploy. Frase “di prod berfungsi” memungkinkan menunda perbaikan hingga rilis berikutnya, mengurangi beban saat ini. Perbaikan yang ditunda — salah satu penyebab utama akumulasi utang teknis dalam tim.

Perbedaan antara lingkungan pengembangan dan produksi

Produksi dan staging tidak pernah sepenuhnya identik — ini secara teknis tidak mungkin karena perbedaan skala, beban, dan data. Namun, parameter kunci harus cocok: versi sistem operasi, compiler, interpreter, basis data, server web, dan semua dependensi proyek. Jika setidaknya satu parameter berbeda — perilaku kode dapat berubah.

Perbedaan utama antara lingkungan meliputi:

• Perangkat keras — prosesor, jumlah RAM, jenis disk (SSD vs HDD) dapat memengaruhi waktu dan kerja multithreading
• Lingkungan jaringan — firewall, DNS, proxy, load balancer hanya ada di produksi
• Data di basis data — di staging biasanya data pengujian, sedangkan catatan pengguna nyata memiliki pola yang tidak terduga
• Versi dependensi — bahkan pembaruan kecil pada pustaka dapat mengubah perilaku kode
• Variabel lingkungan — kunci API, token, flag fitur dapat berbeda antar lingkungan

Kontainerisasi menyelesaikan sebagian besar masalah ini. Image Docker yang dibangun untuk produksi harus digunakan juga di staging. Satu-satunya perbedaan — variabel lingkungan dan pemasangan volume. Menurut Docker State of Application Development 2023, tim yang menggunakan satu image untuk semua lingkungan mengurangi jumlah perbedaan hingga 74%.

Penyebab umum ketidaksesuaian perilaku di produksi

Penyebab pertama dan paling umum — versi dependensi yang berbeda. Pengembang menginstal paket secara lokal dengan flag --save, tetapi lupa memperbarui package.json atau file lock. Saat penyebaran ke produksi, versi lain diinstal yang berperilaku berbeda. Untuk ekosistem npm, file lock sepenuhnya menyelesaikan masalah, untuk manajer paket lain — mekanisme serupa (Gemfile.lock, Podfile.lock, pubspec.lock).

Penyebab kedua — variabel lingkungan yang hilang atau berlebih. Pengembang menggunakan file .env di mesin lokal, tetapi tidak menambahkan variabel yang sesuai ke pipeline CI/CD atau server. Hasilnya — kode gagal dengan kesalahan koneksi ke API atau basis data. Menurut GitLab DevSecOps Survey 2023, 27% insiden di produksi terkait dengan variabel lingkungan yang tidak benar.

Penyebab ketiga — status basis data. Di staging, basis data mungkin berisi catatan yang tidak ada di produksi, atau sebaliknya — migrasi tidak lengkap. Skenario tipikal: pengembang menulis kode yang bekerja dengan bidang baru di tabel, tetapi migrasi belum diterapkan di produksi. Strategi migrasi dengan kompatibilitas mundur — satu-satunya cara untuk menghindari situasi seperti ini.

Penyebab keempat — pengaturan regional dan bahasa. Pemformatan tanggal, pemisah angka desimal, encoding teks — semua ini dapat berbeda di mesin lokal pengembang dan server. Sangat relevan untuk proyek dengan internasionalisasi. Solusi — secara eksplisit menentukan locale dalam konfigurasi aplikasi dan tidak bergantung pada pengaturan sistem.

Cara mendiagnosis masalah “di prod berfungsi”

Langkah pertama — membandingkan log kedua lingkungan. Perbedaan level logging sering menyembunyikan penyebab: di produksi mungkin aktif INFO, di staging DEBUG. Atur level logging yang sama dan pastikan kedua lingkungan menulis dalam format yang memungkinkan perbandingan mesin. Gunakan sistem pengumpulan log terpusat — Sentry, Datadog, ELK Stack.

Langkah kedua — memeriksa versi dependensi. Bandingkan file lock, tampilkan daftar paket yang terinstal di kedua lingkungan. Perbedaan dalam versi minor atau patch — penyebab paling mungkin dari perbedaan. Alat seperti npm ls, pip freeze, mvn dependency:tree membantu dengan cepat mengidentifikasi ketidaksesuaian.

Langkah ketiga — mereproduksi lingkungan produksi secara lokal. Gunakan Docker Compose atau alat serupa untuk membuat salinan persis infrastruktur produksi. Jika bug muncul di kontainer lokal — masalahnya ada di kode, bukan lingkungan. Jika tidak muncul — cari perbedaan dalam konfigurasi.

Langkah keempat — memeriksa feature flags dan pengujian A/B. Mungkin di produksi kode berfungsi dalam mode berbeda karena flag yang salah aktif. Menurut LaunchDarkly State of Feature Management 2023, hingga 40% perilaku tak terduga di produksi terkait dengan nilai feature flags yang tidak benar. Manifest flag terpadu untuk semua lingkungan menyelesaikan masalah ini.

Mencegah perbedaan lingkungan dalam proyek

Alat utama pencegahan — Infrastructure as Code (IaC). Semua lingkungan harus dideskripsikan dalam kode: Dockerfile, docker-compose.yml, skrip Terraform, atau playbook Ansible. Perubahan manual di server dilarang — setiap perubahan konfigurasi melalui repositori dan code review. Ini memastikan bahwa semua lingkungan memiliki konfigurasi yang sama.

Alat kedua terpenting — pipeline CI/CD terpadu. Skrip build, pengujian, dan deploy yang sama harus digunakan untuk semua lingkungan. Perbedaan hanya pada variabel target (URL, kunci). Jika pipeline untuk staging dan produksi berbeda dalam langkah-langkah — perbedaan tidak terhindarkan.

Alat ketiga — sinkronisasi data otomatis. Perbarui staging secara teratur (sekali sehari atau sesuai jadwal) dengan salinan basis data produksi yang dianonimkan. Ini memungkinkan pengujian kode pada data nyata, bukan pada fixture sintetis. Alat: pg_dump/pg_restore untuk PostgreSQL, mysqldump untuk MySQL, layanan khusus seperti DataGrip.

Keempat — monitoring perbedaan. Konfigurasikan pemberitahuan saat mendeteksi perbedaan antara staging dan produksi. Skrip sederhana yang membandingkan hash file konfigurasi atau versi paket yang terinstal akan menghemat waktu debugging berjam-jam. Pencegahan selalu lebih murah daripada diagnosis: mencegah perbedaan lingkungan membutuhkan lebih sedikit usaha daripada mencari penyebab bug “di prod berfungsi”.