Pola Maintenance Aplikasi Laravel Agar Tetap Sehat di Production - Edisi 20260823

Aplikasi Laravel yang sudah live biasanya tidak rusak karena satu masalah besar. Lebih sering karena hal kecil yang dibiarkan menumpuk: queue gagal tidak dipantau, log penuh, dependency ketinggalan, cron diam-diam berhenti, atau query yang awalnya ringan mulai berat setelah data bertambah.

Maintenance bukan pekerjaan “kalau sempat”. Ia bagian dari operasional aplikasi. Tujuannya bukan sekadar menjaga server tetap menyala, tetapi memastikan perubahan kecil tidak berubah menjadi insiden yang mengganggu pengguna.

Ilustrasi ini merangkum konteks utama agar pembaca lebih cepat memahami topik sebelum masuk ke detail.

Mulai dari rutinitas yang realistis

Jangan langsung membuat checklist seratus poin. Untuk sebagian besar aplikasi Laravel, ritme mingguan dan bulanan sudah cukup asalkan konsisten. Yang penting, ada orang atau tim yang benar-benar melihat hasilnya, bukan hanya menjalankan command lalu lupa.

Rutinitas harian atau mingguan

Periksa error rate di aplikasi dan web server.
Lihat failed jobs pada queue. Jangan cuma mengandalkan notifikasi error masuk email.
Cek disk server, terutama folder log dan file upload.
Pastikan scheduler Laravel berjalan sesuai jadwal.
Tinjau pekerjaan yang lambat: endpoint API, job queue, serta query database.

Pada proyek yang memakai Redis dan Horizon, halaman Horizon sering jadi tempat pertama untuk melihat masalah. Job yang menumpuk biasanya bukan sekadar soal worker kurang banyak. Kadang ada API pihak ketiga yang melambat, kadang ada job yang melakukan query berulang, atau job terlalu besar dan seharusnya dipecah.

Ringkasan visual membantu menghubungkan pembahasan dengan contoh penerapan di lingkungan operasional.

Rawat queue seperti komponen utama

Queue sering dianggap fitur tambahan sampai notifikasi WhatsApp, invoice, atau sinkronisasi stok mulai terlambat. Padahal di aplikasi production, queue adalah jalur kerja utama di belakang layar.

Pasang supervisor atau systemd agar worker hidup kembali saat proses mati. Jika memakai Laravel Horizon, aktifkan dashboard dan alert untuk antrean yang terlalu panjang. Tentukan juga batas retry dengan sadar. Retry tanpa batas tidak menyelesaikan masalah; ia hanya memperpanjang antrean dan membuat beban server naik.

php artisan queue:failed
php artisan queue:retry all

Command di atas berguna, tetapi jangan langsung menjalankan queue:retry all tanpa melihat penyebabnya. Kalau kegagalannya karena kredensial API kadaluarsa, semua job akan gagal lagi dalam waktu bersamaan. Lebih aman perbaiki akar masalahnya dulu, lalu retry job yang relevan.

Jangan biarkan log menjadi tempat sampah

Log Laravel sangat membantu saat investigasi, tetapi bisa jadi masalah baru jika tidak diatur. Pernah ada kasus sederhana: partisi server penuh karena file laravel.log tumbuh terus akibat error integrasi yang berulang. Aplikasi tidak benar-benar down pada awalnya, tetapi upload file gagal dan queue ikut macet karena disk habis.

Gunakan channel log harian dengan retensi yang masuk akal. Di production, hindari mencatat payload sensitif seperti token, password, nomor identitas, atau data pembayaran. Log perlu cukup detail untuk debugging, bukan untuk menyimpan semua isi request.

'daily' => [
    'driver' => 'daily',
    'path' => storage_path('logs/laravel.log'),
    'level' => env('LOG_LEVEL', 'warning'),
    'days' => 14,
],

Untuk aplikasi yang trafiknya sudah cukup ramai, kirim log dan error ke layanan observability. Minimal, buat alert untuk exception penting, lonjakan error 5xx, dan kegagalan job berulang.

Update dependency, tapi jangan langsung di server production

Laravel, PHP, package Composer, dan ekstensi server perlu diperbarui. Namun update dependency bukan aktivitas yang cocok dilakukan dengan pola “coba saja composer update di production”. Lock file ada untuk menjaga versi yang sudah diuji tetap konsisten.

Periksa advisory keamanan dan changelog package yang dipakai.
Update pada branch terpisah.
Jalankan test, static analysis bila ada, lalu uji alur penting di staging.
Deploy menggunakan composer install --no-dev --optimize-autoloader, bukan composer update.
Siapkan rollback yang jelas jika terjadi regresi.

Catatan kecil yang sering terlewat: package yang tidak dipakai tetap punya biaya. Ia menambah permukaan risiko dan kadang memicu konflik saat upgrade Laravel. Bersihkan dependency mati ketika ada waktu maintenance.

