Aplikasi Laravel yang sudah live biasanya tidak runtuh karena satu bug besar. Lebih sering, masalah datang pelan-pelan: queue mulai menumpuk, log penuh error yang diabaikan, storage membengkak, cache menyimpan data lama, atau deploy kecil ternyata membuat worker berhenti memproses job.
Maintenance bukan pekerjaan yang dilakukan ketika server sudah merah. Ia perlu jadi kebiasaan operasional. Tujuannya sederhana: masalah kecil ketahuan sebelum mengganggu pengguna atau tim support.
1. Pisahkan pekerjaan harian, mingguan, dan berkala
Kesalahan yang cukup umum adalah membuat daftar maintenance panjang, lalu tidak ada yang menjalankannya karena terasa berat. Lebih realistis kalau tugas dibagi berdasarkan frekuensi.
- Harian: cek error aplikasi, status queue, job gagal, penggunaan disk, dan hasil backup terakhir.
- Mingguan: review performa endpoint penting, bersihkan data sementara, cek antrean email atau notifikasi, serta lihat dependency yang punya update keamanan.
- Bulanan: uji proses restore backup, audit akses admin, review cron, dan evaluasi kapasitas server.
Tidak semua poin harus dicek manual. Justru yang berulang sebaiknya diberi monitoring atau alert. Manusia biasanya telat sadar kalau harus membuka dashboard yang sama setiap pagi.
2. Perlakukan log sebagai sumber diagnosis, bukan tempat sampah
Laravel cukup mudah menghasilkan log, tetapi file laravel.log juga mudah berubah menjadi tumpukan pesan yang tidak pernah dibaca. Saat ada keluhan pengguna, tim akhirnya mencari jarum di gudang.
Gunakan channel log yang jelas untuk area penting, misalnya pembayaran, integrasi pihak ketiga, sinkronisasi data, dan autentikasi. Sertakan konteks yang relevan seperti ID pesanan atau ID pengguna, tetapi jangan pernah memasukkan password, token, nomor kartu, atau data sensitif lain ke log.
Di production, log sebaiknya diputar secara rutin dan dikirim ke tempat yang bisa dicari. Minimal, pastikan rotasi file berjalan. Pernah ada kasus disk server penuh hanya karena exception dari API eksternal terjadi ribuan kali dalam beberapa jam. Aplikasinya tidak langsung mati; beberapa layanan lain yang ikut memakai disk justru lebih dulu bermasalah.
3. Pantau queue dan worker dengan serius
Queue sering menjadi tulang punggung aplikasi Laravel: kirim email, ekspor laporan, proses gambar, webhook, sampai sinkronisasi marketplace. Karena prosesnya berjalan di belakang layar, gangguannya juga sering terlambat terlihat.
Yang perlu dipantau bukan hanya jumlah job di antrean. Perhatikan juga job gagal, durasi eksekusi, retry berulang, dan umur job paling tua. Jika job tertua sudah berumur puluhan menit padahal normalnya selesai dalam beberapa detik, ada sesuatu yang tersendat.
Pastikan worker dikelola process manager
Jangan mengandalkan terminal SSH yang menjalankan php artisan queue:work. Worker production perlu dijaga oleh Supervisor, systemd, atau platform process manager yang setara. Setelah deploy, worker juga perlu direstart dengan cara yang aman agar memakai kode terbaru.
Untuk aplikasi dengan antrean cukup ramai, Laravel Horizon membantu sekali karena status queue dan failed job lebih mudah dilihat. Tetapi dashboard bukan pengganti alert. Kalau antrean macet pukul dua pagi, dashboard yang bagus tidak banyak membantu bila tidak ada notifikasi.
4. Disiplin pada scheduler dan cron
Satu cron entry php artisan schedule:run per menit terdengar sepele, tetapi banyak proses bisnis bergantung padanya. Pengingat tagihan, sinkronisasi stok, penghapusan data sementara, dan laporan otomatis sering hidup di scheduler.
Tambahkan logging atau notifikasi untuk task penting. Jangan hanya menganggap task berjalan karena tidak ada error di layar. Kasus paling menyebalkan biasanya begini: cron mati setelah perubahan server, lalu baru ketahuan tiga minggu kemudian ketika data laporan sudah tertinggal jauh.
Task yang berat juga jangan dipaksakan selesai dalam satu proses scheduler. Lebih aman scheduler hanya memicu job ke queue, lalu worker menangani pekerjaan utama. Ini membuat waktu eksekusi lebih terkontrol dan risiko task saling bertabrakan lebih kecil.
5. Kelola cache dengan sadar konteks
Cache memang membuat aplikasi lebih cepat, tetapi ia juga sering menjadi penyebab data terlihat aneh setelah deploy. Konfigurasi lama, route yang belum terbarui, atau hasil query yang tersimpan terlalu lama bisa membuat tim mengira ada bug baru.
Gunakan cache untuk data yang memang mahal dihitung atau sering dibaca. Tetapkan masa berlaku yang masuk akal, dan pikirkan cara invalidasinya sejak awal. Cache tanpa strategi invalidasi biasanya baik-baik saja sampai data penting berubah.
Saat deployment, proses seperti cache config, route, dan view perlu konsisten dengan cara aplikasi dijalankan. Hindari menjalankan perintah optimasi secara asal di setiap kondisi. Contohnya, config:cache cocok di production, tetapi perubahan environment yang tidak diikuti rebuild cache bisa membuat perilaku aplikasi membingungkan.
6. Jadikan backup sebagai proses yang benar-benar bisa dipulihkan
Backup yang ada tetapi tidak pernah diuji belum tentu berguna saat dibutuhkan. File backup bisa korup, kredensial storage berubah, atau prosedur restore ternyata butuh langkah yang tidak terdokumentasi.
- Backup database secara terjadwal dan simpan di lokasi terpisah dari server aplikasi.
- Backup file penting seperti upload pengguna bila tidak memakai object storage yang sudah punya kebijakan retensi.
- Periksa hasil backup dan buat alert bila proses gagal.
- Lakukan simulasi restore secara berkala di lingkungan aman.
- Dokumentasikan urutan pemulihan, termasuk variabel environment dan proses migrasi bila diperlukan.
Uji restore memang tidak selalu nyaman dikerjakan, tetapi ini salah satu pekerjaan maintenance yang nilainya paling terasa ketika terjadi insiden.
7. Update dependency dengan ritme yang aman
Menunda pembaruan dependency terlalu lama membuat upgrade akhirnya menjadi proyek besar dan berisiko. Sebaliknya, update sembarangan langsung di production juga bukan kebiasaan sehat.
Praktiknya, pantau advisory keamanan untuk Laravel, PHP, package Composer, dan image server yang dipakai. Uji update di staging, jalankan test yang relevan, lalu deploy secara bertahap. Untuk package yang menyentuh autentikasi, pembayaran, file upload, atau integrasi eksternal, beri perhatian lebih.
Jangan lupa versi PHP. Kadang aplikasi masih berjalan, tetapi library baru sudah mulai memberi peringatan kompatibilitas. Memperbaiki ini saat masih kecil jauh lebih murah daripada menunggu sampai upgrade wajib dilakukan dalam kondisi terburu-buru.
8. Rawat database sebelum lambatnya terasa ke pengguna
Database jarang mendadak lambat tanpa tanda. Biasanya query bertambah, tabel log atau riwayat membesar, indeks kurang tepat, atau proses laporan mengambil terlalu banyak data sekaligus.
Review query lambat secara rutin. Untuk endpoint yang sering dipakai, cek apakah ada pola N+1 query, pagination yang buruk, atau filter yang belum punya indeks. Eloquent enak dipakai, tetapi tetap perlu diperiksa hasil query-nya ketika trafik mulai naik.
Data operasional seperti activity log, notifikasi lama, token kedaluwarsa, dan temporary export perlu punya kebijakan retensi. Tidak semua data harus disimpan selamanya di tabel utama. Arsipkan atau hapus dengan prosedur yang jelas sesuai kebutuhan bisnis dan kebijakan privasi.
9. Buat deployment yang bisa diprediksi
Deploy sehat bukan sekadar menjalankan git pull di server. Buat urutannya konsisten: ambil rilis, pasang dependency, jalankan migrasi yang aman, bangun cache yang diperlukan, restart worker, lalu cek health endpoint dan log.
Untuk perubahan database, pikirkan kompatibilitas antara kode lama dan baru. Menambah kolom biasanya aman. Menghapus kolom atau mengubah tipe data bisa berbahaya bila masih ada worker lama atau instance aplikasi lain yang memakai struktur sebelumnya.
Catatan kecil yang sering menyelamatkan waktu: simpan langkah rollback. Bahkan kalau jarang dipakai, mengetahui cara kembali ke rilis sebelumnya membuat keputusan saat insiden lebih tenang.
10. Siapkan checklist insiden yang sederhana
Ketika aplikasi bermasalah, orang cenderung mencoba banyak hal sekaligus. Akibatnya, jejak penyebabnya makin kabur. Checklist singkat membantu tim tetap fokus.
- Cek status aplikasi, server, database, queue, dan layanan pihak ketiga.
- Lihat error terbaru serta perubahan deploy terakhir.
- Identifikasi dampak pengguna dan area yang terdampak.
- Stabilkan layanan lebih dulu, misalnya rollback atau menonaktifkan proses yang bermasalah.
- Catat penyebab, perbaikan, dan tindakan pencegahan setelah insiden selesai.
Tidak perlu langsung membuat dokumen operasi setebal buku. Mulai dari kasus yang pernah benar-benar terjadi. Setelah dua atau tiga insiden, checklist biasanya mulai terbentuk dengan sendirinya.
Penutup
Maintenance Laravel di production pada dasarnya adalah latihan menjaga hal-hal kecil tetap terlihat. Log dibaca, queue tidak dibiarkan diam, backup diuji, dependency tidak ditumpuk bertahun-tahun, dan deployment punya jalur balik.
Kalau harus memilih titik awal, mulai dari tiga hal: monitoring error, kesehatan queue, dan backup yang bisa direstore. Tiga area ini sering memberi dampak terbesar tanpa perlu mengubah arsitektur aplikasi secara besar-besaran.