Cache perlu dikelola, bukan sekadar dibersihkan

Laravel punya banyak cache: config, route, view, application cache, sampai cache dari Redis. Cache membantu performa, tetapi juga bisa membuat deploy terasa aneh ketika konfigurasi lama masih terbaca.

Pola yang cukup aman adalah membersihkan cache yang memang perlu saat deployment, lalu membangun ulang config dan route cache jika aplikasi mendukungnya. Hindari menjalankan php artisan optimize:clear sembarangan pada aplikasi dengan trafik tinggi tanpa memahami dampaknya, terutama bila cache tersebut dipakai untuk data aplikasi.

php artisan config:cache
php artisan route:cache
php artisan view:cache

Pastikan juga perubahan environment variable diikuti proses deployment yang benar. Mengubah .env tanpa membangun ulang config cache adalah sumber bug klasik: file sudah benar, tetapi aplikasi masih memakai nilai lama.

Database: fokus pada pertumbuhan data dan jalur rollback

Database biasanya sehat pada bulan pertama, lalu mulai terasa setelah tabel transaksi menembus ratusan ribu atau jutaan baris. Query daftar riwayat yang dulu cepat bisa tiba-tiba timeout karena indeks belum sesuai pola filter terbaru.

Saat maintenance, lihat slow query log dan query paling sering dipanggil. Perhatikan halaman admin, export data, laporan periodik, dan endpoint pencarian. Empat area ini sering punya query yang tidak disadari mahal.

Tambahkan indeks berdasarkan pola WHERE, JOIN, dan ORDER BY yang benar-benar dipakai.
Hindari memuat relasi besar tanpa pagination atau batas data.
Gunakan eager loading untuk mencegah masalah N+1 query.
Jalankan migrasi besar dengan strategi aman, terutama pada tabel aktif.
Uji restore backup secara berkala. Backup yang belum pernah direstore belum benar-benar terbukti berguna.

Untuk perubahan skema yang berisiko, misalnya menambah kolom wajib pada tabel besar, pecah langkahnya. Tambahkan kolom nullable dulu, isi data lama lewat job bertahap, pindahkan aplikasi ke kolom baru, baru kemudian perketat constraint jika memang diperlukan.

Jaga scheduler dan cron tetap terlihat

Laravel Scheduler memudahkan banyak hal: kirim laporan, bersihkan data sementara, sinkronisasi, hingga penagihan. Masalahnya, scheduler bisa berhenti tanpa ada yang sadar jika cron server berubah atau deploy mengganti konfigurasi.

Pastikan ada cron yang menjalankan php artisan schedule:run setiap menit, lalu catat atau monitor task penting. Untuk task yang tidak boleh tumpang tindih, gunakan withoutOverlapping(). Ini penting untuk proses seperti sinkronisasi marketplace atau generate laporan besar; dua proses berjalan bersamaan bisa menulis data ganda.

Deployment sebaiknya punya urutan yang tetap

Deployment manual masih bisa aman jika urutannya disiplin. Yang berbahaya adalah deploy sambil mengingat-ingat langkahnya. Buat runbook sederhana agar siapa pun di tim menjalankan prosedur yang sama.

Aktifkan mode maintenance bila perubahan tidak kompatibel dengan versi lama.
Ambil kode rilis dan install dependency dari lock file.
Jalankan migration yang sudah diuji.
Bangun cache aplikasi yang dibutuhkan.
Restart queue worker agar memakai kode baru.
Lakukan smoke test pada login, endpoint utama, proses transaksi, dan queue.
Pantau error serta antrean beberapa menit setelah rilis.

Restart worker sering terlupakan. Worker queue adalah proses panjang; tanpa restart, ia dapat tetap menjalankan kode sebelum deploy. Gunakan php artisan queue:restart atau mekanisme restart dari Horizon sebagai bagian wajib deployment.

Siapkan indikator sehat yang mudah dibaca

Aplikasi tidak harus punya dashboard observability yang mahal untuk bisa dirawat dengan baik. Mulai dari indikator sederhana: status uptime, error 5xx, durasi respons endpoint penting, jumlah failed jobs, panjang queue, penggunaan CPU/RAM/disk, dan status backup terakhir.

Kalau satu angka berubah drastis, baru lakukan investigasi. Pendekatan ini lebih masuk akal daripada membuka semua log setiap pagi. Tim juga lebih mudah membedakan mana gangguan sementara dan mana gejala masalah sistemik.

Penutup

Maintenance Laravel yang sehat itu membosankan dalam arti baik: rutinitasnya jelas, perubahan dilakukan terukur, dan masalah kecil tertangkap sebelum menjadi gangguan besar. Rawat queue, log, cache, database, scheduler, dan proses deploy sebagai satu kesatuan. Production jarang gagal karena satu command yang salah; biasanya karena beberapa sinyal kecil tidak sempat diperhatikan.